[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-farrell-dtnrg-bpq) 00

Internet Research Task Force                                  S. Farrell
Internet-Draft                                                  A. Lynch
Intended status: Experimental                     Trinity College Dublin
Expires: November 15, 2012                                   D. Kutscher
                                                                     NEC
                                                             A. Lindgren
                                           Swedish Institute of Computer
                                                                 Science
                                                            May 14, 2012


                 Bundle Protocol Query Extension Block
                        draft-irtf-dtnrg-bpq-00

Abstract

   The Bundle Protocol (BP) provides store-and-forward networking for
   Delay- and Disruption-Tolerant Networks.  This document defines the
   BP query extension block (BPQ) which allows applications to query the
   stores of nodes on the path along which a bundle containing a bundle
   query extension block is routed.

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 November 15, 2012.

Copyright Notice

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



Farrell, et al.         Expires November 15, 2012               [Page 1]


Internet-Draft                  DTNRG BPQ                       May 2012


   carefully, as they describe your rights and restrictions with respect
   to this document.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  BPQ Block Format . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  BPQ Processing . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Application Considerations . . . . . . . . . . . . . . . . . .  9
     5.1.  Usage of Endpoint Identifiers in Bundles . . . . . . . . .  9
     5.2.  Advanced Processing of Query and Copy-Response Bundles . . 11
   6.  Related Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  ChangeLog . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14






























Farrell, et al.         Expires November 15, 2012               [Page 2]


Internet-Draft                  DTNRG BPQ                       May 2012


1.  Introduction

   The Bundle Protocol (BP) specified in RFC 5050 [RFC5050] provides
   store-and-forward networking for Delay- and Disruption-Tolerant
   Networks (DTNs).  RFC 4838 [RFC4838] This document defines the BP
   query extension block (BPQ) which allows applications to query the
   stores of nodes on the path along which a bundle containing a bundle
   query extension block is routed.

   The DTN architecture and the Bundle Protocol can be used for
   different applications and provide a certain degree of flexibility
   for naming sources and destinations, as well for deciding how to
   process and forward bundles at nodes in a DTN network.

   In some applications contexts, the Bundle Protocol is used for
   literally transmitting some payload data from one endpoint to another
   -- potentially leveraging store-and-forward capabilities of
   intermediate nodes to overcome disruptions.  How intermediate nodes
   perform their forwarding decisions is not specified by either the DTN
   architecture nor the Bundle Protocol specification, but often the
   destination endpoint identifier (EID) would be considered.

   But EIDs in a DTN network do not necessarily have to represent single
   nodes -- they can be used for representing receiver groups or for
   specifying some requested service in the network.  This flexibility,
   together with the option of using different approaches for
   disseminating data to nodes in a network, has made DTN an attractive
   candidate technology in a range of content distribution scenarios,
   for instance for publish-subscribe-based content distribution
   [ref.dpsp] and for time-aware content dissemination through info
   stations [ref.taco-dtn].

   In some scenarios, DTN bundles can have query semantics, i.e., a
   bundle is sent in order to query for some information object -- or a
   copy of it that can be available on some DTN node as the result of a
   specific dissemination/routing strategy.  Thus, sometimes when you
   send a query in a DTN, an intermediate BP node already has the data
   you want, and there should be a way to get that data, without having
   to go all the way to the "source" of the data which is, of course,
   the destination for a query bundle.

   The BPQ that is specified in this memo is intended to allow such
   queries that can be answered by intermediate BP nodes, where those
   nodes do not necessarily have to be addressed by the destination EID
   of a corresponding request message.

   A use case: Alice and Bob both want to get a video.  Alice first asks
   for this using the BP.  Now Bob, who's nearby Alice also wants to see



Farrell, et al.         Expires November 15, 2012               [Page 3]


