idnits 2.17.1 draft-kutscher-icnrg-netinf-proto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 625 has weird spacing: '...oto/get for N...' == Line 627 has weird spacing: '...publish for N...' == Line 629 has weird spacing: '.../search for N...' -- The document date (October 4, 2012) is 4212 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5751' is defined on line 903, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Kutscher 3 Internet-Draft NEC 4 Intended status: Standards Track S. Farrell 5 Expires: April 7, 2013 E. Davies 6 Trinity College Dublin 7 October 4, 2012 9 The NetInf Protocol 10 draft-kutscher-icnrg-netinf-proto-00 12 Abstract 14 This document defines a conceptual protocol and corresponding node 15 requirements for NetInf nodes in a NetInf network. A NetInf network 16 offers an information-centric paradigm that supports the creation, 17 location, exchange and storage of Named Data Objects (NDOs). NetInf 18 nodes can provide different services to other NetInf nodes, e.g., 19 forwarding requests for information objects, delivering corresponding 20 response messages, name resolution services etc. This (abstract) 21 protocol is intended to be run over some "convergence layer" that 22 handles transport issues. Two "wire" formats are defined, one that 23 uses HTTP for message transfer and one layered on UDP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 7, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Principles and Assumptions . . . . . . . . . . . . . . . . . . 3 58 3. Convergence Layer Architecture . . . . . . . . . . . . . . . . 5 59 4. The NetInf Protocol - Overview . . . . . . . . . . . . . . . . 7 60 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9 61 5.1. GET/GET-RESP . . . . . . . . . . . . . . . . . . . . . . . 9 62 5.2. PUBLISH/PUBLISH-RESP . . . . . . . . . . . . . . . . . . . 11 63 5.3. SEARCH/SEARCH-RESP . . . . . . . . . . . . . . . . . . . . 13 64 6. Convergence Layer Specifications . . . . . . . . . . . . . . . 14 65 6.1. HTTP CL . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.2. UDP CL . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 74 1. Introduction 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119. [RFC2119] 80 Syntax definitions in this memo are specified according to ABNF 81 [RFC5234]. 83 There is an open-source implementation available that implements 84 (most of) this. See http://sourceforge.net/projects/netinf/ for code 85 and http://village.n4c.eu/getputform.html for access to a test 86 server. 88 2. Principles and Assumptions 90 A NetInf network provides an information-centric networking (ICN) 91 environment in which units of data content can be identified and 92 accessed using a URI-based naming scheme. NetInf nodes in a NetInf 93 network support the creation, location, exchange and storage of these 94 units of content. In order to support interoperable implementation 95 of the NetInf design, [ref.netinf-db2] the following assumptions are 96 made here: 98 o all nodes can take on all NetInf roles (but do not have to); 100 o as necessary, nodes may access a Name Resolution System (NRS) 101 and/or a (possibly name based) message routing infrastructure for 102 NetInf messages; and 104 o the NetInf protocol can be used directly to access content. 106 The NetInf protocol operates on Named Data Objects (see 107 [ref.netinf-db2]) referred to as NDOs. An NDO is an ordered 108 collection of octets associated with a name. The NetInf protocol is 109 designed to cache, locate and transmit complete NDOs. 111 The NetInf protocol is specified so that NDOs can in principle be 112 retrieved from nodes anywhere in the network to which messages can be 113 routed. This routing is intended to be driven by the names of the 114 NDOs, with the option to use an NRS, but this specification does not 115 discuss how routing, nor calling to an NRS, is carried out. Routing 116 will also depend on the underlying Convergence Layer protocol (see 117 Section 3) in use at that node. 119 Nodes offering NetInf services may return locators in some cases. 120 These locators designate network locations where an NDO might 121 potentially be available for retrieval, but locators may not be 122 usable outside of some (possibly hard-to-characterise) domain, or for 123 more than a limited period of time, due to mobility of nodes or time 124 limited access through "pinholes" in middleboxes such as firewalls 125 and Network Address Translators (NATs). Accordingly, a design goal 126 is to enable preferential use of names, with locators mostly as hints 127 to improve efficiency. For this reason one can argue that locators 128 ought not be made available to applications using the NetInf protocol 129 in a form that would allow them to try to use the locator outside the 130 NetInf protocol. NDOs may have multiple locators in order to 131 indicate specific interfaces or to reflect attachment to multiple 132 addressing domains. Locators also typically map to a specific 133 instance (copy) of an NDO residing at a given host. 135 Locators are an example of NDO associated data that may be stored in 136 association with the data content of the NDO. Other types of such 137 data include "metadata" relating to the data content of the NDO, 138 information describing the history of the copy of the NDO in the node 139 where it is stored and search terms that are applicable to the NDO 140 content. The term "affiliated data" will be used to describe the 141 overall set of data, other than the actual octets of the content, 142 stored or transmitted in association with an NDO. This affiliated 143 data could be described as metadata of the NDO but we will reserve 144 that term for a subset of the affiliated data that is usually 145 constructed by the publisher of the NDO describing the content data 146 of the NDO that is sent out in tandem with the data content. The 147 NetInf protocol allows this affiliated data to be transmitted, in 148 whole or in part, in association with NetInf messages. 150 NDO names will often be based on hash-function output values, and 151 since the preferred hash-function will change over time and may 152 change depending on location, this implies that NDOs can also have 153 more than one name. There may also be cases where truncated hash 154 values are desired (e.g., in cases where packets must be kept below 155 some small size and fitting an entire request into one packet is 156 required), and in such cases collisions will occur, or can easily be 157 generated by bad actors. There are also cases where it is desirable 158 to use a name to refer to some "dynamic" NDO, whose octets change 159 (e.g., perhaps the current weather report) and there are 160 cryptographic methods for doing this. This all means that there is 161 no strict 1:1 mapping between names and NDOs, however, we do expect 162 that for most objects, for most ICN deployments, there will in 163 practice be one NDO that is named by each name. That is, each name 164 usually does refer to just one object, and this protocol is designed 165 to work best for that case. 167 The following NetInf services are assumed to be implemented on nodes 168 through the NetInf protocol: 170 o caching of NDOs, both locally originated and acquired through 171 network operations with the NetInf protocol; 173 o requesting the fetching of an NDO using its name, possibly with 174 the addition of a locator, from elsewhere in the network; 176 o responding to NetInf protocol NDO fetch operations using a name 177 referring to one of its locally known NDOs, which may have been 178 locally generated or acquired from another NetInf node and cached 179 here, by returning either or both of the data named in the 180 operation or affiliated data including locator(s) referring to a 181 node where that NDO is (assumed to be) available; 183 o initiating a search for NDOs matching specified search criteria; 185 o responding to search requests received by determining if any 186 locally known NDOs meet the search criteria according to locally 187 determined algorithms; 189 o NDO publication via sending out the name and, optionally, either 190 or both of the content data and some affiliated data, such as 191 locators, to other nodes; 193 o according to locally determined policy, the ability to accept or 194 reject NDO publication requests that are delivered to the node, 195 and to cache either or both of the objects and/or information 196 about those that are accepted; 198 o according to locally determined policy, after carrying out local 199 processing, the ability to forward NetInf messages to other nodes 200 or discard them; 202 o managing the data affiliated with the NDO as well as the content 203 data; and 205 o local cache management, driven by local policy and (optionally) 206 whatever cache directives are carried in NetInf messages. 208 3. Convergence Layer Architecture 210 The idea of the Convergence Layer (CL) is to provide a means to 211 transport NetInf messages between pairs of nodes that offer NetInf 212 services. Any protocol that allows NetInf messages to be passed 213 without loss of information can be used as a NetInf Convergence Layer 214 (NetInf-CL) protocol. 216 This document does not cover the bit-level specification of any CL 217 protocol. The individual CL protocols will provide their own 218 specification regarding their bit-level format. 220 Different CLs can be used in the various regions forming a global 221 NetInf network. Where a message has to pass through several 222 intermediate NetInf-capable nodes from source to destination, the 223 NetInf protocol layer at each node is responsible for selecting the 224 appropriate link and CL to forward messages. 226 Each CL has to offer the following minimal set of capabilities: 228 o unidirectional point-to-point transport of NetInf messages from 229 source to destination, 231 o preservation of message boundaries, 233 o reliable transmission of message octets, and 235 o in-order delivery of message octets to the destination node. 237 If an underlying protocol used by a particular CL cannot offer these 238 capabilities natively, then the CL is responsible for synthesising 239 these capabilities by appropriate means, e.g., use of retransmission 240 or insertion of sequence numbers. However, this does not prevent a 241 CL that uses a more capable underlying protocol from implementing 242 additional capabilities, e.g., bidirectional connections that allow a 243 single connection to send NDOs in both directions. 245 The CL itself does not specify the properties of the messages, how 246 they are interpreted, and the way nodes should interact with them, as 247 that is what is specified in the present document. 249 The CL architecture is inspired by, and similar to, the concept used 250 in Delay-Tolerant Networking. [RFC4838][RFC5050]. 252 However, in contrast to DTN-CLs, the NetInf-CL concept does not 253 include the handling of fragments of an NDO "above" the CL. This is 254 the main difference between the CL concept as used in DTNs and ICNs. 255 Put another way, a DTN-CL may result in a bundle being fragmented, 256 and those fragments are only re-assembled at the final bundle 257 destination. In the case of an NetInf-CL, if an NDO is fragmented or 258 chunked within the CL, then those fragments or chunks are reassembled 259 at the next ICN node and that fragmentation or chunking is not 260 visible to the ICN protocol. One can also consider that the DTN 261 Bundle Protocol (BP)[RFC5050], which runs over a DTN-CL, can itself, 262 with an appropriate extension such as the "BPQ" extension, 263 [I-D.farrell-dtnrg-bpq] be an NetInf-CL. That is, a concrete 264 instance of this protocol could use the BP with the BPQ extension as 265 an NetInf-CL. 267 4. The NetInf Protocol - Overview 269 This protocol assumes that NDOs are named using URIs, and in 270 particular via the "ni" URI scheme [I-D.farrell-decade-ni] which MUST 271 be supported. There are a set of extensions to the "ni" URI scheme 272 [I-D.hallambaker-decade-ni-params] that MAY be supported by nodes. 273 However, other URI forms MAY also be used in the NetInf protocol, in 274 particular as locators, and nodes SHOULD support at least fetching of 275 "http" URLs. 277 Nodes are assumed to be capable of discriminating between names and 278 locators, based on the URI scheme or otherwise. 280 The most common operations for a NetInf node will be fetching (using 281 a GET message) an NDO or responding to such queries. The response to 282 the GET message will, if possible, contain the octets making up the 283 specified NDO and MAY contain 285 o one or more URIs (typically locators) that could subsequently be 286 used to retrieve the octets of the NDO either via this NetInf 287 protocol or by alternative, locator-specific, means, and/or 289 o other affiliated data such as metadata relevant to the NDO. 291 There are some circumstances in which it MAY be appropriate for the 292 response to the GET message to contain only one or more locators and, 293 optionally, other affiliated data. Examples of this situation occur 294 if the responding node is aware that the object content can be 295 returned more effectively using an alternative protocol or from an 296 alternative source because of bandwidth limitations on the links 297 connecting the responding node. 299 In addition to GET, there is the analagous PUBLISH operation where 300 one node sends URIs and/or NDO octets to another. There is also a 301 SEARCH operation, where one node submits a search query and receives 302 a set of URIs and optional meta-data in response. 304 GET, PUBLISH and SEARCH messages MAY be forwarded by any node that 305 receives them if there is good reason and local policy indicates that 306 this would not result in excessive usage of network resources. 308 If a request message is forwarded, then a response message MUST NOT 309 be sent for that request while the overall "transaction" is still in 310 progress. That is, a node that forwards a request does not answer 311 that request itself until it gets an answer from elsewhere. 313 Response messages MUST be forwarded by routers to the node from which 314 the corresponding request message was received. The routing 315 mechanisms that are used to ensure responses are correctly forwarded 316 in this way are not specified here. 318 Since this specification does not determine how message routing, nor 319 use of an NRS is done, we do not otherwise specify how or when 320 messages are to be forwarded. 322 Nodes that want to make a locally stored NDO available with a 323 specific name can use the PUBLISH message to announce that data to 324 the network. This message MAY "push" the octets of the NDO into 325 other nodes' caches. (If those nodes are willing to take them.) The 326 reasoning behind this is that in many circumstances pushing just a 327 name or a locator will not be helpful because the node with the NDO 328 may be located behind a middlebox that will not allow access to the 329 data from "outside." Pushing the complete NDO to a node that is 330 accessible from the originating node but is also accessible from 331 outside the middlebox "interior," can allow global access, e.g., by 332 caching the NDO on a server in the DMZ ("DeMilitarized Zone") of an 333 enterprise network or in a server provided by a home user's 334 ISP.(Internet Service Provider). The publisher MAY also push 335 affiliated data for the NDO, including additional locators and 336 content metadata that can be stored in a node's NDO cache. The 337 caching node MAY choose to store just the affiliated data without the 338 content data depending on local policy. 340 As in the case of routing messages generally, this specification does 341 not determine the node(s) to which an NDO can be "pushed." 343 Finally, NetInf nodes can send a SEARCH message to other NetInf 344 nodes. In response, a NetInf node can perform a local search (i.e., 345 of its local cache) As a response, any of the NetInf nodes that 346 receives the SEARCH message returns a set of "ni" URIs of objects 347 matching the search query. It may also return other types of URI 348 such as "http" URIs. Searching of a node's local cache is the main 349 goal for the SEARCH operation, but if a set of nodes were to forward 350 SEARCH messages, then a global search (e.g., a Google-like service) 351 service could be offered. 353 NDOs together with any affiliated data are represented using MIME 354 objects. [RFC2045]. Placing as much of the affiliated data linked 355 to the NDO in a multipart MIME object along with the octets of the 356 actual object allows for significant specification and code re-use. 357 For example, we do not need to invent a new typing scheme nor any 358 associated registration rules nor registries. 360 As an example we might have a MIME object of that is multipart/mixed 361 and contains image/jpeg and application/json body parts, with the 362 named image in the former and loosely structured associated data in 363 the latter. The "ni" scheme parameters draft discusses such 364 examples. This means that the details of the verification of name- 365 data integrity supported by the ni name scheme also depend on the 366 MIME type(s) used. 368 MIME also simplifies the specification of schemes that make use of 369 digital signatures, reusing techniques from existing systems 370 including Secure MIME (S/MIME) [RFC5751]and the Cryptographic Message 371 Syntax (CMS) [RFC5652]. 373 Note that (as specified in [I-D.farrell-decade-ni]) two "ni" URIs 374 refer to the same object when the digest algorithm and values are the 375 same, and other fields within the URI (e.g., the authority) are not 376 relevant. Two ni names are identical when they refer to the same 377 object. This means that a comparison function for ni names MUST only 378 compare the digest algorithms and values. 380 5. Protocol Details 382 We define the GET, PUBLISH and SEARCH messages in line with the 383 above. GET and PUBLISH MUST be supported. SEARCH SHOULD be 384 supported. Each message has an associated response. 386 This means that GET and PUBLISH MUST be implemented and SEARCH SHOULD 387 be implemented. In terms of services, GET and PUBLISH SHOULD be 388 operational but SEARCH MAY be turned off. 390 5.1. GET/GET-RESP 392 The GET message is used to request an NDO from the NetInf network. A 393 node responding to the GET message would send a GET-RESP that is 394 linked to the GET request using the msg-id from the GET message as 395 the msg-id for corresponding GET-RESP messages if it has an instance 396 of the requested NDO. 398 The "ni" form or URI MUST be supported. Other forms of URI MAY be 399 supported. 401 The msg-id SHOULD be chosen so as to be highly unlikely to collide 402 with any other msg-id and MUST NOT contain information that might be 403 personally identifying, e.g., an IP address or username. A 404 sufficiently long random string SHOULD be used for this. 406 The ext field is to handle future extensibility (e.g., for message 407 authenticators) and allows for the inclusion of a sequence of type, 408 length value tuples. No extensions for GET messages are defined at 409 this point in time. 411 get-req = GET msg-id URI [ ext ] 412 get-resp = status msg-id [ 1*URI ] [ ext ] [ object ] 414 ext = json-coded-string 416 Figure 1: GET/GET-RESP Message Format 418 Any node that receives a GET message and does not have an instance of 419 the NDO referenced in the message MUST either 421 o forward the message to another node, or 423 o generate a GET response message with an appropriate status code 424 and the msg-id from the GET message as the response msg-id. 426 If the message is forwarded, the node SHOULD maintain state that will 427 allow it to generate the GET response message if a matching response 428 message is not received for forwarding within a reasonable period of 429 time after the GET message was forwarded. 431 If the node has an instance of the NDO, the response MAY contain zero 432 or more URIs that MUST be either locators for the specified object or 433 else alternative names for that object. If the receiving node has a 434 copy of the relevant object in its cache it SHOULD include the object 435 in the response. Possible reasons for not including the object would 436 include situations where the GET message was received via a low- 437 bandwidth interface but where the node "knows" that returning a 438 locator will allow the requestor faster access to the object octets. 439 Alternatively, the node may only be maintaining the affiliated data 440 for the NDO and not the content data if it has not yet received the 441 content data or has discarded it due to cache size limitations. 443 The object MUST be encoded as a MIME object. If there is affiliated 444 data linked to the object this MUST also be encoded using MIME and 445 integrated with the object in a multipart/mixed MIME object. 447 If the receiving node does not have a cached copy of the object it 448 MAY choose to forward the message depending on local policy. Such 449 forwarding could be based on name-based routing, on an NRS lookup or 450 other mechanisms (e.g. a node might have a default route). 452 If an get-resp is received with an object that is not MIME encoded or 453 of an unknown MIME type then that MUST be treated as an application/ 454 octet-stream for the purposes of name-data integrity verification. 456 get-resp messages MAY include extensions as with all others. 458 5.2. PUBLISH/PUBLISH-RESP 460 The PUBLISH message allows a node to push the name, and optionally, 461 alternative names, locators, a copy of the object octets and/or 462 object meta-data. Ignoring extensions, only a status code is 463 expected in return. 465 A msg-id MUST be included as in a GET message. 467 A URI containing a name MUST be included. The "ni" URI scheme SHOULD 468 be used for this name. 470 The message MAY also contain additional URIs that represent either 471 alternative names or locators where the identical object can be found 472 and metadata relating to the published content. As mentioned in 473 Section 4 it is the responsibility of the receiving node to 474 discriminate between those URIs used as names and those used as 475 locators. 477 The object octets MAY be included. This is intended to handle the 478 case where the publishing node is not able to receive GET messages 479 for objects. An implementation SHOULD test (or "know") its local 480 network context sufficiently well to decide if the object octets 481 ought to be included or not. Methods for checking this are out of 482 scope of this specification. 484 A node receiving a PUBLISH message chooses what information from the 485 message, if any, to cache according to local policy and availability 486 of resources. It is RECOMMENDED that a node that receives a PUBLISH 487 message containing the object octets verify that the digest in the 488 name under which the content is published matches with the digest of 489 the received data. 491 One way to "fill a cache" if the object octets are not included in 492 the PUBLISH would be for the recipient of the PUBLISH to simply 493 request the object octets using GET and cache those. (There is no 494 point in sending a PUBLISH without the octets and without any 495 locator.) This behaviour is, of course, an implementation issue. 497 In some cases it may make sense for a (contactable) node to only 498 publish the name and metadata about the object. The idea here is 499 that the metadata could help with routing or name resolution or 500 search. Since we are representing both NDO octets and affiliated 501 data such as the metadata as MIME objects, we need to tell the 502 receiver of the PUBLISH message whether or not that message contains 503 the full object. We do this via the "full-ndo-flag" which, if 504 present, indicates that the PUBLISH message contains enough data so 505 the receiver of the PUBLISH message has sufficient data to provide a 506 complete answer a subsequent GET message for that name, i.e., data 507 content and affiliated data. 509 If a node receives a PUBLISH message for an NDO which already exists 510 in its cache, the received information SHOULD be used to complete or 511 update the node's cached information for the NDO: 513 o If the object octets are included and the node currently does not 514 have the octets cached, the data content MAY be added to the 515 cache. Again it is RECOMMENDED that the received data has the 516 correct digest as specified in the NDO name, and 518 o Items in the affiliated data MAY be merged into cached affiliated 519 data, including adding additional locators to the list of known 520 locators for the NDO and merging any content metadata with 521 previously received metadata. If there is a conflict, the choice 522 of metadata to be stored is a matter of policy. 524 It is RECOMMENDED that a timestamp be recorded whenever the cached 525 information for an NDO is updated and that this timestamp be stored 526 in the affiliated data and the most recent timestamp returned with 527 any subsequent GET or SEARCH request that references the NDO. 529 Extensions ("ext") MAY be included as in a GET request. One such 530 HTTP CL-specific extension ("meta") is defined in Section 6.1 below. 532 pub-req = PUBLISH msg-id 1*URI [ ext ] [ [ full-ndo-flag ] object ] 533 pub-resp = status msg-id [ ext ] 535 Figure 2: PUBLISH/PUBLISH-RESP Message Format 537 The response to a PUBLISH message is a status code and the msg-id 538 from the PUBLISH message and optional extensions. 540 A node receiving a PUBLISH message MAY choose to forward the message 541 to other nodes whether or not it chooses to cache any information. 542 If this node does not cache the information but does forward the 543 PUBLISH message, it should postpone sending a response message until 544 a reasonable period of time has elapsed during which no other 545 responses to the PUBLISH message are received for forwarding. 546 However, the node MAY send an extra response message, even if it 547 forwards the PUBLISH message, if the sender of the PUBLISH message 548 would have expected the receiving node to cache the object (e.g., 549 because of a contractual relationship) but it was unable to do so for 550 some reason. 552 5.3. SEARCH/SEARCH-RESP 554 The SEARCH message allows the requestor to send a set of query tokens 555 containing search keywords. The response is either a status code or 556 a multipart MIME object containing a set of metadata body parts, each 557 of which MUST include a name for an NDO that is considered to match 558 the query keywords. 560 search-req = SEARCH msg-id [ 1*token ] [ ext ] 561 search-resp = status msg-id [ results ] [ ext ] 563 Figure 3: SEARCH/SEARCH-RESP Message Format 565 In the case where the response contains results, these MUST take the 566 form of an application/json MIME object containing an array of 567 results. Each result MUST have a "name" field with a URI as the 568 value of that field. Any other fields in array elements SHOULD 569 contain metadata that is intended to allow the requestor to select 570 which, if any, of the names offered to retrieve. 572 The URIs included in a search-resp SHOULD be names, but MAY be 573 locators, to be distinguished by the requestor as in the case of GET 574 responses. 576 The intent of the SEARCH message is to allow nodes to search one 577 another's caches, but without requiring us to fix the details 578 (ontology) for NDO content metadata. While this main intended use- 579 case does not involve forwarding of SEARCH messages that is not 580 precluded. 582 As with PUBLISH messages, if a SEARCH message is forwarded, the 583 forwarding node postpones sending an empty SEARCH response until a 584 reasonable time is elapsed to see if alternative node responds to the 585 SEARCH. 587 If a SEARCH at a node identifies an NDO that is included in the 588 results of a search, the tokens that were used for the search MAY be 589 recorded in the affiliated data cached with the NDO. Each set of 590 search tokens for which a "match" is obtained should be recorded 591 separately resulting in an array of set of tokens. If the search 592 mechanisms used provides a reliability measure, this MAY also be 593 recorded and the measure may be used to limit the size of the search 594 tokens array by discarding (or never inserting) sets of tokens with 595 low reliability scores. 597 SEARCH messages MAY include extensions as for other messages. 599 6. Convergence Layer Specifications 601 This section specifies two convergence layers that represent 602 instantiations of the NetInf protocol. The first, based on HTTP, is 603 intended for using NetInf in existing web infrastructures, whereas 604 the second, based on UDP, provides an efficient datagram-based hop- 605 by-hop message transport that can be used to query for GET requests 606 sent to an NRS node or for multicasting such requests in a local 607 network. 609 6.1. HTTP CL 611 The basic idea with the HTTP CL is to use forms for NetInf protocol 612 requests and Multipart MIME HTTP response bodies for Netinf protocol 613 responses. This has be done to allow web browsers to be able to 614 easily interact with NetInf and because there are many tools 615 available that make implementation relatively easy. Note thought 616 that the NetInf HTTP CL is also intended for use between NetInf 617 infrastructure nodes. 619 The HTTP CL assumes that the client knows the address of the HTTP 620 server to which it will send requests. Clients MAY use the authority 621 part of an ni URI, if one is present to select the HTTP responder. 622 NetInf HTTP responders MUST accept requests sent to the following 623 paths: 625 /netinfproto/get for NetInf GET requests 627 /netinfproto/publish for NetInf PUB requests 629 /netinfproto/search for NetInf SEARCH requests 631 So for example a client would send an HTTP request containing a 632 NetInf GET to http://example.com/netinfproto/get 634 NetInf HTTP responders SHOULD also make ni URIs available at the 635 relevant well-known URL [RFC5785] for the ni URI. 636 [I-D.farrell-decade-ni] 638 NetInf protocol requests use forms. The mapping of the fields from 639 the abstract protocol is as shown in Figure 4. [[NOTE: this is a bit 640 inconsistent now, and just reflects SF's code.]] 641 ------------------------------------------------------------------ 642 Abstract | Form field | Comments (field type in form) 643 Protocol | | 644 Field | | 645 ------------------------------------------------------------------ 646 URI | urival, URI | usually an ni URI (text) 647 | loc1,loc2 | or locator 648 ------------------------------------------------------------------ 649 msg-id | msgid | a message identifier (text) 650 ------------------------------------------------------------------ 651 ext | ext | extension(s) (JSON encoded string) 652 ------------------------------------------------------------------ 653 full-ndo-flag | fullPut | true if object supplied (checkbox) 654 ------------------------------------------------------------------ 655 object | octets | object octets (file specification) 656 ------------------------------------------------------------------ 657 n/a | rform | response format required, can be 658 | | "html" or "json" (radio) 659 ------------------------------------------------------------------ 660 token | tokens | one text field with all search 661 | | keywords (text) 662 ------------------------------------------------------------------ 664 Figure 4: Form fields used in NetInf requests 666 Notes for Figure 4: 668 For GET messages: "URI" and "msgid" are mandatory. 669 "loc1" and "loc2" are optional. 670 "ext" may be used in future but no values 671 currently defined. 673 For PUBLISH messages: "URI" and "msgid" are mandatory. 674 "loc1", "loc2", "ext", "rform" and "fullPut" 675 are optional. 676 If "rform" is absent, the "json" value is 677 assumed. 678 If "fullPut" is absent, a "false" value is 679 assumed. 680 If "fullPut" is present and set to "true", 681 "octets" must be present. 682 If present, "octets" contains a file 683 specification and the object octets. 684 If present, "ext" may contain a "meta" item. 685 The value of "ext" MUST be a JSON object 686 string and the value of the "meta" item MUST 687 be a (subsidiary) object, e.g., the "ext" 688 string might be 689 { "meta": { "mi1": 5, "mi2": { ...}, 690 "mi3": "abcd". "mi4": [...] }} 692 For SEARCH messages: "msgid" and "tokens" are mandatory. 693 "rform" is optional. 694 If "rform" is absent, the "json" value is 695 assumed. 696 "ext" may be used in future but no values 697 currently defined. 699 HTTP responses for each command can differ. 701 For GET, the a successful HTTP response (HTTP response code 2xx) will 702 contain either an application/json (if no object is returned) or else 703 a multipart/mixed with two (and exactly two:-) body parts, the first 704 being an application/json and the second containing the object 705 octets, with whatever MIME type is appropriate. 707 The application/json component will consist of a JSON object that 708 SHOULD contain the following named fields: 710 NetInf A string describing the version of the NetInf protocol 711 in use (e.g., "V0.1a"). 713 ni The "canonicalized" form of the NDO as a URI in the ni 714 scheme: "canonicalized" means that the URI has empty 715 netloc and query string fields. For example: 716 "ni:///sha-256-64;gf2yhPY9Mu0" or "nih:/ 717 sha256-32;81fdb284;d". 719 msgid The value of the msgid field in the GET message that 720 resulted in this response. 722 ts The timestamp of the last update of the cached 723 information in the cache from which the NDO is being 724 sent. 726 status A code, taken from the HTTP 2xx response codes 727 indicating what has been returned (200 if both 728 affiliated data and content has been returned and 203 if 729 only affiliated data is returned). 731 ct The MIME content type of the NDO content data, if known. 732 Empty string if not yet known. 734 loclist Array of locator names (strings) from where the NDO 735 might potentially be retrieved. 737 metadata A JSON object containing any named items copied in from 738 "meta" object(s) supplied by any PUBLISH messages 739 received at the node that sent the response plus an 740 entry named "publish" which contains a string indicating 741 the class of node and software that generated the cache 742 entry. 744 searches A JSON array of objects each containing a set of strings 745 representing search tokens and information about the 746 search mechanism that resulted in a match with the NDO 747 during a previous search. 749 For PUBLISH, the HTTP response will contain an application/json or 750 text/html response, depending on the value of the rform form field. 751 (If rform is missing json is the default.) The application/json 752 structure is as for a GET response. The text/html document will 753 provide a report of the successful publication of the NDO and 754 whatever other relevant information form the affiliated information 755 seems appropriate for inspection by a human user. 757 For SEARCH, the HTTP response will contain an application/json or 758 text/html response, depending on the value of the rform form field. 759 (If rform is missing json is the default.) The application/json 760 structure is similar to the previous structures, but has a "results" 761 object that contains an array of object details. 763 6.2. UDP CL 765 The UDP CL implements the NetInf protocol with a UDP datagram 766 services, i.e., all NetInf messages are mapped to individual UDP 767 messages. The purpose is to provide a light-weight datagram-based CL 768 that can be used to implement NetInf transport protocols on top and 769 that can provide efficient communication for querying NRSs, and 770 request broadcasting/multicasting. The UDP CL provides no hop-by-hop 771 flow control, retransmission and fragmentation/re-assembly. 773 The UDP CL has two sending modes: 1) send to specified destination IP 774 address and 2) send to the well-known IPv4 multicast address 775 225.4.5.6. For both unicast and multicast the UDP port number is 776 2345. All request and response messages are JSON objects, i.e., 777 unordered sets of name/value pairs. 779 For UDP CL messages, the following JSON names for name/value pairs 780 are defined (not all objects have to be present in all messages): 782 version # the NetInf UDP CL protocol version -- currently 783 # "NetInfUDP/1.0" 785 msgType # the message type (e.g., GET) 787 uri # the NI URI 789 msgId # the message ID (must be unique per CL hop and 790 #request/response pair) 792 locators # an array of locators 794 instance # an UDP CL speaker identifier (must be unique per IP host, 795 # e.g., process ID and per process ID 797 Figure 5: UDP CL JSON request structure 799 This version of the specification defines the GET request and the 800 corresponding GET response only. 802 GET request A GET request provides the following objects: 804 version: "NetInfUDP/1.0" 806 msgType: "GET" 808 uri: name of the requested NDO 810 msgId: message ID (see above) 812 GET reponse A GET response provides the following objects: 814 version: "NetInfUDP/1.0" 816 msgType: "GET-RESP" 818 uri: name of the requested NDO 820 msgId: message ID (see above) 822 locators: a list of locator strings 824 7. Security Considerations 826 For privacy preserving reasons requestors SHOULD attempt to limit the 827 personally identifying information (PII) included with search 828 requests. Including fine-grained search keywords can expose 829 requestor PII. For this reason, we RECOMMEND that requestors include 830 more coarse grained keywords and that responders include sufficient 831 meta-data to allow the requestor to refine their search based on the 832 meta-data in the response. 834 Similarly, search responders SHOULD consider whether or not they 835 respond to all or some search requests as exposing one's cached 836 content can also be a form of PII if the cached content is generated 837 at the behest of the responder. 839 Name-data integrity validation details are TBD for some common MIME 840 types. 842 Users need to be aware that the affiliated data is NOT protected by 843 the name-data integrity as this applies only to the data content 844 octets. 846 [[More TBD no doubt.]] 848 8. Acknowledgements 850 This work has been supported by the EU FP7 project SAIL. 852 Claudio Imbrenda and Christian Dannewitz contributed to early 853 versions of this document whilst working at NEC and the University of 854 Paderborn respectively. 856 9. References 858 9.1. Normative References 860 [I-D.farrell-decade-ni] 861 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 862 Keranen, A., and P. Hallam-Baker, "Naming Things with 863 Hashes", draft-farrell-decade-ni-10 (work in progress), 864 August 2012. 866 [I-D.hallambaker-decade-ni-params] 867 Hallam-Baker, P., Stradling, R., Farrell, S., Kutscher, 868 D., and B. Ohlman, "The Named Information (ni) URI Scheme: 869 Optional Features", draft-hallambaker-decade-ni-params-03 870 (work in progress), June 2012. 872 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 873 Extensions (MIME) Part One: Format of Internet Message 874 Bodies", RFC 2045, November 1996. 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, March 1997. 879 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 880 Specifications: ABNF", STD 68, RFC 5234, January 2008. 882 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 883 RFC 5652, September 2009. 885 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 886 Uniform Resource Identifiers (URIs)", RFC 5785, 887 April 2010. 889 9.2. Informative References 891 [I-D.farrell-dtnrg-bpq] 892 Farrell, S., Lynch, A., Kutscher, D., and A. Lindgren, 893 "Bundle Protocol Query Extension Block", 894 draft-farrell-dtnrg-bpq-01 (work in progress), March 2012. 896 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 897 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 898 Networking Architecture", RFC 4838, April 2007. 900 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 901 Specification", RFC 5050, November 2007. 903 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 904 Mail Extensions (S/MIME) Version 3.2 Message 905 Specification", RFC 5751, January 2010. 907 [ref.netinf-db2] 908 SAIL, "NetInf Content Delivery and Operations", SAIL 909 Project Deliverable D-3.2 , May 2012. 911 Authors' Addresses 913 Dirk Kutscher 914 NEC 915 Kurfuersten-Anlage 36 916 Heidelberg, 917 Germany 919 Phone: 920 Email: kutscher@neclab.eu 921 Stephen Farrell 922 Trinity College Dublin 923 Dublin, 2 924 Ireland 926 Phone: +353-1-896-2354 927 Email: stephen.farrell@cs.tcd.ie 929 Elwyn Davies 930 Trinity College Dublin 931 Dublin, 2 932 Ireland 934 Phone: +44 1353 624 579 935 Fax: 936 Email: davieseb@scss.tcd.ie 937 URI: