idnits 2.17.1 draft-farrell-dtnrg-bpq-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2012) is 4425 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force S. Farrell 3 Internet-Draft A. Lynch 4 Intended status: Experimental Trinity College Dublin 5 Expires: September 9, 2012 D. Kutscher 6 NEC 7 A. Lindgren 8 Swedish Institute of Computer 9 Science 10 March 8, 2012 12 Bundle Protocol Query Extension Block 13 draft-farrell-dtnrg-bpq-01 15 Abstract 17 The Bundle Protocol (BP) provides store-and-forward networking for 18 Delay- and Disruption-Tolerant Networks. This document defines the 19 BP query extension block (BPQ) which allows applications to query the 20 stores of nodes on the path along which a bundle containing a bundle 21 query extension block is routed. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 9, 2012. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 56 3. BPQ Block Format . . . . . . . . . . . . . . . . . . . . . . . 7 57 4. BPQ Processing . . . . . . . . . . . . . . . . . . . . . . . . 8 58 5. Application Considerations . . . . . . . . . . . . . . . . . . 9 59 5.1. Usage of Endpoint Identifiers in Bundles . . . . . . . . . 9 60 5.2. Advanced Processing of Query and Copy-Response Bundles . . 11 61 6. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 66 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 67 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 70 1. Introduction 72 The Bundle Protocol (BP) specified in RFC 5050 [RFC5050] provides 73 store-and-forward networking for Delay- and Disruption-Tolerant 74 Networks (DTNs). RFC 4838 [RFC4838] This document defines the BP 75 query extension block (BPQ) which allows applications to query the 76 stores of nodes on the path along which a bundle containing a bundle 77 query extension block is routed. 79 The DTN architecture and the Bundle Protocol can be used for 80 different applications and provide a certain degree of flexibility 81 for naming sources and destinations, as well for deciding how to 82 process and forward bundles at nodes in a DTN network. 84 In some applications contexts, the Bundle Protocol is used for 85 literally transmitting some payload data from one endpoint to another 86 -- potentially leveraging store-and-forward capabilities of 87 intermediate nodes to overcome disruptions. How intermediate nodes 88 perform their forwarding decisions is not specified by either the DTN 89 architecture nor the Bundle Protocol specification, but often the 90 destination endpoint identifier (EID) would be considered. 92 But EIDs in a DTN network do not necessarily have to represent single 93 nodes -- they can be used for representing receiver groups or for 94 specifying some requested service in the network. This flexibility, 95 together with the option of using different approaches for 96 disseminating data to nodes in a network, has made DTN an attractive 97 candidate technology in a range of content distribution scenarios, 98 for instance for publish-subscribe-based content distribution 99 [ref.dpsp] and for time-aware content dissemination through info 100 stations [ref.taco-dtn]. 102 In some scenarios, DTN bundles can have query semantics, i.e., a 103 bundle is sent in order to query for some information object -- or a 104 copy of it that can be available on some DTN node as the result of a 105 specific dissemination/routing strategy. Thus, sometimes when you 106 send a query in a DTN, an intermediate BP node already has the data 107 you want, and there should be a way to get that data, without having 108 to go all the way to the "source" of the data which is, of course, 109 the destination for a query bundle. 111 The BPQ that is specified in this memo is intended to allow such 112 queries that can be answered by intermediate BP nodes, where those 113 nodes do not necessarily have to be addressed by the destination EID 114 of a corresponding request message. 116 A use case: Alice and Bob both want to get a video. Alice first asks 117 for this using the BP. Now Bob, who's nearby Alice also wants to see 118 the same video, and as it happens, due to the routing scheme in 119 force, the video is still stored at Bob's "next hop" DTN router. 120 Wouldn't it be nice if Bob could just query the DTN as a whole and in 121 this case, get the response he wants from a nearby node via probably 122 far less delayed or disrupted links. The BPQ extension block defined 123 here provides a way to enable this kind of re-use of DTN router 124 storage. 126 The BPQ extension block is intended as an enabling mechanism for such 127 applications without anticipating a specific behaviour with respect 128 to EID semantics and routing strategies. Also, it is intended as an 129 optional enhancement to DTN node implementations and does not require 130 all nodes in a network to actually support the extension to be 131 useful. In Section 2 we provide an overview of the general protocol 132 operation, Section 3 specifies the actual BPQ block format, and 133 Section 4 provides the processing requirements for DTN nodes. 134 Section 5 describes a few non-normative application considerations 135 for BPQ, and Section 6 refers to related work. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 2. Protocol Overview 143 The basic idea of the query extension block is that a "query" bundle 144 can contain whatever information is required for the query to succeed 145 when that bundle reaches its destination. This information is 146 typically contained within the BPQ extension block but may also be 147 sent in the application layer payload. 149 One, though not the only, possibility is that the query-response 150 payload has a name (e.g. a file name or a name derived from the query 151 or response payload via hash functions). In such cases, the BPQ 152 extension block can simply contain the data required (plus ancillary 153 data as described below). 155 BP nodes that do not support BPQ simply (store, and) forward query 156 bundles and response bundles as normal and are unaffected. 158 BP nodes supporting BPQ compare the value of the BPQ in an inbound 159 bundle against their bundle cache (details below) and when a matching 160 bundle is found they then respond to the source of the query bundle 161 with a bundle containing the payload of the matching bundle, together 162 with BPQ data that allows other DTN nodes to also successfully match 163 the query and response. 165 When a match is found in the cache, the response bundle that is sent 166 SHOULD be a copy of the bundle in the cache. If the original bundle 167 is sent more than once, subsequent BP nodes may discard the bundles 168 as a duplicates. As the BP uniquely identifies bundles from their 169 creation time-stamp (seconds and sequence number) and their source 170 EID, only changing the destination is not sufficient to avoid 171 duplicate detection. 173 When a response is copied the source EID of the response bundle MUST 174 be set to the local EID and the creation time-stamp MUST be updated 175 to the current time. This changes the bundle ID and prevents it from 176 being discarded as a duplicate. To retain the original ID, an 177 immutable copy of the original creation time-stamp and source EID is 178 stored in the BPQ. 180 When a bundle is copied and its time-stamp is updated, the bundle's 181 lifetime MUST also be adjusted. The lifetime value is relative to 182 the creation time-stamp. If left unchanged, copying a bundle would 183 inadvertently extend the bundles lifetime. 185 Various schemes could be used in order to allow matching the query 186 bundle with a bundle stored on a node, but the simplest way to handle 187 this is simply for there to be an identical unique BPQ value in the 188 response bundle. (The response bundle must also be marked as a 189 response in order not to confuse Alice and Bob's separate queries for 190 the same video.) 192 If a node supporting BPQ finds a complete (i.e. not fragmentary) 193 matching response bundle, then it can produce a copy-response bundle 194 for the requester with the same payload and send that back to the 195 source of the query bundle. In this case, the query bundle need not 196 be forwarded further and can be deleted. For this reason payloads 197 contained in query bundles are not guaranteed to be delivered to 198 their destination. 200 [question: what to do with status reports in this case if the query 201 bundle asked for them? they're not a good idea in any case but I 202 suppose we should say] 204 BPQ aware nodes can store and match against response fragments as 205 well as complete responses. Depending on the content, it does not 206 always make sense for fragments to be cached. For example, the use 207 of intentional names can result in more than one response sharing the 208 same name while having different payloads. In this case nodes SHOULD 209 NOT try to cache fragments or partially answer queries, since 210 fragments from different payloads SHOULD NOT be recombined. For this 211 reason there are two kinds response, normal responses for which 212 fragments may be cached and reassembled, and responses where this is 213 restricted. This in no way influences caching of complete bundles. 215 In the event that the matching response bundle is only a fragment, 216 then the node discovering that match responds with a copy-response 217 bundle containing the fragment. The node SHOULD forward a modified 218 query bundle which reflects the matched fragment, so that other 219 fragments may be retrieved from elsewhere on the query bundle's path. 221 Fragments already marked in the query as matched SHOULD NOT be re- 222 sent. A matched fragment that is a super-set of a previously matched 223 fragment (including a complete match) MAY be returned. If the node 224 finds a set of matching fragments that fully cover the payload, then 225 the node SHOULD NOT forward the query bundle. 227 [question: should a single copy-response be sent, thus re-assembling 228 fragments, or should the just send each fragment as a bundle as it 229 itself received? think about PIB in that case. - ans below.] 231 Fragments MAY be re-assembled by a cache before being returned. This 232 is NOT required as fragments originating from different bundles may 233 contain additional (different) extension blocks. Intermediate nodes 234 MAY respond with multiple fragments for the destination to recombine. 236 In order to allow matching, response bundles (and all fragments 237 thereof) sent out by the "source" of the response, also include a 238 BPQ. In this way, nodes that support BPQ can easily match queries 239 and responses. 241 In principle, there could be many ways to match a query bundle with a 242 response bundle. For example, the query bundle could contain a SQL- 243 like query and the response bundle BPQ extension could contain a 244 database that returns a non-Null response when the query is 245 "executed" by a node. This document however, only specifies an 246 "exact match" matching rule, where the query and response bundles 247 only match if both contain the same set of bits. Other matching 248 rules may be defined in future. 250 Since response bundles containing the BPQ are intended to be re-used, 251 it would appear to be sensible to store such bundles for as long as 252 possible, regardless of routing decisions. (Routing schemes may also 253 call for bundles to be stored, even after having been forwarded one 254 or more times.) 256 [question: the bundles currently live in the cache until they expire 257 or are evicted due to size restrictions. Popular content could have 258 its lifetime extended but this prevents the bundle expiry being used 259 for cache coherency.] 261 3. BPQ Block Format 263 The BPQ consists of: 265 o Block type code (1 byte) defined as in all bundle protocol blocks 266 except the primary bundle block (as described in the Bundle 267 Protocol). The block type code for the BPQ Block is 0xC8 (this is 268 an experimental type) 270 o Block processing control flags (SDNV) - defined as in all bundle 271 protocol blocks except the primary bundle block. SDNV encoding is 272 described in the Bundle Protocol. If a bundle node receives a 273 bundle with a BPQ block and it is capable of supporting the BPQ 274 block but it is not able to parse and process the BPQ value 275 itself, either because it does not support the kind or type being 276 used or because the data is not well-formed, the bundle node MUST 277 process the bundle as if it cannot process the BPQ block. That 278 is, it must operate according to the settings of the Block 279 Processing Control Flags, including the "Delete bundle if block 280 can't be processed" flag and the "Discard block if it can't be 281 processed" flag. The "Block must be replicated in every fragment" 282 bit MUST be set in all BPQ extension blocks. 284 o Block data length (SDNV) - defined as in all bundle protocol 285 blocks except the primary bundle block. SDNV encoding is 286 described in the bundle protocol. 288 Block-type-specific data fields as follows: 290 o A BPQ-kind field (1 byte), with 0x00 meaning a query, 0x01 meaning 291 a response, and 0x02 meaning a response for which fragments MUST 292 NOT be cached. Other values are reserved. 294 o A matching rule type (1 byte) that tells routers how to match the 295 BPQ from a query with the BPQ of a response. Only matching rule 296 type 0x00 is defined here, which represents the "exact match" rule 297 as further defined below. The matching rule MUST be the same in 298 both a query and response in order for there to be a match. 300 o An original creation time-stamp (seconds and sequence number). 301 This is the same pair of SDNVs that are initially set in the 302 bundle's primary block. This time-stamp MUST NOT be modified once 303 set. This MAY be left unset for query bundles. 305 o An original source EID length field (SDNV) the contains the length 306 of the original source EID. 308 o An original source EID. Since this may be changed in the primary 309 block when the bundle is copied, this original copy is required to 310 uniquely identify the bundle. This EID MUST NOT be modified once 311 set. This MAY be left unset for query bundles. 313 o A BPQ-value-length field (SDNV) the contains the length of the 314 BPQ-value. 316 o A BPQ-value field with the length indicated by the BPQ-value- 317 length field, that identifies the relevant response payload and is 318 interpreted according to the matching rule field. 320 o The number of fragments already returned (SDNV) 322 o Where the number of fragments already returned is non-zero, an 323 ordered list containing offset, length pairs (encoded as SDNVs) 324 indicating previously matched fragments. This MAY be recalculated 325 as new fragments are found and overlapping (or adjacent) fragment 326 information MAY be merged. 328 4. BPQ Processing 330 If no match is found, then the node MUST forward the query bundle as 331 if the BPQ block were not present. 333 When creating the copy-response bundle, the source EID of the 334 response bundle MUST contain an EID for the node that found the 335 match. The reply-to EID of copy-response bundle SHOULD be set to the 336 reply-to EID of original response bundle and the destination EID of 337 the copy-response bundle MUST be set to the source EID of the query 338 bundle. 340 The creation time-stamp of the bundle MUST be set to the current 341 time. The difference (in seconds) between the previous time-stamp 342 and the current time MUST be subtracted from the bundle's lifetime 343 value. 345 The payload and all other extension blocks present in the response 346 bundle MUST be copied into the copy-response bundle. 348 Basically, the only difference between a response bundle and a copy- 349 response bundle is the bundle identifier and the source and 350 destination EIDs and the time-stamp and lifetime values. 352 [note: need to check other primary block fields and say what, if 353 anything, to do for each, e.g. for current custodian etc. - a bit of 354 thought needed. 356 When a node is comparing a query bundle against a potential matching 357 bundle using the exact match matching rule, the bundles match iff the 358 BPQ-value field of both are identical. 360 If a matching response bundle is not a fragment, then the query 361 bundle SHOULD NOT be further forwarded by the node in question but 362 SHOULD be deleted after the response bundle has been queued for 363 transmission, as the query has been satisfied. 365 If a matching response bundle is a fragment, then the node SHOULD 366 continue searching in case it has other fragments that match the 367 query. In that case, each fragment is sent as a separate copy- 368 response bundle. That is, the node finding the match SHOULD re- 369 assemble the fragments of the entire bundle, if the node knows how to 370 combine the different sets of extensions blocks of the fragments. If 371 the matching node does not know how to combine the extension blocks, 372 it MUST NOT re-assemble the fragments. The reason is that each 373 fragment could have different sets of extension blocks present and 374 the node might not know how to combine those properly. 376 If a matching response bundle is a fragment, and the node does not 377 have a full set of fragments (that together contain the entire 378 payload) then the node MUST forward the query bundle as would have 379 happened had no match been found. 381 Custody and status report settings for the copy-response bundle 382 bundle SHOULD be set to the same values are were present in the 383 matching response bundle unless the node is specifically configured 384 to do otherwise. 386 [question: is that right? do we really want all those reports and 387 custody acks? There may be a wrinkle there with custody.] 389 [Lots more tedious but obvious detail TBD.] 391 5. Application Considerations 393 This section provides some non-normative considerations on how BPQ 394 can be used. 396 5.1. Usage of Endpoint Identifiers in Bundles 398 DTN EIDs usage for BPQ queries and replies needs to be considered 399 for: 401 o source EIDs in query bundles 402 o destination EIDs in query bundles 404 o source EIDs in (copy-) response bundles 406 o destination EIDs in (copy-) response bundles 408 Source EIDs in query bundles should normally be set to the node EID 409 of query originator. 411 For the destination EID in query bundles, there are three different 412 options: 414 1. Some destination EID if the source of some content is actually 415 known). This could also be interpreted as a default EID for a 416 node to which the query should be forwarded to. 418 2. Some namespace or application identifier such as "dtn:appX" 420 3. An actual information object ID (perhaps with a namespace prefix) 421 such as "dtn:appX:45a87e5d" 423 Ideally, the destination EID for queries should allow non-BPQ-aware 424 DTN nodes to "do the right thing", i.e., forward the bundle to a node 425 with (a copy of) the requested resource. More concretely, specific 426 DTN routing protocols should still work as intended, and these 427 protocols normally perform decision based on the destination EID. 429 For the source EID in (copy-) response bundles, there are essentially 430 two options: 432 1. The EID of the origin DTN node for the requested resource 434 2. The EID of the node that generating the reply, which could be an 435 intermediate BP node that happens to have a matching resource for 436 the request. This option would make the operation of 437 intermediates visible to the actual receivers (normally 438 considered a desirable property) but would end-to-end security 439 (that is based on the source EID). 441 The destination of (copy-) response bundles should normally set to 442 the node EID of the original sender of the request to enable a DTN 443 network to forward the response bundle to this node. However, 444 specific application scenarios may want to leverage DTN multicast 445 capabilities, e.g. when many nodes are interested in a specific 446 resource so that other EID naming strategies become more attractive. 448 5.2. Advanced Processing of Query and Copy-Response Bundles 450 In some named-content distribution scenarios, BPQ nodes can perform 451 additional operations compared to either returning matched bundles or 452 forwarding request bundles. An intermediate BPQ node could also keep 453 an interest table for the requested resource and then later, when a 454 matching resource is available, satisfy the pending requests. This 455 mode of operation could be extended to fragments as well: an 456 intermediate BPQ that has received a request for resource A, for 457 which it has only fragments, could decide to send the fragment(s) 458 directly, or -- e.g. in case of a disruption -- maintain the pending 459 request and complete the response bundle with received fragments 460 until a (more) complete response bundle is eventually sent. 462 When an intermediate BPQ node follows the strategy of maintaining a 463 list of pending requests, there might be a number of requests for the 464 same resource, e.g., for popular content. For such scenarios it 465 would be beneficial to not have to create individual response bundles 466 for the same resource to be sent to each interested node on the 467 network. Domain-specific routing protocols and adequate usage of 468 destination EIDs could be employed in these cases. 470 6. Related Work 472 Using the Bundle Protocol to query the network for near-by resources 473 has been explored in different approaches. Greifenberg and Kutscher 474 have described a DTN Publish-Subscribe Protocol (DPSP) in [ref.dpsp] 475 that allows interested nodes to register interest in some names 476 resource to the network. DPSP nodes would aggregate such 477 subscriptions and forward it towards the direction of an origin node. 478 Corresponding content bundles would be distributed along a tree that 479 has been built implicitly by the subscription messages. In DPSP, 480 destination EIDs in subscription bundles specify the named resource 481 (e.g. content channel), and the subscription information is conveyed 482 in an extension block to enable inter-working with unmodified DTN 483 nodes and routing protocols. 485 Sollazzo, Musolesi and Mascolo have described a Time-Aware COntent- 486 based dissemination system for DTNs (TACO-DTN) in [ref.taco-dtn] that 487 takes time-based information into account to optimize content 488 dissemination in a subscription-based approach. Temporal profiles 489 are associated to each subscription and allow the construction of 490 temporal profiles of info-stations. 492 More general, the idea of accessing named information objects in the 493 network, regardless of the actual object location, is a key notion in 494 different Information-Centric Networking approaches. Ahlgren, 495 D'Ambrosio, Dannewitz et al have developed an elaborate information 496 model for such information objects in [ref.netinf-design]. In the 497 Network of Information approach, information objects can be accessed 498 by unique names that provide additional properties such as self- 499 certification, i.e., provide a cryptographic relation between the 500 object and the name. In such an approach, interested nodes would 501 query the network for specific named objects and the network would 502 perform name-based routing and/or resolution to locators to satisfy 503 such requests. 505 A similar approach is the Content-Centric Networking (CCN) approach 506 described by Jacobsen, Smetters, Thornton et al in [ref.ccn]. In 507 CCN, network nodes receive so-called Interest Packets for names 508 content from interested nodes. Such Interest Packets can be 509 aggregated, and forwarded according to name-based routing 510 information. Corresponding data packets are forwarded in the reverse 511 direction, based on Interest Table state that is maintained at 512 intermediate nodes -- quite similar to the DPSP approach described 513 above. 515 The Query Extension Block as described in this memo could be used to 516 inter-connect DTNs to such Information-Centric Networks and/or to 517 implement Information-Centric Networking with the Bundle Protocol. 519 7. IANA Considerations 521 We'll want an extension block number and maybe a new registry for 522 query kinds and matching rule types if we stick with the above. 524 8. Security Considerations 526 The BPQ in principle allows a node to probe the storage of another 527 node. If BPQ-values are guessable, then this would work. If this is 528 a concern, the unguessable BPQ-values SHOULD be used. 530 The BPQ imposes a load on nodes that support it. If such a load is 531 considered a potential DoS vector, then nodes SHOULD implement some 532 controls on the amount of searching they are willing to carry out. 533 This could be a simple limit, or could depend on the source (or 534 authentication status) of the query bundle. 536 Since the copy-response comes from the matching node, the response 537 bundle's authentication information (e.g. PIB) will not be usable 538 with the copy-response. 540 [note: not sure what to do about this as yet.] 541 If confidentiality of the query-response payload is required the PCB 542 block can be used to provide that service. However, BPQ values could 543 leak information about the payload, for example if the BPQ value were 544 a hash of the payload, then the BPQ value would allow an attacker to 545 check whether a guess of the payload value was correct or not. If 546 this is a concern, then BPQ values SHOULD be chosen so as not to leak 547 information about the response payload. 549 9. References 551 9.1. Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 557 Specification", RFC 5050, November 2007. 559 9.2. Informative References 561 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 562 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 563 Networking Architecture", RFC 4838, April 2007. 565 [ref.ccn] Jacobsen, K, D, F, H, and L, "Networking Named Content", 566 CoNEXT 2009 , December 2009. 568 [ref.dpsp] 569 Greifenberg and Kutscher, "Efficient Publish/ 570 Subscribe-based Multicast for Opportunistic Networking 571 with Self-Organized Resource Utilization", The First IEEE 572 International Workshop on Opportunistic Networking (WON- 573 2008), March 2008. 575 [ref.netinf-design] 576 Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, 577 Pentikousis, Rembarz, Strandberg, and Vercellone, "Design 578 Considerations for a Network of Information", Re-Arch 2008 579 Workshop , December 2008. 581 [ref.taco-dtn] 582 Sollazzo, Musolesi, and Mascolo, "TACO-DTN: A Time-Aware 583 COntent-based dissemination system for Delay Tolerant 584 Networks", MobiOpp 2007 Workshop , 2007. 586 Appendix A. ChangeLog 588 This section to be deleted later. The most recent changes should be 589 added to the end of the list. 591 Stephen: initial version 593 Dirk: added some text to the introduction 595 Dirk: moved some text from introduction to separate section 596 "protocol overview" 598 Dirk: changes processing requirements for fragmented response 599 bundles as discussed 601 Dirk: added section on Application Considerations 603 Dirk: added text to related work section 605 Aidan: Added text about adding already-returned fragments to the 606 query 608 Stephen: Added payload confidentiality sec. cons. note 610 Aidan: Added text intentional naming and combining fragments using 611 original src eid 613 Authors' Addresses 615 Stephen Farrell 616 Trinity College Dublin 617 Dublin, 2 618 Ireland 620 Phone: +353-1-896-2354 621 Email: stephen.farrell@cs.tcd.ie 623 Aidan Lynch 624 Trinity College Dublin 625 Dublin, 2 626 Ireland 628 Phone: 629 Email: lyncha6@tcd.ie 630 Dirk Kutscher 631 NEC 632 Kurfuersten-Anlage 36 633 Heidelberg, 634 Germany 636 Phone: 637 Email: kutscher@neclab.eu 639 Anders Lindgren 640 Swedish Institute of Computer Science 641 Stockholm, 642 Sweden 644 Phone: 645 Email: andersl@sics.se