Internet-Draft                  DTNRG BPQ                       May 2012


   the same video, and as it happens, due to the routing scheme in
   force, the video is still stored at Bob's "next hop" DTN router.
   Wouldn't it be nice if Bob could just query the DTN as a whole and in
   this case, get the response he wants from a nearby node via probably
   far less delayed or disrupted links.  The BPQ extension block defined
   here provides a way to enable this kind of re-use of DTN router
   storage.

   The BPQ extension block is intended as an enabling mechanism for such
   applications without anticipating a specific behaviour with respect
   to EID semantics and routing strategies.  Also, it is intended as an
   optional enhancement to DTN node implementations and does not require
   all nodes in a network to actually support the extension to be
   useful.  In Section 2 we provide an overview of the general protocol
   operation, Section 3 specifies the actual BPQ block format, and
   Section 4 provides the processing requirements for DTN nodes.
   Section 5 describes a few non-normative application considerations
   for BPQ, and Section 6 refers to related work.

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


2.  Protocol Overview

   The basic idea of the query extension block is that a "query" bundle
   can contain whatever information is required for the query to succeed
   when that bundle reaches its destination.  This information is
   typically contained within the BPQ extension block but may also be
   sent in the application layer payload.

   One, though not the only, possibility is that the query-response
   payload has a name (e.g. a file name or a name derived from the query
   or response payload via hash functions).  In such cases, the BPQ
   extension block can simply contain the data required (plus ancillary
   data as described below).

   BP nodes that do not support BPQ simply (store, and) forward query
   bundles and response bundles as normal and are unaffected.

   BP nodes supporting BPQ compare the value of the BPQ in an inbound
   bundle against their bundle cache (details below) and when a matching
   bundle is found they then respond to the source of the query bundle
   with a bundle containing the payload of the matching bundle, together
   with BPQ data that allows other DTN nodes to also successfully match
   the query and response.




Farrell, et al.         Expires November 15, 2012               [Page 4]


Internet-Draft                  DTNRG BPQ                       May 2012


   When a match is found in the cache, the response bundle that is sent
   SHOULD be a copy of the bundle in the cache.  If the original bundle
   is sent more than once, subsequent BP nodes may discard the bundles
   as a duplicates.  As the BP uniquely identifies bundles from their
   creation time-stamp (seconds and sequence number) and their source
   EID, only changing the destination is not sufficient to avoid
   duplicate detection.

   When a response is copied the source EID of the response bundle MUST
   be set to the local EID and the creation time-stamp MUST be updated
   to the current time.  This changes the bundle ID and prevents it from
   being discarded as a duplicate.  To retain the original ID, an
   immutable copy of the original creation time-stamp and source EID is
   stored in the BPQ.

   When a bundle is copied and its time-stamp is updated, the bundle's
   lifetime MUST also be adjusted.  The lifetime value is relative to
   the creation time-stamp.  If left unchanged, copying a bundle would
   inadvertently extend the bundles lifetime.

   Various schemes could be used in order to allow matching the query
   bundle with a bundle stored on a node, but the simplest way to handle
   this is simply for there to be an identical unique BPQ value in the
   response bundle.  (The response bundle must also be marked as a
   response in order not to confuse Alice and Bob's separate queries for
   the same video.)

   If a node supporting BPQ finds a complete (i.e. not fragmentary)
   matching response bundle, then it can produce a copy-response bundle
   for the requester with the same payload and send that back to the
   source of the query bundle.  In this case, the query bundle need not
   be forwarded further and can be deleted.  For this reason payloads
   contained in query bundles are not guaranteed to be delivered to
   their destination.

   [question: what to do with status reports in this case if the query
   bundle asked for them? they're not a good idea in any case but I
   suppose we should say]

   BPQ aware nodes can store and match against response fragments as
   well as complete responses.  Depending on the content, it does not
   always make sense for fragments to be cached.  For example, the use
   of intentional names can result in more than one response sharing the
   same name while having different payloads.  In this case nodes SHOULD
   NOT try to cache fragments or partially answer queries, since
   fragments from different payloads SHOULD NOT be recombined.  For this
   reason there are two kinds response, normal responses for which
   fragments may be cached and reassembled, and responses where this is



Farrell, et al.         Expires November 15, 2012               [Page 5]


