Future Internet with Information Centric Networks Arsitektur Jaringan Terkini

Motivation

Motivation

Current Network

Motivation Networking was introduced for resource sharing Named hosts Model is point-to-point

The Problem ISP

Communication Vs Distribution Naming Endpoints Content Security Secure Process Secure Content

Motivation Movement of content Location orientation of content Predicted global IP traffic in 2014: 64 exabytes/month (4 fold from 2009) (1) 180 exabytes of content created in 2006 (2) Global mobile traffic will double every year (mostly streaming content) (2) Current solutions: P2P and CDNs Location orientation of content Content associated with named hosts Sender orientation Sender can send anywhere Securing content Point-to-point model TLS and SSL secures endpoints

Motivation Mobility and multi-homing Adaptation to disruptions Device mobility is the norm Multiple attachments Mobility currently based on routing or indirection Adaptation to disruptions Challenged networks – sparse connectivity, high-speed mobility, disruptions Problems with network based caching DRM issues Security

Known Architectures Architectures Operation Differentiation Sienna (Publish/Subscribe) Data Oriented Networking Architecture (DONA) Publish Subscribe Internet Routing Paradigm (PSIRP) Network of Information (NetInf) Content Centric Networking (CCN) Operation Differentiation Naming Security Routing Caching Content existence knowledge Producer-consumer meeting

Today Path determined by global routing, not local choice X dst src Today’s internet routing has issues with being a distribution system. There are only a few mechanisms needing change to transform the current Internet from the worst to the best distribution system. Path determined by global routing, not local choice Structural asymmetry precludes market mechanisms and encourages monopoly formation

NDN(Named Data Networking) related to CCN approach Producer ? a/b/c Consumer

NDN(Named Data Networking) related to CCN approach a/b/c/d Producer a/b/c/d ? a/b/c Data Consumer

NDN(Named Data Networking) related to CCN approach a/b Producer ? a/b/c/e Consumer Packets say ‘what’ not ‘where’ (no src or dst) Forwarding decision is local Upstream performance is measurable

We envision replacing this: ISP

With THIS: ISP Mobility is an issue with endpoint addresses, because they keep changing. In NDN, "Mobility is simply irrelevant” -- nothing associated with the communication changes with mobility. Rather than naming the moving object (receiver) as in IP, we name the content desired by that object. Clearly things get delivered where you were – not where you are. If you move and simply request them again, you get them from a cache only one or two hops away, assuming incremental mobility. ISP

Content Centric Networks – Operation Check Pending Interests Table Interest Data Check Content Store Check Pending Interests Table Check Forwarding Information Base

Content Centric Networks – Stack (1) Change of network abstraction from “named hosts” to “named content” Security built-in: secures content and not the hosts Mobility is present by design Can handle static as well as dynamic content Use of 2 messages: Interest and Data Object (1) Van Jacobson, et al, Networking Named Content, CoNEXT 2009

Content Centric Networks – Architecture Each CCN entity has 3 main data structures Content Store, Pending Interest Table, Forwarding Information Base Uses multicast/broadcast Uses “longest prefix matching” lookup for content names

Content Centric Networks – Messages Purpose of messages Interests request for content Data serves these requests No fixed length fields and uses an XML encoding format

Content Centric Networks – Names Core of CCN uses content names for forwarding Applications can interpret names the way they want

Content Centric Networks - CS Uses “longest prefix matching” Implements policies such as LRU or LFU for content replacement Content do not necessarily have to be persistent (only cached)

Content Centric Networks – PIT Uses “longest prefix matching” An entry may point to multiple faces Must time out and not held permanently

Content Centric Networks – FIB Uses “longest prefix matching” Similar to IP FIB Destination may have number of faces

Content Centric Networks – Interest

Content Centric Networks – Data

Routing Three general approaches Two phases Name Resolution Routing (NRR) Content-based Routing (CBR) Name-based routing (NBR) Two phases Routing of NDO requests Routing of NDO back to the requester

Name-Based Routing Client asks for a data object sending interest packets which are routed toward the publisher of the name prefix using longest-prefix matching in the forwarding information base (FIB) of each node. The FIB is built using routing protocols of the Internet. When a note receives multiple requests for the same NDO, only the first is forwarded to the source. When a copy of the data object is encountered on the path, a data packet containing the requested object is sent on the reverse path back to the client and all nodes along the path cache a copy.

Content Centric Network (CCN) Chart notes describe numbered steps Steps 1 – 3: A CCN router maintains a pending interest table (PTT) for outstanding forwarded requests, which enables request aggregation; that is a CCN router would normally not forward a second request for that particular NDO. The PIT maintains state for all interests and maps them to network interface where corresponding requests have been received from. Data is then routed back on the reverse request path using this state (steps 4 – 6). CCN supports on-path caching: NDOs a CCN router receives (in response to requests) can be cached so that subsequent received requests cof the same object can be answered from that cache (steps 7 – 8)

CCN packets There are two CCN packet types: interest (similar to http “get”) and data (similar to http response). Both are encoded in an efficient binary XML.

CCN node model Get /parc.com/videos/ WidgetA.mpg/v3/s2

