Network Working Group                                        D. Kutscher
Internet-Draft                                                       NEC
Intended status: Standards Track                              S. Farrell
Expires: August 14, 2013                                       E. Davies
                                                  Trinity College Dublin
                                                       February 10, 2013


                          The NetInf Protocol
                  draft-kutscher-icnrg-netinf-proto-01

Abstract

   This document defines a conceptual protocol and corresponding node
   requirements for NetInf nodes in a NetInf network.  A NetInf network
   offers an information-centric paradigm that supports the creation,
   location, exchange and storage of Named Data Objects (NDOs).  NetInf
   nodes can provide different services to other NetInf nodes, e.g.,
   forwarding requests for information objects, delivering corresponding
   response messages, name resolution services etc.  This (abstract)
   protocol is intended to be run over some "convergence layer" that
   handles transport issues.  Two "wire" formats are defined, one that
   uses HTTP for message transfer and one layered on UDP.

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 August 14, 2013.

Copyright Notice

   Copyright (c) 2013 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



Kutscher, et al.         Expires August 14, 2013                [Page 1]


Internet-Draft               NetInf Protocol               February 2013


   (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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Principles and Assumptions . . . . . . . . . . . . . . . . . .  3
   3.  Convergence Layer Architecture . . . . . . . . . . . . . . . .  5
   4.  The NetInf Protocol - Overview . . . . . . . . . . . . . . . .  7
   5.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  GET/GET-RESP . . . . . . . . . . . . . . . . . . . . . . .  9
     5.2.  PUBLISH/PUBLISH-RESP . . . . . . . . . . . . . . . . . . . 11
     5.3.  SEARCH/SEARCH-RESP . . . . . . . . . . . . . . . . . . . . 13
   6.  Convergence Layer Specifications . . . . . . . . . . . . . . . 14
     6.1.  HTTP CL  . . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.2.  UDP CL . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21


























Kutscher, et al.         Expires August 14, 2013                [Page 2]


Internet-Draft               NetInf Protocol               February 2013


1.  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.  [RFC2119]

   Syntax definitions in this memo are specified according to ABNF
   [RFC5234].

   There is an open-source implementation available that implements
   (most of) this.  See http://sourceforge.net/projects/netinf/ for code
   and http://village.n4c.eu/getputform.html for access to a test
   server.


2.  Principles and Assumptions

   A NetInf network provides an information-centric networking (ICN)
   environment in which units of data content can be identified and
   accessed using a URI-based naming scheme.  NetInf nodes in a NetInf
   network support the creation, location, exchange and storage of these
   units of content.  In order to support interoperable implementation
   of the NetInf design, [ref.netinf-db2] [ref.netinf-db3] the following
   assumptions are made here:

   o  all nodes can take on all NetInf roles (but do not have to);

   o  as necessary, nodes may access a Name Resolution System (NRS)
      and/or a (possibly name based) message routing infrastructure for
      NetInf messages; and

   o  the NetInf protocol can be used directly to access content.

   The NetInf protocol operates on Named Data Objects (see
   [ref.netinf-db2]) referred to as NDOs.  An NDO is an ordered
   collection of octets associated with a name.  The NetInf protocol is
   designed to cache, locate and transmit complete NDOs.

   The NetInf protocol is specified so that NDOs can in principle be
   retrieved from nodes anywhere in the network to which messages can be
   routed.  This routing is intended to be driven by the names of the
   NDOs, with the option to use an NRS, but this specification does not
   discuss how routing, nor calling to an NRS, is carried out.  Routing
   will also depend on the underlying Convergence Layer protocol (see
   Section 3) in use at that node.

   Nodes offering NetInf services may return locators in some cases.
   These locators designate network locations where an NDO might



Kutscher, et al.         Expires August 14, 2013                [Page 3]


Internet-Draft               NetInf Protocol               February 2013


   potentially be available for retrieval, but locators may not be
   usable outside of some (possibly hard-to-characterise) domain, or for
   more than a limited period of time, due to mobility of nodes or time
   limited access through "pinholes" in middleboxes such as firewalls
   and Network Address Translators (NATs).  Accordingly, a design goal
   is to enable preferential use of names, with locators mostly as hints
   to improve efficiency.  For this reason one can argue that locators
   ought not be made available to applications using the NetInf protocol
   in a form that would allow them to try to use the locator outside the
   NetInf protocol.  NDOs may have multiple locators in order to
   indicate specific interfaces or to reflect attachment to multiple
   addressing domains.  Locators also typically map to a specific
   instance (copy) of an NDO residing at a given host.

   Locators are an example of NDO associated data that may be stored in
   association with the data content of the NDO.  Other types of such
   data include "metadata" relating to the data content of the NDO,
   information describing the history of the copy of the NDO in the node
   where it is stored and search terms that are applicable to the NDO
   content.  The term "affiliated data" will be used to describe the
   overall set of data, other than the actual octets of the content,
   stored or transmitted in association with an NDO.  This affiliated
   data could be described as metadata of the NDO but we will reserve
   that term for a subset of the affiliated data that is usually
   constructed by the publisher of the NDO describing the content data
   of the NDO that is sent out in tandem with the data content.  The
   NetInf protocol allows this affiliated data to be transmitted, in
   whole or in part, in association with NetInf messages.

   NDO names will often be based on hash-function output values, and
   since the preferred hash-function will change over time and may
   change depending on location, this implies that NDOs can also have
   more than one name.  There may also be cases where truncated hash
   values are desired (e.g., in cases where packets must be kept below
   some small size and fitting an entire request into one packet is
   required), and in such cases collisions will occur, or can easily be
   generated by bad actors.  There are also cases where it is desirable
   to use a name to refer to some "dynamic" NDO, whose octets change
   (e.g., perhaps the current weather report) and there are
   cryptographic methods for doing this.  This all means that there is
   no strict 1:1 mapping between names and NDOs, however, we do expect
   that for most objects, for most ICN deployments, there will in
   practice be one NDO that is named by each name.  That is, each name
   usually does refer to just one object, and this protocol is designed
   to work best for that case.

   The following NetInf services are assumed to be implemented on nodes
   through the NetInf protocol:



Kutscher, et al.         Expires August 14, 2013                [Page 4]


Internet-Draft               NetInf Protocol               February 2013


   o  caching of NDOs, both locally originated and acquired through
      network operations with the NetInf protocol;

   o  requesting the fetching of an NDO using its name, possibly with
      the addition of a locator, from elsewhere in the network;

   o  responding to NetInf protocol NDO fetch operations using a name
      referring to one of its locally known NDOs, which may have been
      locally generated or acquired from another NetInf node and cached
      here, by returning either or both of the data named in the
      operation or affiliated data including locator(s) referring to a
      node where that NDO is (assumed to be) available;

   o  initiating a search for NDOs matching specified search criteria;

   o  responding to search requests received by determining if any
      locally known NDOs meet the search criteria according to locally
      determined algorithms;

   o  NDO publication via sending out the name and, optionally, either
      or both of the content data and some affiliated data, such as
      locators, to other nodes;

   o  according to locally determined policy, the ability to accept or
      reject NDO publication requests that are delivered to the node,
      and to cache either or both of the objects and/or information
      about those that are accepted;

   o  according to locally determined policy, after carrying out local
      processing, the ability to forward NetInf messages to other nodes
      or discard them;

   o  managing the data affiliated with the NDO as well as the content
      data; and

   o  local cache management, driven by local policy and (optionally)
      whatever cache directives are carried in NetInf messages.


3.  Convergence Layer Architecture

   The idea of the Convergence Layer (CL) is to provide a means to
   transport NetInf messages between pairs of nodes that offer NetInf
   services.  Any protocol that allows NetInf messages to be passed
   without loss of information can be used as a NetInf Convergence Layer
   (NetInf-CL) protocol.

   This document does not cover the bit-level specification of any CL



Kutscher, et al.         Expires August 14, 2013                [Page 5]


Internet-Draft               NetInf Protocol               February 2013


   protocol.  The individual CL protocols will provide their own
   specification regarding their bit-level format.

   Different CLs can be used in the various regions forming a global
   NetInf network.  Where a message has to pass through several
   intermediate NetInf-capable nodes from source to destination, the
   NetInf protocol layer at each node is responsible for selecting the
   appropriate link and CL to forward messages.

   Each CL has to offer the following minimal set of capabilities:

   o  unidirectional point-to-point transport of NetInf messages from
      source to destination,

   o  preservation of message boundaries,

   o  reliable transmission of message octets, and

   o  in-order delivery of message octets to the destination node.

   If an underlying protocol used by a particular CL cannot offer these
   capabilities natively, then the CL is responsible for synthesising
   these capabilities by appropriate means, e.g., use of retransmission
   or insertion of sequence numbers.  However, this does not prevent a
   CL that uses a more capable underlying protocol from implementing
   additional capabilities, e.g., bidirectional connections that allow a
   single connection to send NDOs in both directions.

   The CL itself does not specify the properties of the messages, how
   they are interpreted, and the way nodes should interact with them, as
   that is what is specified in the present document.

   The CL architecture is inspired by, and similar to, the concept used
   in Delay-Tolerant Networking.  [RFC4838][RFC5050].

   However, in contrast to DTN-CLs, the NetInf-CL concept does not
   include the handling of fragments of an NDO "above" the CL.  This is
   the main difference between the CL concept as used in DTNs and ICNs.
   Put another way, a DTN-CL may result in a bundle being fragmented,
   and those fragments are only re-assembled at the final bundle
   destination.  In the case of an NetInf-CL, if an NDO is fragmented or
   chunked within the CL, then those fragments or chunks are reassembled
   at the next ICN node and that fragmentation or chunking is not
   visible to the ICN protocol.  One can also consider that the DTN
   Bundle Protocol (BP)[RFC5050], which runs over a DTN-CL, can itself,
   with an appropriate extension such as the "BPQ" extension,
   [I-D.farrell-dtnrg-bpq] be an NetInf-CL.  That is, a concrete
   instance of this protocol could use the BP with the BPQ extension as



Kutscher, et al.         Expires August 14, 2013                [Page 6]


Internet-Draft               NetInf Protocol               February 2013


   an NetInf-CL.


4.  The NetInf Protocol - Overview

   This protocol assumes that NDOs are named using URIs, and in
   particular via the "ni" URI scheme [I-D.farrell-decade-ni] which MUST
   be supported.  There are a set of extensions to the "ni" URI scheme
   [I-D.hallambaker-decade-ni-params] that MAY be supported by nodes.
   However, other URI forms MAY also be used in the NetInf protocol, in
   particular as locators, and nodes SHOULD support at least fetching of
   "http" URLs.

   Nodes are assumed to be capable of discriminating between names and
   locators, based on the URI scheme or otherwise.

   The most common operations for a NetInf node will be fetching (using
   a GET message) an NDO or responding to such queries.  The response to
   the GET message will, if possible, contain the octets making up the
   specified NDO and MAY contain

   o  one or more URIs (typically locators) that could subsequently be
      used to retrieve the octets of the NDO either via this NetInf
      protocol or by alternative, locator-specific, means, and/or

   o  other affiliated data such as metadata relevant to the NDO.

   There are some circumstances in which it MAY be appropriate for the
   response to the GET message to contain only one or more locators and,
   optionally, other affiliated data.  Examples of this situation occur
   if the responding node is aware that the object content can be
   returned more effectively using an alternative protocol or from an
   alternative source because of bandwidth limitations on the links
   connecting the responding node.

   In addition to GET, there is the analagous PUBLISH operation where
   one node sends URIs and/or NDO octets to another.  There is also a
   SEARCH operation, where one node submits a search query and receives
   a set of URIs and optional meta-data in response.

   GET, PUBLISH and SEARCH messages MAY be forwarded by any node that
   receives them if there is good reason and local policy indicates that
   this would not result in excessive usage of network resources.

   If a request message is forwarded, then a response message MUST NOT
   be sent for that request while the overall "transaction" is still in
   progress.  That is, a node that forwards a request does not answer
   that request itself until it gets an answer from elsewhere.



Kutscher, et al.         Expires August 14, 2013                [Page 7]


Internet-Draft               NetInf Protocol               February 2013


   Response messages MUST be forwarded by routers to the node from which
   the corresponding request message was received.  The routing
   mechanisms that are used to ensure responses are correctly forwarded
   in this way are not specified here.

   Since this specification does not determine how message routing, nor
   use of an NRS is done, we do not otherwise specify how or when
   messages are to be forwarded.

   Nodes that want to make a locally stored NDO available with a
   specific name can use the PUBLISH message to announce that data to
   the network.  This message MAY "push" the octets of the NDO into
   other nodes' caches.  (If those nodes are willing to take them.)  The
   reasoning behind this is that in many circumstances pushing just a
   name or a locator will not be helpful because the node with the NDO
   may be located behind a middlebox that will not allow access to the
   data from "outside."  Pushing the complete NDO to a node that is
   accessible from the originating node but is also accessible from
   outside the middlebox "interior," can allow global access, e.g., by
   caching the NDO on a server in the DMZ ("DeMilitarized Zone") of an
   enterprise network or in a server provided by a home user's
   ISP.(Internet Service Provider).  The publisher MAY also push
   affiliated data for the NDO, including additional locators and
   content metadata that can be stored in a node's NDO cache.  The
   caching node MAY choose to store just the affiliated data without the
   content data depending on local policy.

   As in the case of routing messages generally, this specification does
   not determine the node(s) to which an NDO can be "pushed."

   Finally, NetInf nodes can send a SEARCH message to other NetInf
   nodes.  In response, a NetInf node can perform a local search (i.e.,
   of its local cache) As a response, any of the NetInf nodes that
   receives the SEARCH message returns a set of "ni" URIs of objects
   matching the search query.  It may also return other types of URI
   such as "http" URIs.  Searching of a node's local cache is the main
   goal for the SEARCH operation, but if a set of nodes were to forward
   SEARCH messages, then a global search (e.g., a Google-like service)
   service could be offered.

   NDOs together with any affiliated data are represented using MIME
   objects.  [RFC2045].  Placing as much of the affiliated data linked
   to the NDO in a multipart MIME object along with the octets of the
   actual object allows for significant specification and code re-use.
   For example, we do not need to invent a new typing scheme nor any
   associated registration rules nor registries.

   As an example we might have a MIME object of that is multipart/mixed



Kutscher, et al.         Expires August 14, 2013                [Page 8]


Internet-Draft               NetInf Protocol               February 2013


   and contains image/jpeg and application/json body parts, with the
   named image in the former and loosely structured associated data in
   the latter.  The "ni" scheme parameters draft discusses such
   examples.  This means that the details of the verification of name-
   data integrity supported by the ni name scheme also depend on the
   MIME type(s) used.

   MIME also simplifies the specification of schemes that make use of
   digital signatures, reusing techniques from existing systems
   including Secure MIME (S/MIME) [RFC5751]and the Cryptographic Message
   Syntax (CMS) [RFC5652].

   Note that (as specified in [I-D.farrell-decade-ni]) two "ni" URIs
   refer to the same object when the digest algorithm and values are the
   same, and other fields within the URI (e.g., the authority) are not
   relevant.  Two ni names are identical when they refer to the same
   object.  This means that a comparison function for ni names MUST only
   compare the digest algorithms and values.


5.  Protocol Details

   We define the GET, PUBLISH and SEARCH messages in line with the
   above.  GET and PUBLISH MUST be supported.  SEARCH SHOULD be
   supported.  Each message has an associated response.

   This means that GET and PUBLISH MUST be implemented and SEARCH SHOULD
   be implemented.  In terms of services, GET and PUBLISH SHOULD be
   operational but SEARCH MAY be turned off.

5.1.  GET/GET-RESP

   The GET message is used to request an NDO from the NetInf network.  A
   node responding to the GET message would send a GET-RESP that is
   linked to the GET request using the msg-id from the GET message as
   the msg-id for corresponding GET-RESP messages if it has an instance
   of the requested NDO.

   The "ni" form or URI MUST be supported.  Other forms of URI MAY be
   supported.

   The msg-id SHOULD be chosen so as to be highly unlikely to collide
   with any other msg-id and MUST NOT contain information that might be
   personally identifying, e.g., an IP address or username.  A
   sufficiently long random string SHOULD be used for this.

   The ext field is to handle future extensibility (e.g., for message
   authenticators) and allows for the inclusion of a sequence of type,



Kutscher, et al.         Expires August 14, 2013                [Page 9]


Internet-Draft               NetInf Protocol               February 2013


   length value tuples.  No extensions for GET messages are defined at
   this point in time.


   get-req = GET msg-id URI [ ext ]
   get-resp =  status msg-id [ 1*URI ] [ ext ] [ object ]

   ext = json-coded-string


                   Figure 1: GET/GET-RESP Message Format

   Any node that receives a GET message and does not have an instance of
   the NDO referenced in the message MUST either

   o  forward the message to another node, or

   o  generate a GET response message with an appropriate status code
      and the msg-id from the GET message as the response msg-id.

   If the message is forwarded, the node SHOULD maintain state that will
   allow it to generate the GET response message if a matching response
   message is not received for forwarding within a reasonable period of
   time after the GET message was forwarded.

   If the node has an instance of the NDO, the response MAY contain zero
   or more URIs that MUST be either locators for the specified object or
   else alternative names for that object.  If the receiving node has a
   copy of the relevant object in its cache it SHOULD include the object
   in the response.  Possible reasons for not including the object would
   include situations where the GET message was received via a low-
   bandwidth interface but where the node "knows" that returning a
   locator will allow the requestor faster access to the object octets.
   Alternatively, the node may only be maintaining the affiliated data
   for the NDO and not the content data if it has not yet received the
   content data or has discarded it due to cache size limitations.

   The object MUST be encoded as a MIME object.  If there is affiliated
   data linked to the object this MUST also be encoded using MIME and
   integrated with the object in a multipart/mixed MIME object.

   If the receiving node does not have a cached copy of the object it
   MAY choose to forward the message depending on local policy.  Such
   forwarding could be based on name-based routing, on an NRS lookup or
   other mechanisms (e.g. a node might have a default route).

   If an get-resp is received with an object that is not MIME encoded or
   of an unknown MIME type then that MUST be treated as an application/



Kutscher, et al.         Expires August 14, 2013               [Page 10]


Internet-Draft               NetInf Protocol               February 2013


   octet-stream for the purposes of name-data integrity verification.

   get-resp messages MAY include extensions as with all others.

5.2.  PUBLISH/PUBLISH-RESP

   The PUBLISH message allows a node to push the name, and optionally,
   alternative names, locators, a copy of the object octets and/or
   object meta-data.  Ignoring extensions, only a status code is
   expected in return.

   A msg-id MUST be included as in a GET message.

   A URI containing a name MUST be included.  The "ni" URI scheme SHOULD
   be used for this name.

   The message MAY also contain additional URIs that represent either
   alternative names or locators where the identical object can be found
   and metadata relating to the published content.  As mentioned in
   Section 4 it is the responsibility of the receiving node to
   discriminate between those URIs used as names and those used as
   locators.

   The object octets MAY be included.  This is intended to handle the
   case where the publishing node is not able to receive GET messages
   for objects.  An implementation SHOULD test (or "know") its local
   network context sufficiently well to decide if the object octets
   ought to be included or not.  Methods for checking this are out of
   scope of this specification.

   A node receiving a PUBLISH message chooses what information from the
   message, if any, to cache according to local policy and availability
   of resources.  It is RECOMMENDED that a node that receives a PUBLISH
   message containing the object octets verify that the digest in the
   name under which the content is published matches with the digest of
   the received data.

   One way to "fill a cache" if the object octets are not included in
   the PUBLISH would be for the recipient of the PUBLISH to simply
   request the object octets using GET and cache those.  (There is no
   point in sending a PUBLISH without the octets and without any
   locator.)  This behaviour is, of course, an implementation issue.

   In some cases it may make sense for a (contactable) node to only
   publish the name and metadata about the object.  The idea here is
   that the metadata could help with routing or name resolution or
   search.  Since we are representing both NDO octets and affiliated
   data such as the metadata as MIME objects, we need to tell the



Kutscher, et al.         Expires August 14, 2013               [Page 11]


Internet-Draft               NetInf Protocol               February 2013


   receiver of the PUBLISH message whether or not that message contains
   the full object.  We do this via the "full-ndo-flag" which, if
   present, indicates that the PUBLISH message contains enough data so
   the receiver of the PUBLISH message has sufficient data to provide a
   complete answer a subsequent GET message for that name, i.e., data
   content and affiliated data.

   If a node receives a PUBLISH message for an NDO which already exists
   in its cache, the received information SHOULD be used to complete or
   update the node's cached information for the NDO:

   o  If the object octets are included and the node currently does not
      have the octets cached, the data content MAY be added to the
      cache.  Again it is RECOMMENDED that the received data has the
      correct digest as specified in the NDO name, and

   o  Items in the affiliated data MAY be merged into cached affiliated
      data, including adding additional locators to the list of known
      locators for the NDO and merging any content metadata with
      previously received metadata.  If there is a conflict, the choice
      of metadata to be stored is a matter of policy.

   It is RECOMMENDED that a timestamp be recorded whenever the cached
   information for an NDO is updated and that this timestamp be stored
   in the affiliated data and the most recent timestamp returned with
   any subsequent GET or SEARCH request that references the NDO.

   Extensions ("ext") MAY be included as in a GET request.  One such
   HTTP CL-specific extension ("meta") is defined in Section 6.1 below.


   pub-req = PUBLISH msg-id 1*URI [ ext ] [ [ full-ndo-flag ] object ]
   pub-resp = status msg-id [ ext ]


               Figure 2: PUBLISH/PUBLISH-RESP Message Format

   The response to a PUBLISH message is a status code and the msg-id
   from the PUBLISH message and optional extensions.

   A node receiving a PUBLISH message MAY choose to forward the message
   to other nodes whether or not it chooses to cache any information.
   If this node does not cache the information but does forward the
   PUBLISH message, it should postpone sending a response message until
   a reasonable period of time has elapsed during which no other
   responses to the PUBLISH message are received for forwarding.
   However, the node MAY send an extra response message, even if it
   forwards the PUBLISH message, if the sender of the PUBLISH message



Kutscher, et al.         Expires August 14, 2013               [Page 12]


Internet-Draft               NetInf Protocol               February 2013


   would have expected the receiving node to cache the object (e.g.,
   because of a contractual relationship) but it was unable to do so for
   some reason.

5.3.  SEARCH/SEARCH-RESP

   The SEARCH message allows the requestor to send a set of query tokens
   containing search keywords.  The response is either a status code or
   a multipart MIME object containing a set of metadata body parts, each
   of which MUST include a name for an NDO that is considered to match
   the query keywords.


   search-req = SEARCH msg-id [ 1*token ] [ ext ]
   search-resp = status msg-id [ results ] [ ext ]


                Figure 3: SEARCH/SEARCH-RESP Message Format

   In the case where the response contains results, these MUST take the
   form of an application/json MIME object containing an array of
   results.  Each result MUST have a "name" field with a URI as the
   value of that field.  Any other fields in array elements SHOULD
   contain metadata that is intended to allow the requestor to select
   which, if any, of the names offered to retrieve.

   The URIs included in a search-resp SHOULD be names, but MAY be
   locators, to be distinguished by the requestor as in the case of GET
   responses.

   The intent of the SEARCH message is to allow nodes to search one
   another's caches, but without requiring us to fix the details
   (ontology) for NDO content metadata.  While this main intended use-
   case does not involve forwarding of SEARCH messages that is not
   precluded.

   As with PUBLISH messages, if a SEARCH message is forwarded, the
   forwarding node postpones sending an empty SEARCH response until a
   reasonable time is elapsed to see if alternative node responds to the
   SEARCH.

   If a SEARCH at a node identifies an NDO that is included in the
   results of a search, the tokens that were used for the search MAY be
   recorded in the affiliated data cached with the NDO.  Each set of
   search tokens for which a "match" is obtained should be recorded
   separately resulting in an array of set of tokens.  If the search
   mechanisms used provides a reliability measure, this MAY also be
   recorded and the measure may be used to limit the size of the search



Kutscher, et al.         Expires August 14, 2013               [Page 13]


Internet-Draft               NetInf Protocol               February 2013


   tokens array by discarding (or never inserting) sets of tokens with
   low reliability scores.

   SEARCH messages MAY include extensions as for other messages.


6.  Convergence Layer Specifications

   This section specifies two convergence layers that represent
   instantiations of the NetInf protocol.  The first, based on HTTP, is
   intended for using NetInf in existing web infrastructures, whereas
   the second, based on UDP, provides an efficient datagram-based hop-
   by-hop message transport that can be used to query for GET requests
   sent to an NRS node or for multicasting such requests in a local
   network.

6.1.  HTTP CL

   The HTTP CL maps the NetInf protocol to HTTP, ensuring
   interoperability with existing web infrastructure (client and server
   implementations as well as installed proxies).

   All NetInf protocol requests are mapped to HTTP POST requests
   [RFC2616].  The corresponding NetInf protocol responses are mapped to
   the HTTP response messages of such HTTP POST request messages.

   The HTTP CL assumes that the client knows the address of the HTTP
   server to which it will send requests.  Clients MAY use the authority
   part of an ni URI, if one is present to select the HTTP responder.
   NetInf HTTP responders MUST accept requests sent to the following
   paths:

   /netinfproto/get  for NetInf GET requests

   /netinfproto/publish  for NetInf PUB requests

   /netinfproto/search  for NetInf SEARCH requests

   So for example a client would send an HTTP POST request containing a
   NetInf GET to http://example.com/netinfproto/get

   NetInf HTTP responders SHOULD also make ni URIs available at the
   relevant well-known URL [RFC5785] for the ni URI.
   [I-D.farrell-decade-ni]

   NetInf protocol requests use HTML forms, and as specified in
   [W3C.REC-html401-19991224] the form data set for the HTTP POST
   messages is included in the body of the form.  The content type of



Kutscher, et al.         Expires August 14, 2013               [Page 14]


Internet-Draft               NetInf Protocol               February 2013


   the form data body depends on the actual NetInf protocol request type
   (see below).  Receivers MUST accept both 'application/
   x-www-form-urlencoded' and 'multipart/form-data' for all requests.

   The mapping of the fields from the abstract protocol is as shown in
   Figure 4.


     ------------------------------------------------------------------
     Abstract      | Form field    | Comments (field type in form)
     Protocol      |               |
     Field         |               |
     ------------------------------------------------------------------
     URI           | urival, URI   | usually an ni URI (text)
                   | loc1,loc2     | or locator
     ------------------------------------------------------------------
     msg-id        | msgid         | a message identifier (text)
     ------------------------------------------------------------------
     ext           | ext           | extension(s) (JSON encoded string)
     ------------------------------------------------------------------
     full-ndo-flag | fullPut       | true if object supplied (checkbox)
     ------------------------------------------------------------------
     object        | octets        | object octets (file specification)
     ------------------------------------------------------------------
     n/a           | rform         | response format required, can be
                   |               | "html" or "json"  (radio)
     ------------------------------------------------------------------
     token         | tokens        | one text field with all search
                   |               | keywords (text)
     ------------------------------------------------------------------


               Figure 4: Form fields used in NetInf requests

   Notes for Figure 4:

   For GET messages:       'application/x-www-form-urlencoded' SHOULD be
                           used as a content type.
                           "URI" and "msgid" parameters are MANDATORY.
                           "loc1" and "loc2" are OPTIONAL.
                           "ext" may be used in future but no values
                           currently defined.

   For PUBLISH messages:   'application/x-www-form-urlencoded' SHOULD be
                           used as a content type if the request does
                           not contain an object.  If the request
                           contains an object (also see the description
                           of the fullPut parameter below), 'multipart/



Kutscher, et al.         Expires August 14, 2013               [Page 15]


Internet-Draft               NetInf Protocol               February 2013


                           form-data' MUST be used as a content type.
                           "URI" and "msgid" are MANDATORY.
                           "loc1", "loc2", "ext", "rform" and "fullPut"
                           are OPTIONAL.
                           If "rform" is absent, the "json" value is
                           assumed.
                           If "fullPut" is absent, a "false" value is
                           assumed.
                           If "fullPut" is present and set to "true",
                           "octets" must be present.
                           If present, "octets" contains a file
                           specification and the object octets.
                           If present, "ext" may contain a "meta" item.
                           The value of "ext" MUST be a JSON object
                           string and the value of the "meta" item MUST
                           be a (subsidiary) object, e.g., the "ext"
                           string might be
                           { "meta": { "mi1": 5, "mi2": { ...},
                           "mi3": "abcd". "mi4": [...] }}

   For SEARCH messages:    'application/x-www-form-urlencoded' SHOULD be
                           used as a content type.
                           "msgid" and "tokens" are MANDATORY.
                           "rform" is OPTIONAL.
                           If "rform" is absent, the "json" value is
                           assumed.
                           "ext" may be used in future but no values
                           currently defined.

   HTTP responses for each request can differ.

   For GET, the a successful HTTP response (HTTP response code 2xx) MUST
   contain either an application/json (if no object is returned) or else
   a multipart/mixed with exactly two body parts, the first being of
   content type 'application/json' and the second containing the object
   octets, with whatever MIME type is appropriate.

      The application/json component MUST consist of a JSON object that
      SHOULD contain the following named fields:

      NetInf    A string describing the version of the NetInf protocol
                in use (e.g., "V0.1a").

      ni        The "canonicalized" form of the NDO as a URI in the ni
                scheme: "canonicalized" means that the URI has empty
                netloc and query string fields.  For example:
                "ni:///sha-256-64;gf2yhPY9Mu0" or "nih:/
                sha256-32;81fdb284;d".



Kutscher, et al.         Expires August 14, 2013               [Page 16]


Internet-Draft               NetInf Protocol               February 2013


      msgid     The value of the msgid field in the GET message that
                resulted in this response.

      ts        The timestamp of the last update of the cached
                information in the cache from which the NDO is being
                sent.

      status    A code, taken from the HTTP 2xx response codes
                indicating what has been returned (200 if both
                affiliated data and content has been returned and 203 if
                only affiliated data is returned).

      ct        The MIME content type of the NDO content data, if known.
                Empty string if not yet known.

      loclist   Array of locator names (strings) from where the NDO
                might potentially be retrieved.

      metadata  A JSON object containing any named items copied in from
                "meta" object(s) supplied by any PUBLISH messages
                received at the node that sent the response plus an
                entry named "publish" which contains a string indicating
                the class of node and software that generated the cache
                entry.

      searches  A JSON array of objects each containing a set of strings
                representing search tokens and information about the
                search mechanism that resulted in a match with the NDO
                during a previous search.

   For PUBLISH, the HTTP response will contain an application/json or
   text/html response, depending on the value of the rform form field.
   (If rform is missing json is the default.)  The application/json
   structure is as for a GET response.  The text/html document will
   provide a report of the successful publication of the NDO and
   whatever other relevant information form the affiliated information
   seems appropriate for inspection by a human user.

   For SEARCH, the HTTP response will contain an application/json or
   text/html response, depending on the value of the rform form field.
   (If rform is missing json is the default.)  The application/json
   structure is similar to the previous structures, but has a "results"
   object that contains an array of object details.

6.2.  UDP CL

   The UDP CL implements the NetInf protocol with a UDP datagram
   services, i.e., all NetInf messages are mapped to individual UDP



Kutscher, et al.         Expires August 14, 2013               [Page 17]


Internet-Draft               NetInf Protocol               February 2013


   messages.  The purpose is to provide a light-weight datagram-based CL
   that can be used to implement NetInf transport protocols on top and
   that can provide efficient communication for querying NRSs, and
   request broadcasting/multicasting.  The UDP CL provides no hop-by-hop
   flow control, retransmission and fragmentation/re-assembly.

   The UDP CL has two sending modes: 1) send to specified destination IP
   address and 2) send to the well-known IPv4 multicast address
   225.4.5.6.  For both unicast and multicast the UDP port number is
   2345.  All request and response messages are JSON objects, i.e.,
   unordered sets of name/value pairs.

   For UDP CL messages, the following JSON names for name/value pairs
   are defined (not all objects have to be present in all messages):



    version  # the NetInf UDP CL protocol version -- currently
             # "NetInfUDP/1.0"

    msgType  # the message type (e.g., GET)

    uri      # the NI URI

    msgId    # the message ID (must be unique per CL hop and
             #request/response pair)

    locators # an array of locators

    instance # an UDP CL speaker identifier (must be unique per IP host,
             # e.g., process ID and per process ID

                  Figure 5: UDP CL JSON request structure

   This version of the specification defines the GET request and the
   corresponding GET response only.

   GET request  A GET request provides the following objects:

      version:  "NetInfUDP/1.0"

      msgType:  "GET"

      uri:      name of the requested NDO







