[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-irtf-icnrg-terminology

icnrg                                                        B. Wissingh
Internet-Draft                                                       TNO
Intended status: Informational                                   C. Wood
Expires: September 14, 2017              University of California Irvine
                                                            A. Afanasyev
                                                                L. Zhang
                                                                    UCLA
                                                                 D. Oran
                                       Network Systems Research & Design
                                                             C. Tschudin
                                                     University of Basel
                                                          March 13, 2017


           Information-Centric Networking (ICN): Terminology
                  draft-wissingh-icnrg-terminology-01

Abstract

   Information Centric Networking (ICN) is a new paradigm where network
   communications are accomplished by requesting named content, instead
   of sending packets to destination addresses.  Named Data Networking
   (NDN) and Content-Centric Networking (CCN) are two prominent ICN
   architectures.  This document provides an overview of the terminology
   and definitions that have been used in describing concepts in these
   two projects.  While there are other ICN architectures, they are not
   part of the NDN and CCN vision and as such are out of scope for this
   document.

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 September 14, 2017.






Wissingh, et al.       Expires September 14, 2017               [Page 1]


Internet-Draft               ICN Terminology                  March 2017


Copyright Notice

   Copyright (c) 2017 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  A Sketch of the Big Picture of ICN  . . . . . . . . . . . . .   3
   3.  Terms by category . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Generic terms . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Terms related to Name Types . . . . . . . . . . . . . . .   6
     3.3.  Terms related to Name Usage . . . . . . . . . . . . . . .   7
     3.4.  Terms related to Data-Centric Security  . . . . . . . . .   8
     3.5.  ICN Node related terms  . . . . . . . . . . . . . . . . .   9
     3.6.  Stateful forwarding plane related terms . . . . . . . . .  10
     3.7.  Specific solution related terms . . . . . . . . . . . . .  12
     3.8.  Uncategorized terms . . . . . . . . . . . . . . . . . . .  12
   4.  Semantics and Usage . . . . . . . . . . . . . . . . . . . . .  12
     4.1.  Data Transfer . . . . . . . . . . . . . . . . . . . . . .  13
     4.2.  Data Transport  . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Lookup Service  . . . . . . . . . . . . . . . . . . . . .  13
     4.4.  Database Access . . . . . . . . . . . . . . . . . . . . .  13
     4.5.  Remote Procedure Call . . . . . . . . . . . . . . . . . .  13
   5.  Informational References  . . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

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 accessing data by name becomes the
   essential network primitive.  The goal is to let applications refer
   to data independently of their location or means of transportation,
   which --for immutable data items-- enables native multicast delivery,
   ubiquitous in-network caching and replication of data objects.




Wissingh, et al.       Expires September 14, 2017               [Page 2]


Internet-Draft               ICN Terminology                  March 2017


   As the work on this topic continues to evolve, many new terms are
   emerging over time.  The goal of this document is to provide a
   thorough collection of these terms with a corresponding definition as
   they are used in the CCNx and NDN projects.  Other, historic ICN
   projects like NetInf, XIA or Mobility First are not covered and will
   be the subject of other documents.

   To help provide context for the individual terms to be defined, in
   this draft we first sketch the bigger picture of an ICN network by
   introducing the basic concepts and identifying the major components
   of 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 ICN

   In networking terms, an ICN is a delivery infrastructure for named
   data.  For other, complementing views see Section 4.

       requestor         zero or more           data sources or
       (node)          forwarding nodes         replica nodes
         |                 | ... |                  |...|
         |   Interest(n)   |     |   Interest(n)    |   |
         | --------------> |     | ---------------> |   |
         |                 |     | -------------------> |
         |                 |     |                  |   |
         |                 |     |  Data([n],c,[s]) |   |
         |                 |     | <--------------- |   |
         |                 |     | <------------------- |
         | Data([n],c,[s]) |     |                  |   |
         | <-------------- |     |                  |   |

   Figure 1: Request-Reply Protocol of ICN networking.  Legend: n=name,
                          c=content, s=signature.

   The following list describes the basic ICN concepts needed to discuss
   the implementation of this service abstraction.

   Request-Reply Protocol (Interest and Data Packet):

   An ICN's lookup service is implemented by defining two types of
   network packet formats: Interest packets that request content by
   name, and data packets that carry the requested content.  The
   returned data packet must match the request's parameters (e.g.,
   having a partially or fully matching name).  If the request is
   ambigious and several data packets would satisfy the request, the ICN
   network will typically return only one matching data packet.

   Packet and Content Names:



Wissingh, et al.       Expires September 14, 2017               [Page 3]


