DTN Research Group                                          S. Symington
Internet-Draft                                                  R. Durst
Intended status: Experimental                                   K. Scott
Expires: February 13, 2010                         The MITRE Corporation
                                                         August 12, 2009


               Delay-Tolerant Networking Bundle Diversion
                   draft-irtf-dtnrg-bundle-divert-01

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 February 13, 2010.

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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.








Symington, et al.       Expires February 13, 2010               [Page 1]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 2]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 3]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 4]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 5]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 6]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 7]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010               [Page 8]


Internet-Draft            DTN Bundle Diversion               August 2009


7.  IANA Considerations

   None at this time.
















































Symington, et al.       Expires February 13, 2010               [Page 9]


Internet-Draft            DTN Bundle Diversion               August 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-06.txt, work-in-progress, March 2009.

   [refs.DTNencaps]
              Symington, S., Durst, R., and K. Scott, "Delay-Tolerant
              Networking Bundle-in-Bundle Encapsulation", draft-irtf-
              dtnrg-bundle-encapsulation-06.txt, work-in-progress,
              August 2009.

   [refs.DTNBPsec]
              Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification",
              draft-irtf-dtnrg-bundle-security-08.txt, work-in-progress,
              March 2009.

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 February 13, 2010              [Page 10]


Internet-Draft            DTN Bundle Diversion               August 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 February 13, 2010              [Page 11]