Internet DRAFT - draft-ivancic-scf-problem-statement

draft-ivancic-scf-problem-statement







Network Working Group                                         W. Ivancic
Internet-Draft                                                  NASA GRC
Intended status: Experimental                                    W. Eddy
Expires: June 16, 2014                                       MTI Systems
                                                               A. Hylton
                                                             D. Iannicca
                                                                J. Ishac
                                                                NASA GRC
                                                       December 13, 2013


               Store, Carry and Forward Problem Statement
                 draft-ivancic-scf-problem-statement-01

Abstract

   This document provides a problem statement for non-realtime
   communication between systems that are generally disconnected, which
   require multiple network hops between source and destination, and
   which may never be fully connected end-to-end at any given time.
   This document describes a number of use cases that motivate having a
   standard method to communicate between such systems, as multi-
   organization and multi-vendor support and interoperability is highly
   desirable.  These use cases include dismounted soldiers, sensorwebs,
   medical devices, animal tracking, low-Earth-orbiting satellites and
   data mule scenarios.  To avoid confusion in terminology when trying
   to focus on the problem and requirements without bias towards
   particular technical solutions, at this time, we refer to the
   protocol instances that would support such communications as Store,
   Carry, and Forwarding (SCF) agents, and refer to their activity as
   SCF networking.  The concepts involved in SCF networking are not
   entirely new and several facets of the problem have been solved in
   multiple incompatible ways in existing or historic systems.  This
   document describes the core SCF problem and gives an assessment of
   the ability to use existing technologies as solutions.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any



Ivancic, et al.           Expires June 16, 2014                 [Page 1]

Internet-Draft                 SCF Problem                 December 2013


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 16, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction and Background . . . . . . . . . . . . . . . . .   4
   3.  Generic Architecture  . . . . . . . . . . . . . . . . . . . .   7
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   9
   5.  Use Cases and Deployment Scenarios  . . . . . . . . . . . . .  11
     5.1.  Data Mule . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.2.  Data Gathering  . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Traveling the Beaten Path . . . . . . . . . . . . . . . .  14
     5.4.  Rapid Disruption  . . . . . . . . . . . . . . . . . . . .  15
     5.5.  Dismounted Soldier  . . . . . . . . . . . . . . . . . . .  15
     5.6.  Low Earth Orbiting Sensor Satellite . . . . . . . . . . .  16
   6.  Consideration of Existing Technologies  . . . . . . . . . . .  18
   7.  Characteristics of Information  . . . . . . . . . . . . . . .  20
   8.  Network Management  . . . . . . . . . . . . . . . . . . . . .  21
   9.  Lessons Learned Summary . . . . . . . . . . . . . . . . . . .  22
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  24
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     13.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25



Ivancic, et al.           Expires June 16, 2014                 [Page 2]

Internet-Draft                 SCF Problem                 December 2013


1.  Terminology

   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 [RFC2119].

   "What's in a Word.  Words make a difference.  They affect how we
   think about something.  The terms chosen to describe a concept are a
   crucial part of any model.  The right concepts with terms that give
   the wrong connotation can make a problem much more difficult.  The
   right terms can make it much easier.  Adopting the mindset of the
   terms may allow you to see things you might not otherwise see." -
   John Day [Patterns]

   In developing this document, we have intentionally avoided some
   terminology used by other protocols - particularly other store-and-
   forward protocols - to avoid biases and confusion that may otherwise
   ensue.

   o  Container - the application/user data to be transported over the
      network as well as a checksum of that information.  Containers may
      include sub-containers, or be sub-containers themselves.

   o  Container Aggregation - The process of organizing one or multiple
      containers as sub-containers inside another larger container.

   o  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.

   o  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.

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

   o  Delay - propagation delay between SCF agents.  Delay does not
      include disconnection time.

   o  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.




Ivancic, et al.           Expires June 16, 2014                 [Page 3]

Internet-Draft                 SCF Problem                 December 2013


   o  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.

   o  Metadata - synonymous with a Container's Shipping Label

   o  SCF - Store, Carry and Forward

   o  SF - Store-and-Forward, or "store and forward" as used generically
      in other literature (where the presence of hyphenation varies)

   o  SCF Agent - a protocol instance providing SCF services to an
      upper-layer user/application

   o  Shipping Label - metadata describing the characteristics of a
      container and its forwarding requirements

   o  Sub-Container - A smaller container residing inside a larger
      container.

   o  Transport Capacity - (as a first order approximation) the product
      of link capacity and contact time.

2.  Introduction and Background

   Internet technology has become pervasive and is now present in many
   types of devices that end up being deployed in the field for use in
   scenarios where they do not have good (or any) actual Internet
   connectivity.  The networking stacks are used to support data
   transfer during episodes of connectivity, and the applications and
   protocol configurations avoid reliance on many typical infrastructure
   services (e.g. DNS).  For instance, these devices may be only
   intermittently connected to other devices, and are used to support
   data flows where the source and ultimate destination might never be
   fully connected to one another at any time.  These applications
   operate highly asynchronously, with non-realtime constraints on their
   communication.  Often, there are intermediate relaying nodes (or
   "agents") that must "carry" the data while waiting for connectivity
   to develop.  The means for relaying data has been highly specialized
   in such systems (almost per-deployment), and varies widely, with
   little code-reuse or commonality in the supporting network design.
   This "problem statement" document describes several of these
   scenarios generically, motivates the development of a common
   solution, and describes shortcomings in existing technologies.

   This problem statement is explicitly not trying to look at the
   situation where a smart phone or mobile computer is temporarily off
   or removed from the Internet, and then is reattached directly to the



Ivancic, et al.           Expires June 16, 2014                 [Page 4]