Internet-Draft                  DTNRG BPQ                       May 2012


   restricted.  This in no way influences caching of complete bundles.

   In the event that the matching response bundle is only a fragment,
   then the node discovering that match responds with a copy-response
   bundle containing the fragment.  The node SHOULD forward a modified
   query bundle which reflects the matched fragment, so that other
   fragments may be retrieved from elsewhere on the query bundle's path.

   Fragments already marked in the query as matched SHOULD NOT be re-
   sent.  A matched fragment that is a super-set of a previously matched
   fragment (including a complete match) MAY be returned.  If the node
   finds a set of matching fragments that fully cover the payload, then
   the node SHOULD NOT forward the query bundle.

   [question: should a single copy-response be sent, thus re-assembling
   fragments, or should the just send each fragment as a bundle as it
   itself received? think about PIB in that case. - ans below.]

   Fragments MAY be re-assembled by a cache before being returned.  This
   is NOT required as fragments originating from different bundles may
   contain additional (different) extension blocks.  Intermediate nodes
   MAY respond with multiple fragments for the destination to recombine.

   In order to allow matching, response bundles (and all fragments
   thereof) sent out by the "source" of the response, also include a
   BPQ.  In this way, nodes that support BPQ can easily match queries
   and responses.

   In principle, there could be many ways to match a query bundle with a
   response bundle.  For example, the query bundle could contain a SQL-
   like query and the response bundle BPQ extension could contain a
   database that returns a non-Null response when the query is
   "executed" by a node.  This document however, only specifies an
   "exact match" matching rule, where the query and response bundles
   only match if both contain the same set of bits.  Other matching
   rules may be defined in future.

   Since response bundles containing the BPQ are intended to be re-used,
   it would appear to be sensible to store such bundles for as long as
   possible, regardless of routing decisions.  (Routing schemes may also
   call for bundles to be stored, even after having been forwarded one
   or more times.)

   [question: the bundles currently live in the cache until they expire
   or are evicted due to size restrictions.  Popular content could have
   its lifetime extended but this prevents the bundle expiry being used
   for cache coherency.]




Farrell, et al.         Expires November 15, 2012               [Page 6]


Internet-Draft                  DTNRG BPQ                       May 2012


3.  BPQ Block Format

   The BPQ consists of:

   o  Block type code (1 byte) defined as in all bundle protocol blocks
      except the primary bundle block (as described in the Bundle
      Protocol).  The block type code for the BPQ Block is 0xC8 (this is
      an experimental type)

   o  Block processing control flags (SDNV) - defined as in all bundle
      protocol blocks except the primary bundle block.  SDNV encoding is
      described in the Bundle Protocol.  If a bundle node receives a
      bundle with a BPQ block and it is capable of supporting the BPQ
      block but it is not able to parse and process the BPQ value
      itself, either because it does not support the kind or type being
      used or because the data is not well-formed, the bundle node MUST
      process the bundle as if it cannot process the BPQ block.  That
      is, it must operate according to the settings of the Block
      Processing Control Flags, including the "Delete bundle if block
      can't be processed" flag and the "Discard block if it can't be
      processed" flag.  The "Block must be replicated in every fragment"
      bit MUST be set in all BPQ extension blocks.

   o  Block data length (SDNV) - defined as in all bundle protocol
      blocks except the primary bundle block.  SDNV encoding is
      described in the bundle protocol.

   Block-type-specific data fields as follows:

   o  A BPQ-kind field (1 byte), with 0x00 meaning a query, 0x01 meaning
      a response, and 0x02 meaning a response for which fragments MUST
      NOT be cached.  Other values are reserved.

   o  A matching rule type (1 byte) that tells routers how to match the
      BPQ from a query with the BPQ of a response.  Only matching rule
      type 0x00 is defined here, which represents the "exact match" rule
      as further defined below.  The matching rule MUST be the same in
      both a query and response in order for there to be a match.

   o  An original creation time-stamp (seconds and sequence number).
      This is the same pair of SDNVs that are initially set in the
      bundle's primary block.  This time-stamp MUST NOT be modified once
      set.  This MAY be left unset for query bundles.

   o  An original source EID length field (SDNV) the contains the length
      of the original source EID.





Farrell, et al.         Expires November 15, 2012               [Page 7]


