DTN Research Group S. Symington
Internet-Draft R. Durst
Intended status: Experimental K. Scott
Expires: August 6, 2009 The MITRE Corporation
February 2, 2009
Delay-Tolerant Networking Bundle Diversion
draft-irtf-dtnrg-bundle-divert-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 6, 2009.
Copyright Notice
Copyright (c) 2009 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.
Symington, et al. Expires August 6, 2009 [Page 1]
Internet-Draft DTN Bundle Diversion February 2009
Abstract
This document defines two extensions to the capabilities of a Bundle
Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing
bundles within the context of a Delay-Tolerant Network architecture
[refs.DTNarch]. It defines an operation called "diversion", which is
the act of a bundle protocol agent moving an entire bundle from some
point in bundle processing in the BPA to a DTN application agent.
This diversion of a bundle from the BPA to an application agent is
distinct from delivery of the bundle at that application agent. This
document defines a second operation, called "injection", which is the
inverse of diversion. Injection is the act of an application agent
moving an entire bundle from the application agent into some point in
bundle processing in the BPA. This injection of a bundle from an
application agent to the BPA is distinct from bundle transmission.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivating Use Case . . . . . . . . . . . . . . . . . . . . . 4
3. Bundle Diversion Operation . . . . . . . . . . . . . . . . . . 5
4. Bundle Injection Operation . . . . . . . . . . . . . . . . . . 6
5. Relationship of Diversion to Injection . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Symington, et al. Expires August 6, 2009 [Page 2]
Internet-Draft DTN Bundle Diversion February 2009
1. Introduction
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
[refs.RFC2119].
This document defines two extensions to the capabilities of a Bundle
Protocol Agent (BPA) (as defined in [refs.DTNBP]) that is processing
bundles within the context of a Delay-Tolerant Network architecture
[refs.DTNarch]. It defines an operation called "diversion", which is
the act of a bundle protocol agent moving an entire bundle from some
point in bundle processing in the BPA to a DTN application agent.
This diversion of a bundle from the BPA to an application agent is
distinct from delivery of the bundle at that application agent. This
document defines a second operation, called "injection", which is the
inverse of diversion. Injection is the act of an application agent
moving an entire bundle from the application agent into some point in
bundle processing in the BPA. This injection of a bundle from an
application agent to the BPA is distinct from bundle transmission.
The capabilities described in this document are OPTIONAL for
deployment with the Bundle Protocol. Bundle Protocol implementations
claiming to support bundle diversion MUST be capable of both:
-moving entire bundles from bundle processing in the BPA to an
application agent in an operation that is distinct from
delivery of those bundles at that application agent
(diversion), and
-moving entire bundles from an application agent to bundle
processing in the BPA in an operation that is distinct from
bundle transmission (injection)
as defined in this document, and of
-providing a raw bundle interface between the BPA and all
application agents to which bundles will be diverted or from which
bundles will be injected.
Symington, et al. Expires August 6, 2009 [Page 3]
Internet-Draft DTN Bundle Diversion February 2009
2. Motivating Use Case
Bundle diversion is expected to be of general utility in DTN in
instances in which all or part of a bundle needs to be transcoded
while the bundle is being forwarded through the network. A bundle
that is received at a BPA in one coding format can be diverted to an
application agent that has as its purpose the conversion of the
bundle to an alternate coding format. After transcoding, an
application agent can inject a transcoded bundle back into BPA
processing to be forwarded or delivered in its new format.
Bundle-in-bundle encapsulation [refs.DTNencaps] is a specific example
of a use case that has been identified for bundle diversion. If a
bundle is forwarded to a bundle protocol agent that is intended to
serve as the entrance of an encapsulation tunnel, that BPA would
divert the bundle to an encapsulation-specific application agent.
This encapsulation-specific application agent would encapsulate the
diverted bundle into another, encapsulating bundle and request
transmission of this encapsulating bundle. The source endpoint of
the encapsulating bundle would have the encapsulation-specific
application agent as its member and the destination endpoint of the
encapsulating bundle would have as a member the application agent
that will de-encapsulate the bundle. The encapsulating bundle would
therefore be transmitted from the encapsulating application agent for
delivery to the de-encapsulating application agent. At the bundle
node where the de-encapsulating application agent is located, the de-
encapsulating application agent would extract the encapsulated bundle
from the encapsulating bundle and inject that original bundle into
the bundle protocol agent for processing, including forwarding and/or
delivery. In order to perform such tunneling, bundle diversion is
required to move the bundle to be encapsulated from BPA processing to
the encapsulating application at the start of the tunnel, and bundle
injection is required to move the de-encapsulated bundle from the de-
encapsulating application back into BPA bundle processing at the end
of the tunnel.
Symington, et al. Expires August 6, 2009 [Page 4]
Internet-Draft DTN Bundle Diversion February 2009
3. Bundle Diversion Operation
The "divert" operation occurs when some (here unspecified) mechanism,
e.g. a routing table lookup, causes an entire bundle to be moved from
bundle processing in the BPA to a (here unspecified, but arbitrary)
DTN application agent. Diversion of a bundle from the BPA to an
application agent is distinct from delivery of the bundle at that
application agent. Some of the ways in which diversion differs from
delivery are as follows: the application agent to which the bundle is
diverted is not a member of the bundle's destination endpoint; an
entire bundle is diverted, not just an application data unit and
associated metadata; a bundle may be diverted at an arbitrary point
in bundle processing, so that it may include extension blocks or a
fragmented payload; and no bundle delivery status or custodial
delivery reports are transmitted upon diversion as they might be on
delivery.
Bundles may be diverted at any point after bundle transmission or
reception and before bundle dispatching relative to the bundle
processing procedures defined in [refs.DTNBP] and to the procedures
required to process any extension blocks (e.g. security blocks,
Previous Hop Insertion Block, etc.) in the bundle. The point in
bundle processing at which diversion will occur should be documented
as part of the specification of the AA to which the diversion will
occur.
When diverting a bundle, the BPA may pass not only the bundle, but
additional information, if needed, that is meaningful to the AA to
which the bundle is being diverted.
Symington, et al. Expires August 6, 2009 [Page 5]
Internet-Draft DTN Bundle Diversion February 2009
4. Bundle Injection Operation
The "inject" operation occurs when some application agent at a bundle
node causes an entire bundle to be moved from that AA into the BPA
for bundle processing. Injection of a bundle from an application
agent to the BPA is distinct from bundle transmission. Some of the
ways in which injection differs from transmission are as follows: the
injecting application entity is not a member of the source EID in the
bundle; an entire bundle is injected by the AA, not just a
application data unit; the injected bundle may already have extension
blocks, a current custodian, and other values set; an injected bundle
may have a fragmentary payload; and a bundle may be injected at an
arbitrary point in BPA bundle processing.
Bundles may be injected at any point in BPA processing after bundle
transmission or reception and before bundle dispatching relative to
the bundle processing procedures defined in [refs.DTNBP] and to the
procedures required to process any extension blocks (e.g. security
blocks, Previous Hop Insertion Block, etc.) in the bundle. The point
in bundle processing at which injection will occur should be
documented as part of the specification of the AA that will perform
the injection.
When injecting a bundle, the AA may pass not only the bundle, but
additional information, if needed, that is meaningful to the BPA to
which the bundle is being diverted.
Symington, et al. Expires August 6, 2009 [Page 6]
Internet-Draft DTN Bundle Diversion February 2009
5. Relationship of Diversion to Injection
Normally, when bundles are injected into the same BPA from which they
were diverted, the bundle processing step at which a bundle is
injected should be the same step at which it was diverted. For
example, bundles diverted just before bundle forwarding should be
injected just before bundle forwarding; bundles diverted just after
bundle reception should be injected just after bundle reception;
bundles diverted just before/after processing of a given extension
block should be injected just before/after processing of that
extension block.
Bundles injected into the same BPA from which they were diverted,
MUST re-enter bundle processing so as to avoid the looping that would
occur if the same bundle were to be diverted more than once at the
same processing step.
When bundles are injected into a different BPA from which they were
diverted, it is not possible for the BPA into which the bundles are
being injected to determine, through implementation-specific means
(such as from the convergence layer), the EID of the forwarding node
of these injected bundles. The forwarding node of an injected bundle
is the node that diverted the bundle, and the node that diverted the
bundle is not necessarily a neighbor (in the DTN overlay) of the node
into which the bundle is being injected. Therefore, if the EID of
the forwarding node of an injected bundle is needed for use by the
BPA into which the bundle is being injected, this EID MUST be present
in the diverted bundle, for example, in a Previous Hop Insertion
Block [refs.PrevHopExt] or in the EID reference to the security-
source of a BAB [refs.DTNBPsec], if the bundle contains a BAB.
Symington, et al. Expires August 6, 2009 [Page 7]
Internet-Draft DTN Bundle Diversion February 2009
6. Security Considerations
When a bundle is diverted, the diverted bundle itself may be
protected by one or more security blocks. In particular, it may
contain a Bundle Authentication Block (BAB), which is designed to be
processed by a next-hop neighboring DTN node. If a bundle with a BAB
is diverted by one node and later injected into a non-neighboring
node, the bundle protocol agent into which the bundle is injected
must be capable of validating the security result in the BAB if its
security policy requires such validation. Therefore, diversion and
injection of bundles protected by BABs may require that keys that are
normally only shared between neighbors in the DTN overlay be
distributed further so that they are shared by the diverting and
injecting nodes. Furthermore, as explained in the previous section,
the EID of the node that creates the BAB and diverts the bundle MUST
be identified within the bundle because it will not be possible for
the BPA into which the bundle is injected, which is responsible for
validating the security result in the BAB, to determine the EID of
the BAB-creating node through implementation-specific means (such as
from the convergence layer).
Symington, et al. Expires August 6, 2009 [Page 8]
Internet-Draft DTN Bundle Diversion February 2009
7. IANA Considerations
None at this time.
Symington, et al. Expires August 6, 2009 [Page 9]
Internet-Draft DTN Bundle Diversion February 2009
8. References
8.1. Normative References
[refs.RFC2119]
Bradner, S. and J. Reynolds, "Key words for use in RFCs to
Indicate Requirement Levels", RFC 2119, October 1997.
[refs.DTNBP]
Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC, 5050, November 2007.
[refs.PrevHopExt]
Symington, S., "Delay-Tolerant Networking Previous Hop
Insertion Block", draft-irtf-dtnrg-bundle-previous-hop-
block-04.txt, work-in-progress, September 2008.
[refs.DTNencaps]
Symington, S., Durst, R., and K. Scott, "Delay-Tolerant
Networking Bundle-in-Bundle Encapsulation", draft-irtf-
dtnrg-bundle-encapsulation-05.txt, work-in-progress,
February 2009.
[refs.DTNBPsec]
Symington, S., Farrell, S., Weiss, H., and P. Lovell,
"Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-06.txt, work-in-progress,
November 2008.
8.2. Informative References
[refs.DTNarch]
Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Network Architecture", RFC 4838, April 2007.
Symington, et al. Expires August 6, 2009 [Page 10]
Internet-Draft DTN Bundle Diversion February 2009
Authors' Addresses
Susan Flynn Symington
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7209
Email: susan@mitre.org
URI: http://mitre.org/
Robert C. Durst
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-7535
Email: durst@mitre.org
URI: http://mitre.org/
Keith L. Scott
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
US
Phone: +1 (703) 983-6547
Email: kscott@mitre.org
URI: http://mitre.org/
Symington, et al. Expires August 6, 2009 [Page 11]