<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc category="exp" ipr="noModificationTrust200811" docName="draft-ivancic-scf-requirements-expectations-01">
<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<!--<?rfc rfcedstyle="yes"?>-->
<?rfc sortrefs="yes" ?>

  <front>
     <title abbrev="SCF Requirements">Store, Carry and Forward Requirements and Expectations</title>
     
     <author initials="W." surname="Ivancic" fullname="William Ivancic">
        <organization abbrev="NASA GRC">NASA Glenn Research Center</organization>
        <address>
          <postal>
             <street>21000 Brookpark Road</street>
             <city>Cleveland</city><region>Ohio</region>
             <code>44135</code>
             <country>United States</country>
          </postal>
            <phone>+1-216-433-3494</phone>
            <email>william.d.ivancic@nasa.gov</email>
        </address>
      </author>

    <author initials="W. M." surname="Eddy" fullname="Wesley M. Eddy">
      <organization abbrev="MTI Systems">MTI Systems</organization>
      <address>
      <email>wes@mti-systems.com</email>
      </address>
    </author>

      <author initials="A." surname="Hylton" fullname="Alan G. Hylton">
        <organization abbrev="NASA GRC">NASA Glenn Research Center</organization>
        <address>
          <postal>
             <street>21000 Brookpark Road</street>
             <city>Cleveland</city><region>Ohio</region>
             <code>44135</code>
             <country>United States</country>
          </postal>
            <phone>+1-216-433-6045</phone>
            <email>alan.g.hylton@nasa.gov</email>
        </address>
      </author>
      
           <author initials="D. C." surname="Iannicca" fullname="Dennis C. Iannicca">
        <organization abbrev="NASA GRC">NASA Glenn Research Center</organization>
        <address>
          <postal>
             <street>21000 Brookpark Road</street>
             <city>Cleveland</city><region>Ohio</region>
             <code>44135</code>
             <country>United States</country>
          </postal>
            <phone>+1-216-433-6493</phone>
            <email>dennis.c.iannicca@nasa.gov</email>
        </address>
      </author>
      
           <author initials="J. A." surname="Ishac" fullname="Joseph A. Ishac">
        <organization abbrev="NASA GRC">NASA Glenn Research Center</organization>
        <address>
          <postal>
             <street>21000 Brookpark Road</street>
             <city>Cleveland</city><region>Ohio</region>
             <code>44135</code>
             <country>United States</country>
          </postal>
            <phone>+1-216-433-6587</phone>
            <email>jishac@nasa.gov</email>
        </address>
      </author>
  

    <date year="2013" />
    <area>individual</area>
    <keyword>store carry and forward</keyword>
    <keyword>SCF</keyword>
    <keyword>disconnected networking</keyword>


        
       

    <keyword>modem</keyword>
    <keyword>SCA</keyword>

    <abstract>

<t> 
This document describes the requirements for a Store, Carry and Forward (SCF) protocol, 
and the expectations placed upon the SCF agents and SCF applications. 
</t>

<t>
The Requirements and Expectations document is one of three that fully describe the SCF system. The other two are the problem statement and the testing requirements document.
</t>
    </abstract>

  </front>
  
  
  
  <middle>

	<section title="Terminology"> 

<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 <xref target="RFC2119" />.
</t>

<!-- below seems like a rehash of the other doc. Should it even be here? L. -->
<t>
In developing this document, we have intentionally avoided some terminology used by other protocols - particularly store-and-forward protocols - to avoid biases and confusion that may otherwise ensue.
</t>

