idnits 2.17.1 draft-ivancic-scf-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (December 13, 2013) is 3777 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 237 -- Looks like a reference, but probably isn't: '2' on line 237 -- Looks like a reference, but probably isn't: '3' on line 245 -- Looks like a reference, but probably isn't: '4' on line 245 -- Looks like a reference, but probably isn't: '5' on line 246 -- Looks like a reference, but probably isn't: '6' on line 246 -- Looks like a reference, but probably isn't: '7' on line 265 -- Looks like a reference, but probably isn't: '8' on line 265 -- Looks like a reference, but probably isn't: '9' on line 265 -- Looks like a reference, but probably isn't: '10' on line 265 -- Looks like a reference, but probably isn't: '11' on line 266 -- Looks like a reference, but probably isn't: '12' on line 278 == Unused Reference: 'RFC0768' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'AMQP' is defined on line 1037, but no explicit reference was found in the text == Unused Reference: 'DTNRG' is defined on line 1041, but no explicit reference was found in the text == Unused Reference: 'FidoNet' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'I-D.ivancic-scf-requirements-expectations' is defined on line 1046, but no explicit reference was found in the text == Unused Reference: 'IMAP' is defined on line 1057, but no explicit reference was found in the text == Unused Reference: 'JMS' is defined on line 1061, but no explicit reference was found in the text == Unused Reference: 'MQTT' is defined on line 1064, but no explicit reference was found in the text == Unused Reference: 'POP' is defined on line 1067, but no explicit reference was found in the text == Unused Reference: 'SMIME' is defined on line 1081, but no explicit reference was found in the text == Unused Reference: 'SMTP' is defined on line 1084, but no explicit reference was found in the text == Unused Reference: 'STOMP' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'UPPC' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'XMPP' is defined on line 1099, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ivancic-scf-requirements-expectations-00 == Outdated reference: A later version (-01) exists of draft-ivancic-scf-testing-requirements-00 Summary: 0 errors (**), 0 flaws (~~), 18 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Ivancic 3 Internet-Draft NASA GRC 4 Intended status: Experimental W. Eddy 5 Expires: June 16, 2014 MTI Systems 6 A. Hylton 7 D. Iannicca 8 J. Ishac 9 NASA GRC 10 December 13, 2013 12 Store, Carry and Forward Problem Statement 13 draft-ivancic-scf-problem-statement-01 15 Abstract 17 This document provides a problem statement for non-realtime 18 communication between systems that are generally disconnected, which 19 require multiple network hops between source and destination, and 20 which may never be fully connected end-to-end at any given time. 21 This document describes a number of use cases that motivate having a 22 standard method to communicate between such systems, as multi- 23 organization and multi-vendor support and interoperability is highly 24 desirable. These use cases include dismounted soldiers, sensorwebs, 25 medical devices, animal tracking, low-Earth-orbiting satellites and 26 data mule scenarios. To avoid confusion in terminology when trying 27 to focus on the problem and requirements without bias towards 28 particular technical solutions, at this time, we refer to the 29 protocol instances that would support such communications as Store, 30 Carry, and Forwarding (SCF) agents, and refer to their activity as 31 SCF networking. The concepts involved in SCF networking are not 32 entirely new and several facets of the problem have been solved in 33 multiple incompatible ways in existing or historic systems. This 34 document describes the core SCF problem and gives an assessment of 35 the ability to use existing technologies as solutions. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on June 16, 2014. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 This document may not be modified, and derivative works of it may not 70 be created, except to format it for publication as an RFC or to 71 translate it into languages other than English. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction and Background . . . . . . . . . . . . . . . . . 4 77 3. Generic Architecture . . . . . . . . . . . . . . . . . . . . 7 78 4. Operational Considerations . . . . . . . . . . . . . . . . . 9 79 5. Use Cases and Deployment Scenarios . . . . . . . . . . . . . 11 80 5.1. Data Mule . . . . . . . . . . . . . . . . . . . . . . . . 11 81 5.2. Data Gathering . . . . . . . . . . . . . . . . . . . . . 13 82 5.3. Traveling the Beaten Path . . . . . . . . . . . . . . . . 14 83 5.4. Rapid Disruption . . . . . . . . . . . . . . . . . . . . 15 84 5.5. Dismounted Soldier . . . . . . . . . . . . . . . . . . . 15 85 5.6. Low Earth Orbiting Sensor Satellite . . . . . . . . . . . 16 86 6. Consideration of Existing Technologies . . . . . . . . . . . 18 87 7. Characteristics of Information . . . . . . . . . . . . . . . 20 88 8. Network Management . . . . . . . . . . . . . . . . . . . . . 21 89 9. Lessons Learned Summary . . . . . . . . . . . . . . . . . . . 22 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 24 95 13.2. Informative References . . . . . . . . . . . . . . . . . 24 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 98 1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 "What's in a Word. Words make a difference. They affect how we 105 think about something. The terms chosen to describe a concept are a 106 crucial part of any model. The right concepts with terms that give 107 the wrong connotation can make a problem much more difficult. The 108 right terms can make it much easier. Adopting the mindset of the 109 terms may allow you to see things you might not otherwise see." - 110 John Day [Patterns] 112 In developing this document, we have intentionally avoided some 113 terminology used by other protocols - particularly other store-and- 114 forward protocols - to avoid biases and confusion that may otherwise 115 ensue. 117 o Container - the application/user data to be transported over the 118 network as well as a checksum of that information. Containers may 119 include sub-containers, or be sub-containers themselves. 121 o Container Aggregation - The process of organizing one or multiple 122 containers as sub-containers inside another larger container. 124 o Container Deaggregation - The process of removing one or more sub- 125 containers from a larger container. This differs from 126 fragmentation because rather than creating new containers, 127 deaggregation operates on existing sub-containers. 129 o Container Fragmentation - The process of dividing a single 130 container's contents into multiple new containers which will need 131 to be eventually reassembled back into the original container 132 before delivery to the application. 134 o Container Reassembly - The process of recombining the contents of 135 multiple containers into the single container that they were 136 originally part of, and which needs to be delivered to the 137 application intact. 139 o Delay - propagation delay between SCF agents. Delay does not 140 include disconnection time. 142 o Disruption - a relatively short period of disconnection within an 143 otherwise well-connected network, e.g. a loss of connectivity in 144 the range of seconds to perhaps minutes. 146 o Disconnection - a relatively long period where communication 147 between a significant proportion of hosts is not possible for 148 various reasons, e.g. due to the inability to close a radio link. 150 o Metadata - synonymous with a Container's Shipping Label 152 o SCF - Store, Carry and Forward 154 o SF - Store-and-Forward, or "store and forward" as used generically 155 in other literature (where the presence of hyphenation varies) 157 o SCF Agent - a protocol instance providing SCF services to an 158 upper-layer user/application 160 o Shipping Label - metadata describing the characteristics of a 161 container and its forwarding requirements 163 o Sub-Container - A smaller container residing inside a larger 164 container. 166 o Transport Capacity - (as a first order approximation) the product 167 of link capacity and contact time. 169 2. Introduction and Background 171 Internet technology has become pervasive and is now present in many 172 types of devices that end up being deployed in the field for use in 173 scenarios where they do not have good (or any) actual Internet 174 connectivity. The networking stacks are used to support data 175 transfer during episodes of connectivity, and the applications and 176 protocol configurations avoid reliance on many typical infrastructure 177 services (e.g. DNS). For instance, these devices may be only 178 intermittently connected to other devices, and are used to support 179 data flows where the source and ultimate destination might never be 180 fully connected to one another at any time. These applications 181 operate highly asynchronously, with non-realtime constraints on their 182 communication. Often, there are intermediate relaying nodes (or 183 "agents") that must "carry" the data while waiting for connectivity 184 to develop. The means for relaying data has been highly specialized 185 in such systems (almost per-deployment), and varies widely, with 186 little code-reuse or commonality in the supporting network design. 187 This "problem statement" document describes several of these 188 scenarios generically, motivates the development of a common 189 solution, and describes shortcomings in existing technologies. 191 This problem statement is explicitly not trying to look at the 192 situation where a smart phone or mobile computer is temporarily off 193 or removed from the Internet, and then is reattached directly to the 194 edge of a well-connected network. Such systems are well-suited to 195 utilize standard Internet protocols and are able to support realtime 196 communications when connected. The systems and applications that 197 this document is concerned with are primarily operating with a much 198 higher level of asynchrony between the data producers, individual 199 relays, and eventual data consumers. We call these "Store, Carry, 200 and Forward" (SCF) systems to distinguish them from typical Store- 201 and-Forward (SF) systems, which generally operate over a better- 202 connected infrastructure. This section clarifies the distinction 203 between SCF and the better-understood SF concept, which is already 204 implemented by a number of different networking technologies. 206 Because so many analogies exist between SF/SCF-based computer 207 communications and offline non-computer-based systems, it is useful 208 to understand (very) early communications. Relay systems have been 209 present even in ancient civilizations, where rulers utilized 210 intelligence gathering via courier services to convey and obtain 211 information. Relays consisted of runners, messengers, and even 212 pigeons conveying messages and documents. These types of relay 213 agents had only intermittent connectivity with one another and needed 214 to hold onto messages for possibly long amounts of time before 215 delivering them. Later relay systems included the ancient Greeks 216 using fires, mirrors, or colored flags for visually communicating 217 over large distances, and the the 18th century French using a system 218 of telescopes and semaphores. These involved relatively well- 219 connected systems of relay infrastructure, compared to the earlier 220 methods that involved physical carriage of the stored messages for 221 some time in order to reach the next forwarding point. Telegraph and 222 later systems had equally well-connected infrastructures. 224 In computer networking, numerous technologies that support SF message 225 communications between systems have evolved, and some have 226 incorporated pieces of what SCF systems require. We very roughly 227 group these developments into "generations" in order to highlight a 228 general progression of capabilities. This is not prescriptive, and 229 though some detailed aspects of the classification may be debatable, 230 the basic notions hold. 232 1st-generation Store and Forward systems consisted of Message 233 switching, with buffering of messages at intermediate nodes in order 234 to handle intermittent connectivity. There was little or no 235 automation, intelligence, or capabilities for forming routing tables, 236 security, network management, and handling anything but rather slow- 237 scale dynamics. Examples include UUCP [1], FidoNet [2]. "In FidoNet 238 As all modem phone numbers are published in the nodelist, point-to- 239 point transfers are always possible. But, as store-and-forward 240 capabilities are specified in the basic standards, email tends to be 241 routed through a world-wide hierarchic topology and enews via a 242 world-wide ad hoc, but generally geographically hierarchic, acyclic 243 graph." 245 2nd-generation SF consist of Internet email via SMTP [3] + POP [4] / 246 IMAP [5] + S/MIME [6] and so on. Key features include separation of 247 message transfer agents, user agents, and message submission/delivery 248 agents. There are increased capabilities for security and 249 management. There is some (weak) separation between message format 250 and message transfer protocols. Email servers generally operate 251 within a well-connected environment. There are major performance 252 problems outside this well-connected environment, because there is 253 little diversity in message transport between nodes, and little or no 254 improvement in dealing with dynamics. 256 3rd-generation SF protocols are an advance over 2nd-generation 257 concepts. These are used to implement messaging middleware and are 258 applied as the basis of enterprise service bus systems. There is an 259 increased separation between message format and message transfer 260 protocols with increased message transform / mediation capability. 261 There has been a proliferation of proprietary formats, APIs and 262 systems, with great diversity in capabilities. Generally, there are 263 still problems operating outside a well-connected environment, and 264 the security mechanisms are not advanced beyond 2nd-generation ones. 265 Examples include: JMS/OpenWire [7], AMQP [8], STOMP [9], XMPP [10], 266 and MQTT [11]. 268 4th-generation SF protocols are directed at systems with long delays 269 and intermittent connectivity and are known as Delay Tolerant 270 Networking (DTN) [RFC4838], [RFC5050]. There is very strong 271 separation between format and transfer protocol as well as strong 272 separation between format and addressing/routing. Architecturally, 273 there are many alternatives available for transfer, addressing, and 274 routing with heavy tailoring per each pocket of deployment. Security 275 is possible for implementation in a limited subset of intended use 276 cases. There are a number of experimental implementations including 277 Interplanetary Overlay Network (ION), DTN2 and others including 278 substantial profiles of features and capabilities. DTNRG [12]. 280 5th-generation (conceptual) systems include significant amounts of 281 longer-term storage that can be "carried" between episodes of 282 connectivity as a main component (i.e. Store, Carry and Forward) 283 There is an increased separation of message metadata (i.e. shipping 284 labels) from message bodies (i.e. containers) beyond the 4th 285 generation, enabling new approaches to security, forwarding, and 286 possibilities for pull-based routing. Emphasis is on the "carry" 287 function and need for strong automation in management of stored data, 288 including support for implementing policy in QoS, security, and 289 routing. 5th-generation systems that embody the SCF concept have not 290 yet been widely deployed. The fielded applications that could 291 benefit from such SCF capabilities are either using point solutions 292 adapted from prior generations of SF technology, or are lacking the 293 strength in automation, security, and other features that the SCF 294 technology should provide. Later sections of this document describe 295 a generic network architecture expected to be supported by SCF / 5th- 296 generation systems, the envisioned scenarios and use cases for these 297 systems, more detailed comparison/contrast with existing / prior- 298 generation systems, and a summary of lessons learned from experience 299 with earlier systems. 301 3. Generic Architecture 303 Figure 1 illustrates a generic SCF network architecture, with the SCF 304 agents (labelled "SCF") frequently partitioned into time-varying 305 disconnected subsets. Depending on specifics of an individual 306 scenario, it may be likely that some SCF agents are permanently 307 attached to a connected network in order to provide stable gateways 308 to/from the other SCF agents. However, in general, the system should 309 be considered to consist of a number of primarily disconnected SCF 310 agents at any point in time. The importance of this consideration as 311 it relates to design, implementation, and test of potential SCF 312 protocols is emphasized later in this document, as its effects have 313 plagued prior SF systems. 315 _,.--SCF -. 316 SCF ' / `-SCF 317 .' / DISCONNECTED 318 / / NETWORK 319 .' SCF_ 320 SCF / `-.. 321 `. .' SCF 322 `. | 323 ,SCF. 324 / \ 325 / \ 326 / \ 327 ; CONNECTED : 328 | NETWORK | 329 : ; 330 \ / 331 \ / 332 \ / 333 ,SCF`. 334 SCF----'''' | `-. 335 | \ `.SCF 336 / | .-' 337 / SCF_.-' 338 SCF .' 339 `. .' DISCONNECTED 340 `-. .' NETWORKS 341 SCF 343 Store, Carry and Forward Network 345 Figure 1 347 When visualizing an SCF network, it may help to think more along the 348 lines of a topologically dynamically-changing (mobile) relay system 349 of agents that can periodically communicate with one another, and may 350 be able to make at least rough predictions about their future 351 contacts. The distribution of news and mail in the mid-1800s as 352 described in Herman Melville's book, "Moby Dick," is a good analogy. 354 "For the long absent ship, the outward-bounder, perhaps, has letters 355 on board; at any rate, she will be sure to let her have some papers 356 of a date a year or two later than the last one on her blurred and 357 thumb-worn files. And in return for that courtesy, the outward-bound 358 ship would receive the latest whaling intelligence from the cruising- 359 ground to which she may be destined, a thing of the utmost importance 360 to her. And in degree, all this will hold true concerning whaling 361 vessels crossing each other's track on the cruising-ground itself, 362 even though they are equally long absent from home. For one of them 363 may have received a transfer of letters from some third, and now far 364 remote vessel; and some of those letters may be for the people of the 365 ship she now meets..... 367 ...Every whale-ship takes out a goodly number of letters for various 368 ships, whose delivery to the persons to whom they may be addressed, 369 depends upon the mere chance of encountering them in the four oceans. 370 Thus, most letters never reach their mark; and many are only received 371 after attaining an age of two or three years or more." 373 Another analogy that illustrates aggregation and deaggregation are 374 the parcel post delivery companies. Here, individual packages 375 (containers) are delivered from a source to destinations via numerous 376 transport mechanisms, e.g. trucks, planes, trains and boats. Along 377 the way, these packages are aggregated into larger and larger 378 shipping containers as they move further from the source, and then 379 and deaggregated into smaller and smaller containers as they move 380 closer to the destination. Such aggregation and deaggregation enable 381 scaling of the system. There is a strong parallel between this flow 382 of packages and the data flows seen in some of the scenarios 383 described later in this document. 385 4. Operational Considerations 387 Some of the key operational considerations for SCF are: 389 o What types of applications might be suitable to utilize SCF 390 networking? 392 * Engineering Telemetry - Accumulated over time for offline 393 monitoring and analysis of some device or system's performance, 394 which may be related to long-term administration of the device, 395 but occurs in non-realtime and at a remote location. Fidelity 396 of the received data is important, though partial delivery of 397 data may be acceptable and more desirable than slower delivery 398 of complete and fully accurate data. It is expected that a 399 telemetry-sending application may operate in a fire-and-forget 400 mode, where it does not retain data after sending. 402 * Science Data Gathering - Similar to engineering telemetry, but 403 sensor data is collected at a potentially much larger volume or 404 over a much longer timescale. Accuracy of the delivered data 405 is critical, and timeliness in routing may be sacrificed to 406 provide a complete and error-free data set. Due to the size of 407 data sets collected, having multiple copies in-flight within 408 the network may be undesirable, and end-nodes may need to purge 409 old data after it has been sent in order to gather new data. 411 * Software Update - Numerous deployed devices that may never be 412 able to contact an update server in realtime may need to have 413 patches or updates deployed and activated. This can require 414 high reliability and guarantee of eventual delivery of the 415 data, even if the latency involved in applying the update is 416 not extremely critical. The sender is likely to retain access 417 to the sent update/patch perpetually, even after copies have 418 been distributed into the network. While some acknowledgement 419 of reception end-to-end may be desirable, this might be 420 inferred through other means at the application level (e.g. via 421 telemetry) rather than requiring SCF-level acknowledgement. 423 o In general, any distributed application where senders and 424 receivers can operate asynchronously in non-realtime, without any 425 real-time requirement on the infrastructure (e.g. to do resolution 426 of DNS names) might be able to function over an SCF service. 428 o What are the potential deployment environments and platform 429 capabilities? 431 * Some relevant use cases are discussed in detail in the 432 following section. In general, the SCF agents may be either 433 co-located or independent of the hardware/software platforms 434 that host the end-applications. Aside from having a non- 435 trivial amount of persistent storage, very few assumptions can 436 be made about the SCF agent computing platforms. Typically, 437 they will have to be embedded systems, e.g. within a device 438 that's part of some other portable electronic system (e.g. 439 handheld device, medical implant, avionics hardware, etc.) 440 rather than typical workstations and servers. This means that 441 links are expected to be (much) less capable and more time- 442 varying than wired Ethernet, and frequent administrative access 443 is not likely to be possible. 445 o What are the upper-layer user/application data-set sizes? 447 * From existing systems in-use that could benefit from SCF, at 448 least several GB of data collected onto an SCF agent between 449 contacts with other SCF agents is possible. There are also 450 applications where only several kilobytes of container are 451 necessary. 453 o What are the traffic patterns? 455 * In envisioned SCF scenarios, movement is not fully random, even 456 for mobile ad-hoc networks, though at the very edges, it may 457 appear random. 459 * In envisioned SCF scenarios, information flow is not fully 460 random, even for mobile ad-hoc networks. 462 o What type of interface between SCF agents and end applications is 463 feasible? 465 * Applications should be able to select their own globally-unique 466 identifiers and notify SCF agents of them, along with providing 467 proof of ownership. SCF agents may be able to notify 468 applications of pending received data, but applications are 469 always able to poll a SCF agent for such data as well. 471 o What interaction between SCF agents is expected? 473 * When in contact with one another, SCF agents minimally need to 474 be able to identify one another securely and prove that they 475 can be trusted as relays for a given destination application. 476 Agents should be able to indicate (or deny) forwarding of 477 individual containers, based on exchanging their labels only. 479 5. Use Cases and Deployment Scenarios 481 There are numerous deployment scenarios for SCF systems. The 482 following section highlights a few more common scenarios. 484 5.1. Data Mule 486 The Data Mule scenario is a common generic scenario and shows up in 487 many deployments. In the Data Mule scenario, SCF agents communicate 488 with each other mainly via some type of circulating entity carrying 489 data, called the "mule". This entity may be an unmanned (or manned) 490 aircraft, a ship, a bus, or any type of vehicle that periodically 491 moves over the same relative area. Connectivity is likely to consist 492 of high periods of disruption followed by short periods of 493 connectivity over relatively high-bandwidth, low-delay, and possibly 494 symmetric, links. 496 In the Data Mule scenario, connectivity is generally of the episodic 497 variety (opportunistic). There may be one or a larger number of 498 mules; each of which runs its own SCF agent. 500 .-------. 501 | SCF | .-------. 502 |Agent 1| | SCF | .--o 503 `-------' /''\. |Agent 5| / `. 504 `. .' '._ .-----.,--. `-------' / | 505 \ | `.._|Data | ``. \ / `. 506 / |Mule | `-. \ ' |_ 507 | `-----' `. ,/ | 508 | Movement \.,.--- | 509 ' <<======= | 510 / | 511 / | 512 | Path Well .-------. | 513 | Traveled | SCF | | 514 | |Agent 3| | 515 / ...._ `-------' \ 516 | | `. / `\ 517 \ _.. | `./ .' 518 `' `---`... `.._ `-. ,' 519 .-------. _, ". ``. \ _,,' 520 | SCF |,' `. \ `--...,-'. 521 |Agent 2| `. `. | 522 `-------' `. _ \ .-------. 523 ' `'-...._ | | SCF | 524 `"--------' |Agent 4| 525 `-------' 527 Data Mule Scenario 529 Figure 2 531 Within this type of Data Mule scenario, the generic use case for SCF 532 networking involves an application being able to push its data into 533 containers on a SCF agent, who then interacts with the Data Mule SCF 534 agents in order to deliver the containers to destination applications 535 attaching to other SCF agents. In order to realize this use case, 536 the SCF agents need to be identifiable to one another during periods 537 of episodic connectivity, and the mule needs to somehow be able to 538 express its expected future capability to relay containers towards 539 the destination application. 541 The Data Mule is a common military scenario. It is often used to 542 join partitioned connected networks such as groups of mobile ad-hoc 543 networks (manets). In Figure 2, the SCF Agents could be concentrator 544 points in a manet cluster that enables communication between disjoint 545 manets on the battlefield, thus enabling communications between 546 clusters on the far ends of the communication infrastructure, the 547 edge networks. 549 5.2. Data Gathering 551 The generic Data Gathering scenario is also quite common and 552 applicable to SCF networks. Specific use cases involving sensorwebs, 553 medical monitoring and animal tracking would fit into this scenario. 554 Figure 3 illustrates a sensorweb where some sensors wake up and 555 forward data through other SCF agents until they reach an SCF 556 connected to a more powerful radio system. A gathering agent may 557 then come by from time to time (e.g. days, weeks, months) and collect 558 the data. 560 GATHERING AGENT 562 // 563 /____ /X// _ 564 \ (\ //-'// 565 / \)---' 566 /X// 568 ))'(( ))'(( ))'(( 569 | | | 570 SCF SCF SCF 571 _,-' | `.. / \ _,' | '-. 572 ,' | `-. ,' ` ,' | `._ 573 SCF SCF SCF SCF SCF SCF SCF SCF 574 / \ / \ 575 ,' ` ,' ` 576 SCF SCF DATA SOURCES SCF SCF 578 Data Gathering Scenario 580 Figure 3 582 Major challenges of the use cases in a Data Gathering scenario, which 583 go beyond those of a Data Mule, are related to the increased level of 584 complexity in the topology between SCF agents. There is potentially 585 less predictability, potentially more heterogeneity (or hierarchy) in 586 SCF agent capabilities, and potentially a higher risk of routing 587 loops or wasted resources. 589 The use cases for Data Gathering do, however, involve data flows that 590 are generally either all directed from sensors up through the 591 Gathering Agents or down from the Gathering Agents, so these still 592 represent a sort of core network that all containers eventually go 593 through (similar to the Data Mules). 595 5.3. Traveling the Beaten Path 597 There are many instances where communications may occur between 598 entities traveling a well-worn path. In this scenario, communication 599 is more ad-hoc than the data-mule example. The probability of 600 encountering other SCF agents is quite high. Such scenarios include: 601 communication in mining operations, among hikers, among boats along 602 well traveled waterways, within the fisheries industry (the Moby Dick 603 example) and along trade routes. 605 Figure 4 illustrates Traveling the Beaten Path. Consider a nomadic 606 trade route in a third-world country. Here, SCF-1 may travel from 607 the one end of the path to the other in one direction, while SCF-5 608 moves in the other direction. SCF-1 and SCF-5 will encounter all 609 other SCFs along the way. SCFs 2, 3 and 4 only move along portions 610 of this trade route. Most likely, none of this information is known 611 in advance, and the movements may or may not be predictably 612 repeatable. 614 PATH 615 ==-._ _,,---.=-..__ 616 '`-`''`;--=...__ _....,,...'-'' `''`.\ ___ 617 `''':::.._,,,-'-'' `---.:,-''' 618 '`''' 620 --------- SCF-1 --------------------------------------------> 622 <---- SCF-2 ---> 624 <----- SCF-3 ------> 626 <--------------------------- SCF-4 ---> 628 <----------------------------------------------- SCF-5 ----- 630 Traveling the Beaten Path 632 Figure 4 634 5.4. Rapid Disruption 636 Many wireless networks (particularly military ones), when connected, 637 may be relatively well-connected to a large number of other nodes in 638 near real-time. However, individual nodes or subsets of the network 639 may be only episodically connected because of variable link 640 conditions given terrain, foliage, weather, jamming, or desire to 641 evade detection. Furthermore, even when basically connected, 642 temporary radio signal power fades can cause rapid, short, periods of 643 disconnection. All of these lower-layer hindrances may result in 644 short periods of disruption witnessed by applications, as well as 645 rapid changes in network topology and the set of reachable relays. 647 SCF provides some potential solutions for such networks. SCF routing 648 may be capable of moving containers towards destinations via store- 649 and-forward if the proper naming structures, addressing and routing 650 algorithms can be developed. 652 5.5. Dismounted Soldier 654 On the battlefield, it often occurs that a group of soldiers is on a 655 mission and arrives via a vehicle or group of vehicles, one of which 656 may have very good connectivity to larger networks. Once dismounted, 657 much of the communications may be via use of that vehicle 658 communication system as a relay or anchor. Once the group moves a 659 significant distance from this anchor and from one other, they may 660 become disconnected for periods of time. At this point, SCF becomes 661 necessary to improve communications and maintain situational 662 awareness. SCF provides this communication in two ways. Near- 663 synchronous communications might be maintained via multi-hops through 664 other SCF agents, or in the worst case, asynchronous communications 665 can be served sporadically when within radio contact of the anchor 666 relay on the vehicle. 668 This scenario is also applicable to first responders during disaster 669 situations where infrastructure may be severely damaged. 671 5.6. Low Earth Orbiting Sensor Satellite 673 The Low Earth Orbit (LEO) scenario described is for a sensor 674 satellite communicating directly with ground terminals. One such 675 network is described in reference [UK-DMC]. Note, in this scenario, 676 no geostationary relay satellite is involved. Here, the contact 677 times may be known in order to direct the satellite transmitter to 678 turn on. Some type of automated hailing could also be used. 680 LEO 681 Sensor 682 Satellite 683 +-------+ _ +-------+ 684 | |:_:| | 685 +-------+ +-------+ 686 ,' `. 687 Space/Ground ,' `-. Space/Ground 688 Link 1 ,-' `. Link 2 689 ,' `._ 690 ,' `. 691 ,' Connect Connect `._ 692 _,' T1 T2 `. 693 . ' ` / 694 Ground `. ..,' Ground 695 Station /\'' ___...------'''''''------....__ /\ Station 696 1 /__\.,--' `'--./__\ 2 697 _,,-' ._ _, `--.._ 698 ' `. Ground/Ground Ground/Ground ,' ' 699 `-. Link 1 Link 2 ,-' 700 `._ ,-' 701 `. _,' 702 ' .-----------. 703 | Data | 704 |Collection | 705 | Center | 706 `-----------' 708 Low Earth Orbit Sensor Satellite 710 Figure 5 712 Low Earth Orbit (LEO) is a low-propagation-delay environment of less 713 than ten milliseconds delay to ground, with long periods of 714 disconnection between passes over ground stations. Contact times 715 consist of a few minutes per ground station for Earth satellites 716 orbiting at a couple hundred kilometers altitude (~100 minutes per 717 orbit). Thus, the more ground systems that are available, the 718 greater the potential for contact. The ground stations are connected 719 across the terrestrial Internet, or other backbones. 721 In this scenario, the SCF agent onboard the satellite does not need 722 to perform forwarding of received containers. The satellite is a 723 source for sensor data and may be a sink for command data. 725 The main reason to use SCF in this scenario is to provide a 726 standardized relaying technique and to decouple the control loops 727 between the space/ground link and the ground/ground link. 729 There are numerous companies and systems today that transfer 730 extremely large sensor data sets from LEO to ground without a 731 standardized SCF method. Those data sets are in the multi-gigabyte 732 region and growing. However, they are using protocols and 733 implementations that are not compatible with one another, and which 734 require them to go through various levels of customization per-use. 736 6. Consideration of Existing Technologies 738 In this document, we characterized DTN-based systems as 4th- 739 generation SF rather than SCF systems. Several aspects of DTN are 740 highly desirable for SCF though, and DTN technology may represent a 741 basis for developing SCF standards. DTN utilizes "bundle agents" 742 that are similar to the "SCF agent". Several DTN routing protocols, 743 that exist at varying levels of maturity, can work well for 744 individual SCF scenarios that have been outlined. For instance, 745 Contact Graph Routing is particularly useful in scenarios where 746 future connectivity is predictable/known ahead of time. 748 The SCF container aggregation and deaggregation bears some surface 749 similarity to bundle fragmentation operations in DTN, but there are 750 major differences. SCF containers are intended to be aggregatable 751 within the network, even if they are not portions of the same 752 original container from the application. Additionally, some SCF 753 applications (e.g. science data collection) may find (optional) 754 partial reception of subsets of large containers that have been 755 deaggregated into smaller containers, to still be useful, whereas DTN 756 only delivers entire (reassembled) bundles. This does require the 757 data formats used by such SCF applications to be self-synchronizing, 758 so that they can be parsed, but this is an issue for the application. 760 SCF scenarios require some features that are not yet a part of the 761 DTN specifications: 763 The ability to avoid DoS by propagating an application's permit/ 764 deny filters to SCF agents. 766 The ability to generate and prove ownership of globally-unique 767 application identifiers. 769 DTN goes beyond SCF in one way, which is the targeting of operation 770 over very high-latency data links. SCF does not explicitly attempt 771 to operate over such links, though it may end up being possible. 772 Since these links are mostly only applicable to deep-space scenarios 773 with small numbers of nodes, SCF motivations do not include high- 774 delay. 776 This document also identified JMS and MQ Telemetry Transport message- 777 broker systems as 3rd-generation SF rather than SCF systems. JMS 778 "messages" transferred between "brokers" and applications are similar 779 to the containers transferred between SCF agents and applications. 780 JMS offers both point-to-point (unicast) and publish-subscribe 781 (multicast) models of communication. JMS uses named "queues" (in the 782 point-to-point model) or "topics" (in the publish-subscribe model) in 783 order to identify destinations. JMS brokers often implement a 784 "durable" messaging service that allows messages (and queues) to 785 persist even when the applications that created them (or need to 786 receive them) are disconnected from the broker. 788 SCF scenarios require some features that are not yet really reflected 789 within the JMS specifications: 791 Multi-hop relaying among brokers and secure propagation of 792 information about the queues/topics present or acceptable is not 793 standardized. 795 Communication of an application's desired permit/deny filters on 796 queues that it owns is not standardized. 798 JMS is an API and not a protocol standard. This is the primary 799 hurdle in using JMS to support SCF, as the wire-protocols and other 800 mechanisms used in a particular JMS implementation are not 801 necessarily compatible with others. SCF requires full vendor/ 802 platform interoperability in order to be cost-effective to pursue in 803 preference to point-solutions. JMS is also significantly focused on 804 transfer of Java objects rather than generic containers of bytes as 805 SCF should be. 807 One of the biggest challenges to using existing systems (whether they 808 be DTN implementations, JMS products, or some others) is that most 809 have been designed to include a multitude of additional (optional) 810 features and this results in, at best, limited compatibility between 811 implementations. For instance, the DTN Bundle Protocol is an 812 excellent platform for experimentation due to its flexibility and 813 ease of defining new "blocks" to implement different functionalities. 814 DTN has been used or demonstrated in a wide range of scenarios with 815 differing needs, including simulated military exercises, connecting 816 people in remote regions, moving data from LEO spacecraft, deep-space 817 missions, mining operations, and others. However, individual 818 implementations have grown up to support distinct subsets of the 819 defined blocks, identifier schemes, and algorithms that suit the 820 unique properties of their pet environments. Developing, and then 821 maintaining, a baseline for compatibility has not been a primary 822 concern. For an operational system, a baseline profile of the 823 required functionality would need to exist, which could be present 824 across the spectrum of vendors. For SCF, this type of profile is not 825 present in the existing systems to a level that would enable the 826 scenarios described in this document. Saving energy and running on 827 very small devices (e.g. sensors and embedded medical devices) also 828 motivates having such a profile that could aid in developing very 829 small, yet fully compatible, implementations. 831 MQ Telemetry Transport is a lightweight protocol used for publish/ 832 subscribe messaging between devices. MQTT was designed for low- 833 bandwidth, high latency networks while attempting to ensure 834 reliability of delivery. A major design criteria was simplicity - 835 must be simple to implement and must not add too many "bells and 836 whistles" that would complicate implementation, while still providing 837 a solid building block which can easily be integrated into other 838 solutions. MQTT is designed to handle frequent short periods of 839 network disruption using a technique called "Last Will and 840 Testament". Although not part of the specification, MQTT has been 841 modified to operate in multi-hop environments. 843 7. Characteristics of Information 845 Since information has to be transported and stored in an ACF use 846 case, it is important to be aware of the key characteristics of the 847 information being acted upon. All information has a source and one 848 or more eventual destinations. All application information ready to 849 be sent, has a size that may be very small or quite large (several 850 bytes to multiple gigabytes). Size is important because storage is 851 not unlimited in either the source application's system nor in the 852 relays, and because transmission bandwidth and contact times limit 853 the amount of data that can be sent during any given contact time. 855 Information may have security restrictions placed on it - sensitive 856 or restricted (for your eyes only), and in some cases this may be 857 handled at the application layer, as is done by securing email. 859 All information has a useful lifetime. It may be very short 860 (seconds) or very long (days, weeks, years). Regardless, it is only 861 the users of the information that know what the real useful lifetime 862 is, and it is the application that would be required to set that 863 lifetime. With the exception of specific cases, it is not at all 864 clear that the application can generally make that decision. 866 When investigating the use of DTN bundle lifetimes in DTN deployments 867 and implementations, we have found that the lifetimes have generally 868 been set to match the duration of the experiment. There are 869 instances where some finer granularity has been deployed such and in 870 the Defense Advanced Research Project Agency's (DARPA) Wireless 871 Network after Next (WNaN) where a small number of choices in 872 lifetimes of minutes or hours are used depending on the nature of the 873 data. The DTN bundle lifetime can be used for two purposes: 874 expedited forwarding for end-applications and purging stale 875 information from the relays. Thus, the real requirement we see for 876 SCF should be the ability to expedite forwarding of priority 877 containers and purge stale containers from the system, but not 878 necessarily to specify time-sensitivity on a per-second basis. There 879 may be other means to accommodate this requirement without having to 880 burden the SCF agents with the management and synchronization of 881 notions of "time" - particularly per container - which has been 882 burdensome in DTN use. 884 Often data has a "freshness" characteristic. For a given 885 application, data that is more recent (fresher) is often of greater 886 value that data that is older (stale). In such cases, it may be more 887 important to forward the most recent data, rather that the data that 888 is near the end of its useful lifetime. One might even purge the 889 system of stale data. One trival example that illustrates why data 890 freshness is important would be reception of stock quotes. 891 Obviously, one would not expect an SCF systems to be used for 892 commodities trading due to disruption and ordering issues (assured 893 timeliness). Rather, applications such as sensor data transmissions, 894 software updates or distributed security-key databases are more 895 amenable to SCF deployments. 897 8. Network Management 899 Network management is needed to keep the network running smoothly. 900 It is required for system configuration and maintenance, and monitors 901 the system to determine faults, performance, security issues and 902 accounting. From the scenarios presented, it appears that network 903 management is likely to be per-scenario, and may be effectively 904 accomplished out-of-band. For example: in the Data Mule scenario, 905 one may manage the data mule, but not the edge SCF systems. In the 906 Data Gathering scenario, one is likely to preconfigure the remote 907 sensor nodes and only manage the data-gathering SCF and perhaps the 908 data concentrator SCFs, the ones with high-power radios. 910 This does not imply the network management could not or should not be 911 performed in-band; only that it may not be required. 913 Since resources (e.g. bandwidth, transmit power, and storage) are a 914 precious commodity in SCF networks, policy that manages those 915 resources is expected to be a major component of system 916 configuration. For example: a particular SCF agent may restrict 917 particular information sources to limited storage space and limited 918 storage time. Such policy may restrict all information to a limited 919 storage time in order to purge stale containers. Also, particular 920 sources may get preferential treatment per peering agreements. 922 9. Lessons Learned Summary 924 There are numerous lessons to be learned from previous deployments of 925 manets and 4th-generation store and forward networks such as DTNs. 926 Some of the more critical and important pieces of knowledge are 927 listed below: 929 o SCF systems are generally connected via radio networks. Some 930 radio systems may take far less power to listen than to transmit, 931 though this varies by individual link technology. Wasted 932 transmission is wasted power on a wireless system and can quickly 933 drain a battery. The problem is compounded for devices whose 934 entire lifetime is determined by their battery (e.g. non- 935 rechargeable sensor nodes). Thus, reducing wasted transmissions 936 is high desirable. 938 * The ability to reactively fragment large data sets en-route is 939 highly desirable. This has been demonstrated in DTN 940 experiments. 942 * Routing loops in the SCF will not be caught by layers below. 943 It is imperative that data dies naturally and quickly so as to 944 not waste bandwidth or transmission power. Such loops have 945 been encountered in early experiments with DTN overlays, and 946 are correctable. 948 * It is highly desirable for the sender to know early in a 949 transmission whether or not the receiver will accept the data. 950 This permits a savings in power and optimization of network 951 capacity usage. For instance, in DTN experiments with large 952 bundles, the entire large bundle may be sent, only to be 953 discarded due to security, resource scarcity, or other issues. 955 o Disconnected networks are difficult, if not impossible, to 956 globally synchronize state across. 958 o Managing fine-grained notions of time in a protocol is difficult 959 and adds considerable complexity. 961 o Having a relay protocol be time-dependent opens is up to security 962 vulnerabilities. 964 o Having a relay protocol be time-dependent complicates use of that 965 protocol to synchronize the system - even for coarse 966 synchronization. 968 o It is highly desirable for a receiving agent to determine early 969 within a transfer whether or not to accept the data. Large data 970 sets utilize significant processing and storage resources for data 971 that may end up being discarded due to security, resource 972 constraints, or other policy issues. 974 o It is highly desirable to keep forwarding tables small, and make 975 forwarding decisions ahead of time for predicted contacts. Book- 976 keeping type of processing while forwarding a large number of 977 small containers can overload the processing system. 979 o Testing should be thorough and include exercising both the storage 980 and forwarding systems. Failure to do so will lead to erroneous 981 results [I-D.ivancic-scf-testing-requirements]. Thus, any testing 982 and validation should exercise both the storage and forwarding 983 mechanisms of the implementation. To do otherwise may lead to 984 misleading results. 986 10. Security Considerations 988 Applications need to authenticate to an SCF agent before they can 989 send or receive containers. 991 Authentication of SCF agents to one another needs to be tackled 992 before advertisements of forwarding capability can be acted upon. 994 Bandwidth, Storage, and Processing Power are precious resources in an 995 SCF. In order to reduce DoS vulnerabilities and properly allocate 996 resources, an SCF should be able to determine whether or not to act 997 on a container based solely on the Shipping Label. 999 Applications should be able to limit DoS by expressing explicit 1000 desires to a serving SCF agent for/against certain traffic selectors. 1001 It may be beneficial for this information to propagate between SCF 1002 agents, though it should be recognized that any dynamics in these 1003 preferences causes a risk of data loss due to lack of synchronization 1004 of the filter rules. 1006 While some aspects of Public-Key Infrastructure (PKI) may be 1007 applicable to SCF, PKI itself is not because, in general, PKI 1008 requires connectivity. Public-Keys with caching may be applicable; 1009 however, this would require at least some coarse network 1010 synchronization. 1012 11. IANA Considerations 1014 This document neither creates nor updates any registries or 1015 codepoints, so there are no IANA Considerations. 1017 12. Acknowledgements 1019 Much work builds on lessons learned from the work performed by the 1020 IRTF DTN Research Group. 1022 Work on this document at NASA's Glenn Research Center was funded by 1023 the NASA Glenn Research Center Innovation Funds. 1025 13. References 1027 13.1. Normative References 1029 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1030 August 1980. 1032 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1033 Requirement Levels", BCP 14, RFC 2119, March 1997. 1035 13.2. Informative References 1037 [AMQP] "Advanced Message Queuing Protocol", 1038 . 1041 [DTNRG] "DTN Research Group Wiki", 1042 . 1044 [FidoNet] "FidoNet Home Page", . 1046 [I-D.ivancic-scf-requirements-expectations] 1047 Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store, 1048 Carry and Forward Requirements and Expectations", draft- 1049 ivancic-scf-requirements-expectations-00 (work in 1050 progress), July 2012. 1052 [I-D.ivancic-scf-testing-requirements] 1053 Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store, 1054 Carry and Forward Testing Requirements", draft-ivancic- 1055 scf-testing-requirements-00 (work in progress), July 2012. 1057 [IMAP] "Internet Message Access Protocol", 1058 . 1061 [JMS] "JSM/OpenWire", 1062 . 1064 [MQTT] "Message Queuing Telemetry Transport", 1065 . 1067 [POP] "Post Office Protocol", 1068 . 1070 [Patterns] 1071 Day, J., "Patterns In Network Architectures - A Return to 1072 Fundamentals", Prentice Hall , 2008. 1074 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 1075 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 1076 Networking Architecture", RFC 4838, April 2007. 1078 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 1079 Specification", RFC 5050, November 2007. 1081 [SMIME] "Secure/Multipurpose Internet Mail Extensions", 1082 . 1084 [SMTP] "Simple Mail Transfer Protocole", . 1087 [STOMP] "Streaming Text Oriented Messaging Protocol", 1088 . 1091 [UK-DMC] Wood, L., Ivancic, W., Eddy, W., Stewart, D., Jackson, C., 1092 and A. da Silva Curiel, "Use of the Delay-Tolerant 1093 Networking Bundle Protocol from Space", 59th International 1094 Astronautical Congress, Glasgow Paper IAC-08-B2.3.10 (also 1095 NASA-TM-2009-215582), September 2008. 1097 [UPPC] "Unix-to-Unix Copy", . 1099 [XMPP] "Extensible Messaging and Presence Protocol", 1100 . 1102 Authors' Addresses 1103 William Ivancic 1104 NASA Glenn Research Center 1105 21000 Brookpark Road 1106 Cleveland, Ohio 44135 1107 United States 1109 Phone: +1-216-433-3494 1110 Email: william.d.ivancic@nasa.gov 1112 Wesley M. Eddy 1113 MTI Systems 1115 Email: wes@mti-systems.com 1117 Alan G. Hylton 1118 NASA Glenn Research Center 1119 21000 Brookpark Road 1120 Cleveland, Ohio 44135 1121 United States 1123 Phone: +1-216-433-6045 1124 Email: alan.g.hylton@nasa.gov 1126 Dennis C. Iannicca 1127 NASA Glenn Research Center 1128 21000 Brookpark Road 1129 Cleveland, Ohio 44135 1130 United States 1132 Phone: +1-216-433-6493 1133 Email: dennis.c.iannicca@nasa.gov 1135 Joseph A. Ishac 1136 NASA Glenn Research Center 1137 21000 Brookpark Road 1138 Cleveland, Ohio 44135 1139 United States 1141 Phone: +1-216-433-6587 1142 Email: jishac@nasa.gov