Internet-Draft                 SCF Problem                 December 2013


   edge of a well-connected network.  Such systems are well-suited to
   utilize standard Internet protocols and are able to support realtime
   communications when connected.  The systems and applications that
   this document is concerned with are primarily operating with a much
   higher level of asynchrony between the data producers, individual
   relays, and eventual data consumers.  We call these "Store, Carry,
   and Forward" (SCF) systems to distinguish them from typical Store-
   and-Forward (SF) systems, which generally operate over a better-
   connected infrastructure.  This section clarifies the distinction
   between SCF and the better-understood SF concept, which is already
   implemented by a number of different networking technologies.

   Because so many analogies exist between SF/SCF-based computer
   communications and offline non-computer-based systems, it is useful
   to understand (very) early communications.  Relay systems have been
   present even in ancient civilizations, where rulers utilized
   intelligence gathering via courier services to convey and obtain
   information.  Relays consisted of runners, messengers, and even
   pigeons conveying messages and documents.  These types of relay
   agents had only intermittent connectivity with one another and needed
   to hold onto messages for possibly long amounts of time before
   delivering them.  Later relay systems included the ancient Greeks
   using fires, mirrors, or colored flags for visually communicating
   over large distances, and the the 18th century French using a system
   of telescopes and semaphores.  These involved relatively well-
   connected systems of relay infrastructure, compared to the earlier
   methods that involved physical carriage of the stored messages for
   some time in order to reach the next forwarding point.  Telegraph and
   later systems had equally well-connected infrastructures.

   In computer networking, numerous technologies that support SF message
   communications between systems have evolved, and some have
   incorporated pieces of what SCF systems require.  We very roughly
   group these developments into "generations" in order to highlight a
   general progression of capabilities.  This is not prescriptive, and
   though some detailed aspects of the classification may be debatable,
   the basic notions hold.

   1st-generation Store and Forward systems consisted of Message
   switching, with buffering of messages at intermediate nodes in order
   to handle intermittent connectivity.  There was little or no
   automation, intelligence, or capabilities for forming routing tables,
   security, network management, and handling anything but rather slow-
   scale dynamics.  Examples include UUCP [1], FidoNet [2].  "In FidoNet
   As all modem phone numbers are published in the nodelist, point-to-
   point transfers are always possible.  But, as store-and-forward
   capabilities are specified in the basic standards, email tends to be
   routed through a world-wide hierarchic topology and enews via a



Ivancic, et al.           Expires June 16, 2014                 [Page 5]

Internet-Draft                 SCF Problem                 December 2013


   world-wide ad hoc, but generally geographically hierarchic, acyclic
   graph."

   2nd-generation SF consist of Internet email via SMTP [3] + POP [4] /
   IMAP [5] + S/MIME [6] and so on.  Key features include separation of
   message transfer agents, user agents, and message submission/delivery
   agents.  There are increased capabilities for security and
   management.  There is some (weak) separation between message format
   and message transfer protocols.  Email servers generally operate
   within a well-connected environment.  There are major performance
   problems outside this well-connected environment, because there is
   little diversity in message transport between nodes, and little or no
   improvement in dealing with dynamics.

   3rd-generation SF protocols are an advance over 2nd-generation
   concepts.  These are used to implement messaging middleware and are
   applied as the basis of enterprise service bus systems.  There is an
   increased separation between message format and message transfer
   protocols with increased message transform / mediation capability.
   There has been a proliferation of proprietary formats, APIs and
   systems, with great diversity in capabilities.  Generally, there are
   still problems operating outside a well-connected environment, and
   the security mechanisms are not advanced beyond 2nd-generation ones.
   Examples include: JMS/OpenWire [7], AMQP [8], STOMP [9], XMPP [10],
   and MQTT [11].

   4th-generation SF protocols are directed at systems with long delays
   and intermittent connectivity and are known as Delay Tolerant
   Networking (DTN) [RFC4838], [RFC5050].  There is very strong
   separation between format and transfer protocol as well as strong
   separation between format and addressing/routing.  Architecturally,
   there are many alternatives available for transfer, addressing, and
   routing with heavy tailoring per each pocket of deployment.  Security
   is possible for implementation in a limited subset of intended use
   cases.  There are a number of experimental implementations including
   Interplanetary Overlay Network (ION), DTN2 and others including
   substantial profiles of features and capabilities.  DTNRG [12].

   5th-generation (conceptual) systems include significant amounts of
   longer-term storage that can be "carried" between episodes of
   connectivity as a main component (i.e. Store, Carry and Forward)
   There is an increased separation of message metadata (i.e. shipping
   labels) from message bodies (i.e. containers) beyond the 4th
   generation, enabling new approaches to security, forwarding, and
   possibilities for pull-based routing.  Emphasis is on the "carry"
   function and need for strong automation in management of stored data,
   including support for implementing policy in QoS, security, and
   routing.  5th-generation systems that embody the SCF concept have not



Ivancic, et al.           Expires June 16, 2014                 [Page 6]

Internet-Draft                 SCF Problem                 December 2013


   yet been widely deployed.  The fielded applications that could
   benefit from such SCF capabilities are either using point solutions
   adapted from prior generations of SF technology, or are lacking the
   strength in automation, security, and other features that the SCF
   technology should provide.  Later sections of this document describe
   a generic network architecture expected to be supported by SCF / 5th-
   generation systems, the envisioned scenarios and use cases for these
   systems, more detailed comparison/contrast with existing / prior-
   generation systems, and a summary of lessons learned from experience
   with earlier systems.