Kutscher, et al.         Expires August 14, 2013               [Page 18]


Internet-Draft               NetInf Protocol               February 2013


      msgId:    message ID (see above)

   GET reponse  A GET response provides the following objects:

      version:  "NetInfUDP/1.0"

      msgType:  "GET-RESP"

      uri:      name of the requested NDO

      msgId:    message ID (see above)

      locators: a list of locator strings


7.  Security Considerations

   For privacy preserving reasons requestors SHOULD attempt to limit the
   personally identifying information (PII) included with search
   requests.  Including fine-grained search keywords can expose
   requestor PII.  For this reason, we RECOMMEND that requestors include
   more coarse grained keywords and that responders include sufficient
   meta-data to allow the requestor to refine their search based on the
   meta-data in the response.

   Similarly, search responders SHOULD consider whether or not they
   respond to all or some search requests as exposing one's cached
   content can also be a form of PII if the cached content is generated
   at the behest of the responder.

   Name-data integrity validation details are TBD for some common MIME
   types.

   Users need to be aware that the affiliated data is NOT protected by
   the name-data integrity as this applies only to the data content
   octets.

   [[More TBD no doubt.]]


8.  Acknowledgments

   This work has been supported by the EU FP7 project SAIL (FP7-ICT-
   2009-5-257448).

   Claudio Imbrenda and Christian Dannewitz contributed to early
   versions of this document whilst working at NEC and the University of
   Paderborn respectively.



