[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                    B. Ahlgren, Ed.
Internet-Draft                                                      SICS
Intended status: Experimental                                  B. Ohlman
Expires: August 18, 2014                                        Ericsson
                                                       February 14, 2014


              NetInf Protocol Extensions for Cache Control
              draft-ahlgren-icnrg-netinf-cache-control-00

Abstract

   This document defines NetInf protocol extensions for controlling
   caching behaviour.  This includes bypassing caches, asking to not
   return data, setting expiration time for objects, and marking objects
   as non-cacheable.

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 18, 2014.

Copyright Notice

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






Ahlgren & Ohlman         Expires August 18, 2014                [Page 1]


Internet-Draft               NetInf Routing                February 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Fromorigin extension for NetInf GET . . . . . . . . . . . . .   3
     2.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Nodata extension for NetInf GET . . . . . . . . . . . . . . .   4
     3.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Expires NDO metadata  . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Nocache NDO metadata  . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Processing  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Applications  . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  NetInf ping . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Dynamically generated data  . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   [[Text in double square brackets (like this) is commentary.]]

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

   This document describes extensions to the NetInf protocol
   [I-D.kutscher-icnrg-netinf-proto] for controlling the object caching
   behaviour from client requests (NetInf GET) and by publishers (NetInf
   PUBLISH).

   The extensions have several uses.  For example, they enable a
   publisher to provide dynamic data that is recomputed at certain
   intervals.  To be useful, the object name must be able to handle
   dynamic data.  The extensions also enable the implementation of a
   NetInf counterpart to the IP program "ping".

   [[Ideally, the extensions in this specification should be defined
   independently of NetInf convergence layer (CL), but that currently
   seems impossible.]]



Ahlgren & Ohlman         Expires August 18, 2014                [Page 2]


Internet-Draft               NetInf Routing                February 2014


2.  Fromorigin extension for NetInf GET

   "Fromorigin" is an extension parameter for the NetInf protocol
   message GET.  The latter is defined in Section 5.1 of the NetInf
   protocol specification [I-D.kutscher-icnrg-netinf-proto].  The
   purpose of the parameter is to enable a client to ask for an NDO to
   be served from an origin server, and thus that the NDO is not served
   from a NetInf cache.  The concept of an "origin server" for an NDO
   needs to be defined more precisely, but the intention is that this is
   a server that has received and accepted a NetInf PUBLISH message for
   the NDO with a so called "full put", that is, including the actual
   NDO content data, or that it is a server that makes the NDO
   available, for instance by PUBLISH:ing the existence of the NDO to a
   NetInf name resolution server.

2.1.  Syntax

   The "fromorigin" parameter MUST be encoded in a json key-value field
   named "fromorigin" in the "ext" parameter of the GET message.  Its
   data type MUST be boolean with the following interpretation of the
   values:

   true  The client issuing the GET is requesting that the named NDO be
      served from an origin server (and thus not from a cache).

   false  The client issuing the GET is not requesting any special
      processing.  The NDO can be served from a cache or origin server.
      This is the normal, default, case when the parameter is not
      present in the GET message.

   An example is shown in Figure 1.

    ext = { "fromorigin": true }

                  Figure 1: Example fromorigin parameter

2.2.  Processing

   A NetInf node that receives a GET message with the "fromorigin"
   parameter set to true, SHOULD modify its processing of the request as
   follows.

   If the NetInf node has a copy of the NDO named in the GET message,
   but it is not an origin server for the NDO, it SHOULD ignore that
   copy and proceed with any other processing of the GET request,
   including forwarding to another node.





Ahlgren & Ohlman         Expires August 18, 2014                [Page 3]


Internet-Draft               NetInf Routing                February 2014


   This extension opens up a possibility for a DDOS attack which the
   publisher of the data has no control over.  See further discussion in
   Section 7.

3.  Nodata extension for NetInf GET

   "Nodata" is an extension parameter for the NetInf protocol message
   GET.  The latter is defined in Section 5.1 of the NetInf protocol
   specification [I-D.kutscher-icnrg-netinf-proto].  The purpose of the
   parameter is to enable a client to check whether an NDO is available
   without receiving a copy of the NDO.

3.1.  Syntax

   The "nodata" parameter MUST be encoded in a json key-value field
   named "nodata" in the "ext" parameter of the GET message.  Its data
   type MUST be boolean with the following interpretation of the values:

   true  The client issuing the GET is requesting that the NDO data is
      not sent back in response, but rather just a status response
      indicating whether the NDO exists.

   false  The client issuing the GET is not requesting any special
      processing.  This is the normal, default, case when the parameter
      is not present in the GET message.

   An example is shown in Figure 2.

    ext = { "nodata": true }

                    Figure 2: Example nodata parameter

3.2.  Processing

   A NetInf node that receives a GET message with the "nodata" parameter
   set to true, MUST modify its processing of the request as follows.

   If the NetInf node has a copy of the NDO named in the GET message, it
   MUST NOT include the NDO data in the GET-RESP message, but rather
   only include URI locators as specified in Section 5.1 of
   [I-D.kutscher-icnrg-netinf-proto].

4.  Expires NDO metadata

   "Expires" is an NDO metadata field that can be specified by the
   publisher of an NDO.  "Expires" contains the time delta from current,
   publishing, time to when the publisher regards the NDO as expired,
   and thus wants any cached copies of the NDO to be regarded as



Ahlgren & Ohlman         Expires August 18, 2014                [Page 4]


Internet-Draft               NetInf Routing                February 2014


   invalid.  The metadata is stored together with the actual NDO data as
   discussed in Section 5.2 of [I-D.kutscher-icnrg-netinf-proto].

   The "expires" NDO metadata is specified by publishers in the PUBLISH
   message as part of the "meta" field in the json-encoded "ext"
   parameter.  When the NDO is returned in a GET-RESP message, the
   "expires" metadata is supplied as part of the affiliated data to the
   NDO in the application/json MIME part.

   There are multiple issues with this kind of parameter.  A time delta,
   as currently specified, depends on that nodes can decrement the value
   with reasonable accuracy.  An alternative or complement would be to
   add a parameter with absolute expiration time.  That solution depends
   on reasonable accurate timekeeping.  Another alternative is to add
   the publishing time.  The exact solution is for further study and
   experimentation.

4.1.  Syntax

   The "expires" NDO metadata MUST be specified as an json key-value
   field with the name "expires".  Its data type MUST be of type
   integer.  It specifies the time delta as number of seconds.

   [[Perhaps use RFC3339 format instead?  Durations in its Appendix A
   from ISO8601?]]

   In the NetInf PUBLISH message, the "expires" key-value field is
   contained in a "meta" key-value field in the "ext" parameter as
   specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].  An
   example is shown in Figure 3.

    ext = { "meta": { "expires": 3600 } }

           Figure 3: Example expires metadata in PUBLISH message

   In the NetInf GET-RESP message, the "expires" key-value field is
   contained in the application/json component of the message body as
   part of the "metadata" key-value field as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