3.  Generic Architecture

   Figure 1 illustrates a generic SCF network architecture, with the SCF
   agents (labelled "SCF") frequently partitioned into time-varying
   disconnected subsets.  Depending on specifics of an individual
   scenario, it may be likely that some SCF agents are permanently
   attached to a connected network in order to provide stable gateways
   to/from the other SCF agents.  However, in general, the system should
   be considered to consist of a number of primarily disconnected SCF
   agents at any point in time.  The importance of this consideration as
   it relates to design, implementation, and test of potential SCF
   protocols is emphasized later in this document, as its effects have
   plagued prior SF systems.



























Ivancic, et al.           Expires June 16, 2014                 [Page 7]

Internet-Draft                 SCF Problem                 December 2013


                            _,.--SCF -.
                       SCF '      /    `-SCF
                                 .'       /   DISCONNECTED
                                 /       /      NETWORK
                                .'     SCF_
                               SCF     /   `-..
                                 `.   .'       SCF
                                   `. |
                                   ,SCF.
                                  /     \
                                 /       \
                                /         \
                               ; CONNECTED :
                               |  NETWORK  |
                               :           ;
                                \         /
                                 \       /
                                  \     /
                                   ,SCF`.
                        SCF----''''  |   `-.
                        |            \      `.SCF
                        /             |      .-'
                       /              SCF_.-'
                      SCF            .'
                        `.         .'        DISCONNECTED
                          `-.    .'            NETWORKS
                             SCF

                     Store, Carry and Forward Network

                                 Figure 1

   When visualizing an SCF network, it may help to think more along the
   lines of a topologically dynamically-changing (mobile) relay system
   of agents that can periodically communicate with one another, and may
   be able to make at least rough predictions about their future
   contacts.  The distribution of news and mail in the mid-1800s as
   described in Herman Melville's book, "Moby Dick," is a good analogy.

   "For the long absent ship, the outward-bounder, perhaps, has letters
   on board; at any rate, she will be sure to let her have some papers
   of a date a year or two later than the last one on her blurred and
   thumb-worn files.  And in return for that courtesy, the outward-bound
   ship would receive the latest whaling intelligence from the cruising-
   ground to which she may be destined, a thing of the utmost importance
   to her.  And in degree, all this will hold true concerning whaling
   vessels crossing each other's track on the cruising-ground itself,
   even though they are equally long absent from home.  For one of them



Ivancic, et al.           Expires June 16, 2014                 [Page 8]

Internet-Draft                 SCF Problem                 December 2013


   may have received a transfer of letters from some third, and now far
   remote vessel; and some of those letters may be for the people of the
   ship she now meets.....

   ...Every whale-ship takes out a goodly number of letters for various
   ships, whose delivery to the persons to whom they may be addressed,
   depends upon the mere chance of encountering them in the four oceans.
   Thus, most letters never reach their mark; and many are only received
   after attaining an age of two or three years or more."

   Another analogy that illustrates aggregation and deaggregation are
   the parcel post delivery companies.  Here, individual packages
   (containers) are delivered from a source to destinations via numerous
   transport mechanisms, e.g. trucks, planes, trains and boats.  Along
   the way, these packages are aggregated into larger and larger
   shipping containers as they move further from the source, and then
   and deaggregated into smaller and smaller containers as they move
   closer to the destination.  Such aggregation and deaggregation enable
   scaling of the system.  There is a strong parallel between this flow
   of packages and the data flows seen in some of the scenarios
   described later in this document.

4.  Operational Considerations

   Some of the key operational considerations for SCF are:

   o  What types of applications might be suitable to utilize SCF
      networking?

      *  Engineering Telemetry - Accumulated over time for offline
         monitoring and analysis of some device or system's performance,
         which may be related to long-term administration of the device,
         but occurs in non-realtime and at a remote location.  Fidelity
         of the received data is important, though partial delivery of
         data may be acceptable and more desirable than slower delivery
         of complete and fully accurate data.  It is expected that a
         telemetry-sending application may operate in a fire-and-forget
         mode, where it does not retain data after sending.

      *  Science Data Gathering - Similar to engineering telemetry, but
         sensor data is collected at a potentially much larger volume or
         over a much longer timescale.  Accuracy of the delivered data
         is critical, and timeliness in routing may be sacrificed to
         provide a complete and error-free data set.  Due to the size of
         data sets collected, having multiple copies in-flight within
         the network may be undesirable, and end-nodes may need to purge
         old data after it has been sent in order to gather new data.




Ivancic, et al.           Expires June 16, 2014                 [Page 9]

Internet-Draft                 SCF Problem                 December 2013


      *  Software Update - Numerous deployed devices that may never be
         able to contact an update server in realtime may need to have
         patches or updates deployed and activated.  This can require
         high reliability and guarantee of eventual delivery of the
         data, even if the latency involved in applying the update is
         not extremely critical.  The sender is likely to retain access
         to the sent update/patch perpetually, even after copies have
         been distributed into the network.  While some acknowledgement
         of reception end-to-end may be desirable, this might be
         inferred through other means at the application level (e.g. via
         telemetry) rather than requiring SCF-level acknowledgement.

   o  In general, any distributed application where senders and
      receivers can operate asynchronously in non-realtime, without any
      real-time requirement on the infrastructure (e.g. to do resolution
      of DNS names) might be able to function over an SCF service.

   o  What are the potential deployment environments and platform
      capabilities?

      *  Some relevant use cases are discussed in detail in the
         following section.  In general, the SCF agents may be either
         co-located or independent of the hardware/software platforms
         that host the end-applications.  Aside from having a non-
         trivial amount of persistent storage, very few assumptions can
         be made about the SCF agent computing platforms.  Typically,
         they will have to be embedded systems, e.g. within a device
         that's part of some other portable electronic system (e.g.
         handheld device, medical implant, avionics hardware, etc.)
         rather than typical workstations and servers.  This means that
         links are expected to be (much) less capable and more time-
         varying than wired Ethernet, and frequent administrative access
         is not likely to be possible.

   o  What are the upper-layer user/application data-set sizes?

      *  From existing systems in-use that could benefit from SCF, at
         least several GB of data collected onto an SCF agent between
         contacts with other SCF agents is possible.  There are also
         applications where only several kilobytes of container are
         necessary.

   o  What are the traffic patterns?

      *  In envisioned SCF scenarios, movement is not fully random, even
         for mobile ad-hoc networks, though at the very edges, it may
         appear random.




Ivancic, et al.           Expires June 16, 2014                [Page 10]

Internet-Draft                 SCF Problem                 December 2013


      *  In envisioned SCF scenarios, information flow is not fully
         random, even for mobile ad-hoc networks.

   o  What type of interface between SCF agents and end applications is
      feasible?

      *  Applications should be able to select their own globally-unique
         identifiers and notify SCF agents of them, along with providing
         proof of ownership.  SCF agents may be able to notify
         applications of pending received data, but applications are
         always able to poll a SCF agent for such data as well.

   o  What interaction between SCF agents is expected?

      *  When in contact with one another, SCF agents minimally need to
         be able to identify one another securely and prove that they
         can be trusted as relays for a given destination application.
         Agents should be able to indicate (or deny) forwarding of
         individual containers, based on exchanging their labels only.

5.  Use Cases and Deployment Scenarios

   There are numerous deployment scenarios for SCF systems.  The
   following section highlights a few more common scenarios.

5.1.  Data Mule

   The Data Mule scenario is a common generic scenario and shows up in
   many deployments.  In the Data Mule scenario, SCF agents communicate
   with each other mainly via some type of circulating entity carrying
   data, called the "mule".  This entity may be an unmanned (or manned)
   aircraft, a ship, a bus, or any type of vehicle that periodically
   moves over the same relative area.  Connectivity is likely to consist
   of high periods of disruption followed by short periods of
   connectivity over relatively high-bandwidth, low-delay, and possibly
   symmetric, links.

   In the Data Mule scenario, connectivity is generally of the episodic
   variety (opportunistic).  There may be one or a larger number of
   mules; each of which runs its own SCF agent.











Ivancic, et al.           Expires June 16, 2014                [Page 11]

Internet-Draft                 SCF Problem                 December 2013


      .-------.
      | SCF   |                                .-------.
      |Agent 1|                                | SCF   |   .--o
      `-------'  /''\.                         |Agent 5|  /    `.
            `.  .'   '._    .-----.,--.        `-------' /      |
              \ |       `.._|Data |    ``.          \   /       `.
               /            |Mule |       `-.        \  '        |_
               |            `-----'          `.       ,/           |
              |            Movement            \.,.---             |
              '           <<=======                                |
             /                                                      |
            /                                                       |
            |                     Path Well     .-------.           |
            |                     Traveled      | SCF   |           |
           |                                    |Agent 3|           |
           /                              ...._ `-------'            \
          |                              |     `.   /                 `\
           \ _..                         |       `./                  .'
           `'   `---`...                 `.._       `-.              ,'
         .-------.  _,  ".                   ``.       \         _,,'
         | SCF   |,'      `.                    \       `--...,-'.
         |Agent 2|          `.                   `.              |
         `-------'            `. _                 \       .-------.
                                ' `'-...._          |      | SCF   |
                                          `"--------'      |Agent 4|
                                                           `-------'


                            Data Mule Scenario

                                 Figure 2

   Within this type of Data Mule scenario, the generic use case for SCF
   networking involves an application being able to push its data into
   containers on a SCF agent, who then interacts with the Data Mule SCF
   agents in order to deliver the containers to destination applications
   attaching to other SCF agents.  In order to realize this use case,
   the SCF agents need to be identifiable to one another during periods
   of episodic connectivity, and the mule needs to somehow be able to
   express its expected future capability to relay containers towards
   the destination application.










Ivancic, et al.           Expires June 16, 2014                [Page 12]

Internet-Draft                 SCF Problem                 December 2013


   The Data Mule is a common military scenario.  It is often used to
   join partitioned connected networks such as groups of mobile ad-hoc
   networks (manets).  In Figure 2, the SCF Agents could be concentrator
   points in a manet cluster that enables communication between disjoint
   manets on the battlefield, thus enabling communications between
   clusters on the far ends of the communication infrastructure, the
   edge networks.

5.2.  Data Gathering

   The generic Data Gathering scenario is also quite common and
   applicable to SCF networks.  Specific use cases involving sensorwebs,
   medical monitoring and animal tracking would fit into this scenario.
   Figure 3 illustrates a sensorweb where some sensors wake up and
   forward data through other SCF agents until they reach an SCF
   connected to a more powerful radio system.  A gathering agent may
   then come by from time to time (e.g. days, weeks, months) and collect
   the data.




                                           GATHERING AGENT

                                                //
                                  /____        /X//  _
                                  \          (\ //-'//
                                             / \)---'
                                            /X//




                 ))'((                ))'((             ))'((
                   |                    |                 |
                  SCF                  SCF               SCF
              _,-' | `..              /   \           _,' | '-.
            ,'     |    `-.         ,'     `        ,'    |    `._
          SCF     SCF     SCF     SCF      SCF    SCF    SCF    SCF
         /   \                                          /   \
       ,'     `                                       ,'     `
     SCF      SCF                DATA SOURCES       SCF      SCF


                          Data Gathering Scenario

                                 Figure 3




Ivancic, et al.           Expires June 16, 2014                [Page 13]

Internet-Draft                 SCF Problem                 December 2013


   Major challenges of the use cases in a Data Gathering scenario, which
   go beyond those of a Data Mule, are related to the increased level of
   complexity in the topology between SCF agents.  There is potentially
   less predictability, potentially more heterogeneity (or hierarchy) in
   SCF agent capabilities, and potentially a higher risk of routing
   loops or wasted resources.

   The use cases for Data Gathering do, however, involve data flows that
   are generally either all directed from sensors up through the
   Gathering Agents or down from the Gathering Agents, so these still
   represent a sort of core network that all containers eventually go
   through (similar to the Data Mules).

5.3.  Traveling the Beaten Path

   There are many instances where communications may occur between
   entities traveling a well-worn path.  In this scenario, communication
   is more ad-hoc than the data-mule example.  The probability of
   encountering other SCF agents is quite high.  Such scenarios include:
   communication in mining operations, among hikers, among boats along
   well traveled waterways, within the fisheries industry (the Moby Dick
   example) and along trade routes.

   Figure 4 illustrates Traveling the Beaten Path.  Consider a nomadic
   trade route in a third-world country.  Here, SCF-1 may travel from
   the one end of the path to the other in one direction, while SCF-5
   moves in the other direction.  SCF-1 and SCF-5 will encounter all
   other SCFs along the way.  SCFs 2, 3 and 4 only move along portions
   of this trade route.  Most likely, none of this information is known
   in advance, and the movements may or may not be predictably
   repeatable.




















Ivancic, et al.           Expires June 16, 2014                [Page 14]

Internet-Draft                 SCF Problem                 December 2013


                                PATH
      ==-._                                _,,---.=-..__
     '`-`''`;--=...__           _....,,...'-''     `''`.\      ___
                  `''':::.._,,,-'-''                     `---.:,-'''
                         '`'''

      --------- SCF-1 -------------------------------------------->

                  <---- SCF-2 --->

                        <----- SCF-3 ------>

                     <--------------------------- SCF-4 --->

      <----------------------------------------------- SCF-5 -----


                         Traveling the Beaten Path

                                 Figure 4