Kutscher, et al.         Expires August 14, 2013               [Page 19]


Internet-Draft               NetInf Protocol               February 2013


   Petteri Poeyhoenen and Janne Tuononen helped with interop testing and
   corresponding feedback.


9.  References

9.1.  Normative References

   [I-D.farrell-decade-ni]
              Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keraenen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", draft-farrell-decade-ni-10 (work in progress),
              August 2012.

   [I-D.hallambaker-decade-ni-params]
              Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher,
              D., and B. Ohlman, "The Named Information (ni) URI Scheme:
              Optional Features", draft-hallambaker-decade-ni-params-03
              (work in progress), June 2012.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
              RFC 5652, September 2009.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [W3C.REC-html401-19991224]
              Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
              Specification", World Wide Web Consortium
              Recommendation REC-html401-19991224, December 1999,
              <http://www.w3.org/TR/1999/REC-html401-19991224>.





Kutscher, et al.         Expires August 14, 2013               [Page 20]


Internet-Draft               NetInf Protocol               February 2013


9.2.  Informative References

   [I-D.farrell-dtnrg-bpq]
              Farrell, S., Lynch, A., Kutscher, D., and A. Lindgren,
              "Bundle Protocol Query Extension Block",
              draft-farrell-dtnrg-bpq-01 (work in progress), March 2012.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [ref.netinf-db2]
              SAIL, "NetInf Content Delivery and Operations", SAIL
              Project Deliverable D-3.2 , May 2012.

   [ref.netinf-db3]
              SAIL, "Final NetInf Architecture", SAIL Project
              Deliverable D-3.3 , January 2013.


Authors' Addresses

   Dirk Kutscher
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: kutscher@neclab.eu


   Stephen Farrell
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie





Kutscher, et al.         Expires August 14, 2013               [Page 21]


Internet-Draft               NetInf Protocol               February 2013


   Elwyn Davies
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone: +44 1353 624 579
   Fax:
   Email: davieseb@scss.tcd.ie
   URI:










































Kutscher, et al.         Expires August 14, 2013               [Page 22]