Internet-Draft               ICN Terminology                  March 2017


   Without an irrefutable binding between a name of a data packet and
   its content, data packet names would be useless for fetching specific
   content.  In ICN, verification of a data packet's name-to-content
   binding is achieved through cryptographic means, either by (1) a
   cryptographic signature that explicitely binds an application-chosen
   name to a data packet's content, or (2) relying on an implicit name
   (cryptographic hash of the data packet) that the data consumer
   obtained through other means.

   Data Authenticity and Encryption:

   Any data consumer and network element can validate the authenticity
   of a data packet by verifying its cryptographic name-to-content
   binding.  In contrast, whether a data packet's content (payload)
   itself is encrypted or not is irrelevant to the ICN network: The use
   and management of content encryption keys is an application-layer
   concern.

   Trust:

   Data authenticity is distinct from data trustworthiness, though the
   two concepts are related.  A packet is authentic if it has a valid
   name-to-content binding.  A packet is trustworthy, i.e., it comes
   from a reputable or trusted origin, if this binding is only valid in
   the context of a trust model.  For example, if a corresponding trust
   infrastructure (e.g., PKI) is in place, a packet's signature even
   enables to assess authenticity with relation to to real world
   identities which can be trusted or not.

   Segmenting and Versioning:

   An ICN network will be engineered for some packet size limit.  As
   application-level data objects will often be considerably larger,
   objects must be segmented into multiple data packets.  The names for
   these data packets can, for example, be constructed by choosing one
   application-level object name to which a different suffix is added
   for each segment.  The same method can be used to handle different
   versions of an application-level object by including a version number
   into the name of the overall object.

   Packet and Frame:

   NDN and CCN introduce Protocol Data Units (PDUs) which typically are
   larger than the maximum transmission unit of the underlying
   networking technology.  We refer to PDUs as 'packets' and the
   (potentially fragmented) packet parts that traverse MTU-bound links
   as 'frames'.  Handling link-layer technologies which lead to




Wissingh, et al.       Expires September 14, 2017               [Page 4]


Internet-Draft               ICN Terminology                  March 2017


   fragmentation of ICN packets is done inside the ICN network and is
   not visible at the service interface.

   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
   for some time before forwarding it to next node.  An ICN node may
   also run routing protocols to assist its interest forwarding
   decisions.


                      --> add ASCII art here
                      (of a forwarding node
                      and its PIT, FIB, CS)

              Figure 2: Structure of an ICN forwarding node.

   Forwarding Plane:

   The canonical way of implementing packet forwarding in an ICN network
   like NDN and CCN relies on three data structures that capture a
   node's state: 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.  There exist
   alternative approaches which aim at reducing the amount of state that
   a nodes must keep, up to fully PIT-less designs using packets for
   keeping state but without changing the overall service model.

3.  Terms by category

3.1.  Generic terms

      Information-Centric Networking (ICN): a networking architecture
      that retrieves data packets as response to interest packets.
      Content-Centric Networking (CCN) and Named Data Networking (NDN)
      are two types of ICN architectures.

      Data packet: a network-level packet that carries payload, uniquely
      identified by a name, and is directly secured.



Wissingh, et al.       Expires September 14, 2017               [Page 5]


Internet-Draft               ICN Terminology                  March 2017


         Common aliases include: data, data object, content object,
         content object packet, data message, named data object, named
         data.

      Interest packet: a network-level packet that expresses the request
      for a data packet using either an exact name or a name prefix.  An
      interest packet may optionally carry a set of additional
      restrictions (e.g. interest selectors).  An interest may be
      associated with additional information to facilitate forwarding
      and can include interest lifetime, hop limit, forwarding hints,
      labels, etc.  In different ICN designs, the set of additional
      associated information may vary.

         Common aliases include: interest, interest message, information
         request

      Data packet immutability: after a data packet is created, it
      cannot change.  If the content carried in the data packet is
      mutable, versioning should be used, so that each version uniquely
      identifies an immutable instance of the content.  This allows
      disambiguation of coordination in distributed systems.

3.2.  Terms related to Name Types

      Name: a data packet identifier.  An ICN name is expressive,
      flexible and can be application-specific (akin to a HTTP URL).  A
      Name may encode information about application context, semantics,
      locations (topological, geographical, hyperbolic, etc.), a service
      name, etc.  A Name is a sequence of non-empty name components (see
      below).  The components of a name are said to be complete if they
      uniquely identify a single data packet.  A Name is exact if its
      components are complete.

         Common aliases include: data name, interest name, content name.

      Name component: a sequence of octets and optionally a numeric type
      representing a single label in the hierarchical structured name.

         Common aliases include: name segment (as in CCN).

      Packet ID: a unique cryptographic identifier for a data packet.
      Typically, this is the cryptographic hash digest of a data packet,
      including its name, payload, meta information, and signature.

      Full Name: An exact Name with the Packet ID of the corresponding
      data packet.

      Prefix Name: A Name with incomplete components.



