Internet DRAFT - draft-ahlgren-icnrg-netinf-cache-control
draft-ahlgren-icnrg-netinf-cache-control
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]
