Internet DRAFT - draft-ivancic-scf-requirements-expectations
draft-ivancic-scf-requirements-expectations
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 Requirements and Expectations
draft-ivancic-scf-requirements-expectations-01
Abstract
This document describes the requirements for a Store, Carry and
Forward (SCF) protocol, and the expectations placed upon the SCF
agents and SCF applications.
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.
Status of This Memo
This Internet-Draft is submitted to IETF 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
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
Ivancic, et al. Expires June 16, 2014 [Page 1]
Internet-Draft SCF Requirements December 2013
(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.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Considerations . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 5
5. Agent Requirements and Expectations . . . . . . . . . . . . . 10
6. Application Requirements and Expectations . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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].
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.
o 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.
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
Ivancic, et al. Expires June 16, 2014 [Page 2]
Internet-Draft SCF Requirements December 2013
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 a single container that they were
originally part of, and that 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)
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 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 Container - the application/user data to be transported
over the network as well as an optional checksum of that
information.
o Shipping Label - metadata describing the characteristics of a
container and its forwarding requirements, as well as a mandatory
checksum of that information.
o Sub-Container - A small container residing inside a larger
container.
o Transport Capacity - (as a first order approximation) the
combination of bandwidth and contact time.
Ivancic, et al. Expires June 16, 2014 [Page 3]
Internet-Draft SCF Requirements December 2013
2. Introduction
This document describes the requirements for a Store, Carry and
Forward (SCF) protocol, and the expectations placed upon the SCF
agents and SCF applications.
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.
As background, the SCF Problem Statement
[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.
3. Design Considerations
The following design considerations are explicitly stated with a goal
of keeping the protocol simple. (Anyone can make things more
complicated!)
o Do not overload the relaying protocol. Keep It Simple.
* Keep network management functions separate from the relaying
protocol.
* Content Based Networking is different than SCF. SCF can be
used to move content, but should not be considered an in-
network content store.
* Rationale: Separation allows for independent development and
optimizations.
o The SCF protocol MUST NOT rely on time synchronization between
applications or relaying agents.
* 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.
o Protocol options make interoperability hard. Options are often
used as a placeholder for fixing a bad design.
o Naming and addressing are key to security and scalability.
Ivancic, et al. Expires June 16, 2014 [Page 4]
Internet-Draft SCF Requirements December 2013
o Addressing should be topological (location dependent). This
enables aggregation of the routing locator space and improves
scalability for the routing system.
o 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.
4. Protocol Requirements
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.
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.
PROTOCOL-REQ1: The SCF relaying protocol MUST be able to handle
data sets that are very small (several bytes) and
very large (several gigabytes).
* 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.
PROTOCOL-REQ2: The SCF protocol MUST permit SCF agents to be able
to aggregate containers.
* 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
Ivancic, et al. Expires June 16, 2014 [Page 5]
Internet-Draft SCF Requirements December 2013
recombining containers as the information moves
through the relay network.
PROTOCOL-REQ3: The SCF protocol MUST permit SCF agents to be able
to deaggregate containers.
* 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.
PROTOCOL-REQ4: The SCF protocol MUST permit SCF agents to be able
to reactively fragment a container.
* 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.
PROTOCOL-REQ5: The SCF protocol SHOULD permit SCF agents to be
able to proactively fragment a container.
* 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.
PROTOCOL-REQ6: 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.
Ivancic, et al. Expires June 16, 2014 [Page 6]
Internet-Draft SCF Requirements December 2013
* 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.
PROTOCOL-REQ7: An SCF protocol MUST be capable of implementing
reliability on the Shipping Container.
* 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.
PROTOCOL-REQ8: The SCF protocol security implementation MUST
authenticate the Shipping Label independent of the
Shipping Container.
* 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.
PROTOCOL-REQ9: The SCF protocol security implementation MUST work
with reactive fragmentation.
* 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 [Multi-Terminal][Multi-
Terminal].
PROTOCOL-REQ10: The SCF protocol security implementation MUST have
a security policy database to control resources.
Ivancic, et al. Expires June 16, 2014 [Page 7]
Internet-Draft SCF Requirements December 2013
* 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).
PROTOCOL-REQ11: The SCF protocol MUST be able to separate the
Shipping Label from the Shipping Container
* 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.
PROTOCOL-REQ12: The SCF protocol MUST have a mechanism that enables
data to die naturally.
* 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).
PROTOCOL-REQ13: The SCF protocol MUST have a naming mechanism that
specifies the application and instance to which the
content is bound.
* 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.
PROTOCOL-REQ14: The SCF protocol MUST have a Quality-of-Service
(QOS) mechanism to expedite forwarding and to
handle storage lifetimes.
* Rationale: Past experiences with other store-
and-forward technologies such as DTN [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 Bundle
Ivancic, et al. Expires June 16, 2014 [Page 8]
Internet-Draft SCF Requirements December 2013
Lifetimes [1]. 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.
PROTOCOL-REQ15: 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).
* Rationale: This allows a sending system to
release the container if it so desires, thereby
improving resource usage.
PROTOCOL-REQ16: The SCF protocol MUST have a mechanism to notify a
sender that the container will not be processed.
* 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.
PROTOCOL-REQ17: The SCF protocol SHOULD have a mechanism that
enables one to identify fresh versus stale content
for a given flow.
* 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.
* 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
Ivancic, et al. Expires June 16, 2014 [Page 9]
Internet-Draft SCF Requirements December 2013
bundling, this is problematic as there is no
such formalized standard sequencing (i.e.
sequence numbers).
5. Agent Requirements and Expectations
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.
AGENT-REQ1: An SCF agent MUST NOT be required to implement SCF
security. Security must be optional.
* 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.
AGENT-REQ2: An SCF agent MAY implement reliability on the Shipping
Container.
* 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.
AGENT-REQ3: 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.
* 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.
AGENT-REQ4: An SCF agent MAY remove a container once it receives
notification from the next hop SCF that the container
has been delivered.
* Rationale: The ability to release containers enables
efficient use of storage resources. Note, some
Ivancic, et al. Expires June 16, 2014 [Page 10]
Internet-Draft SCF Requirements December 2013
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.
AGENT-REQ5: An SCF agent SHOULD NOT accept a container if it has no
intention of giving a best effort to forward the
container.
* 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.
AGENT-REQ6: An SCF agent SHOULD implement a policy system that
controls resources. Such a policy system MAY include
the filters described below.
* 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.
(a) What volume (size) container will be accepted.
+ 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
Ivancic, et al. Expires June 16, 2014 [Page 11]
Internet-Draft SCF Requirements December 2013
(b) What sources are permitted to use resources and how much
resource?
+ 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.
(c) What destinations are permitted to use resources and how much
resource?
+ 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.
(d) Prioritized container delivery.
+ 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.
(e) A mapping of QoS to retention lifetime and forwarding
priority.
+ 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.
AGENT-REQ7: 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.
* 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.
Ivancic, et al. Expires June 16, 2014 [Page 12]
Internet-Draft SCF Requirements December 2013
AGENT-REQ8: SCF Agents MUST be able to indicate (or deny) forwarding
of individual containers, based on exchanging their
shipping labels only.
* 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.
AGENT-REQ9: SCF Agents MAY notify applications of pending received
data.
* 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.
6. Application Requirements and Expectations
APPLICATION-REQ1: Applications SHOULD be designed to operate in a
disconnected systems.
* Rationale: Applications that have been designed
assuming a connected network are likely to
break.
* 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.
APPLICATION-REQ2: Applications MUST be able to select their own
globally-unique identifiers and notify SCF agents
of them, along with providing proof of ownership.
* Rational:
APPLICATION-REQ3: Applications MUST be able to poll a SCF agent for
pending received data.
* Rationale: Applications are the only ones that
can keep track of the shared state between
sender and receiver. The Application cannot
Ivancic, et al. Expires June 16, 2014 [Page 13]
Internet-Draft SCF Requirements December 2013
expect lower layers such as the SCF agent to
fully understand its needs.
* Rationale: This eliminates putting undue burden
on the SCF, and ensures interoperability to
specify a known operational expectation.
7. Security Considerations
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.
8. IANA Considerations
This document neither creates nor updates any registries or
codepoints, so there are no IANA Considerations.
9. 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.
10. References
10.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.
10.2. Informative References
[I-D.ivancic-scf-problem-statement]
Ivancic, W., Eddy, W., Iannicca, D., and J. Ishac, "Store,
Carry and Forward Problem Statement", draft-ivancic-scf-
problem-statement-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.
Ivancic, et al. Expires June 16, 2014 [Page 14]
Internet-Draft SCF Requirements December 2013
[Multi-Terminal]
Ivancic, W., Paulsen, P., Stewart, D., Taylor, J., Lynch,
S., Heberle, J., Northam, J., Jackson, C., and L. Wood,
""Large File Transfers from Space using Multiple Ground
Terminals and Delay-Tolerant Networking"", IEEE Global
Telecommunications Conference (GLOBECOM 2010), , December
2010.
[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.
Authors' Addresses
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
Ivancic, et al. Expires June 16, 2014 [Page 15]
Internet-Draft SCF Requirements December 2013
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 16]
