icnrg B. Wissingh
Internet-Draft TNO
Intended status: Informational C. Wood
Expires: January 9, 2017 PARC
L. Zhang
A. Afanasyev
D. Oran
Cisco Systems, Inc.
July 8, 2016

Information-Centric Networking: Terminology


Information Centric Networking (ICN) is a new paradigm where network communications are accomplished by requesting named content, instead of sending packets to destination addresses. This document provides an overview of the terminology and definitions that have been used in describing this new paradigm. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 9, 2017.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Information-centric networking (ICN) is an approach to evolve the Internet infrastructure from the existing host-centric design to a data-centric architecture where named data becomes the essential network primitive. The ICN design directly names and secures data objects, making them independent of their location or means of transportation, and enabling native multicast delivery and ubiquitous in-network caching and replication of data objects.

As the work on this topic continues to evolve, many new terms are born over time. The goal of this document is to provide a complete collection of these terms with a corresponding definition. To help provide the context of the individual terms to be defined, in this draft we first sketch the bigger picture of an ICN network, introducing the basic concepts and identifying the major components in the architecture in section 2 after which in section 3 ICN related terms are listed by different categories.

2. A Sketch of the Big Picture of an ICN Network Architecture

In an ICN network data is fetched by names. This is accomplished by defining two types of network packet formats: interest packets that request a piece of named content and data packets that carry the requested content. Every data packet must be cryptographically signed which binds its name and content together. A basic set of ICN concepts is listed below:

Data Naming:

Within ICN, the granularity of names is on a per packet basis. This implies that if the size of a piece of content from an application exceeds the network packet size limit, the content is segmented into multiple data packets. Each of these individual data packets is then uniquely named with the content name concatenated with the segment number.

Each ICN data packet is also immutable. This is accomplished by assigning a version number to each piece of application content. When the content changes, the version number in its name changes as well.

Data-Centric Security:

Security within ICN concerns data authentication, confidentiality, and user privacy. Each ICN data packet carries a signature that binds the name and content of the data packet together, allowing a named packet to be fetched from anywhere while the application is still able to verify the validity of the data packet.

ICN node:

A node within an ICN network can fulfill the role of a data producer, a data consumer, and/or a forwarder for interest and data packets. When a forwarder has connectivity to neighbor nodes, it performs interest and data packet forwarding in real time. It can also behave like a packet mule, that is it may carry an interest or data packet over some distance before forwarding it to next node. An ICN node may also run routing protocols to assist its interest forwarding decisions.

Stateful forwarding plane:

Generally speaking, an ICN forwarder keeps three data structures: a Forwarding Interest Table (FIB), a Pending Interest Table (PIT), and a Content Store (CS). It also utilizes interest forwarding strategies which takes input from both FIB and measurements to make interest forwarding decisions. When a node receives an ICN interest packet, it checks its CS and PIT to find a matching name; if no match is found, the node records the interest in its PIT and forwards the interest to the next hop(s) towards the requested content based on the information in its FIB.

3. Terms by category

3.1. Generic terms

3.2. Data naming related terms

3.3. Data-Centric Security related terms

3.4. ICN Node related terms

3.5. Stateful forwarding plane related terms

3.6. Specific solution related terms

3.7. Uncategorized terms

4. Informational References

[I-D.irtf-icnrg-ccnxmessages] marc.mosko@parc.com, m., Solis, I. and c. cwood@parc.com, "CCNx Messages in TLV Format", Internet-Draft draft-irtf-icnrg-ccnxmessages-03, June 2016.
[I-D.irtf-icnrg-ccnxsemantics] marc.mosko@parc.com, m., Solis, I. and c. cwood@parc.com, "CCNx Semantics", Internet-Draft draft-irtf-icnrg-ccnxsemantics-03, June 2016.
[I-D.irtf-icnrg-challenges] Kutscher, D., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T. and M. Waehlisch, "ICN Research Challenges", Internet-Draft draft-irtf-icnrg-challenges-06, March 2016.
[I-D.irtf-icnrg-disaster] Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan, K. and N. Blefari-Melazzi, "Using ICN in disaster scenarios", Internet-Draft draft-irtf-icnrg-disaster-00, February 2016.
[I-D.irtf-icnrg-evaluation-methodology] Pentikousis, K., Ohlman, B., Davies, E., Spirou, S. and G. Boggia, "Information-centric Networking: Evaluation and Security Considerations", Internet-Draft draft-irtf-icnrg-evaluation-methodology-05, April 2016.
[I-D.irtf-icnrg-videostreaming] cedric.westphal@huawei.com, c., Lederer, S., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, N., Timmerer, C., Posch, D., aytav.azgin, a. and S. (Will), "Adaptive Video Streaming over ICN", Internet-Draft draft-irtf-icnrg-videostreaming-08, April 2016.
[RFC7476] Pentikousis, K., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A. and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015.

Appendix A. Acknowledgments

The authors would like to thank Christian Tschudin for providing suggestions on the structure of the document and some of the ICN related terms.

Authors' Addresses

Bastiaan Wissingh TNO EMail: bastiaan.wissingh@tno.nl
Christopher Wood PARC EMail: christopher.wood@parc.com
Lixia Zhang UCLA EMail: lixia@cs.ucla.edu
Alex Afanasyev UCLA EMail: aa@cs.ucla.edu
David Oran Cisco Systems, Inc. EMail: oran@cisco.com