<t>
	<list style="symbols"> 
	

	  <t>Container - metadata describing the characteristics of application/user data to be transported over the network and its forwarding requirements as well as a mandatory checksum of that information (Shipping Label) and the application/user data to be transported over the network  as well as an optional checksum of that information (Shipping Container).  Containers may consists of one or more  sub-containers.</t>
	  
	  <t>Container Aggregation - The process of organizing one or multiple containers as sub-containers inside another larger container.</t>
	  
	  <t>Container Deaggregation - The process of removing one or more sub-containers from a larger container.  This differs from fragmentation because rather than creating new containers, deaggregation operates on existing sub-containers.</t>
	 
	  <t>Container Fragmentation - The process of dividing a single container's contents into multiple new containers which will need to be eventually reassembled back into the original container before delivery to the application.</t>

	  <t>Container Reassembly - The process of recombining the contents of multiple containers into a single container that they were originally part of, and that needs to be delivered to the application intact.</t>

	  <t>Delay - propagation delay between SCF agents. Delay does not include disconnection time.</t>

	  <t>Disruption - a relatively short period of disconnection within an otherwise well-connected network (e.g. a loss of connectivity in the range of seconds to perhaps minutes)</t>

	  <t>Disconnection - a relatively long period where communication between a significant proportion of hosts is not possible for various reasons (e.g. due to the inability to close a radio link)</t>
	 
	  <t>Metadata - synonymous with a Container's Label</t>
	  
	  <t>SCF - Store, Carry and Forward</t>
	  
	  <t>SF - Store-and-Forward, or "store and forward" as used generically in other literature (where the presence of hyphenation varies)</t>

	  <t>SCF Agent - a protocol instance providing SCF services to an upper-layer user/application</t>
	  
	  <t>Shipping Container - the application/user data to be transported over the network  as well as an optional checksum of that information.</t> 

	  <t>Shipping Label - metadata describing the characteristics of a container and its forwarding requirements, as well as a mandatory checksum of that information.</t>
      <!-- is checksum the right word? integrity check? L. -->

	  <t>Sub-Container - A small container residing inside a larger container.</t>
	
	  <t>Transport Capacity - (as a first order approximation) the combination of bandwidth and contact time.</t>


</list>
</t>

	
	</section>





	<section title="Introduction"> 
	
<t> 
This document describes the requirements for a Store, Carry and Forward (SCF) protocol, 
and the expectations placed upon the SCF agents and SCF applications. 
</t>

<t>
This Requirements and Expectations document is one of three that fully describe the SCF system. The other two are the problem statement and the testing requirements document.
</t>

<t>
As background, the SCF Problem Statement <xref target= "I-D.ivancic-scf-problem-statement"/> is suggested reading.
The SCF Problem Statement describes the core SCF problem and gives an assessment of the
potential to use existing technologies as solutions. In addition, it provides a number of SCF deployment scenarios.
</t>
 
</section>
	
	    <section anchor="Design" title="Design Considerations">
		
<t>The following design considerations are explicitly stated with a goal of keeping the protocol simple.
(Anyone can make things more complicated!)</t>

	<t>
	<list style="symbols"> 
	<t>Do not overload the relaying protocol. Keep It Simple.
		<list style="symbols"> 	
			<t>Keep network management functions separate from the relaying protocol.</t>
	  
			<t>Content Based Networking is different than SCF.  
			SCF can be used to move content, but should not be 
			considered an in-network content store.</t>
	  
			<t>Rationale: Separation allows for independent development and optimizations.</t>
		</list>
		</t>
		
	<t>The SCF protocol MUST NOT rely on time synchronization between applications or relaying agents.
		<list style="symbols"> 	
			<t>It is very difficult, if not impossible, to synchronize disconnected networks. 
			Furthermore, if the protocol requires synchronization to work, it can never be 
			used to synchronize a system - even for coarse synchronization. 
			In addition, reliance on absolute time creates security vulnerabilities.</t> <!-- this seems like a nit-pciking reaction to DTN? L. -->
		</list>
		</t>
		
	<t>Protocol options make interoperability hard. 
	Options are often used as a placeholder for fixing a bad design.</t>
	
	<t>Naming and addressing are key to security and scalability.</t>
	
	<t>Addressing should be topological (location dependent). 
	This enables aggregation of the routing locator space and improves 
	scalability for the routing system. </t>
	
	<t>Strive to limit the size of the forwarding table. Large forwarding tables place a great burden on the SCF processing system. There is always a limit for any CPU. The further one is removed from reaching that limit, the better. </t>
	</list>		
	</t>

	</section>	
	
    <section anchor="ProtoReq" title="Protocol Requirements">

<t>
The following are a list of requirements for a SCF Protocol. The requirements are specifically written in general terms. The intent is to identify what is required, not how to solve the requirement. The requirements are in no particular order of precedence, but are numbered in order to aid in referencing for discussion.</t>

<t>SCF Agent Requirements and Agent operation expectations have been intentionally separated, as the SCF Agent requirements are more policy-based than protocol-based.  However, one needs to understand both in order to effectively implement the SCF protocol.</t>

	<t>
	<list style="format PROTOCOL-REQ%d: ">