5.4.  Rapid Disruption

   Many wireless networks (particularly military ones), when connected,
   may be relatively well-connected to a large number of other nodes in
   near real-time.  However, individual nodes or subsets of the network
   may be only episodically connected because of variable link
   conditions given terrain, foliage, weather, jamming, or desire to
   evade detection.  Furthermore, even when basically connected,
   temporary radio signal power fades can cause rapid, short, periods of
   disconnection.  All of these lower-layer hindrances may result in
   short periods of disruption witnessed by applications, as well as
   rapid changes in network topology and the set of reachable relays.

   SCF provides some potential solutions for such networks.  SCF routing
   may be capable of moving containers towards destinations via store-
   and-forward if the proper naming structures, addressing and routing
   algorithms can be developed.

5.5.  Dismounted Soldier

   On the battlefield, it often occurs that a group of soldiers is on a
   mission and arrives via a vehicle or group of vehicles, one of which
   may have very good connectivity to larger networks.  Once dismounted,
   much of the communications may be via use of that vehicle
   communication system as a relay or anchor.  Once the group moves a
   significant distance from this anchor and from one other, they may
   become disconnected for periods of time.  At this point, SCF becomes



Ivancic, et al.           Expires June 16, 2014                [Page 15]

Internet-Draft                 SCF Problem                 December 2013


   necessary to improve communications and maintain situational
   awareness.  SCF provides this communication in two ways.  Near-
   synchronous communications might be maintained via multi-hops through
   other SCF agents, or in the worst case, asynchronous communications
   can be served sporadically when within radio contact of the anchor
   relay on the vehicle.

   This scenario is also applicable to first responders during disaster
   situations where infrastructure may be severely damaged.