Publish-Subscribe Internet Routing Paradigm (PSIRP) The structure can be seen as a data and control plane. The control place (topology system) creates distributed awareness of the structure of the network, similar to what today’s routing protocols do. On top of the topology system lies the rendezvous system which has the responsibility for matching between publishers and subscribers. Whenever it identifies a publication that has both a publisher (or an up to date cache) and one or more active subscribers, it requests the topology system to construct a logical forwarding tree from the present location(s) of the data to the subscribers and to provide the publisher (or caches) with suitable forwarding information for the data delivery. The data place takes care of forwarding functionality as well as traditional transport functions, such as error detection and traffic scheduling. A number of new network functions arise such as opportunistic caching and lateral error correction. Step 1: NDOs are published into the network by the NDO sources. Step 2: Receivers subscribe to NDOs. The subscription request specifies the scope identifier (SI) and the rendezvous identifier (RI) that together name the desired NDO. Step 3: The publications and subscriptions are matched by a rendezvous system. Step 4: The identifiers are input to a matching procedure resulting in a forwarding identifier (FI), which is sent to the NDO source. Steps 5 – 7: Source starts forwarding data to subscribers. Chart notes describe numbered steps

Content-based Publish-Subscribe Routing

Content-based Pub/Sub Routing

Content-based Pub-Sub Routing

Forwarding on Bloomed link ids The FI encodes the network links (rather than the nodes) on the path of interest between the producer and consumers FI is encoded in a probabilistic data structure called a Bloom filter that routers use for selecting interfaces on which to forward an NDO. Bloom filters encode source route-style forwarding information into packet headers, enabling forwarding without depending on end-to-end addressing. Routers do not need to keep forwarding state. Forwarding decisions are simple and forwarding tables are small, potentially allowing faster, smaller, and more energy-efficient switches. The use of Bloom filters result in a certain number of false positives; in this case this means forwarding on some interfaces where there are no receivers.

Pub/Sub Routing using Link ID and FI zFilter: FI Bloom Filter For each point to point link, two identifiers called Link IDs are asigned, one in each direction. A LinkID is an m-bit long name with just k bits set to one, with k<<m and m is relatively large. The topology system creates a graph of the network using LinkIDs and connectivity information. When it gets a request to determine a forwarding tree for a certain publication, it crates a conceptual delivery tree using the network graph and the location of the publishers and subscribers. Once it has such an internal representation of the tree, it knows which links the packets need to pass, and it determines when to use LinkIDs and where/when to create state. Source-routing approach encodes all LinkIDs of the tree into a Bloom Filter and place it into the packet header. Once all link IDs have been added to the filter, a mapping from the data topic identifier to the BF is handed to the note acting as the data source and can be used for data delivery along the tree. Note that this establishes a temporary binding between the Bloom Filter and the Topic ID of the Pub/Sub channel. When the interest of the source changes to a new topic the binding is no longer valid and has to be recomputed. See chart notes for further description

Network of Information In ICN there are two key functions that name resolution and routing must achieve when there is a request for a specific NDO. The first is to find a node that holds a copy of the NDO and deliver the request to that node (i.e., routing of NDO requests). The second is to find a path from that node back to the requester over which the NDO can be delivered (i.e. routing of NDOs). One way to do this is through a name resolution, which means that a resolution service is queried and one ore more lower-layer locators are returned. These locators can then be used to retrieve the object using a protocol like HTTP or direct IP. Name resolution might also include some steps that involve name-based routing, as when a Distributed Hash Table (DHT)-based name resolution is used. See for example: http://conferences.sigcomm.org/sigcomm/2012/paper/icn/p43.pdf

Name Resolution Routing Use a Name Resolution Service (NRS) that stores the bindings from object names to topology-based locators pointing to corresponding storage locations in the network. Three conceptual routing phases: Routing the request message to the responsible NRS node where the object name is translated into one or multiple source addresses Routing the request message to the source address(es) Routing the data from the source(s) to the requester. All phases can potentially use different routing algorithms. A name-based routing method might be used for the first phase. The second and third phases might use a topology-based routing like IP. There are multiple alternatives to loosely or tightly integrate the phases in an ICN architecture.

Summary of characteristics of the ICN approaches

Content-Based Security Name-content mapping verification via per-data packet signature Data packet is authenticated with digital signature ICN trust establishment by associating content namespaces w/ public keys

Basic ICN forwarding Consumer ‘broadcasts’ an ‘interest’ over any & all available communications media: get ‘/rutgers/ECE544/Lecture06-14.pdf’ Interest identifies a collection of data - all data items whose name has the interest as a prefix. Anything that hears the interest and has an element of the collection can respond with that data: HereIs ‘/rutgers/ECE544/presentation.pdf/p1’ <data>

Basic ICN transport Data that matches an interest ‘consumes’ it. Interest must be re-expressed to get new data. (Controlling the re-expression allows for traffic management and environmental adaptation.) Multiple (distinct) interests in same collection may be expressed (similar to TCP window).

Caching Storage for caching NDOs is an integral part of the ICN service. All nodes potentially have caches; requests for NDOs can be satisfied by any node holding a copy in the cache. ICN combines caching at the network edge as in P2P and other overlay networks with in-network caching (e.g., transparent web caches)

References A Survey of Information-Centric Networking, B. Ahlgren, et. al. IEEE Communications Magazine, July 2012 Named Data Networking. IEEE CCW. Oct 10, 2011. www.named-data. based on Van Jacobson Bloom Filters http://billmill.org/bloomfilter-tutorial/ http://en.wikipedia.org/wiki/Bloom_filter#Examples