4.2.  Processing










Ahlgren & Ohlman         Expires August 18, 2014                [Page 5]


Internet-Draft               NetInf Routing                February 2014


   A NetInf node receiving a NetInf GET message for an NDO that is
   present in its cache SHOULD check the NDO's metadata for an "expires"
   key-value field.  The node SHOULD to the best of its ability
   determine whether the expiration time has passed.  If the expiration
   time has passed, it SHOULD disregard the cached copy and continue
   with any other processing of the GET message, including the
   possibility to forward the message to another node.

   A NetInf node receiving a NetInf PUBLISH message containing object
   data ("full-ndo-flag") and the "expires" key-value field in the NDO
   metadata, SHOULD keep the key-value field with the NDO as affiliated
   data.  This is normal processing as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

   A NetInf node responding with a NetInf GET-RESP containing the NDO
   object octets, SHOULD include any "expires" key-value field metadata
   associated with the NDO in the application/json body part.  This is
   also normal processing as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

   A NetInf node receiving a NetInf GET-RESP message containing the NDO
   object octets, SHOULD keep any "expires" key-value field metadata
   associated with the NDO.  This applies both if the node forwards the
   GET-RESP back to another requester, and if the node decides to keep
   this NDO in its local cache.  This is normal processing as specified
   in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].

5.  Nocache NDO metadata

   "Nocache" is an NDO metadata field that can be specified by the
   publisher of an NDO.  "Nocache" is a boolean value that when set to
   true, inhibits caching of the NDO by NetInf nodes.  The metadata is
   stored together with the actual NDO data as discussed in Section 5.2
   of [I-D.kutscher-icnrg-netinf-proto].

   The "nocache" NDO metadata is specified by publishers in the PUBLISH
   message as part of the "meta" field in the json-encoded "ext"
   parameter.  When the NDO is returned in a GET-RESP message, the
   "nocache" metadata is supplied as part of the affiliated data to the
   NDO in the application/json MIME part.