5.6.  Low Earth Orbiting Sensor Satellite

   The Low Earth Orbit (LEO) scenario described is for a sensor
   satellite communicating directly with ground terminals.  One such
   network is described in reference [UK-DMC].  Note, in this scenario,
   no geostationary relay satellite is involved.  Here, the contact
   times may be known in order to direct the satellite transmitter to
   turn on.  Some type of automated hailing could also be used.

































Ivancic, et al.           Expires June 16, 2014                [Page 16]

Internet-Draft                 SCF Problem                 December 2013


                                 LEO
                                Sensor
                               Satellite
                         +-------+ _ +-------+
                         |       |:_:|       |
                         +-------+   +-------+
                               ,'      `.
             Space/Ground    ,'          `-.    Space/Ground
               Link 1     ,-'               `.    Link 2
                        ,'                    `._
                      ,'                         `.
                    ,'  Connect            Connect `._
                 _,'      T1                 T2       `.
             .  '                                       `   /
     Ground  `.                                         ..,'  Ground
    Station  /\''    ___...------'''''''------....__      /\ Station
       1    /__\.,--'                               `'--./__\   2
         _,,-' ._                                     _,    `--.._
        '        `.  Ground/Ground    Ground/Ground ,'            '
                   `-.  Link 1           Link 2  ,-'
                      `._                     ,-'
                         `.                _,'
                           ' .-----------.
                             |   Data    |
                             |Collection |
                             |  Center   |
                             `-----------'


                     Low Earth Orbit Sensor Satellite

                                 Figure 5

   Low Earth Orbit (LEO) is a low-propagation-delay environment of less
   than ten milliseconds delay to ground, with long periods of
   disconnection between passes over ground stations.  Contact times
   consist of a few minutes per ground station for Earth satellites
   orbiting at a couple hundred kilometers altitude (~100 minutes per
   orbit).  Thus, the more ground systems that are available, the
   greater the potential for contact.  The ground stations are connected
   across the terrestrial Internet, or other backbones.

   In this scenario, the SCF agent onboard the satellite does not need
   to perform forwarding of received containers.  The satellite is a
   source for sensor data and may be a sink for command data.