<!--	<list style="numbers"> -->
	<t>The SCF relaying protocol MUST be able to handle data sets that are very small (several bytes) and very large (several gigabytes).
		<list style="symbols"> 	
			<t>Rationale: SCF is useful for very small, simple, low-power, low-processing minimally-capable sensor systems, as well as for more capable high-end data mules. In a simple sensor-web one may be moving extremely small containers of information on the order of bytes; whereas later onward delivery by a data mule may be moving containers containing gigabytes of data.</t>
		</list>
		</t>

	<t>The SCF protocol MUST permit SCF agents to be able to aggregate containers.
		<list style="symbols"> 	
			<t>Rationale: Aggregation will reduce forwarding table size and enable pre-processing of forwarding queues. Without aggregation, the SCF agent processing capabilities can be quickly overwhelmed - particularly for a large number of small containers - even if those containers are destined for the same location.  Aggregation and Deaggregation enable efficient shipping of information through a SCF network from a variety sources to a common destination by continually recombining containers as the information moves through the relay network.</t>
		</list>
		</t>
		
	<t>The SCF protocol MUST permit SCF agents to be able to deaggregate containers.
		<list style="symbols"> 	
			<t>Rationale: Deaggregation allows subcontainers to be removed from larger aggregated containers and either shipped separately due to contact limitations, or spread out to multiple other relaying SCF agents in parallel.  </t>
		</list>
		</t>

	<t>The SCF protocol MUST permit SCF agents to be able to reactively fragment a container.
		<list style="symbols"> 	
			<t>Rationale: It is often not possible to determine how long a contact time will be between SCF agents. In such instances, which may be the norm, one cannot determine the transport capacity and may only be able to transfer a portion of a container before the contact ends. In order to improve transport efficiency and effectively utilize the radio link, one should not have to retransmit what has already been received.</t>
		</list>
		</t>

	<t>The SCF protocol SHOULD permit SCF agents to be able to proactively fragment a container.
		<list style="symbols"> 	
			<t>Rationale: It may be possible to a priori know the transport capacity between SCF agents. In such instances, one may determine that an entire container could only be transfer between agents if it is divided into smaller units. In other cases, a SCF agent may wish to limit the size of containers as a matter of policy. In either of these cases, proactive fragmentation would be useful. However, it would be more desirable for the application to limit the size of the container if at all possible, rather than having this done by the SCF agent.</t>
		</list>
		</t>	

	<t>An SCF protocol MUST implement reliability on the Shipping Label, and a damaged Shipping Label MUST NOT propagate to further SCF agents or have its container further propagated or delivered to applications.
    <!-- standards language in this doc? L. -->
		<list style="symbols"> 	
			<t>Rationale: An SCF agent needs to be able to determine if the shipping label is damaged in order to prevent misdelivery of data, waste of resources (storage, battery, network capacity, etc.), and other suboptimal results of operating on flawed forwarding information.</t>		
		</list>
		</t>
	

	<t>An SCF protocol MUST be capable of implementing reliability on the Shipping Container.
		<list style="symbols"> 	
			<t>Rationale: An SCF agent must be able to determine if the shipping container is damaged.  A damaged Shipping Container MAY be discarded along with the associated Shipping Label. Note, user of reliability on the Shipping Container is not mandatory, but the ability to have such capability is.</t>		
		</list>
		</t>
	


	<t>The SCF protocol security implementation MUST authenticate the Shipping Label independent of the Shipping Container.
		<list style="symbols"> 	
			<t>Rationale: The ability to authenticate data sources and control resource usage  early on is critical to reducing vulnerabilities to denial-of-service attacks, whether intentional or unintentional.  For large containers, if the entire container had to be received and processed before a determination could be made as the the source of the Container, multiple resources would be wasted including bandwidth, processing cycles and storage. </t>
		</list>
		</t>
	

	<t>The SCF protocol security implementation MUST work with reactive fragmentation.
		<list style="symbols"> 	
			<t>Rationale: For medium- and high-end SCF systems, the ability to authenticate data sources and control resource usage is critical.  Likewise, reactive fragmentation may be quite common and has been shown to be invaluable in transporting large data sets <xref target="Multi-Terminal" />[Multi-Terminal].</t>
		</list>
		</t>
	

	<t>The SCF protocol security implementation MUST have a security policy database to control resources.
		<list style="symbols"> 	
			<t>Rationale: Once a data source is authenticated, the security policy will determine what type and amount of resources that source can use, as well as possibly the forwarding priorities. It is anticipated that SCF systems will have different peering arrangements with different entities (e.g. peers, groups, or organizations).</t>
		</list>
		</t>
	

	<t>The SCF protocol MUST be able to separate the Shipping Label from the Shipping Container
		<list style="symbols"> 	
			<t>Rationale: The SCF agent must be able to determine whether or not it wishes to receive or store a container prior to receiving the entire container. This reduces denial-of-service vulnerabilities and enables efficient use of radio and system resources. </t>
		</list>
		</t>
	

	<t>The SCF protocol MUST have a mechanism that enables data to die naturally.
		<list style="symbols"> 	
			<t>Rationale: Data should die naturally to avoid routing loops at the SCF layer.  Routing loops at the SFC layer cannot be eliminated by lower-layer mechanisms (i.e. and IPv6 hop count will not correct an SCF routing loop).</t>
		</list>
		</t>
	

	<t>The SCF protocol MUST have a naming mechanism that specifies the application and instance to which the content is bound.
		<list style="symbols"> 	
			<t>Rationale: This naming mechanism is necessary in order for the SCF agent end system to pass the Shipping Container content to the proper instance of a given application since multiple instances may be invoked at any given time.</t>
		</list>
		</t>


	<t>The SCF protocol MUST have a Quality-of-Service (QOS) mechanism to expedite forwarding and to handle storage lifetimes.
		<list style="symbols"> 	
			<t>Rationale: Past experiences with other store-and-forward technologies such as DTN
 <xref target="RFC5050" /> have shown that it is very difficult for many applications to determine how long the useful life of data is. Rather, bundle lifetimes have been set either arbitrarily or rather coarsely (e.g. short, medium, forever) - see <eref target="http://www.dtnrg.org/wiki/DtnBone">Bundle Lifetimes</eref>. QOS will enable and SCF to expedite, store and purge data on a much more coarse scale than the use of absolute or relative time. Such QOS policies could be a configuration setting within individual SCF agents, or within an SCF network. This greatly simplifies the protocol processing as well as aggregation and deaggregation of containers.</t>
		</list>
		</t>

	<t>The SCF protocol MUST have a mechanism for a receiving system to acknowledge reception of a container from the sending system (i.e. hop-by-hop acknowledgements).
		<list style="symbols"> 	
			<t>Rationale: This allows a sending system to release the container if it so desires, thereby improving resource usage.</t>
		</list>
		</t>
		
	<t>The SCF protocol MUST have a mechanism to notify a sender that the container will not be processed.
		<list style="symbols"> 	
			<t>Rationale: If the agent's policy states “Do not accept" for any possible reason, it is important to inform the sender as soon as possible (ASAP) that the container will not be accepted, to allow the sender to stop transmission and determine a different route for that container. Note, there may be security reasons not to provide this information, but in generally such a response SHOULD be sent.</t>
		</list>
		</t>


	<t>The SCF protocol SHOULD have a mechanism that enables one to identify fresh versus stale content for a given flow.
		<list style="symbols"> 	
			<t>Rationale: Fresh data is often of far greater value than stale data.  The ability to identify fresh data and either replace the stale data with fresh, or send the fresh data first, is highly desirable in order to optimize resource usage - particularly storage and bandwidth.</t>
			<t>Comment: There appears to be a desire in many instances to proactively create fixed bundle sizes in DTN and then what the application to put them back in order.  With proactive fragmentation, this is possible and there is a mechanism to allow reordering.  With straight bundling, this is problematic as there is no such formalized standard sequencing (i.e. sequence numbers).</t>
		</list>
		</t>

 	</list>
	</t>
	</section>



	
    <section anchor="AgentReq" title="Agent Requirements and Expectations">

