| TOC |
|
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.
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 May 12, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
1.
Introduction
2.
Protocol Overview
3.
BPQ Block Format
4.
BPQ Processing
5.
Application Considerations
5.1.
Usage of Endpoint Identifiers in Bundles
5.2.
Advanced Processing of Query and Copy-Response Bundles
6.
Related Work
7.
IANA Considerations
8.
Security Considerations
9.
References
9.1.
Normative References
9.2.
Informative References
Appendix A.
ChangeLog
§
Authors' Addresses
| TOC |
The Bundle Protocol (BP) specified in RFC 5050 (Scott, K. and S. Burleigh, “Bundle Protocol Specification,” November 2007.) [RFC5050] provides store-and-forward networking for Delay- and Disruption-Tolerant Networks (DTNs). RFC 4838 (Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, “Delay-Tolerant Networking Architecture,” April 2007.) [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] (Greifenberg and Kutscher, “Efficient Publish/Subscribe-based Multicast for Opportunistic Networking with Self-Organized Resource Utilization,” March 2008.) and for time-aware content dissemination through info stations [ref.taco‑dtn] (Sollazzo, Musolesi, and Mascolo, “TACO-DTN: A Time-Aware COntent-based dissemination system for Delay Tolerant Networks,” 2007.).
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 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 behavior 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 (Protocol Overview) we provide an overview of the general protocol operation, Section 3 (BPQ Block Format) specifies the actual BPQ block format, and Section 4 (BPQ Processing) provides the processing requirements for DTN nodes. Section 5 (Application Considerations) describes a few non-normative application considerations for BPQ, and Section 6 (Related Work) 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
The basic idea of the query extension block is that a "query" bundle can contain whatever application layer payload is required for the query to succeed when that bundle reaches its destination. The query bundle however, in addition to the application specific payload, also contains a BPQ extension block, which (somehow) uniquely identifies the correct query-response 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 store (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, toghether with BPQ data that allows other DTN nodes to also successfully match the query and response.
[question: what, if any, fields of the matching bundle to change, other than the destination? changing the source EID seems wrong, but so does not changing the source EID.]
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 requestor with the same payload and send that back to the source of the query bundle. In this case, (it seems, TBC) the query bundle need not be forwarded further and can be deleted.
[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]
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 resent. A matched fragment that is a superset 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.]
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.)
| TOC |
The BPQ consists of:
Block-type-specific data fields as follows:
| TOC |
If no match is found, then the node MUST forward the query bundle as if the BPQ block were not present.
The source EID of a response bundle MUST contain an EID for the node that found the match.
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 source.
[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.
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 identicial.
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.
[Question: once a node has finished searching for matching fragments within its store, should the node search subsequent incoming traffic for remaining fragments?]
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.]
| TOC |
This section provides some non-normative considerations on how BPQ can be used.
| TOC |
DTN EIDs usage for BPQ queries and replies needs to be considered for:
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:
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:
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.
| TOC |
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.
| TOC |
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] (Greifenberg and Kutscher, “Efficient Publish/Subscribe-based Multicast for Opportunistic Networking with Self-Organized Resource Utilization,” March 2008.) 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] (Sollazzo, Musolesi, and Mascolo, “TACO-DTN: A Time-Aware COntent-based dissemination system for Delay Tolerant Networks,” 2007.) 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, D'Ambrosio, Dannewitz et al have developed an elaborate information model for such information objects in [ref.netinf‑design] (Ahlgren, D'Ambrosio, Dannewitz, Marchisio, Marsh, Ohlman, Pentikousis, Rembarz, Strandberg, and Vercellone, “Design Considerations for a Network of Information,” December 2008.). 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] (Jacobsen, K, D, F, H, and L, “Networking Named Content,” December 2009.). 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.
| TOC |
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.
| TOC |
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.]
If confidentiality of the query-response payload is required the PCB block can be used to provide that servcice. 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.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC5050] | Scott, K. and S. Burleigh, “Bundle Protocol Specification,” RFC 5050, November 2007 (TXT). |
| TOC |
| [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 (TXT). |
| [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. |
| TOC |
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
| TOC |
| 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@scss.tcd.ie |
| 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 |