Ivancic, et al.           Expires June 16, 2014                [Page 17]

Internet-Draft                 SCF Problem                 December 2013


   The main reason to use SCF in this scenario is to provide a
   standardized relaying technique and to decouple the control loops
   between the space/ground link and the ground/ground link.

   There are numerous companies and systems today that transfer
   extremely large sensor data sets from LEO to ground without a
   standardized SCF method.  Those data sets are in the multi-gigabyte
   region and growing.  However, they are using protocols and
   implementations that are not compatible with one another, and which
   require them to go through various levels of customization per-use.

6.  Consideration of Existing Technologies

   In this document, we characterized DTN-based systems as 4th-
   generation SF rather than SCF systems.  Several aspects of DTN are
   highly desirable for SCF though, and DTN technology may represent a
   basis for developing SCF standards.  DTN utilizes "bundle agents"
   that are similar to the "SCF agent".  Several DTN routing protocols,
   that exist at varying levels of maturity, can work well for
   individual SCF scenarios that have been outlined.  For instance,
   Contact Graph Routing is particularly useful in scenarios where
   future connectivity is predictable/known ahead of time.

   The SCF container aggregation and deaggregation bears some surface
   similarity to bundle fragmentation operations in DTN, but there are
   major differences.  SCF containers are intended to be aggregatable
   within the network, even if they are not portions of the same
   original container from the application.  Additionally, some SCF
   applications (e.g. science data collection) may find (optional)
   partial reception of subsets of large containers that have been
   deaggregated into smaller containers, to still be useful, whereas DTN
   only delivers entire (reassembled) bundles.  This does require the
   data formats used by such SCF applications to be self-synchronizing,
   so that they can be parsed, but this is an issue for the application.

   SCF scenarios require some features that are not yet a part of the
   DTN specifications:

      The ability to avoid DoS by propagating an application's permit/
      deny filters to SCF agents.

      The ability to generate and prove ownership of globally-unique
      application identifiers.

   DTN goes beyond SCF in one way, which is the targeting of operation
   over very high-latency data links.  SCF does not explicitly attempt
   to operate over such links, though it may end up being possible.
   Since these links are mostly only applicable to deep-space scenarios



Ivancic, et al.           Expires June 16, 2014                [Page 18]

Internet-Draft                 SCF Problem                 December 2013


   with small numbers of nodes, SCF motivations do not include high-
   delay.

   This document also identified JMS and MQ Telemetry Transport message-
   broker systems as 3rd-generation SF rather than SCF systems.  JMS
   "messages" transferred between "brokers" and applications are similar
   to the containers transferred between SCF agents and applications.
   JMS offers both point-to-point (unicast) and publish-subscribe
   (multicast) models of communication.  JMS uses named "queues" (in the
   point-to-point model) or "topics" (in the publish-subscribe model) in
   order to identify destinations.  JMS brokers often implement a
   "durable" messaging service that allows messages (and queues) to
   persist even when the applications that created them (or need to
   receive them) are disconnected from the broker.

   SCF scenarios require some features that are not yet really reflected
   within the JMS specifications:

      Multi-hop relaying among brokers and secure propagation of
      information about the queues/topics present or acceptable is not
      standardized.

      Communication of an application's desired permit/deny filters on
      queues that it owns is not standardized.

   JMS is an API and not a protocol standard.  This is the primary
   hurdle in using JMS to support SCF, as the wire-protocols and other
   mechanisms used in a particular JMS implementation are not
   necessarily compatible with others.  SCF requires full vendor/
   platform interoperability in order to be cost-effective to pursue in
   preference to point-solutions.  JMS is also significantly focused on
   transfer of Java objects rather than generic containers of bytes as
   SCF should be.

   One of the biggest challenges to using existing systems (whether they
   be DTN implementations, JMS products, or some others) is that most
   have been designed to include a multitude of additional (optional)
   features and this results in, at best, limited compatibility between
   implementations.  For instance, the DTN Bundle Protocol is an
   excellent platform for experimentation due to its flexibility and
   ease of defining new "blocks" to implement different functionalities.
   DTN has been used or demonstrated in a wide range of scenarios with
   differing needs, including simulated military exercises, connecting
   people in remote regions, moving data from LEO spacecraft, deep-space
   missions, mining operations, and others.  However, individual
   implementations have grown up to support distinct subsets of the
   defined blocks, identifier schemes, and algorithms that suit the
   unique properties of their pet environments.  Developing, and then



Ivancic, et al.           Expires June 16, 2014                [Page 19]

Internet-Draft                 SCF Problem                 December 2013


   maintaining, a baseline for compatibility has not been a primary
   concern.  For an operational system, a baseline profile of the
   required functionality would need to exist, which could be present
   across the spectrum of vendors.  For SCF, this type of profile is not
   present in the existing systems to a level that would enable the
   scenarios described in this document.  Saving energy and running on
   very small devices (e.g. sensors and embedded medical devices) also
   motivates having such a profile that could aid in developing very
   small, yet fully compatible, implementations.

   MQ Telemetry Transport is a lightweight protocol used for publish/
   subscribe messaging between devices.  MQTT was designed for low-
   bandwidth, high latency networks while attempting to ensure
   reliability of delivery.  A major design criteria was simplicity -
   must be simple to implement and must not add too many "bells and
   whistles" that would complicate implementation, while still providing
   a solid building block which can easily be integrated into other
   solutions.  MQTT is designed to handle frequent short periods of
   network disruption using a technique called "Last Will and
   Testament".  Although not part of the specification, MQTT has been
   modified to operate in multi-hop environments.