Wissingh, et al.       Expires September 14, 2017               [Page 6]


Internet-Draft               ICN Terminology                  March 2017


         Common aliases include: prefix.

      Selector: Depending on the implementation, some restrictors show
      up as name components or as explicit fields of an interest.
      Selectors are not 'names' in a proper sense although they are able
      to "name content."  Examples include selectors used to reference
      nameless objects, specify publisher restriction, etc.  In that
      sense, a single data packet will have multiple 'name-like
      properties' through which it can be referenced, interest packets
      are able to express them.

         Common aliases include: restrictor.

      Nonce: Field of an interest packet that transiently 'names' an
      interest instance.

3.3.  Terms related to Name Usage

      Naming scheme (ICN naming scheme): a convention/agreement/
      specification for the data packet naming.  Structures a name
      space.

      Hierarchically structured naming: the naming scheme that assigns
      and interprets name as a sequence of labels (name components) with
      hierarchical structure.  A structure provides useful context
      information for the name.

         Common aliases include: hierarchical naming, structured naming.

      Flat naming: the naming scheme that assigns and interprets name as
      a single label (name component) without any internal structure.
      This can be considered a special (or degenerated) case of
      structured names.

      Segmentation: a process of splitting large application content
      into a set of uniquely named data packets.  When using
      hierarchically structured name, each created data packet has a
      common prefix and additional component representing the segment
      (chunk) number.

         Common aliases include: chunking (as in CCN).

      Versioning: a process of assigning a unique name to the revision
      of the content carried in the data packet.  When using a
      hierarchically structured name, the version of the data packet can
      be carried in a dedicated name component (e.g., prefix identifies
      data, unique version component identifies the revision of the
      data).



Wissingh, et al.       Expires September 14, 2017               [Page 7]


Internet-Draft               ICN Terminology                  March 2017


      Fragmentation: a process of splitting data packets into frames so
      that they can be transmitted over the link with a smaller MTU
      size.

3.4.  Terms related to Data-Centric Security

      Directly secured data packet: a data packet with inherent security
      properties (authenticity and optionally confidentiality), i.e.,
      the security properties stay with the data packet regardless where
      it is stored and how it is retrieved.

      Data authenticator: a set of parameters carried in the data packet
      that is used to verify integrity and authenticity of the data
      packet.  The Data authenticator can include a cryptographic
      signature (RSA, ECDSA, HMAC, etc.), meta information about the
      signature (e.g., validity period), and additional information to
      facilitate signature verification (e.g., key locator, key ID, HMAC
      tag identifier, etc.)

         Common aliases include: content authenticator.

      Data confidentiality credentials: a set of parameters carried in
      the data packet that identify the needed algorithm and key
      identifiers to decrypt the confidential data.

      Key owner (same as Identity): an entity (user, device, program,
      program instance, module in the program instance, etc.) that owns
      private key(s) and the corresponding public key(s).

      Certificate: a data packet that carries a public key as payload
      with optional additional meta information regarding the key (e.g.,
      validity period, signature time, etc.).  Ownership of the public
      key is made implicitly through the name of the packet or
      explicitly through meta information.

      Key locator: Parameter(s) that identify the ICN key.  A key
      locatore can be the ICN key's name, its prefix, the ICN key ID,
      etc.

      Key ID: Unique identifier (e.g., hash digest) for a public or
      secret key.

      Trust model: a model or framework that defines trust
      relationships, i.e., which entity (represented by an ICN key) is
      authorized to sign which data packets.






Wissingh, et al.       Expires September 14, 2017               [Page 8]


Internet-Draft               ICN Terminology                  March 2017


      Trust schema: a formal description of a trust model, e.g., in the
      form of a set of name-based relationships between data and key
      names and a set of the trust anchors.

      Trust anchor: an ICN key that is assumed to be trusted within the
      context of a specific trust model.

      ICN key chain: a chain of ICN keys (certificates) wherein each key
      (certificate) is signed by its predecessor and the head of the
      chain is a trust anchor, i.e., its authenticity is assumed.

         Common aliases include: certificate chain.

