idnits 2.17.1 draft-ott-dtnrg-dtn-appl-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 790. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 12, 2007) is 6009 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC2045' on line 411 -- Looks like a reference, but probably isn't: 'RFC2046' on line 411 -- Looks like a reference, but probably isn't: 'OP2006' on line 591 ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3850 (ref. '4') (Obsoleted by RFC 5750) ** Obsolete normative reference: RFC 3851 (ref. '5') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 2326 (ref. '9') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '10') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-06) exists of draft-ietf-avt-rtp-howto-02 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTN Research Group J. Ott 3 Internet-Draft T. Kaerkkaeinen 4 Intended status: Experimental TKK Netlab 5 Expires: May 15, 2008 M. Pitkaenen 6 Helsinki Institute of Physics 7 (HIP) Technology Programme 8 November 12, 2007 10 Application Conventions for Bundle-based Communications 11 draft-ott-dtnrg-dtn-appl-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on May 15, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document discusses issues arising when moving the bundle 45 protocol usage from closed or lab deployments into open, 46 heterogeneous environments with a variety of usages and applications 47 carried over common bundle agents. We address naming conventions and 48 endpoint identifiers, content encapsulation, and on the 49 identification of application contents. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. DTN Operation in an Open Environment . . . . . . . . . . . . . 4 55 3. Conventions for DTN EIDs . . . . . . . . . . . . . . . . . . . 6 56 4. Routing conventions and EIDs . . . . . . . . . . . . . . . . . 8 57 5. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 11 58 5.1. Encapsulation Formats . . . . . . . . . . . . . . . . . . 11 59 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 6. Application Hints Extensions . . . . . . . . . . . . . . . . . 15 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 66 Intellectual Property and Copyright Statements . . . . . . . . . . 22 68 1. Introduction 70 Communications using the bundle protocol specification [2] has so far 71 mostly been carried out in rather closed environments. That is, 72 bundle agents have typically been handling messages from either a 73 single type of application or from multiple applications developed in 74 a coordinated fashion. Common usage conventions for the URIs for 75 endpoint identification and bundle routing are not an issue in such 76 environments. Recent research, however, has suggested the use of 77 Delay-tolerant Networking based upon the DTNRG architecture [6] for a 78 number of open applications to be run across the Internet or 79 connected to the Internet, suggesting the use of DTN for addressing 80 basic communication needs in remote areas and in support of mobility. 81 In this context, various application layer protocols from the 82 Internet realm have been adapted for transmission over the bundle 83 protocol, most notably email and HTTP, with further protocols under 84 investigation. 86 Building upon some of the thoughts put forward in [12], this document 87 identifies some further issues requiring consideration when moving 88 from the aforementioned "closed" DTN operation to an open environment 89 and suggests usage conventions for the URIs for endpoint 90 identification and bundle routing that allow arbitrary applications 91 to co-exist in a shared DTN environment. In addition, this document 92 proposes an---initially experimental---extension to the bundle 93 protocol header in support of application-specific functions. 95 This document is based upon experience gained from using and 96 extending the DTN reference implementation, expanding on it, and 97 writing prototype applications and protocol encapsulations. Our 98 experience is based upon supporting delay-tolerant interpersonal 99 communications; other application scenarios will bring along further 100 and possibly different requirements and observations. Comments and 101 additions are solicited to create a more comprehensive view of the 102 problems at hand when moving from closed to open deployments of DTNs. 104 For draft specifications in this document, the keywords MUST, SHOULD, 105 and MAY as defined in RFC 2119 [1] apply. 107 2. DTN Operation in an Open Environment 109 When running DTN applications in the open Internet, and ultimately at 110 large scale, bundle routers form a DTN overlay of some sort (which 111 may go well beyond the 'borders' of the Internet of today). If 112 arbitrary applications are run in such an environment, it is 113 necessary that (see also [12]): 115 o different types of applications choose their endpoint identifiers 116 (EIDs) from disjoint namespaces so that different application 117 instances do not accidentally collide with one another; 119 o different applications of the same type choose their EIDs from the 120 same namespace but still ensure that these are unique and allow 121 for adequate multiplexing within the application class where 122 necessary; 124 o bundle agents cooperating to serve multiple applications agree on 125 a set of rules for routing based upon EIDs so that bundles are 126 forwarded to their respective destinations; and 128 o the usage of EIDs across the DTN allows for efficient routing 129 protocols if dynamic exchange of routing information is deemed 130 necessary (how to exchange the routing information is yet another 131 aspect). 133 This calls for common usage conventions for the URIs for endpoint 134 identification and bundle routing. The basic URI conventions are 135 addressed in section 3, discussions on routing will be captured in 136 section 4 (to be expanded further in a future revision of this 137 document). 139 Furthermore, per-application conventions should be provided that 140 specify how application protocol messages are encapsulated in 141 bundles. In general, this may include 143 o message encoding rules, 145 o how to delineate messages (if stacking multiple messages is 146 allowed in the same bundle), 148 o specifying the message and content type, 150 o possibly specifying rules for (reactive) fragmentation, 152 o the utilization of bundle-layer mechanisms (such as end-to-end 153 delivery confirmations), and 155 o possibly transfer-encodings and other operations (such as 156 compression of the message contents). 158 To a certain extent, guidelines---somewhat similar to those specified 159 for writers of RTP payload types [8] [13]---are conceivable. Such a 160 set of encapsulation rules for text-based Internet application 161 protocols is addressed in section 5. 163 Finally, bundle routing and forwarding schemes may benefit from 164 understanding, at an abstract level, the application and message type 165 of a particular message. Depending on the URI conventions used, some 166 of this information may already be extracted from the EID. In order 167 to decouple endpoint addressing from application-independent bundle 168 contents identification, we suggest an extension block for the bundle 169 protocol that captures common information about the bundle contents. 170 This is specified in section 6. 172 3. Conventions for DTN EIDs 174 Endpoint identifiers (EIDs) are used to denote individual endpoints 175 (singletons) or groups of endpoints. They serve as the primary point 176 for routing/forwarding towards a (set of) physical/logical node(s) as 177 well as for demultiplexing different applications running on a single 178 node. EIDs are defined to be Unique Resource Identifiers (URIs) and 179 thus comprise a 'scheme' and a 'scheme-specific part' (SSP), all 180 text-encoded and separated by the colon (':') character [2]. 182 Some considerations on EIDs have been raised in [12] which explains a 183 lot of the open issues with EIDs. This document expands on these 184 with some concrete proposals. 186 Currently, one URI scheme for DTNs ('dtn:') is suggested with no 187 explicit substructure defined for the SSP. Only 'dtn:none' is 188 defined [2]. However, the DTN reference implementation uses a 189 structure of 'dtn:/' which has been 190 described in earlier versions of the bundle protocol specification. 192 To perform demultiplexing across different applications, the 193 respective application-specific URI schemes MUST be used, e.g., 195 o 'mailto:' to identify senders and receivers of email messages 196 encapsulated in bundles 198 o 'http:' to identify HTTP traffic 200 o 'ftp:' to denote file transfer operations 202 This is in contrast to an earlier proposal contained in the bundle 203 specification about using suffixes of the EID to denote individual 204 applications (which is still, however, one of the practices supported 205 in the DTN reference implementation). 207 The demultiplexing beyond the application protocol is not defined in 208 this document and is considered to be application-specific. However, 209 note that some guidelines are necessary which deserve common 210 discussion: 212 o For many applications, well-known addresses used to contact a 213 server or peer instance on a particular node (the "listening EID") 214 may need to be distinguished from application instances initiating 215 outgoing communications (the latter of which may be assigned 216 "dynamic EIDs") so that multiple instances of an application can 217 be instantiated on a node. One simple approach would be to use a 218 base EID for the well-known address and append application- 219 specific instance numbers (as has been done in the DTN reference 220 implementation and for various applications). For applications 221 that do not perform a specific registrations when initiating 222 communications to a peer randomly assigned identifiers could be 223 used. 225 o Whenever one DTN endpoint acts as a representative for multiple 226 others, discussion is needed if and how a differentiation between 227 the final target and its representative shall take place. One 228 example are email message stores (servers) which maintain messages 229 for a set of users: for (interactive) access and/or for backup 230 purposes. Another one is the case of communication between DTN 231 realms and applications in the Internet, e.g., via DTN-to-Internet 232 gateways as have been designed for email. 234 Another interesting aspect is how much application context an EID 235 should include. Two basic options are conceivable: 237 o The EID includes only sufficient information to identify the 238 application entity itself while application-specific information 239 is not part of the EID. For an HTTP URI, this would mean that the 240 HTTP URI does not contain a local resource (but simply 241 http://hostname/). It needs to be verified that such reductions 242 are allowed in the respective URI formats. 244 o The EID includes additional information about the local resource 245 and the respective application entity is found by means of (local) 246 prefix or suffix matching. For an HTTP URI, this would mean that 247 the complete resource URI is included (http://hostname/path). 248 Particularly in this case, wildcard matching for routing and 249 forwarding as well as for registrations is required to allow 250 "server applications" to easily take responsibility for a large 251 set of resources. 253 Combinations are also possible. On the one hand, allowing further 254 demultiplexing information in the EID may simplify application- 255 specific processing as no further intra-application demultiplexing 256 points are needed and load balancing across multiple instances of the 257 same application may be simplified. On the other hand, disallowing 258 demultiplexing may simplify aggregation of routing information. 259 However, it should be considered that, unlike the current Internet, 260 DTNs may not use routing schemes that benefit from hierarchical 261 structures and URIs (e.g., those belonging to users such as mailto: 262 URIs) may not be singletons as they have been in the traditional 263 Internet. 265 Further considerations on routing using different EID schemes are 266 given in the next section. 268 4. Routing conventions and EIDs 270 At this point, this document restricts itself to outlining the 271 options for DTN routing based upon EIDs to stimulate discussion. 272 Future revisions will incorporate findinds from such discussions and 273 give recommendations on how DTN routing protocols should be defined 274 to make use of EIDs. 276 Basically, there are several alternatives for DTN routing protocols: 278 a. Routing protocols may treat EIDs as opaque strings without any 279 substructure and perform forwarding decisions only upon full 280 matches. 282 b. Routing protocols may treat EIDs as opaque strings without any 283 substructure but assume significance to decrease from left to 284 right. In such a case, they may perform forwarding decisions 285 based upon longest prefix matches. 287 c. Routing protocols may utilize the URI structure of EIDs being 288 composed of a 'scheme' and a 'scheme-specific part' (SSP). They 289 may choose to route independent of the respective scheme and 290 treat the SSP either as an opaque string and perform routing as 291 per (a) or (b) on the SSP. 293 d. Like (c), however, routing may be dependent on the respective 294 scheme. The forwarding decision may treat the scheme as more 295 important than the SSP (and, e.g., choose the forwarding table 296 based upon the scheme) or less important (and, e.g., take only 297 scheduling or load balancing decisions based upont the scheme). 298 In either case, the SSP may be treated as an opaque string and 299 perform routing as per (a) or (b) on the SSP. 301 e. Like (c) and (d), however, the scheme-specific part is treated as 302 having a substructure composed of one part (A) denoting a host or 303 a topologically or administratively significant entity to be 304 exploited for routing purposes and another part (B) identifying a 305 sub-entity within the former. In the traditional Internet, this 306 would be an IP address (A) and a port number (B). For HTTP URIs, 307 this would be a "hostport" part identifying the server (A) and 308 the identifier for the local resource (B). For mailto and other 309 URIs identifying users, this would be the user identifier (B) and 310 a host/domain name (A), with the sequence being reversed. In 311 these cases, a hierarchical routing may be applied that first 312 tries to route towards the (physical) entity (e.g., a host) using 313 (c) or (d) on part (A) but does not consider part (B) for 314 'global' forwarding. Part (B) will only be considered for 315 'local' delivery. 317 f. Within part (A) identified in (e), some further substructure may 318 be considerd, e.g., following a hierarchy similar to the DNS (but 319 not necessarily resolvable via DNS). If some substructure is 320 assumed, further hierarchical routing and route aggregation are 321 possible. It should be noted that, with current practice in the 322 DTN URI scheme, such a hierarchy may be present but does not map 323 to the DNS and hence cannot be used to resolve DTN URIs into 324 specific bundle routers. For specific URI schemes, such a 325 mapping may be specified at some point; however, in general, no 326 such mapping can be assumed. 328 g. Finally, some form of wildcard or full regular expression-based 329 matching could be applied to the entire EID (and thus, 330 implicitly, also separately to both parts (A) and (B)) to allow 331 for utmost flexibility. 333 Obviously, the definition of URI conventions from section 3 and the 334 routing/forwarding conventions specified in section 5 require some 335 degree of coordination. 337 In particular, when allowing for arbitrary URI schemes, hierarchical 338 routing may only be possible if the URI schemes are understood by all 339 bundle agents. This requires careful definition of the routing 340 conventions to maintain extensibility towards future URI schemes. 342 Two simple examples of different ordering of hierarchies: 344 mailto:jo@example.com 346 http://www.example.com/~jo/ 348 Unless a well-known (at the time of the initial specification) scheme 349 is used, an EID could explicitly indicate whether prefix matching 350 should be done from left to right or from the right to the left and 351 which parts should be considered. This is depicted in figure 1: 353 : 355 ^ ^ ^ 356 |---- A ----|--- B ---| 357 ^ ^ 358 | | 359 start-offset | 360 end-offset 362 Figure 1: Indicating forwarding-relevant information in an EID 363 For this purpose, three additional fields (optional) would be 364 required (operating on octets): 366 o start-offset for the 'routable part' of the EID> 368 o end-offset for the 'routable part' of the EID 370 o matching-flag: indicates 'FULL', 'LP', or 'LS' to denote the type 371 of matching (full, longest-prefix, or longest-suffix') 373 Recent experience when using the DTN reference implementation for 374 realizing an email gateway confirms the need for conventions to 375 handle routing based upon EIDs. In the specific case, the DTN 376 reference implementation interprets mailto URIs (mailto:user@domain) 377 and disregards the part left of the '@' sign (i.e., the user) for 378 routing. While this supports efficient routing towards a 379 representative mail server (as discussed above), it prohibits user- 380 specific routing based upon the full EID in ad-hoc networks. An 381 explicit expression of how the respective EID is to be treated 382 internally by intermediate nodes hence is advisable. Proper hints 383 should ideally allow for both delivery to individual users as well as 384 delivery via representatives. 386 A precise specification and more detailed recommendations are left 387 for further study after agreement on the basics has been reached. 389 5. Message Encapsulation 391 Basically, the aforementioned definition of a demultiplexing scheme 392 for bundles based upon the (DTN) URI is sufficient for disambiguating 393 bundles targeted at different applications. However, numerous (text- 394 based) protocols in the Internet follow common conventions, such as 395 using RFC2822-style headers and MIME encapsulation, which provide the 396 benefit of code re-use across different applications. Therefore, it 397 may be worthwhile discussing these conventions and defining a common 398 encapsulation format for this class of applications. Currently, the 399 set of text-based application protocols making use of similar message 400 structures include (but are not limited to): electronic mail [3], 401 HTTP [10], RTSP [9], and SIP [11]. Furthermore, numerous XML-based 402 protocols (such as Jabber) could potentially benefit from a common 403 encapsulation format. 405 The text-based protocols following the RFC2822 conventions usually 406 consist of three parts: a start line, a sequence of message headers, 407 and an optional message body. The message headers are subdivided 408 into protocol header pertaining to the application protocol and 409 entity headers describing the message body. The message body MAY be 410 further encapsulated using the Multipurpose Internet Mail Extensions 411 (MIME) [RFC2045, RFC2046] and MAY comprise multiple parts (using MIME 412 multipart). 414 Other protocols are for further study. 416 5.1. Encapsulation Formats 418 The message body of a text-based message following one of the 419 aforementioned protocols is usually identified by means of the 420 Content-Type: entity header, but similar media type definitions also 421 exist for the entire messages, e.g., message/rfc822, message/http, 422 message/sip [http://www.iana.org/assignments/media-types/message/]. 424 This leads to three alternatives for message encapsulation: 426 1. The application message is placed into the DTN bundle without 427 further designation or encapsulation. In this case, the bundle 428 content is implied from the EID and no further designation is 429 provided. 431 Example: 433 [Primary bundle block] 434 [Bundle payload block 435 HTTP/1.1 200 OK 436 Content-Type: text/plain 437 Content-Length: 13 439 Hello, world 440 ] 442 2. The application message is encapsulated in a MIME envelope which 443 includes an explicit Content-Type denoting the message contents 444 as well as possibly other parameters (such as content transfer 445 encoding). This supports including additional entity headers in 446 the MIME envelope. 448 Example: 450 [Primary bundle block] 451 [Bundle payload block 452 Content-Type: message/http 453 Content-Length: ... 455 HTTP/1.1 200 OK 456 Content-Type: text/plain 457 Content-Length: 13 459 Hello, world 460 ] 462 3. The message is encapsulated without the 'overhead' of a text- 463 encoded MIME header but a separate header extension block is 464 provided to include a content designation if desired. This field 465 could simply indicate a MIME type (thus sharing the same 466 registry), which may be preferred over setting up and maintaining 467 yet another content registry. Optionally, additional MIME 468 attributes might be included (is there value?). Protocols will 469 be expected to specify default content types in which case this 470 block would not need to be included, thus avoiding overhead for 471 the default operation. 473 Example: 475 [Primary bundle block] 476 [Bundle payload identification block 477 content-type: message/http] 478 [Bundle payload block 479 Content-Type: message/http 480 Content-Length: ... 482 HTTP/1.1 200 OK 483 Content-Type: text/plain 484 Content-Length: 13 486 Hello, world 487 ] 489 Approach (1) is the simpler message encapsulation with less overhead 490 and leads to slightly easier processing. However, it also precludes 491 further operations such as encryption, authentication, or compression 492 of the complete message. If such mechanisms were to be applied, the 493 EIDs need to be used for demultiplexing (just as different port 494 numbers are used for HTTP and HTTPS). 496 Approach (2) incurs more overhead (some 50 bytes minimum) but 497 provides explicit content description and thus allows for 498 demultiplexing different message formats. 500 Approach (3) incurs less overhead than (2) while maintaining the 501 explicit content description and thus allows for demultiplexing 502 different message formats. 504 Allowing multiple encapsulation formats, however, may increase the 505 risk of non-interoperability (e.g., if a sender is not aware that the 506 transfer encoding or compression used is not understood by the 507 receiver). Such issues may be expensive or impossible to repair in 508 DTN environments due to the potentially limited degree of 509 interactivity. Application protocol encapsulation specifications 510 would need to clearly address these issues and define mandatory to 511 implement formats. 513 If the message content format shall be made explicit, as per (3), a 514 dedicated extension block could also be used for this purpose 515 (expanding further on the one proposed in section 6). The pros and 516 cons of replicating such a description at the DTN layer will have to 517 be investigated, depending on how many parameters will be needed to 518 fully describe the bundle contents adequately. 520 In either case, allowing for an explicit identification of the 521 respective contents will enable distinguishing between a single 522 contained resource and set of aggregated resources (using, e.g., 523 multipart/mixed or multipart/related), e.g., multiple objects 524 required to display a web page [7]. 526 An open question is whether such a multiplexing of multiple closely 527 related resources should happen within a single bundle payload, 528 should occur by combining multiple payload blocks or bundles, or 529 simply by using a batch of otherwise unrelated bundles. Or such a 530 decision could be left entirely to the application-specific payload 531 definition. 533 5.2. Security 535 Application protocols communicating via the bundle protocol may make 536 use of the bundle security mechanisms (e.g., for end-to-end 537 protection). In some cases, however, it may be desirable to maintain 538 the application layer security properties (e.g., a signature on a 539 piece of contents) beyond the bundle transmission and reception 540 process. In such cases, security mechanisms should be applied above 541 the bundle layer and attached to the payloads rather than to the 542 encapsulating bundle protocols. 544 For the protocols described above, one viable option is using S/MIME 545 [4] [5] as lasting encapsulation format. Depending on the intended 546 semantics, either the entire application message or just the message 547 body may be protected. 549 Note that for optionally protecting the entire application message, 550 one of the enhanced encapsulation formats (2) or (3) from section 5.1 551 needs to be used. 553 6. Application Hints Extensions 555 As bundle agents store, possibly carry, and forward bundles from 556 different applications, the nodes may carry these bundles for an 557 extended period of time. In environments with frequent 558 disconnections (and possibly short connectivity times), significant 559 queues may build up in a bundle agent that may not be easily worked 560 off during a single or a contact or contact time. This requires 562 o a bundle agent to drop queued bundles if new ones come in, 564 o scheduling bundles for (re-)transmission to the next contact, and 566 o decide for which bundles to accept custody. 568 These decisions are taken in conjunction with the specific routing 569 protocols and forwarding algorithms in use: these may demand 570 replicating a bundle a certain number of times or transmitting it 571 just once, determine to which contact(s) to forward a bundle, and 572 define the order of deletion (e.g., earliest vs. latest expiry time, 573 size-based). For infrastructure nodes dealing with random bundles or 574 in closed environments with more or less 'equal' bundles, such 575 mechanisms---as they should typically also be applied in IP 576 networks---are just fine. 578 This neutral treatment can be questioned, however, when dealing with 579 personal mobile devices running heterogenenous applications for two 580 reasons: 582 o Mobile nodes may prefer to utilize local resources (power, CPU, 583 memory) for bundles from those applications they are running by 584 themselves. Similarly, requests and responses for application 585 protocols may be treated differently. Both parameters could be 586 made explicit in a block header. 588 o Beyond this, mobile devices may improve their service quality 589 (e.g., response time, request completion probability) by employing 590 cooperative caching mechanisms that leverage messages stored in 591 bundle agents [OP2006]. For this purpose, a bundle agent would 592 benefit from an identification of the resource contained in the 593 bundle and its 'cache lifetime' (rather than its bundle lifetime). 595 To allow for such application-aware processing, the following 596 extension block ("Application-Hints") is defined. (Note that 597 draft-symington-dtnrg-bundle-metadata-block-00 defines a related 598 metadata block, which is rather complementary as it describes a 599 bundle while the Application-Hints defined below identifies a bundle 600 and its properties.) 601 +----------------+----------------+----------------+----------------+ 602 | Block type | Flags | Block length | 603 +----------------+----------------+----------------+----------------+ 604 | Resource Hash (0 if unused) | 605 +----------------+----------------+----------------+----------------+ 606 | Application Layer Lifetime | 607 +----------------+----------------+----------------+----------------+ 608 | OpType | ApplProtLength |ResourceIdLength| ExtensionLength| 609 +----------------+----------------+----------------+----------------+ 610 | Application protocol id (e.g., http) | 611 +----------------+----------------+----------------+----------------+ 612 | Resource identifier, in UTF-8 | 613 : (e.g., http://www.dtnrg.org/index.html) : 614 | | 615 +----------------+----------------+----------------+----------------+ 617 The Block type value for the Application Hints block is TBD. 619 The Flags fields specifies the Block processing fields are per 620 section 4.3 of the bundle protocol specification [2]. The flags MUST 621 be set as follows: 623 0 - TRUE. Block must be replicated in every fragment. 624 1 - FALSE. Transmit status report if block can't be processed. 625 2 - FALSE. Delete bundle if block can't be processed. 626 3 - As appropriate. Last block. 627 4 - FALSE. Discard block if it can't be processed. 628 5 - As appropriate. Block was forwarded without being processed. 629 Should initially be set to FALSE. 630 6 - FALSE. Block contains an EID-reference field. 632 Block length: This field specifies the length of the block. This is 633 an SDNV and is represented as a 16-bit value only for convenience of 634 the presentation. 636 Resource hash: A SHA-1 hash of the resource contained (if any) 637 excluding all headers to allow for efficient comparison. 639 The Application Layer Lifetime includes the validity of the resource 640 (if any) using the same format as the bundle protocol. A value of 641 zero specifies that the lifetime is unknown. This is an SDNV and is 642 shown in the above figure as a 32-bit value only for convenience of 643 the presentation. 645 The OpType is an 8-bit field indicating the application-specific 646 operation type. The MSB indicates whether or not a resource is 647 included in the bundle. The following values are defined: 649 0x00 - Unknown / other / not specified, no resource included 650 0x80 - Unknown / other / not specified, resource included 651 0x01 - Request, no resource included 652 0x81 - Request, resource included 653 0x02 - Response, no rescource included 654 0x82 - Response, rescource included 655 0x03 - Unconfirmed event, no resource included 656 0x83 - Unconfirmed event, resource included 658 Further values are to be defined. The hint whether or not a resource 659 is included shall give an indication to an intermediate bundle agent 660 about the potential 'value' of this bundle. 662 The ApplProtLength indicates the length of the included application 663 protocol identifier. A value of zero indicates that no protocol 664 identifier is present. This is an SDNV and is represented as an 665 8-bit value only for convenience of the presentation. 667 The ResourceLength indicates the length of the included resource 668 value (e.g., an application-layer message id or an HTTP URI). A 669 value of zero indicates that no resource identifier is present. This 670 is an SDNV and is represented as an 8-bit value only for convenience 671 of the presentation. 673 The ExtensionLength indicates the length of an extension following 674 the resource identifier. Details TBD. A value of zero indicates 675 that no extension is present. This is an SDNV and is represented as 676 an 8-bit value only for convenience of the presentation. 678 The application protocol id field is used to encode the protocol as a 679 URI scheme. The resource should be a full URI or URN including the 680 respective scheme, so that both the application protocol and the 681 actual resource can be derived from this field. 683 The Resource value field is used to encode the resource contained in 684 the bundle in UTF-8. The resource should be a full URI or URN 685 including the respective scheme, so that both the application 686 protocol and the actual resource can be derived from this field. 688 This document does not specify specific treatment of the Application- 689 Hints block, but rather suggests providing such hints as a means for 690 service differentiation in resource-constrained nodes. Drawing 691 conclusions for local treatment is left to the implementation. (This 692 entire section may ultimately be moved to a different document.) 694 7. Security Considerations 696 Any kind of application-specific tagging of contents (as, e.g., 697 defined in section 6) is subject to forgery. Applications may 698 attempt to guess for which hints they might obtain better service and 699 fake the field to this end. As long as intermediate nodes exhibit 700 heterogenous behavior (so that a malicious node cannot tell when it 701 may receive better service), this issue is partly mitigated. 702 Trustworthy identification of the sender will allow an intermediary 703 to decide whether to take such application-hints into account or not. 705 Further issues are TBD. 707 8. References 709 8.1. Normative References 711 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 712 Levels", BCP 14, RFC 2119, March 1997. 714 [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 715 draft-irtf-dtnrg-bundle-spec-10 (work in progress), July 2007. 717 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 719 [4] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 720 (S/MIME) Version 3.1 Certificate Handling", RFC 3850, 721 July 2004. 723 [5] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 724 (S/MIME) Version 3.1 Message Specification", RFC 3851, 725 July 2004. 727 [6] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., 728 Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking 729 Architecture", RFC 4838, April 2007. 731 8.2. Informative References 733 [7] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, "MIME 734 Encapsulation of Aggregate Documents, such as HTML (MHTML)", 735 RFC 2557, March 1999. 737 [8] Handley, M. and C. Perkins, "Guidelines for Writers of RTP 738 Payload Format Specifications", BCP 36, RFC 2736, 739 December 1999. 741 [9] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming 742 Protocol (RTSP)", RFC 2326, April 1998. 744 [10] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 745 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- 746 HTTP/1.1", RFC 2616, June 1999. 748 [11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 749 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 750 Session Initiation Protocol", RFC 3261, June 2002. 752 [12] Eddy, W., "Architectural Considerations for the use of Endpoint 753 Identifiers in Delay Tolerant Networking", 754 draft-eddy-dtnrg-eid-00 (work in progress), May 2006. 756 [13] Westerlund, M., "How to Write an RTP Payload Format", 757 draft-ietf-avt-rtp-howto-02 (work in progress), July 2007. 759 Authors' Addresses 761 Joerg Ott 762 TKK Netlab 763 Otakaari 5A 764 Espoo 02150 765 Finland 767 Teemu Kaerkkaeinen 768 TKK Netlab 769 Otakaari 5A 770 Espoo 02150 771 Finland 773 Mikko Juhani Pitkaenen 774 Helsinki Institute of Physics (HIP) Technology Programme 776 Full Copyright Statement 778 Copyright (C) The IETF Trust (2007). 780 This document is subject to the rights, licenses and restrictions 781 contained in BCP 78, and except as set forth therein, the authors 782 retain all their rights. 784 This document and the information contained herein are provided on an 785 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 786 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 787 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 788 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 789 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 790 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 792 Intellectual Property 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Acknowledgment 818 Funding for the RFC Editor function is provided by the IETF 819 Administrative Support Activity (IASA).