7.  Characteristics of Information

   Since information has to be transported and stored in an ACF use
   case, it is important to be aware of the key characteristics of the
   information being acted upon.  All information has a source and one
   or more eventual destinations.  All application information ready to
   be sent, has a size that may be very small or quite large (several
   bytes to multiple gigabytes).  Size is important because storage is
   not unlimited in either the source application's system nor in the
   relays, and because transmission bandwidth and contact times limit
   the amount of data that can be sent during any given contact time.

   Information may have security restrictions placed on it - sensitive
   or restricted (for your eyes only), and in some cases this may be
   handled at the application layer, as is done by securing email.

   All information has a useful lifetime.  It may be very short
   (seconds) or very long (days, weeks, years).  Regardless, it is only
   the users of the information that know what the real useful lifetime
   is, and it is the application that would be required to set that
   lifetime.  With the exception of specific cases, it is not at all
   clear that the application can generally make that decision.

   When investigating the use of DTN bundle lifetimes in DTN deployments
   and implementations, we have found that the lifetimes have generally
   been set to match the duration of the experiment.  There are



Ivancic, et al.           Expires June 16, 2014                [Page 20]

Internet-Draft                 SCF Problem                 December 2013


   instances where some finer granularity has been deployed such and in
   the Defense Advanced Research Project Agency's (DARPA) Wireless
   Network after Next (WNaN) where a small number of choices in
   lifetimes of minutes or hours are used depending on the nature of the
   data.  The DTN bundle lifetime can be used for two purposes:
   expedited forwarding for end-applications and purging stale
   information from the relays.  Thus, the real requirement we see for
   SCF should be the ability to expedite forwarding of priority
   containers and purge stale containers from the system, but not
   necessarily to specify time-sensitivity on a per-second basis.  There
   may be other means to accommodate this requirement without having to
   burden the SCF agents with the management and synchronization of
   notions of "time" - particularly per container - which has been
   burdensome in DTN use.

   Often data has a "freshness" characteristic.  For a given
   application, data that is more recent (fresher) is often of greater
   value that data that is older (stale).  In such cases, it may be more
   important to forward the most recent data, rather that the data that
   is near the end of its useful lifetime.  One might even purge the
   system of stale data.  One trival example that illustrates why data
   freshness is important would be reception of stock quotes.
   Obviously, one would not expect an SCF systems to be used for
   commodities trading due to disruption and ordering issues (assured
   timeliness).  Rather, applications such as sensor data transmissions,
   software updates or distributed security-key databases are more
   amenable to SCF deployments.

8.  Network Management

   Network management is needed to keep the network running smoothly.
   It is required for system configuration and maintenance, and monitors
   the system to determine faults, performance, security issues and
   accounting.  From the scenarios presented, it appears that network
   management is likely to be per-scenario, and may be effectively
   accomplished out-of-band.  For example: in the Data Mule scenario,
   one may manage the data mule, but not the edge SCF systems.  In the
   Data Gathering scenario, one is likely to preconfigure the remote
   sensor nodes and only manage the data-gathering SCF and perhaps the
   data concentrator SCFs, the ones with high-power radios.

   This does not imply the network management could not or should not be
   performed in-band; only that it may not be required.

   Since resources (e.g. bandwidth, transmit power, and storage) are a
   precious commodity in SCF networks, policy that manages those
   resources is expected to be a major component of system
   configuration.  For example: a particular SCF agent may restrict



Ivancic, et al.           Expires June 16, 2014                [Page 21]

Internet-Draft                 SCF Problem                 December 2013


   particular information sources to limited storage space and limited
   storage time.  Such policy may restrict all information to a limited
   storage time in order to purge stale containers.  Also, particular
   sources may get preferential treatment per peering agreements.

9.  Lessons Learned Summary

   There are numerous lessons to be learned from previous deployments of
   manets and 4th-generation store and forward networks such as DTNs.
   Some of the more critical and important pieces of knowledge are
   listed below:

   o  SCF systems are generally connected via radio networks.  Some
      radio systems may take far less power to listen than to transmit,
      though this varies by individual link technology.  Wasted
      transmission is wasted power on a wireless system and can quickly
      drain a battery.  The problem is compounded for devices whose
      entire lifetime is determined by their battery (e.g. non-
      rechargeable sensor nodes).  Thus, reducing wasted transmissions
      is high desirable.

      *  The ability to reactively fragment large data sets en-route is
         highly desirable.  This has been demonstrated in DTN
         experiments.

      *  Routing loops in the SCF will not be caught by layers below.
         It is imperative that data dies naturally and quickly so as to
         not waste bandwidth or transmission power.  Such loops have
         been encountered in early experiments with DTN overlays, and
         are correctable.

      *  It is highly desirable for the sender to know early in a
         transmission whether or not the receiver will accept the data.
         This permits a savings in power and optimization of network
         capacity usage.  For instance, in DTN experiments with large
         bundles, the entire large bundle may be sent, only to be
         discarded due to security, resource scarcity, or other issues.

   o  Disconnected networks are difficult, if not impossible, to
      globally synchronize state across.

   o  Managing fine-grained notions of time in a protocol is difficult
      and adds considerable complexity.

   o  Having a relay protocol be time-dependent opens is up to security
      vulnerabilities.





Ivancic, et al.           Expires June 16, 2014                [Page 22]