3.5.  ICN Node related terms

      ICN Interface: a generalization of the network interface that can
      represent a physical network interface (ethernet, wifi, bluetooth
      adapter, etc.), an overlay inter-node channel (IP/UDP tunnel,
      etc.), or an intra-node IPC channel to an application (unix
      socket, shared memory, intents, etc.).

         Common aliases include: face.

      ICN Consumer: an ICN entity that requests data packets by
      generating and sending out interest packets towards local (using
      intra-node interfaces) or remote (using inter-node interfaces) ICN
      Forwarders.

         Common aliases include: consumer, information consumer, data
         consumer, consumer of the content.

      ICN Producer: an ICN entity that creates data packets and makes
      them available for retrieval.

         Common aliases include: producer, publisher, information
         publisher, data publisher, data producer.

      ICN Forwarder: an ICN entity that implements stateful forwarding.

         Common aliases include: ICN router.

      Data Mule: an ICN entity that temporarily stores and potentially
      carries an interest or data packet before forwarding it to next
      ICN entity.







Wissingh, et al.       Expires September 14, 2017               [Page 9]


Internet-Draft               ICN Terminology                  March 2017


3.6.  Stateful forwarding plane related terms

      Stateful forwarding: a forwarding process that records incoming
      interest packets in the PIT and uses the recorded information to
      forward the retrieved data packets back to the consumer(s).  The
      recorded information can also be used to measure data plane
      performance, e.g., to adjust interest forwarding strategy
      decisions.

         Common aliases include: ICN Data plane, ICN Forwarding.

      Name-based routing: a process of forwarding interest packets using
      the names in interests to guide the forwarding process

      ICN Pending Interest Table (PIT): a database that records received
      and not yet satisfied interests with the interfaces from where
      they were received.  The PIT can also store interfaces to where
      Interests were forwarded, and information to assess data plane
      performance.  Interests for the same data are aggregated into a
      single PIT entry.

      ICN Routing plane: an ICN protocol or a set of ICN protocols to
      exchange information about name space reachability.

      Reverse path forwarding: a process of forwarding the incoming data
      packet to the incoming interface(s) recorded in the corresponding
      PIT entry (entries) and removing the PIT entry (entries).

      Interest forwarding strategy: a module of the ICN stateful
      forwarding (ICN data) plane that implements a decision on where/
      how to forward the incoming interest packet.  The forwarding
      strategy can take input from ICN Forwarding Information Base
      (FIB), measured data plane performance parameters, and/or use
      other mechanisms to make the decision.

         Common aliases include: forwarding strategy.

      Satisfying an interest: overall process of returning content that
      satisfies the constraints imposed by the Interest, most notably a
      match in the provided name.  Four different flavors of "matching"
      are used in an ICN network, as described below.

      Interest match in FIB (longest prefix match): a process of finding
      a FIB entry with the longest name (in terms of name components)
      that is a prefix of the specified name.






Wissingh, et al.       Expires September 14, 2017              [Page 10]


Internet-Draft               ICN Terminology                  March 2017


      Interest match in PIT (exact match): a process of finding a PIT
      entry that stores the same as specified interest (including
      interest restrictions, if any).

      Data match in PIT (all match): a process of finding (a set of) PIT
      entries that can be satisfied with the specified data packet.

      Interest match in CS (any match): a process of finding an entry in
      router's content store that can satisfy the specified interest.

      Interest aggregation: a process of combining multiple interest
      packets for the same data into a single PIT entry.

         Common aliases include: interest suppression, interest
         collapsing.

      ICN Forwarding Information Base (FIB): a database that, for a set
      of prefixes, records a list of interfaces that can be used to
      retrieve data packets with names under the corresponding prefixes.
      The list of interfaces for each prefix can be ranked, and prefix/
      interfaces mapping , and interfaces can be associated with the
      additional information to facilitate forwarding strategy
      decisions.

      ICN Routing Information Base (RIB): a database that records a set
      of prefix-interface mappings that represent a candidate interface
      through which a data packet with the specified prefix can be
      retrieved.  RIB can be used to populate FIB.

      Interest Nack: a packet that contains the interest packet and
      optional annotation, which is sent by the router to the
      interface(s) the Interest was received from.  Interest Nack is
      used to inform downstream ICN nodes about inability to forward the
      included interest packet.  The annotation can describe the reason.

         Common aliases include: network NACK, interest return.

      Upstream forwarding: forwarding packets in the direction of
      interests (i.e., interests are forwarded upstream): consumer,
      router, router, ..., producer.

      Downstream forwarding: forwarding packets in the direction
      opposite of interest forwarding (i.e., data and interest nacks are
      forwarded downstream): producer, router, ..., consumer(s).

      In-network storage: a process of storing a data packet within the
      network (in routers opportunistic on-path caches, in dedicated on/
      off path caches, and managed in-network storage systems), so it



