NetInf Protocol Extensions for Cache Control

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. Syntax definitions in this memo are specified according to ABNF . This document describes extensions to the NetInf protocol 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.

"Fromorigin" is an extension parameter for the NetInf protocol message GET. The latter is defined in Section 5.1 of the NetInf protocol specification . 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.

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: The client issuing the GET is requesting that the named NDO be served from an origin server (and thus not from a cache). 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 .

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. This extension opens up a possibility for a DDOS attack which the publisher of the data has no control over. See further discussion in .

"Nodata" is an extension parameter for the NetInf protocol message GET. The latter is defined in Section 5.1 of the NetInf protocol specification . The purpose of the parameter is to enable a client to check whether an NDO is available without receiving a copy of the NDO.

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

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 .

"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 invalid. The metadata is stored together with the actual NDO data as discussed in Section 5.2 of . 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.

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 . An example is shown in .

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 .

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

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

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. 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 . An example is shown in .

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 .

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

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

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.

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.

fromorgin - opens for dos attacks on origin servers (especially when not together with nodata) This section needs much more work!

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