Internet-Draft                  DTNRG BPQ                       May 2012


   o  An original source EID.  Since this may be changed in the primary
      block when the bundle is copied, this original copy is required to
      uniquely identify the bundle.  This EID MUST NOT be modified once
      set.  This MAY be left unset for query bundles.

   o  A BPQ-value-length field (SDNV) the contains the length of the
      BPQ-value.

   o  A BPQ-value field with the length indicated by the BPQ-value-
      length field, that identifies the relevant response payload and is
      interpreted according to the matching rule field.

   o  The number of fragments already returned (SDNV)

   o  Where the number of fragments already returned is non-zero, an
      ordered list containing offset, length pairs (encoded as SDNVs)
      indicating previously matched fragments.  This MAY be recalculated
      as new fragments are found and overlapping (or adjacent) fragment
      information MAY be merged.


4.  BPQ Processing

   If no match is found, then the node MUST forward the query bundle as
   if the BPQ block were not present.

   When creating the copy-response bundle, the source EID of the
   response bundle MUST contain an EID for the node that found the
   match.  The reply-to EID of copy-response bundle SHOULD be set to the
   reply-to EID of original response bundle and the destination EID of
   the copy-response bundle MUST be set to the source EID of the query
   bundle.

   The creation time-stamp of the bundle MUST be set to the current
   time.  The difference (in seconds) between the previous time-stamp
   and the current time MUST be subtracted from the bundle's lifetime
   value.

   The payload and all other extension blocks present in the response
   bundle MUST be copied into the copy-response bundle.

   Basically, the only difference between a response bundle and a copy-
   response bundle is the bundle identifier and the source and
   destination EIDs and the time-stamp and lifetime values.

   [note: need to check other primary block fields and say what, if
   anything, to do for each, e.g. for current custodian etc. - a bit of
   thought needed.



Farrell, et al.         Expires November 15, 2012               [Page 8]


Internet-Draft                  DTNRG BPQ                       May 2012


   When a node is comparing a query bundle against a potential matching
   bundle using the exact match matching rule, the bundles match iff the
   BPQ-value field of both are identical.

   If a matching response bundle is not a fragment, then the query
   bundle SHOULD NOT be further forwarded by the node in question but
   SHOULD be deleted after the response bundle has been queued for
   transmission, as the query has been satisfied.

   If a matching response bundle is a fragment, then the node SHOULD
   continue searching in case it has other fragments that match the
   query.  In that case, each fragment is sent as a separate copy-
   response bundle.  That is, the node finding the match SHOULD re-
   assemble the fragments of the entire bundle, if the node knows how to
   combine the different sets of extensions blocks of the fragments.  If
   the matching node does not know how to combine the extension blocks,
   it MUST NOT re-assemble the fragments.  The reason is that each
   fragment could have different sets of extension blocks present and
   the node might not know how to combine those properly.

   If a matching response bundle is a fragment, and the node does not
   have a full set of fragments (that together contain the entire
   payload) then the node MUST forward the query bundle as would have
   happened had no match been found.

   Custody and status report settings for the copy-response bundle
   bundle SHOULD be set to the same values are were present in the
   matching response bundle unless the node is specifically configured
   to do otherwise.

   [question: is that right? do we really want all those reports and
   custody acks?  There may be a wrinkle there with custody.]

   [Lots more tedious but obvious detail TBD.]


5.  Application Considerations

   This section provides some non-normative considerations on how BPQ
   can be used.

5.1.  Usage of Endpoint Identifiers in Bundles

   DTN EIDs usage for BPQ queries and replies needs to be considered
   for:

   o  source EIDs in query bundles




Farrell, et al.         Expires November 15, 2012               [Page 9]


Internet-Draft                  DTNRG BPQ                       May 2012


   o  destination EIDs in query bundles

   o  source EIDs in (copy-) response bundles

   o  destination EIDs in (copy-) response bundles

   Source EIDs in query bundles should normally be set to the node EID
   of query originator.

   For the destination EID in query bundles, there are three different
   options:

   1.  Some destination EID if the source of some content is actually
       known).  This could also be interpreted as a default EID for a
       node to which the query should be forwarded to.

   2.  Some namespace or application identifier such as "dtn:appX"

   3.  An actual information object ID (perhaps with a namespace prefix)
       such as "dtn:appX:45a87e5d"

   Ideally, the destination EID for queries should allow non-BPQ-aware
   DTN nodes to "do the right thing", i.e., forward the bundle to a node
   with (a copy of) the requested resource.  More concretely, specific
   DTN routing protocols should still work as intended, and these
   protocols normally perform decision based on the destination EID.

   For the source EID in (copy-) response bundles, there are essentially
   two options:

   1.  The EID of the origin DTN node for the requested resource

   2.  The EID of the node that generating the reply, which could be an
       intermediate BP node that happens to have a matching resource for
       the request.  This option would make the operation of
       intermediates visible to the actual receivers (normally
       considered a desirable property) but would end-to-end security
       (that is based on the source EID).

   The destination of (copy-) response bundles should normally set to
   the node EID of the original sender of the request to enable a DTN
   network to forward the response bundle to this node.  However,
   specific application scenarios may want to leverage DTN multicast
   capabilities, e.g. when many nodes are interested in a specific
   resource so that other EID naming strategies become more attractive.