Wissingh, et al.       Expires September 14, 2017              [Page 11]


Internet-Draft               ICN Terminology                  March 2017


      can satisfy an incoming interest for this data packet.  The in-
      network storages can optionally advertise the stored data packets
      in the routing plane.

      Opportunistic caching (or on-path in-network caching or just
      caching): a process of temporarily storing a forwarded data packet
      in the router's memory (RAM or disk), so it can be used to satisfy
      future interests for the same data, if any.

      Managed caching (or off-path in-network storage): a process of
      temporarily, permanently, or scheduled storing of a selected (set
      of) data packet(s).

      Content Store (CS): a database on an ICN router that provides
      opportunistic caching.

      Managed in-network storage (repository, repo): an entity acting as
      an ICN producer that implements managed caching.

3.7.  Specific solution related terms

      Route-By-Name Routing (RBNR)

      Lookup-By-Name Routing (LBNR)

      Bread-crumbs routing

      Replication-by-name

      Routing Locator Signing

3.8.  Uncategorized terms

      Content based

      ICN API

      Information Centric Delay Tolerant Network

      Located-Named-Data

      Sessionless

4.  Semantics and Usage

   The terminology described above is the manifestation of intended
   semantics of NDN and CCN operations (what do we expect the network to




Wissingh, et al.       Expires September 14, 2017              [Page 12]


Internet-Draft               ICN Terminology                  March 2017


   do?).  In this section we summarize the most commonly proposed use
   cases and interpretations.

4.1.  Data Transfer

   The networking view of NDN and CCN is that the request/reply protocol
   implements a basic, unreliable data transfer service for single,
   named packets.

4.2.  Data Transport

   Data transfer can be turned into a data transport service for
   application-level objects by additional logic.  This transport logic
   must understand and construct the series of names needed to
   reassemble the segmented object.  Various flavors of transport can be
   envisaged (reliable, streaming, mailbox, etc)

4.3.  Lookup Service

   A more distributed systems view of the basic request/reply protocol
   is that NDN and CCN provide a distributed lookup service: Given a key
   value (=name), the service will return the corresponding value.

4.4.  Database Access

   The lookup service turns into a database access protocol by ...
   namespace design ... prefix standing for a collection ... The DB
   query expression must be encoded as a name.

4.5.  Remote Procedure Call

   More generally, ... parameters in the interest ... used e.g.  as
   command channel for remote control of neighbor routers.

5.  Informational References

   [I-D.irtf-icnrg-ccnxmessages]
              marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com,
              "CCNx Messages in TLV Format", draft-irtf-icnrg-
              ccnxmessages-03 (work in progress), June 2016.

   [I-D.irtf-icnrg-ccnxsemantics]
              marc.mosko@parc.com, m., Solis, I., and c. cwood@parc.com,
              "CCNx Semantics", draft-irtf-icnrg-ccnxsemantics-03 (work
              in progress), June 2016.






Wissingh, et al.       Expires September 14, 2017              [Page 13]


Internet-Draft               ICN Terminology                  March 2017


   [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", draft-irtf-icnrg-challenges-06
              (work in progress), March 2016.

   [I-D.irtf-icnrg-disaster]
              Seedorf, J., Arumaithurai, M., Tagami, A., Ramakrishnan,
              K., and N. Blefari-Melazzi, "Using ICN in disaster
              scenarios", draft-irtf-icnrg-disaster-00 (work in
              progress), 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", draft-irtf-icnrg-evaluation-
              methodology-05 (work in progress), 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", draft-irtf-
              icnrg-videostreaming-08 (work in progress), April 2016.

   [RFC7476]  Pentikousis, K., Ed., 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 2016,
              <http://www.rfc-editor.org/info/rfc7476>.





















Wissingh, et al.       Expires September 14, 2017              [Page 14]


Internet-Draft               ICN Terminology                  March 2017


Appendix A.  Acknowledgments

   Mark Mosco, ...

Authors' Addresses

   Bastiaan Wissingh
   TNO

   EMail: bastiaan.wissingh@tno.nl


   Christopher A. Wood
   University of California Irvine

   EMail: woodc1@uci.edu


   Alex Afanasyev
   UCLA

   EMail: aa@cs.ucla.edu


   Lixia Zhang
   UCLA

   EMail: lixia@cs.ucla.edu


   David Oran
   Network Systems Research & Design

   EMail: daveoran@orandom.net


   Christian Tschudin
   University of Basel

   EMail: christian.tschudin@unibas.ch











Wissingh, et al.       Expires September 14, 2017              [Page 15]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/