5.1.  Syntax

   The "nocache" NDO metadata MUST be specified as an json key-value
   field with the name "nocache".  Its data type MUST be of type
   boolean.  When set to "true", the publisher indicates that this NDO
   should not be cached.  When set to "false", the default if not
   present, indicates that NetInf nodes may cache the NDO object data.



Ahlgren & Ohlman         Expires August 18, 2014                [Page 6]


Internet-Draft               NetInf Routing                February 2014


   In the NetInf PUBLISH message, the "nocache" key-value field is
   contained in a "meta" key-value field in the "ext" parameter as
   specified in Section 6.1 of [I-D.kutscher-icnrg-netinf-proto].  An
   example is shown in Figure 4.

    ext = { "meta": { "nocache": true } }

           Figure 4: Example nocache metadata in PUBLISH message

   In the NetInf GET-RESP message, the "nocache" key-value field is
   contained in the application/json component of the message body as
   part of the "metadata" key-value field as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

5.2.  Processing

   A NetInf node receiving a NetInf PUBLISH message containing object
   data ("full-ndo-flag") and the "nocache" key-value field in the NDO
   metadata, MUST keep the key-value field with the NDO as affiliated
   data.  This is normal processing as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

   A NetInf node receiving a NetInf GET-RESP message containing an NDO
   with the "nocache" key-value field set to true, MUST NOT keep a copy
   of the NDO in its cache.

   A NetInf node responding with a NetInf GET-RESP message containing
   the NDO object octets, MUST include any "nocache" key-value field
   metadata associated with the NDO in the application/json body part.
   This is also normal processing as specified in Section 6.1 of
   [I-D.kutscher-icnrg-netinf-proto].

6.  Applications

   The extensions described in this document can be used for several
   purposes.  Some of them are described in this section.

6.1.  NetInf ping

   A kind of "NetInf ping" can be implemented, with which the
   reachability of a certain NDO can be checked.  A client issues a
   NetInf GET request with the "nodata" extension.  If a valid response
   is received, the NDO is reachable.  The request can be combined with
   the "fromorigin" extension, so that the request is not satisfied when
   a cached copy is encountered, but rather forwarded to an origin
   publisher for the NDO.  The client can with this combination check
   the reachability of the NDO at the publisher or origin server.




Ahlgren & Ohlman         Expires August 18, 2014                [Page 7]


Internet-Draft               NetInf Routing                February 2014


6.2.  Dynamically generated data

   Two kinds of dynamically generated data can be created by publishers
   using the "expires" and "nocache" NDO metadata.  To be useful,
   dynamically generated data should not use names including the content
   hash in the name, since new, different, data then necessarily results
   in a new name.  A scheme that ensures name-data integrity using
   signatures is rather needed.

   Using "nocache" means that all requests for that particular NDO name
   will reach the origin publisher, which then dynamically can create
   the data when the request arrives.

   Using "expires" means that the NDO can be cached for a certain time
   duration.  The publisher can then regularly update the NDO with new
   data.

7.  Security Considerations

   fromorgin - opens for dos attacks on origin servers (especially when
   not together with nodata)

   [[This section needs much more work!]]

8.  Acknowledgements

   Ericsson and SICS colleagues in Center for Networked Systems at SICS,
   the EFRAIM project, and partners in the former EU FP7 project SAIL.

9.  Normative References

   [I-D.kutscher-icnrg-netinf-proto]
              Kutscher, D., Farrell, S., and E. Davies, "The NetInf
              Protocol", draft-kutscher-icnrg-netinf-proto-01 (work in
              progress), February 2013.

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

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

Authors' Addresses








Ahlgren & Ohlman         Expires August 18, 2014                [Page 8]


Internet-Draft               NetInf Routing                February 2014


   Bengt Ahlgren (editor)
   SICS
   Isafjordsgatan 22
   Kista  SE-16429
   Sweden

   Email: bengta@sics.se


   Boerje Ohlman
   Ericsson
   Faeroegatan 6
   Kista  SE-16429
   Sweden

   Email: borje.ohlman@ericsson.com



































Ahlgren & Ohlman         Expires August 18, 2014                [Page 9]


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