Content Centric Networking Fred Baker

Agenda and comments I am commenting on networking research Paradigm: identifying and retrieving content, as opposed to talking with computers Multiple related projects: Van Jacobson (PARC) Content Centric Networking (CCN) Lixia Zhang (UCLA) Named Data Networking (NDN) European projects generally called Information-Centric Networking (ICN) Giovanna Carofiglio’s work at Alcatel-Lucent, Bell Labs, and Cisco gcarofig@cisco.com Numerous others… The big questions at Tical will be: Why? What? How to experiment with it?

CCN in a nutshell Today’s Internet Content Centric Networking (CCN) CCN advantages Ever-growing amount of digital info From point-to-point to (multi)point-to-multipoint info dissemination Connectivity diversity: multiple devices, heterogeneous networks Waste of resources in content replication! Simplified network management Traffic reduction and localization Seamless, ubiquitous connectivity Congestion reduction Effective Security Names not addresses Packet self-identification Packet self-certification Receiver-based transport Enhanced router storage Before… …After 3 3

Content names and packets Content items are identified by a unique name and are split into self-identified chunks (packets) CCN names are hierarchically structured to allow aggregation of routing and forwarding table entries. E.g. /BellLabs/ICN/talks/reality.avi/chunk0 CCN packets are of two types: Hierarchical naming scheme, content published in repositories, repositories annouce prefixes they can serve. Data is divided in chunks. A user expresses interest for every packet of the content.

CCN Communication Model /BellLabs/ICN/talks/reality.avi A B Interest H /BellLabs/ICN/talks/reality.avi/chunk0 Users generate Interest messages to request content chunk- by-chunk One Interest retrieves one specific content chunk (Data packet) Interests are routed towards permanent copies of the content Data is transmitted only in response to an Interest and follows reverse Interest path Intermediate nodes transparently cache in-transit Data packets

Name-based Routing Routing can be done in a similar fashion to today’s IP routing: Routers announce “name prefixes” covering data they are willing to serve Announcements are propagated through the network via a routing protocol Every router builds its Forwarding Information Base (FIB) Component-wise longest prefix match forwarding based on FIB information

CCN vs IP Forwarding CCN IP CCN FIB (Forwarding Information Base) is used to forward Interest packets toward potential sources. Almost identical to IP FIB. Content Store enhances buffer memory in an IP router and has a caching function: in-transit Data are stored in order to serve future requests and replaced only when the cache is full. PIT (Pending Interest table) keeps track of forwarded Interests. Only one entry per “similar” requests is kept. This entry is used to forward Data packets toward interested consumers.

CCN node operations Interest packet Data packet Lookup Content Store Lookup+Update(Add/Change entry) Pending Interest Table (PIT) Lookup Forwarding Information Base (FIB) Forwarding Data packet Lookup+Update(Remove entry) Pending Interest Table (PIT) Store in Content Store Forwarding Additional operations may be required to verify packets

CCN Transport imdb.com www.imdb.com/title/tt12242 www.imdb.com/title/tt12242 So the end-user emits a content request by requesting the first chunk with a named interest packet. The interest is forwarded upstream until tehe first hitting cache or the repo and each intermediate node keeps track of the pending interest in a structure called PIT. Once the data chunk is found it is sent back to the user following the reverse path of the interests. PIT entries play the role of the breadcrumbs allowing to build the reverse path. The data packet is then cached at each node before the user in order to serve subsequent requests for the same content. Interests are forwarded along named-based routes (RIB/FIB) Data are retrieved from the first hitting cache (Content Store) Chunks of a given content may be retrieved from multiple locations Interest aggregation on a pending interest (PIT)

CCN transport principles receiver based Receiver controls Interest rate for a content retrieval based on Data rate (window-based controller), performs loss and congestion control. natively multipath Interest may be forwarded along different routes according to different forwarding strategies. Chunks of the same content may be retrieved from different locations. coupled with in-path caching The sender endpoint is not known. On a path between user and a permanent copy of the content every intermediate node can send the content in response to an Interest.

Using CCN/NBN/ICN

Threads IoT Model Origin: Google Nest Enclave communicating with upstream service https://docs.mbed.com/docs/arm-ipv66lowpan-stack/en/latest/thread_overview/ Defined gateway (UDP/IPv6 <-> 6LowPAN) Security managed by architecture 6LowPAN within 802.15.4 network

Message Queue Telemetry Transport (MQTT): Similar model, but publish/subscribe Devices communicate with MQTT Gateway MQTT Gateway is intermediate or temporary data repository Powered devices: TLS/TCP Low power devices: DTLS/UDP, sleeping nodes Data is identified by message identifier Command to “the light bulbs on the second floor” Telemetry from “motion sensors on the second floor” Upstream application unaware of individual sensors or actuators Publish Subscribe Enclave communicating with upstream service

ICN: named data pull not push, and no sessions Sending commands for light bulbs on second floor, interested in telemetry from second floor motion sensors Enclave communicating with upstream service Devices communicate with content router advertising a class of names Router is intermediate or temporary data repository Data is identified by content name “Command for the light bulbs on the second floor” “Telemetry from motion sensors on the second floor” Upstream application may or may not be aware of individual sensors or actuators Any system may issue named messages Systems wanting to receive them send “interest” messages Interested in commands for light bulbs on second floor, sending telemetry from second floor motion sensors

Example application In a hospital, tracking patients Traditional model: Sensors in rooms Nursing station or other system monitoring sensors IP address, if used, is for a device in the room But is the room what is important? Probably not: probably the patient and data type are important The patient might move! Privacy – who should have access to patient data? Different types of sensors – who needs to know their data? So – name the data for the patient and the type of information And apply security policies around patient confidentiality

Sounds good, but what are the weaknesses? Predicting names! Scalabiliy of Inter-Domain Routing Traditional IP sends data when someone wants to send it And might send spam or malware ICN sends data that someone wants when they want to receive it If they can’t predict its existence or its name, that can be difficult Data that is predictably generated or in a repository works well Voice and video are current research topics

Discussion…