<t>
The following are a list of requirements for an SCF Agent. The requirements are in no particular order of precedence, but are numbered in order to aid in referencing for discussion.</t>

<t>
	<list style="format AGENT-REQ%d:" counter="my_count">
<!--	<list style="numbers"> --> 


	<t>An SCF agent MUST NOT be required to implement SCF security. Security must be optional.
		<list style="symbols"> 	
			<t>Rationale: Simple devices such as sensors may wish to utilize the SCF protocol, but have neither the need for security, nor the processing capability to implement SCF security.</t>
		</list>
		</t>
	

	<t>An SCF agent MAY implement reliability on the Shipping Container.
		<list style="symbols"> 	
			<t>Rationale: An application may or may not care if the contents of the container arrive without modification. For example, protecting a large image file from a bit flip may not be considered as important as reducing the processing overheard of creating and checking reliability on the Shipping Container.</t>
		</list>
		</t>


	<t>An SCF agent MUST hold onto a container until it can either be transferred or QOS policy indicates its useful lifetime has expired or storage resources reach a level that requires some purging of containers based on policy.
			<list style="symbols"> 	
			<t>Rationale: The sender expects the receiver to do its best to forward the container, and MAY release the container upon notification from the receiver that the container has been received. If the receiver does not plan to hold onto the container, it SHOULD send a notification to the sender stating such.</t>
		</list>
		</t>


	<t>An SCF agent MAY remove a container once it receives notification from the next hop SCF that the container has been delivered.
			<list style="symbols"> 	
			<t>Rationale: The ability to release containers enables efficient use of storage resources. Note, some deployments and some routing protocols MAY mandate that the agent retain a container even after a successful transfer. In such deployments, containers would likely be removed based on a retention policy which may be based on QOS.</t>
		</list>
		</t>

	<t>An SCF agent SHOULD NOT accept a container if it has no intention of giving a best effort to forward the container. 			
	   <list style="symbols"> 	
			<t>Rationale: The sending SCF's default expectation is that, if accepted, the receiving SCF will do its best to forward the container. This allows the sending SCF, if so desired, to purge the container from its storage with some confidence that the container will be delivered.</t>
		</list>
		</t>


	<t>An SCF agent SHOULD implement a policy system that controls resources. Such a policy system MAY include the filters described below.
		<list style="symbols"> 	

		<t>Rationale: Resources including bandwidth and storage storage are precious commodities that need to be controlled. Various SCF deployments are expected to have vastly different capabilities and needs. For example, an SCF science sensorweb may have not need for security, while implementing a policy that basically says "Accept Everything", because all containers are know a priori to be small and the deployment is a closed network. Other deployments may consist of high-end SCF agents supporting multiple organizations and transferring and storing Gigabytes or more of information. The ability to tune the policies to fit the deployment makes such deployments realizable.</t>
			</list>
			</t>