Farrell, et al.         Expires November 15, 2012              [Page 10]


Internet-Draft                  DTNRG BPQ                       May 2012


5.2.  Advanced Processing of Query and Copy-Response Bundles

   In some named-content distribution scenarios, BPQ nodes can perform
   additional operations compared to either returning matched bundles or
   forwarding request bundles.  An intermediate BPQ node could also keep
   an interest table for the requested resource and then later, when a
   matching resource is available, satisfy the pending requests.  This
   mode of operation could be extended to fragments as well: an
   intermediate BPQ that has received a request for resource A, for
   which it has only fragments, could decide to send the fragment(s)
   directly, or -- e.g. in case of a disruption -- maintain the pending
   request and complete the response bundle with received fragments
   until a (more) complete response bundle is eventually sent.

   When an intermediate BPQ node follows the strategy of maintaining a
   list of pending requests, there might be a number of requests for the
   same resource, e.g., for popular content.  For such scenarios it
   would be beneficial to not have to create individual response bundles
   for the same resource to be sent to each interested node on the
   network.  Domain-specific routing protocols and adequate usage of
   destination EIDs could be employed in these cases.


6.  Related Work

   Using the Bundle Protocol to query the network for near-by resources
   has been explored in different approaches.  Greifenberg and Kutscher
   have described a DTN Publish-Subscribe Protocol (DPSP) in [ref.dpsp]
   that allows interested nodes to register interest in some names
   resource to the network.  DPSP nodes would aggregate such
   subscriptions and forward it towards the direction of an origin node.
   Corresponding content bundles would be distributed along a tree that
   has been built implicitly by the subscription messages.  In DPSP,
   destination EIDs in subscription bundles specify the named resource
   (e.g. content channel), and the subscription information is conveyed
   in an extension block to enable inter-working with unmodified DTN
   nodes and routing protocols.

   Sollazzo, Musolesi and Mascolo have described a Time-Aware COntent-
   based dissemination system for DTNs (TACO-DTN) in [ref.taco-dtn] that
   takes time-based information into account to optimize content
   dissemination in a subscription-based approach.  Temporal profiles
   are associated to each subscription and allow the construction of
   temporal profiles of info-stations.

   More general, the idea of accessing named information objects in the
   network, regardless of the actual object location, is a key notion in
   different Information-Centric Networking approaches.  Ahlgren,



Farrell, et al.         Expires November 15, 2012              [Page 11]


Internet-Draft                  DTNRG BPQ                       May 2012


   D'Ambrosio, Dannewitz et al have developed an elaborate information
   model for such information objects in [ref.netinf-design].  In the
   Network of Information approach, information objects can be accessed
   by unique names that provide additional properties such as self-
   certification, i.e., provide a cryptographic relation between the
   object and the name.  In such an approach, interested nodes would
   query the network for specific named objects and the network would
   perform name-based routing and/or resolution to locators to satisfy
   such requests.

   A similar approach is the Content-Centric Networking (CCN) approach
   described by Jacobsen, Smetters, Thornton et al in [ref.ccn].  In
   CCN, network nodes receive so-called Interest Packets for names
   content from interested nodes.  Such Interest Packets can be
   aggregated, and forwarded according to name-based routing
   information.  Corresponding data packets are forwarded in the reverse
   direction, based on Interest Table state that is maintained at
   intermediate nodes -- quite similar to the DPSP approach described
   above.

   The Query Extension Block as described in this memo could be used to
   inter-connect DTNs to such Information-Centric Networks and/or to
   implement Information-Centric Networking with the Bundle Protocol.


