idnits 2.17.1 draft-ivancic-scf-requirements-expectations-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 date (December 13, 2013) is 3787 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 385 == Unused Reference: 'RFC0768' is defined on line 654, but no explicit reference was found in the text == Unused Reference: 'I-D.ivancic-scf-testing-requirements' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC4838' is defined on line 680, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-ivancic-scf-problem-statement-00 == Outdated reference: A later version (-01) exists of draft-ivancic-scf-testing-requirements-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 Requirements and Expectations 13 draft-ivancic-scf-requirements-expectations-01 15 Abstract 17 This document describes the requirements for a Store, Carry and 18 Forward (SCF) protocol, and the expectations placed upon the SCF 19 agents and SCF applications. 21 The Requirements and Expectations document is one of three that fully 22 describe the SCF system. The other two are the problem statement and 23 the testing requirements document. 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 16, 2014. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 This document may not be modified, and derivative works of it may not 55 be created, except to format it for publication as an RFC or to 56 translate it into languages other than English. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Design Considerations . . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5 64 5. Agent Requirements and Expectations . . . . . . . . . . . . . 10 65 6. Application Requirements and Expectations . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 10.2. Informative References . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Terminology 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 In developing this document, we have intentionally avoided some 81 terminology used by other protocols - particularly store-and-forward 82 protocols - to avoid biases and confusion that may otherwise ensue. 84 o Container - metadata describing the characteristics of application 85 /user data to be transported over the network and its forwarding 86 requirements as well as a mandatory checksum of that information 87 (Shipping Label) and the application/user data to be transported 88 over the network as well as an optional checksum of that 89 information (Shipping Container). Containers may consists of one 90 or more sub-containers. 92 o Container Aggregation - The process of organizing one or multiple 93 containers as sub-containers inside another larger container. 95 o Container Deaggregation - The process of removing one or more sub- 96 containers from a larger container. This differs from 97 fragmentation because rather than creating new containers, 98 deaggregation operates on existing sub-containers. 100 o Container Fragmentation - The process of dividing a single 101 container's contents into multiple new containers which will need 102 to be eventually reassembled back into the original container 103 before delivery to the application. 105 o Container Reassembly - The process of recombining the contents of 106 multiple containers into a single container that they were 107 originally part of, and that needs to be delivered to the 108 application intact. 110 o Delay - propagation delay between SCF agents. Delay does not 111 include disconnection time. 113 o Disruption - a relatively short period of disconnection within an 114 otherwise well-connected network (e.g. a loss of connectivity in 115 the range of seconds to perhaps minutes) 117 o Disconnection - a relatively long period where communication 118 between a significant proportion of hosts is not possible for 119 various reasons (e.g. due to the inability to close a radio link) 121 o Metadata - synonymous with a Container's Label 123 o SCF - Store, Carry and Forward 125 o SF - Store-and-Forward, or "store and forward" as used generically 126 in other literature (where the presence of hyphenation varies) 128 o SCF Agent - a protocol instance providing SCF services to an 129 upper-layer user/application 131 o Shipping Container - the application/user data to be transported 132 over the network as well as an optional checksum of that 133 information. 135 o Shipping Label - metadata describing the characteristics of a 136 container and its forwarding requirements, as well as a mandatory 137 checksum of that information. 139 o Sub-Container - A small container residing inside a larger 140 container. 142 o Transport Capacity - (as a first order approximation) the 143 combination of bandwidth and contact time. 145 2. Introduction 147 This document describes the requirements for a Store, Carry and 148 Forward (SCF) protocol, and the expectations placed upon the SCF 149 agents and SCF applications. 151 This Requirements and Expectations document is one of three that 152 fully describe the SCF system. The other two are the problem 153 statement and the testing requirements document. 155 As background, the SCF Problem Statement 156 [I-D.ivancic-scf-problem-statement] is suggested reading. The SCF 157 Problem Statement describes the core SCF problem and gives an 158 assessment of the potential to use existing technologies as 159 solutions. In addition, it provides a number of SCF deployment 160 scenarios. 162 3. Design Considerations 164 The following design considerations are explicitly stated with a goal 165 of keeping the protocol simple. (Anyone can make things more 166 complicated!) 168 o Do not overload the relaying protocol. Keep It Simple. 170 * Keep network management functions separate from the relaying 171 protocol. 173 * Content Based Networking is different than SCF. SCF can be 174 used to move content, but should not be considered an in- 175 network content store. 177 * Rationale: Separation allows for independent development and 178 optimizations. 180 o The SCF protocol MUST NOT rely on time synchronization between 181 applications or relaying agents. 183 * It is very difficult, if not impossible, to synchronize 184 disconnected networks. Furthermore, if the protocol requires 185 synchronization to work, it can never be used to synchronize a 186 system - even for coarse synchronization. In addition, 187 reliance on absolute time creates security vulnerabilities. 189 o Protocol options make interoperability hard. Options are often 190 used as a placeholder for fixing a bad design. 192 o Naming and addressing are key to security and scalability. 194 o Addressing should be topological (location dependent). This 195 enables aggregation of the routing locator space and improves 196 scalability for the routing system. 198 o Strive to limit the size of the forwarding table. Large 199 forwarding tables place a great burden on the SCF processing 200 system. There is always a limit for any CPU. The further one is 201 removed from reaching that limit, the better. 203 4. Protocol Requirements 205 The following are a list of requirements for a SCF Protocol. The 206 requirements are specifically written in general terms. The intent 207 is to identify what is required, not how to solve the requirement. 208 The requirements are in no particular order of precedence, but are 209 numbered in order to aid in referencing for discussion. 211 SCF Agent Requirements and Agent operation expectations have been 212 intentionally separated, as the SCF Agent requirements are more 213 policy-based than protocol-based. However, one needs to understand 214 both in order to effectively implement the SCF protocol. 216 PROTOCOL-REQ1: The SCF relaying protocol MUST be able to handle 217 data sets that are very small (several bytes) and 218 very large (several gigabytes). 220 * Rationale: SCF is useful for very small, simple, 221 low-power, low-processing minimally-capable 222 sensor systems, as well as for more capable 223 high-end data mules. In a simple sensor-web one 224 may be moving extremely small containers of 225 information on the order of bytes; whereas later 226 onward delivery by a data mule may be moving 227 containers containing gigabytes of data. 229 PROTOCOL-REQ2: The SCF protocol MUST permit SCF agents to be able 230 to aggregate containers. 232 * Rationale: Aggregation will reduce forwarding 233 table size and enable pre-processing of 234 forwarding queues. Without aggregation, the SCF 235 agent processing capabilities can be quickly 236 overwhelmed - particularly for a large number of 237 small containers - even if those containers are 238 destined for the same location. Aggregation and 239 Deaggregation enable efficient shipping of 240 information through a SCF network from a variety 241 sources to a common destination by continually 242 recombining containers as the information moves 243 through the relay network. 245 PROTOCOL-REQ3: The SCF protocol MUST permit SCF agents to be able 246 to deaggregate containers. 248 * Rationale: Deaggregation allows subcontainers to 249 be removed from larger aggregated containers and 250 either shipped separately due to contact 251 limitations, or spread out to multiple other 252 relaying SCF agents in parallel. 254 PROTOCOL-REQ4: The SCF protocol MUST permit SCF agents to be able 255 to reactively fragment a container. 257 * Rationale: It is often not possible to determine 258 how long a contact time will be between SCF 259 agents. In such instances, which may be the 260 norm, one cannot determine the transport 261 capacity and may only be able to transfer a 262 portion of a container before the contact ends. 263 In order to improve transport efficiency and 264 effectively utilize the radio link, one should 265 not have to retransmit what has already been 266 received. 268 PROTOCOL-REQ5: The SCF protocol SHOULD permit SCF agents to be 269 able to proactively fragment a container. 271 * Rationale: It may be possible to a priori know 272 the transport capacity between SCF agents. In 273 such instances, one may determine that an entire 274 container could only be transfer between agents 275 if it is divided into smaller units. In other 276 cases, a SCF agent may wish to limit the size of 277 containers as a matter of policy. In either of 278 these cases, proactive fragmentation would be 279 useful. However, it would be more desirable for 280 the application to limit the size of the 281 container if at all possible, rather than having 282 this done by the SCF agent. 284 PROTOCOL-REQ6: An SCF protocol MUST implement reliability on the 285 Shipping Label, and a damaged Shipping Label MUST 286 NOT propagate to further SCF agents or have its 287 container further propagated or delivered to 288 applications. 290 * Rationale: An SCF agent needs to be able to 291 determine if the shipping label is damaged in 292 order to prevent misdelivery of data, waste of 293 resources (storage, battery, network capacity, 294 etc.), and other suboptimal results of operating 295 on flawed forwarding information. 297 PROTOCOL-REQ7: An SCF protocol MUST be capable of implementing 298 reliability on the Shipping Container. 300 * Rationale: An SCF agent must be able to 301 determine if the shipping container is damaged. 302 A damaged Shipping Container MAY be discarded 303 along with the associated Shipping Label. Note, 304 user of reliability on the Shipping Container is 305 not mandatory, but the ability to have such 306 capability is. 308 PROTOCOL-REQ8: The SCF protocol security implementation MUST 309 authenticate the Shipping Label independent of the 310 Shipping Container. 312 * Rationale: The ability to authenticate data 313 sources and control resource usage early on is 314 critical to reducing vulnerabilities to denial- 315 of-service attacks, whether intentional or 316 unintentional. For large containers, if the 317 entire container had to be received and 318 processed before a determination could be made 319 as the the source of the Container, multiple 320 resources would be wasted including bandwidth, 321 processing cycles and storage. 323 PROTOCOL-REQ9: The SCF protocol security implementation MUST work 324 with reactive fragmentation. 326 * Rationale: For medium- and high-end SCF systems, 327 the ability to authenticate data sources and 328 control resource usage is critical. Likewise, 329 reactive fragmentation may be quite common and 330 has been shown to be invaluable in transporting 331 large data sets [Multi-Terminal][Multi- 332 Terminal]. 334 PROTOCOL-REQ10: The SCF protocol security implementation MUST have 335 a security policy database to control resources. 337 * Rationale: Once a data source is authenticated, 338 the security policy will determine what type and 339 amount of resources that source can use, as well 340 as possibly the forwarding priorities. It is 341 anticipated that SCF systems will have different 342 peering arrangements with different entities 343 (e.g. peers, groups, or organizations). 345 PROTOCOL-REQ11: The SCF protocol MUST be able to separate the 346 Shipping Label from the Shipping Container 348 * Rationale: The SCF agent must be able to 349 determine whether or not it wishes to receive or 350 store a container prior to receiving the entire 351 container. This reduces denial-of-service 352 vulnerabilities and enables efficient use of 353 radio and system resources. 355 PROTOCOL-REQ12: The SCF protocol MUST have a mechanism that enables 356 data to die naturally. 358 * Rationale: Data should die naturally to avoid 359 routing loops at the SCF layer. Routing loops 360 at the SFC layer cannot be eliminated by lower- 361 layer mechanisms (i.e. and IPv6 hop count will 362 not correct an SCF routing loop). 364 PROTOCOL-REQ13: The SCF protocol MUST have a naming mechanism that 365 specifies the application and instance to which the 366 content is bound. 368 * Rationale: This naming mechanism is necessary in 369 order for the SCF agent end system to pass the 370 Shipping Container content to the proper 371 instance of a given application since multiple 372 instances may be invoked at any given time. 374 PROTOCOL-REQ14: The SCF protocol MUST have a Quality-of-Service 375 (QOS) mechanism to expedite forwarding and to 376 handle storage lifetimes. 378 * Rationale: Past experiences with other store- 379 and-forward technologies such as DTN [RFC5050] 380 have shown that it is very difficult for many 381 applications to determine how long the useful 382 life of data is. Rather, bundle lifetimes have 383 been set either arbitrarily or rather coarsely 384 (e.g. short, medium, forever) - see Bundle 385 Lifetimes [1]. QOS will enable and SCF to 386 expedite, store and purge data on a much more 387 coarse scale than the use of absolute or 388 relative time. Such QOS policies could be a 389 configuration setting within individual SCF 390 agents, or within an SCF network. This greatly 391 simplifies the protocol processing as well as 392 aggregation and deaggregation of containers. 394 PROTOCOL-REQ15: The SCF protocol MUST have a mechanism for a 395 receiving system to acknowledge reception of a 396 container from the sending system (i.e. hop-by-hop 397 acknowledgements). 399 * Rationale: This allows a sending system to 400 release the container if it so desires, thereby 401 improving resource usage. 403 PROTOCOL-REQ16: The SCF protocol MUST have a mechanism to notify a 404 sender that the container will not be processed. 406 * Rationale: If the agent's policy states "Do not 407 accept" for any possible reason, it is important 408 to inform the sender as soon as possible (ASAP) 409 that the container will not be accepted, to 410 allow the sender to stop transmission and 411 determine a different route for that container. 412 Note, there may be security reasons not to 413 provide this information, but in generally such 414 a response SHOULD be sent. 416 PROTOCOL-REQ17: The SCF protocol SHOULD have a mechanism that 417 enables one to identify fresh versus stale content 418 for a given flow. 420 * Rationale: Fresh data is often of far greater 421 value than stale data. The ability to identify 422 fresh data and either replace the stale data 423 with fresh, or send the fresh data first, is 424 highly desirable in order to optimize resource 425 usage - particularly storage and bandwidth. 427 * Comment: There appears to be a desire in many 428 instances to proactively create fixed bundle 429 sizes in DTN and then what the application to 430 put them back in order. With proactive 431 fragmentation, this is possible and there is a 432 mechanism to allow reordering. With straight 433 bundling, this is problematic as there is no 434 such formalized standard sequencing (i.e. 435 sequence numbers). 437 5. Agent Requirements and Expectations 439 The following are a list of requirements for an SCF Agent. The 440 requirements are in no particular order of precedence, but are 441 numbered in order to aid in referencing for discussion. 443 AGENT-REQ1: An SCF agent MUST NOT be required to implement SCF 444 security. Security must be optional. 446 * Rationale: Simple devices such as sensors may wish to 447 utilize the SCF protocol, but have neither the need 448 for security, nor the processing capability to 449 implement SCF security. 451 AGENT-REQ2: An SCF agent MAY implement reliability on the Shipping 452 Container. 454 * Rationale: An application may or may not care if the 455 contents of the container arrive without 456 modification. For example, protecting a large image 457 file from a bit flip may not be considered as 458 important as reducing the processing overheard of 459 creating and checking reliability on the Shipping 460 Container. 462 AGENT-REQ3: An SCF agent MUST hold onto a container until it can 463 either be transferred or QOS policy indicates its useful 464 lifetime has expired or storage resources reach a level 465 that requires some purging of containers based on 466 policy. 468 * Rationale: The sender expects the receiver to do its 469 best to forward the container, and MAY release the 470 container upon notification from the receiver that 471 the container has been received. If the receiver 472 does not plan to hold onto the container, it SHOULD 473 send a notification to the sender stating such. 475 AGENT-REQ4: An SCF agent MAY remove a container once it receives 476 notification from the next hop SCF that the container 477 has been delivered. 479 * Rationale: The ability to release containers enables 480 efficient use of storage resources. Note, some 481 deployments and some routing protocols MAY mandate 482 that the agent retain a container even after a 483 successful transfer. In such deployments, containers 484 would likely be removed based on a retention policy 485 which may be based on QOS. 487 AGENT-REQ5: An SCF agent SHOULD NOT accept a container if it has no 488 intention of giving a best effort to forward the 489 container. 491 * Rationale: The sending SCF's default expectation is 492 that, if accepted, the receiving SCF will do its best 493 to forward the container. This allows the sending 494 SCF, if so desired, to purge the container from its 495 storage with some confidence that the container will 496 be delivered. 498 AGENT-REQ6: An SCF agent SHOULD implement a policy system that 499 controls resources. Such a policy system MAY include 500 the filters described below. 502 * Rationale: Resources including bandwidth and storage 503 storage are precious commodities that need to be 504 controlled. Various SCF deployments are expected to 505 have vastly different capabilities and needs. For 506 example, an SCF science sensorweb may have not need 507 for security, while implementing a policy that 508 basically says "Accept Everything", because all 509 containers are know a priori to be small and the 510 deployment is a closed network. Other deployments 511 may consist of high-end SCF agents supporting 512 multiple organizations and transferring and storing 513 Gigabytes or more of information. The ability to 514 tune the policies to fit the deployment makes such 515 deployments realizable. 517 (a) What volume (size) container will be accepted. 519 + Rationale: Storage resources are not infinite. It is 520 likely policy will limit container size and/or overall 521 memory allocations per source, address range, or other 522 filters. In addition, some SCF agents may have limited 523 processing and not be willing or capable of handling 524 extremely large containers 526 (b) What sources are permitted to use resources and how much 527 resource? 529 + Rationale: Resources including bandwidth and storage are 530 precious. It is anticipated that peering arrangements 531 will exist to populate this database. Not every source 532 may be permitted to utilize the resources. 534 (c) What destinations are permitted to use resources and how much 535 resource? 537 + Rationale: Resources including bandwidth and storage are 538 precious. It is anticipated that peering arrangements 539 will exist to populate this database. Not every 540 destination may be permitted to utilize the resources. 542 (d) Prioritized container delivery. 544 + Rationale: It is anticipated that peering arrangements 545 will exist to populate this database. Some peers are 546 likely to be given preferential treatment, while others 547 may be serviced only after all commitments have been met, 548 regardless of QoS (e.g. the general's containers are 549 processed before the private's; the organization who owns 550 the SCF agent gets preferential treatment over all other 551 organizations. 553 (e) A mapping of QoS to retention lifetime and forwarding 554 priority. 556 + Rationale: A coarse-grained retention policy is 557 anticipated. Such granularity may be minutes, hours, 558 days, forever (until resources become scarce and memory 559 must be released). This alleviates the need for actual 560 lifetime settings within the SCF protocol and allows 561 various deployments to be uniquely configured. 563 AGENT-REQ7: If security is implemented, when coming in contact with 564 one another, adjacent SCF agents MUST minimally be able 565 to identify one another securely and prove that they can 566 be trusted as relays for a given destination 567 application. 569 * Rationale: Such a mechanism is necessary to prevent 570 hijacking of information. Also, aggregation and 571 deaggregation may be implemented along a container's 572 route. Trust between forwarding agents must be 573 established to enable this. 575 AGENT-REQ8: SCF Agents MUST be able to indicate (or deny) forwarding 576 of individual containers, based on exchanging their 577 shipping labels only. 579 * Rationale: This allows for efficient use of RF 580 resources as well as reducing DOS vulnerabilities. 581 It the SCF Agent had to process an entire Container 582 prior to denying acceptance, a malicious entity could 583 easily perform a DOS attack by sending extremely 584 large containers which would have to be stored and 585 processed by the receiving SCF prior to rejection. 587 AGENT-REQ9: SCF Agents MAY notify applications of pending received 588 data. 590 * Rationale: If the SCF agent knows it is bound to an 591 application and can notify the application of pending 592 received data, this could improve the application's 593 operations. 595 6. Application Requirements and Expectations 597 APPLICATION-REQ1: Applications SHOULD be designed to operate in a 598 disconnected systems. 600 * Rationale: Applications that have been designed 601 assuming a connected network are likely to 602 break. 604 * Rationale: Streaming may work, but should not 605 be encouraged as streaming applications with 606 reasonably significant volumes of traffic are 607 likely to only work for connected systems or 608 very short fades. Such systems probably do not 609 need SCF. 611 APPLICATION-REQ2: Applications MUST be able to select their own 612 globally-unique identifiers and notify SCF agents 613 of them, along with providing proof of ownership. 615 * Rational: 617 APPLICATION-REQ3: Applications MUST be able to poll a SCF agent for 618 pending received data. 620 * Rationale: Applications are the only ones that 621 can keep track of the shared state between 622 sender and receiver. The Application cannot 623 expect lower layers such as the SCF agent to 624 fully understand its needs. 626 * Rationale: This eliminates putting undue burden 627 on the SCF, and ensures interoperability to 628 specify a known operational expectation. 630 7. Security Considerations 632 This document does not specify a protocol or implementation, only the 633 requirements set. The rationale for individual requirements related 634 to security includes discussion of the security considerations that 635 motivate them. 637 8. IANA Considerations 639 This document neither creates nor updates any registries or 640 codepoints, so there are no IANA Considerations. 642 9. Acknowledgements 644 Much work builds on lessons learned from the work performed by the 645 IRTF DTN Research Group. 647 Work on this document at NASA's Glenn Research Center was funded by 648 the NASA Glenn Research Center Innovation Funds. 650 10. References 652 10.1. Normative References 654 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 655 August 1980. 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, March 1997. 660 10.2. Informative References 662 [I-D.ivancic-scf-problem-statement] 663 Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store, 664 Carry and Forward Problem Statement", draft-ivancic-scf- 665 problem-statement-00 (work in progress), July 2012. 667 [I-D.ivancic-scf-testing-requirements] 668 Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store, 669 Carry and Forward Testing Requirements", draft-ivancic- 670 scf-testing-requirements-00 (work in progress), July 2012. 672 [Multi-Terminal] 673 Ivancic, W., Paulsen, P., Stewart, D., Taylor, J., Lynch, 674 S., Heberle, J., Northam, J., Jackson, C., and L. Wood, 675 ""Large File Transfers from Space using Multiple Ground 676 Terminals and Delay-Tolerant Networking"", IEEE Global 677 Telecommunications Conference (GLOBECOM 2010), , December 678 2010. 680 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 681 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 682 Networking Architecture", RFC 4838, April 2007. 684 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 685 Specification", RFC 5050, November 2007. 687 Authors' Addresses 689 William Ivancic 690 NASA Glenn Research Center 691 21000 Brookpark Road 692 Cleveland, Ohio 44135 693 United States 695 Phone: +1-216-433-3494 696 Email: william.d.ivancic@nasa.gov 698 Wesley M. Eddy 699 MTI Systems 701 Email: wes@mti-systems.com 703 Alan G. Hylton 704 NASA Glenn Research Center 705 21000 Brookpark Road 706 Cleveland, Ohio 44135 707 United States 709 Phone: +1-216-433-6045 710 Email: alan.g.hylton@nasa.gov 711 Dennis C. Iannicca 712 NASA Glenn Research Center 713 21000 Brookpark Road 714 Cleveland, Ohio 44135 715 United States 717 Phone: +1-216-433-6493 718 Email: dennis.c.iannicca@nasa.gov 720 Joseph A. Ishac 721 NASA Glenn Research Center 722 21000 Brookpark Road 723 Cleveland, Ohio 44135 724 United States 726 Phone: +1-216-433-6587 727 Email: jishac@nasa.gov