</list>
</t>


<t>
<list>

		  <t>
		  <list style="format (%c)">
			<t>What volume (size) container will be accepted.
				<list style="symbols"> 	
				<t>Rationale: Storage resources are not infinite. 
				It is likely policy will limit container size and/or 
				overall memory allocations per source, address range, or other filters. 
				In addition, some SCF agents may have limited processing and not be
				willing or capable of handling extremely large containers</t>
				</list>
				</t>

			<t>What sources are permitted to use resources and how much resource?
				<list style="symbols"> 	
				<t>Rationale: Resources including bandwidth and storage are precious. 
				It is anticipated that peering arrangements will exist to populate this database. 
				Not every source may be permitted to utilize the resources.</t>
				</list>
				</t>
			
			<t>What destinations are permitted to use resources and how much resource?
				<list style="symbols"> 
				<t>Rationale: Resources including bandwidth and storage are precious. 
				It is anticipated that peering arrangements will exist to populate this database. 
				Not every destination may be permitted to utilize the resources.</t>
				</list>
				</t>
				
			<t>Prioritized container delivery.
				<list style="symbols"> 	
				<t>Rationale: It is anticipated that peering arrangements will exist to populate this database. 
				Some peers are likely to be given preferential treatment, while others may be serviced only
				after all commitments have been met, regardless of QoS (e.g. the general's containers
				are processed before the private's; the organization who owns the SCF agent gets 
				preferential treatment over all other organizations.</t>
				</list>
				</t>
			<t>A mapping of QoS to retention lifetime and forwarding priority.
				<list style="symbols"> 	
				<t>Rationale: A coarse-grained retention policy is anticipated. Such granularity may be
				minutes, hours, days, forever (until resources become scarce and memory must be released). 
				This alleviates the need for actual lifetime settings within the SCF protocol 
				and allows various deployments to be uniquely configured.</t>
				</list>
				</t>
			</list>
			</t>   
</list>
</t>	


<t>
<list style="format AGENT-REQ%d:" counter="my_count">		
	
	<t>If security is implemented, when coming in contact with one another, adjacent SCF agents MUST minimally be able to identify one another securely and prove that they can be trusted as relays for a given destination application. 
		<list style="symbols">
		<t>Rationale: Such a mechanism is necessary to prevent hijacking of information. Also, aggregation and deaggregation may be implemented along a container's route. Trust between forwarding agents must be established to enable this.</t>
		</list>
        </t>

	<t>SCF Agents MUST be able to indicate (or deny) forwarding of individual containers, based on exchanging their shipping labels only.
		<list style="symbols">
		<t>Rationale: This allows for efficient use of RF resources as well as reducing DOS vulnerabilities. It the SCF Agent had to process an entire Container prior to denying acceptance, a malicious entity could easily perform a DOS attack by sending extremely large containers which would have to be stored and processed by the receiving SCF prior to rejection.</t>
		</list>
		</t>

	<t>SCF Agents MAY notify applications of pending received data.
		<list style="symbols">
		<t>Rationale: If the SCF agent knows it is bound to an application and can notify the application of pending received data, this could improve the application's operations.</t>
		</list>
		</t>
	
</list>
</t>			
</section>
		
	
		
    <section anchor="AppReq" title="Application Requirements and Expectations">	
	
	<t>
		<list style="format APPLICATION-REQ%d:">
<!--	<list style="numbers"> -->
	
		<t>Applications SHOULD be designed to operate in a disconnected systems. 	   
			<list style="symbols">
			<t>Rationale: Applications that have been designed assuming a connected network are likely to break.</t>
			<t>Rationale: Streaming may work, but should not be encouraged as streaming applications with reasonably significant volumes of traffic are likely to only work for connected systems or very short fades.  Such systems probably do not need SCF.</t> <!-- hmmm, streaming from sensorwebs? The LEO SSTL scenario? L. -->
			</list>
			</t>			

		
		<t>Applications MUST be able to select their own globally-unique identifiers and notify SCF agents of them, along with providing proof of ownership. 
		<!-- Should the MUST be a SHOULD? Does a MUST force a rewrite of applications. (But then, that might not be a bad thing. -->
        <!-- globally-unique implies connectivity to ensure this. L. -->
			<list style="symbols">
			<t> Rational: </t>
			</list>
	   </t>
	   		
		<t>Applications MUST be able to poll a SCF agent for pending received data.
			<list style="symbols">
				<t>Rationale: Applications are the only ones that can keep track of the shared state between sender and receiver. The Application cannot expect lower layers such as the SCF agent to fully understand its needs.</t>
				<t>Rationale: This eliminates putting undue burden on the SCF, and ensures interoperability to specify a known operational expectation.</t>
			</list>
		</t>
	
	</list>   
	</t>
	</section>

	
    <section anchor="sec-con" title="Security Considerations">
<t>
This document does not specify a protocol or implementation, only the requirements set.  The rationale
for individual requirements related to security includes discussion of the security considerations that
motivate them.
</t>


    </section>
	
	      
    <section title="IANA Considerations">
<t>
This document neither creates nor updates any registries or codepoints, so there are no IANA Considerations.
</t>
    </section>

    <section title="Acknowledgements">


<t>
Much work builds on lessons learned from the work performed by the IRTF DTN Research Group. 
</t>


<t>
Work on this document at NASA's Glenn Research Center was funded by the NASA
Glenn Research Center Innovation Funds. 
</t>
 
    </section>

</middle>


  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>
      <?rfc include="reference.RFC.0768" ?>
    </references>

    <references title="Informative References">
        <?rfc include="reference.RFC.4838" ?>
        <?rfc include="reference.RFC.5050" ?>
        <?rfc include="reference.I-D.ivancic-scf-testing-requirements" ?>
        <?rfc include="reference.I-D.ivancic-scf-problem-statement" ?>






			<reference anchor="Multi-Terminal">
        <front>
          <title>"Large File Transfers from Space using Multiple Ground Terminals and Delay-Tolerant Networking"</title>

          <author initials="W." surname="Ivancic">
            <organization></organization>
	  </author>

	  <author initials="P." surname="Paulsen">
            <organization></organization>
	  </author>
	  
           <author initials="D." surname="Stewart">
            <organization></organization>
	  </author>

          <author initials="J." surname="Taylor">
            <organization></organization>
	  </author>

	  <author initials="S." surname="Lynch">
            <organization></organization>
	  </author>
	  
           <author initials="J." surname="Heberle">
            <organization></organization>
	  </author>
 
          <author initials="J." surname="Northam">
            <organization></organization>
	  </author>
 			<author initials="C." surname="Jackson">
            <organization></organization>
	  </author>        
	  
		  <author initials="L." surname="Wood">
            <organization></organization>
	  </author>


          <date month="December" year="2010" />
        </front>

        <seriesInfo name="IEEE Global Telecommunications Conference (GLOBECOM 2010),"
                    value="" />
      </reference>
      <!-- above reference needs to be completed. L. -->


 
    </references>



  </back>
</rfc>