Internet-Draft                 SCF Problem                 December 2013


   o  Having a relay protocol be time-dependent complicates use of that
      protocol to synchronize the system - even for coarse
      synchronization.

   o  It is highly desirable for a receiving agent to determine early
      within a transfer whether or not to accept the data.  Large data
      sets utilize significant processing and storage resources for data
      that may end up being discarded due to security, resource
      constraints, or other policy issues.

   o  It is highly desirable to keep forwarding tables small, and make
      forwarding decisions ahead of time for predicted contacts.  Book-
      keeping type of processing while forwarding a large number of
      small containers can overload the processing system.

   o  Testing should be thorough and include exercising both the storage
      and forwarding systems.  Failure to do so will lead to erroneous
      results [I-D.ivancic-scf-testing-requirements].  Thus, any testing
      and validation should exercise both the storage and forwarding
      mechanisms of the implementation.  To do otherwise may lead to
      misleading results.

10.  Security Considerations

   Applications need to authenticate to an SCF agent before they can
   send or receive containers.

   Authentication of SCF agents to one another needs to be tackled
   before advertisements of forwarding capability can be acted upon.

   Bandwidth, Storage, and Processing Power are precious resources in an
   SCF.  In order to reduce DoS vulnerabilities and properly allocate
   resources, an SCF should be able to determine whether or not to act
   on a container based solely on the Shipping Label.

   Applications should be able to limit DoS by expressing explicit
   desires to a serving SCF agent for/against certain traffic selectors.
   It may be beneficial for this information to propagate between SCF
   agents, though it should be recognized that any dynamics in these
   preferences causes a risk of data loss due to lack of synchronization
   of the filter rules.

   While some aspects of Public-Key Infrastructure (PKI) may be
   applicable to SCF, PKI itself is not because, in general, PKI
   requires connectivity.  Public-Keys with caching may be applicable;
   however, this would require at least some coarse network
   synchronization.




Ivancic, et al.           Expires June 16, 2014                [Page 23]

Internet-Draft                 SCF Problem                 December 2013


11.  IANA Considerations

   This document neither creates nor updates any registries or
   codepoints, so there are no IANA Considerations.

12.  Acknowledgements

   Much work builds on lessons learned from the work performed by the
   IRTF DTN Research Group.

   Work on this document at NASA's Glenn Research Center was funded by
   the NASA Glenn Research Center Innovation Funds.

13.  References

13.1.  Normative References

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

13.2.  Informative References

   [AMQP]     "Advanced Message Queuing Protocol",
              <http://en.wikipedia.org/wiki/
              Advanced_Message_Queuing_Protocol>.

   [DTNRG]    "DTN Research Group Wiki",
              <http://www.dtnrg.org/wiki/Code>.

   [FidoNet]  "FidoNet Home Page", <http://www.fidonet.org/>.

   [I-D.ivancic-scf-requirements-expectations]
              Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store,
              Carry and Forward Requirements and Expectations", draft-
              ivancic-scf-requirements-expectations-00 (work in
              progress), July 2012.

   [I-D.ivancic-scf-testing-requirements]
              Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store,
              Carry and Forward Testing Requirements", draft-ivancic-
              scf-testing-requirements-00 (work in progress), July 2012.

   [IMAP]     "Internet Message Access Protocol",
              <http://en.wikipedia.org/wiki/
              Internet_Message_Access_Protocol>.



Ivancic, et al.           Expires June 16, 2014                [Page 24]

Internet-Draft                 SCF Problem                 December 2013


   [JMS]      "JSM/OpenWire",
              <http://en.wikipedia.org/wiki/Java_Message_Service>.

   [MQTT]     "Message Queuing Telemetry Transport",
              <http://mqtt.org/wiki/>.

   [POP]      "Post Office Protocol",
              <http://en.wikipedia.org/wiki/Post_Office_Protocol>.

   [Patterns]
              Day, J., "Patterns In Network Architectures - A Return to
              Fundamentals", Prentice Hall , 2008.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [SMIME]    "Secure/Multipurpose Internet Mail Extensions",
              <http://en.wikipedia.org/wiki/S/MIME>.

   [SMTP]     "Simple Mail Transfer Protocole", <http://en.wikipedia.org
              /wiki/Simple_Mail_Transfer_Protocol>.

   [STOMP]    "Streaming Text Oriented Messaging Protocol",
              <http://en.wikipedia.org/wiki/
              Streaming_Text_Oriented_Messaging_Protocol>.

   [UK-DMC]   Wood, L., Ivancic, W., Eddy, W., Stewart, D., Jackson, C.,
              and A. da Silva Curiel, "Use of the Delay-Tolerant
              Networking Bundle Protocol from Space", 59th International
              Astronautical Congress, Glasgow Paper IAC-08-B2.3.10 (also
              NASA-TM-2009-215582), September 2008.

   [UPPC]     "Unix-to-Unix Copy", <http://www.3gpp.org/>.

   [XMPP]     "Extensible Messaging and Presence Protocol",
              <http://xmpp.org>.

Authors' Addresses









Ivancic, et al.           Expires June 16, 2014                [Page 25]

Internet-Draft                 SCF Problem                 December 2013


   William Ivancic
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   United States

   Phone: +1-216-433-3494
   Email: william.d.ivancic@nasa.gov


   Wesley M. Eddy
   MTI Systems

   Email: wes@mti-systems.com


   Alan G. Hylton
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   United States

   Phone: +1-216-433-6045
   Email: alan.g.hylton@nasa.gov


   Dennis C. Iannicca
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   United States

   Phone: +1-216-433-6493
   Email: dennis.c.iannicca@nasa.gov


   Joseph A. Ishac
   NASA Glenn Research Center
   21000 Brookpark Road
   Cleveland, Ohio  44135
   United States

   Phone: +1-216-433-6587
   Email: jishac@nasa.gov







Ivancic, et al.           Expires June 16, 2014                [Page 26]