7.  IANA Considerations

   We'll want an extension block number and maybe a new registry for
   query kinds and matching rule types if we stick with the above.


8.  Security Considerations

   The BPQ in principle allows a node to probe the storage of another
   node.  If BPQ-values are guessable, then this would work.  If this is
   a concern, the unguessable BPQ-values SHOULD be used.

   The BPQ imposes a load on nodes that support it.  If such a load is
   considered a potential DoS vector, then nodes SHOULD implement some
   controls on the amount of searching they are willing to carry out.
   This could be a simple limit, or could depend on the source (or
   authentication status) of the query bundle.

   Since the copy-response comes from the matching node, the response
   bundle's authentication information (e.g.  PIB) will not be usable
   with the copy-response.

   [note: not sure what to do about this as yet.]



Farrell, et al.         Expires November 15, 2012              [Page 12]


Internet-Draft                  DTNRG BPQ                       May 2012


   If confidentiality of the query-response payload is required the PCB
   block can be used to provide that service.  However, BPQ values could
   leak information about the payload, for example if the BPQ value were
   a hash of the payload, then the BPQ value would allow an attacker to
   check whether a guess of the payload value was correct or not.  If
   this is a concern, then BPQ values SHOULD be chosen so as not to leak
   information about the response payload.


9.  References

9.1.  Normative References

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

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

9.2.  Informative References

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.

   [ref.ccn]  Jacobsen, K, D, F, H, and L, "Networking Named Content",
              CoNEXT 2009 , December 2009.

   [ref.dpsp]
              Greifenberg and Kutscher, "Efficient Publish/
              Subscribe-based Multicast for Opportunistic Networking
              with Self-Organized Resource Utilization", The First IEEE
              International Workshop on Opportunistic Networking (WON-
              2008), March 2008.

   [ref.netinf-design]
              Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman,
              Pentikousis, Rembarz, Strandberg, and Vercellone, "Design
              Considerations for a Network of Information", Re-Arch 2008
              Workshop , December 2008.

   [ref.taco-dtn]
              Sollazzo, Musolesi, and Mascolo, "TACO-DTN: A Time-Aware
              COntent-based dissemination system for Delay Tolerant
              Networks", MobiOpp 2007 Workshop , 2007.






Farrell, et al.         Expires November 15, 2012              [Page 13]


Internet-Draft                  DTNRG BPQ                       May 2012


Appendix A.  ChangeLog

   This section to be deleted later.  The most recent changes should be
   added to the end of the list.

      Stephen: initial version

      Dirk: added some text to the introduction

      Dirk: moved some text from introduction to separate section
      "protocol overview"

      Dirk: changes processing requirements for fragmented response
      bundles as discussed

      Dirk: added section on Application Considerations

      Dirk: added text to related work section

      Aidan: Added text about adding already-returned fragments to the
      query

      Stephen: Added payload confidentiality sec. cons. note

      Aidan: Added text intentional naming and combining fragments using
      original src eid


Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie


   Aidan Lynch
   Trinity College Dublin
   Dublin,   2
   Ireland

   Phone:
   Email: lyncha6@tcd.ie





Farrell, et al.         Expires November 15, 2012              [Page 14]


Internet-Draft                  DTNRG BPQ                       May 2012


   Dirk Kutscher
   NEC
   Kurfuersten-Anlage 36
   Heidelberg,
   Germany

   Phone:
   Email: kutscher@neclab.eu


   Anders Lindgren
   Swedish Institute of Computer Science
   Stockholm,
   Sweden

   Phone:
   Email: andersl@sics.se


































Farrell, et al.         Expires November 15, 2012              [Page 15]


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