Internet DRAFT - draft-burleigh-dtnrg-imc

draft-burleigh-dtnrg-imc






Network Working Group                                        S. Burleigh
Internet-Draft                                Jet Propulsion Laboratory,
Intended status: Experimental                   California Institute of
Expires: May 11, 2013                                         Technology
                                                        November 7, 2012


                    CBHE-Compatible Bundle Multicast
                      draft-burleigh-dtnrg-imc-00

Abstract

   This document describes a mechanism for Delay-Tolerant Networking
   (DTN) multicast that is compatible with Compressed Bundle Header
   Encoding (CBHE).  The mechanism, named "Interplanetary Multicast"
   (IMC), comprises (a) a single network-wide multicast spanning tree
   overlaid on any single Bundle Protocol (BP)-based network, (b)
   multicast groups that take the form of ordinary BP non-singleton
   endpoints, (c) a new CBHE-compatible URI scheme, "imc", for
   expressing the identities of these endpoints, (d) a new type of BP
   administrative record that propagates multicast "petitions"
   (announcements regarding nodes' membership in IMC endpoints) through
   the multicast tree, and (e) a new bundle forwarding procedure by
   which bundles whose destinations are multicast groups are forwarded
   through the multicast tree in accord with previously received
   petitions.

   IMC is designed to provide simple and efficient multi-source,
   generally reliable, delay-tolerant multi-point data delivery in a
   network of arbitrary size.  Anycast, content-centric networking,
   persistent messages, and similar research challenges are not
   explicitly supported.

   For research purposes and small-scale deployment, it is anticipated
   that multicast tree construction and maintenance can be manual.  For
   larger networks an automated protocol for IMC tree management would
   be required; the design of such a protocol is beyond the scope of
   this specification.

Requirements Language

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

Status of this Memo

   This Internet-Draft is submitted in full conformance with the



Burleigh                  Expires May 11, 2013                  [Page 1]

Internet-Draft                     IMC                     November 2012


   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 May 11, 2013.

Copyright Notice

   Copyright (c) 2012 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.























Burleigh                  Expires May 11, 2013                  [Page 2]

Internet-Draft                     IMC                     November 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  IMC Design Elements  . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  The "imc" Endpoint ID Scheme . . . . . . . . . . . . . . .  5
     2.2.  Multicast groups . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Multicast tree . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Petitions  . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.5.  Multicast forwarding . . . . . . . . . . . . . . . . . . .  9
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12




































Burleigh                  Expires May 11, 2013                  [Page 3]

Internet-Draft                     IMC                     November 2012


1.  Introduction

   This document describes a mechanism for Delay-Tolerant Networking
   (DTN) multicast that is compatible with Compressed Bundle Header
   Encoding (CBHE) [RFC6260].  The mechanism, named "Interplanetary
   Multicast" (IMC), is designed to be a simple, efficient multicast
   capability operating in the context of the Delay-Tolerant Networking
   (DTN) Bundle Protocol (BP) [RFC5050].  The key elements of that
   design are as follows:

   o  A single network-wide multicast spanning tree overlaid on any
      single Bundle Protocol (BP)-based network.

   o  Multicast groups that take the form of ordinary BP non-singleton
      endpoints.

   o  A new CBHE-compatible URI scheme, "imc", for expressing the
      identities of these endpoints.

   o  A new type of BP administrative record that propagates multicast
      "petitions" (announcements regarding nodes' membership in IMC
      endpoints) through the multicast tree.

   o  A new bundle forwarding procedure by which bundles whose
      destinations are multicast groups are forwarded through the
      multicast tree in accord with previously received petitions.

   The IMC multicast concept is intended to offer the following
   features:

   o  Delay- and disruption-tolerant multicast.  Data destined for an
      IMC multicast group are conveyed by DTN protocols that can achieve
      successful data delivery hours or days after transmission despite
      frequent and/or lengthy lapses in connectivity on end-to-end
      paths.

   o  Multi-source multicast.  Any IMC-capable node anywhere in the
      network can be the source of a bundle that is to be delivered to
      the members of any specified multicast group.

   o  Generally reliable multicast.  IMC transmission is not perfectly
      reliable, but properly configured it is significantly more
      reliable than standard IP multicast.  This is because propagation
      through the multicast tree is accomplished by the Bundle Protocol
      utilizing underlying "convergence layer" protocols that may
      perform automatic acknowledgment and retransmission between
      topologically adjacent network nodes.  Delegating retransmission
      responsibility to the convergence layer serves as a scalable



Burleigh                  Expires May 11, 2013                  [Page 4]

Internet-Draft                     IMC                     November 2012


      alternative to retransmission from the original source node and
      also avoids the complexities of trying to accomplish concurrent BP
      custody transfer to all receiving nodes for each multicast bundle.
      Custodial multicast is problematic in part because the multiple
      copies of a given bundle that are to be forwarded to different
      neighbors are indistinguishable: accurate application of custody
      signals and retransmission timeout events is difficult.

   o  Scalable multi-point delivery.  The multicast tree structure
      partitions the multi-point forwarding problem, balancing the load
      among forwarding nodes and enabling the multicast infrastructure
      to grow to arbitrary size.  Using a single tree structure to
      support all possible multicast groups minimizes multicast
      reconfiguration traffic in the network.

   Anycast, content-centric networking, persistent messages, and similar
   research challenges are not explicitly supported.


2.  IMC Design Elements

2.1.  The "imc" Endpoint ID Scheme

   A BP endpoint identifier (EID) is a Uniform Record Identifier (URI)
   as defined by [RFC3986].  More specifically, each BP EID is a URI
   consisting of a "scheme name" followed by ":", followed by a sequence
   of characters - historically termed the "scheme-specific part" (SSP)
   in DTN specifications - conforming to URI syntax as defined by
   RFC3986.

   All EIDs identifying IMC endpoints MUST conform to the "imc" URI
   scheme described below.  As noted in Section 4 below, IANA
   registration is requested for this new URI scheme.

   The SSP of every URI formed within the "imc" scheme must comprise:

   1.  A sequence of ASCII numeric digits representing an integer in the
       range 1 to (2^64 - 1), termed the "group number" of the URI.

   2.  An ASCII period ('.') character.

   3.  An ASCII zero ("0") character.

   The group number identifies an IMC multicast group.  The constant
   value zero following the period character is the endpoint ID's
   "service number", structurally analogous to the service number as
   described in the definition of the unicast "ipn" URI scheme.
   (Distinct service numbers are needed for demultiplexing among



Burleigh                  Expires May 11, 2013                  [Page 5]

Internet-Draft                     IMC                     November 2012


   applications in IPN unicast for BP, to distinguish among multiple
   endpoints at which bundles may be sent and received on a given node,
   because the node's own identifying number must be cited identically
   in the identifier for each such endpoint.  No such mechanism is
   needed in IMC, because the node's own identifying number does not
   appear in the endpoint ID; the group number itself is the
   demultiplexor.)

   For example, "imc:11.0" would be a conformant IMC endpoint ID.

   "imc" is a CBHE-conformant URI scheme, like "ipn", so conversion of
   an IMC EID to and from a tuple of two integers for efficient
   representation in a transmitted bundle is straightforward as
   described in the CBHE specification [RFC6260].

   Endpoints identified by EIDs conforming to the "imc" scheme MAY be
   the destinations of bundles but MUST NOT function in any other
   capacity (e.g., as source, report-to, or custodian) in bundle
   processing.

   Citing an IMC endpoint ID as the destination of a bundle implicitly
   asserts that the destination of the bundle is an endpoint that may
   have multiple members, so any bundle whose destination is an IMC
   endpoint ID MUST have the "destination endpoint is a singleton"
   bundle processing flag set to 0.

   Note that scheme names themselves are not encoded by CBHE procedures.
   A BP node that receives a bundle whose destination endpoint is CBHE-
   encoded (as indicated by a dictionary length of zero) must be able to
   determine whether that endpoint should be decoded to the "ipn" scheme
   or to the "imc" scheme, i.e, whether the bundle is unicast or
   multicast.  This determination is straightforward:

   o  "ipn" and "imc" are the only CBHE-conformant URI schemes (except
      that "dtn:none" is CBHE-conformant, encoded as the integer pair
      (0, 0)).

   o  If the bundle's "destination endpoint is a singleton" bundle
      processing flag is set to 1, then the destination endpoint scheme
      is "ipn", which is restricted to unicast transmission.

   o  Otherwise the destination endpoint scheme is "imc".

2.2.  Multicast groups

   An IMC multicast group is a non-singleton BP endpoint that is
   identified by a URI that conforms to the "imc" scheme.  A BP node
   joins an IMC multicast group by simply registering in that endpoint;



Burleigh                  Expires May 11, 2013                  [Page 6]

Internet-Draft                     IMC                     November 2012


   it leaves the group by unregistering within that endpoint.

   Note that the fact that an IMC multicast group is a non-singleton
   endpoint provides no information about the current size of the
   endpoint's membership at any moment; it only signifies that the
   endpoint is not prohibited from having multiple members.  An IMC
   multicast group may at any time have zero, one, or many members.

2.3.  Multicast tree

   IPN multicast is made possible by the propagation of both "petitions"
   (as described below) and multicast application bundles through a
   single spanning tree structured as an overlay upon the nodes of a
   single DTN-based network.

   A node can only be IMC-capable if it has accurate current information
   identifying all of its "immediate relatives" in the tree, i.e, the
   nodes that are its parent and all of its children.  For this purpose,
   all IMC-capable nodes MUST be uniquely identifiable.  One possible
   node identification mechanism would be node number as defined for the
   "ipn" URI scheme, but this is an implementation matter.

   Mechanisms for propagating information about nodes' immediate
   relatives in an IMC multicast tree are an implementation matter.  For
   research purposes and small-scale deployment, it is anticipated that
   multicast tree construction and maintenance can be manual.  For
   larger networks an automated protocol for IMC tree management would
   be required; the design of such a protocol is beyond the scope of
   this specification.

   Every immediate relative of a given node in the multicast tree MUST
   be a "neighbor" of that node in the topology of the underlying DTN-
   based network; that is, each node must be able to exchange bundles
   directly, by means of some convergence-layer protocol, with each of
   its immediate relatives.  This is because loop-free IMC multicast
   petition and application bundle forwarding procedures requires that
   the identity of the immediate relative that sends each received
   bundle be known with certainty.  That identity can be inferred from
   information provided by the convergence-layer adapter, or it could be
   asserted by an attached Previous-Hop Node extension block
   authenticated by a Bundle Authentication Block, but no such
   information can be provided when a bundle is forwarded by an
   intermediary node.

2.4.  Petitions

   The propagation of bundles through an IMC multicast tree is governed
   by expressions of interest -- "petitions" -- that are signaled when



Burleigh                  Expires May 11, 2013                  [Page 7]

Internet-Draft                     IMC                     November 2012


   IMC-capable nodes join and leave IMC multicast groups.  An IMC
   petition is a Bundle Protocol administrative record constructed as
   follows:

   o  Record type code is 5, i.e., bit pattern 0101.

   o  The content of the administrative record consists of a single SDNV
      indicating the multicast group to which the petition pertains,
      followed by a single byte indicating interest in that group.

   o  The value of the "interest" byte is 0x01 if the petition indicates
      assertion of interest in this group; it is 0x00 if the petition
      indicates cancellation of interest in this group.

   When a node joins an IMC multicast group, it MUST send a petition
   with interest value 1, citing the number of that group, to each of
   its immediate relatives (parent and children) in the multicast tree.

   When a node leaves an IMC multicast group, it MUST send a petition
   with interest value 0, citing the number of that group, to each of
   its immediate relatives in the multicast tree.

   When the administrative element of a node's application agent
   receives a petition in a bundle whose bundle ID timestamp (creation
   time and sequence number) is greater than the bundle ID timestamp of
   the most recently accepted petition regarding the same multicast
   group sent by the same immediate relative in the multicast tree, the
   petition is considered a "current" petition.  Otherwise, the petition
   is considered not current and MUST be ignored.  This prevents the
   propagation of obsolete petition information when bundles arrive out
   of transmission order.

   When the administrative element of a node's application agent
   receives a current petition with interest value 1 it MUST:

   o  Note that the node from which the petition was received has an
      interest in bundles destined for the indicated group.

   o  Forward the petition to each of its immediate relatives in the
      multicast tree except the node from which the petition was
      received, UNLESS either the receiving node is a member of the
      indicated group or one or more other immediate relatives' interest
      in bundles destined for the indicated group is currently noted.
      In the latter case, the petition MAY (but need not) be forwarded.

   When the administrative element of a node's application agent
   receives a current petition with interest value 0 it MUST:




Burleigh                  Expires May 11, 2013                  [Page 8]

Internet-Draft                     IMC                     November 2012


   o  Note that the node from which the petition was received now has no
      interest in bundles destined for the indicated group.

   o  Forward the petition to each of its immediate relatives in the
      multicast tree except the node from which the petition was
      received, UNLESS either the receiving node is a member of the
      indicated group or one or more other immediate relatives'
      continued interest in bundles destined for the indicated group is
      currently noted.  In the latter case, the petition MUST NOT be
      forwarded.

   When a new immediate relative (parent or child) in the multicast tree
   is added for some node, that node MUST send to the new relative a
   petition with interest value 1 for each multicast group in which
   either (a) the node itself is a member or (b) interest is currently
   noted by one or more of the node's other immediate relatives.

   When any one of a node's immediate relatives in the multicast tree is
   removed, that node MUST send to every remaining immediate relative a
   petition with interest value 0 for each multicast group in which (a)
   the node itself is not a member and (b) the removed relative was
   interested but no other immediate relative is currently interested.

2.5.  Multicast forwarding

   When an application requests bundle transmission of an application
   data unit to an IMC multicast group, the node MUST create the bundle
   (as prescribed by the Bundle Protocol specification) and:

   o  Deliver the bundle locally, if the node is itself a member of that
      multicast group.

   o  Forward a copy of the bundle to every immediate relative that is
      currently interested in bundles destined for that group.

   When an IMC-capable node receives a bundle whose destination is an
   IMC multicast group, the node MUST:

   o  Deliver the bundle locally, if the node is itself a member of that
      multicast group.

   o  Forward a copy of the bundle to every immediate relative that is
      currently interested in bundles destined for that group, except
      the relative from which the bundle was received.







Burleigh                  Expires May 11, 2013                  [Page 9]

Internet-Draft                     IMC                     November 2012


3.  IANA Considerations

   Provisional registration (per [RFC4395]) for a URI scheme for CBHE is
   requested, with the string "imc" as the suggested scheme name, as
   follows.

   URI scheme name: "imc".

   Status: provisional.

   URI scheme syntax:

   This specification uses the Augmented Backus-Naur Form (ABNF)
   notation of [RFC5234], including the core ABNF syntax rule for DIGIT
   defined by that specification.

   imc-uri = "imc:" ipn-hier-part
   imc-hier-part = group-nbr nbr-delim service-nbr ; a path-rootless
   group-nbr = 1*DIGIT
   nbr-delim = "."
   service-nbr = "0"

   None of the reserved characters defined in the generic URI syntax are
   used as delimiters within URIs of the IPN scheme.

   URI scheme semantics: URIs of the IPN scheme are used as endpoint
   identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
   (BP) [RFC5050] as described in 2.1 above.

   Encoding considerations: URIs of the IMC scheme are encoded
   exclusively in US-ASCII characters.

   Applications and/or protocols that use this URI scheme name: the
   Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050].

   Interoperability considerations: as noted above, URIs of the IPN
   scheme are encoded exclusively in US-ASCII characters.

   Security considerations:

   o  Reliability and consistency: none of the BP endpoints identified
      by the URIs of the IMC scheme are guaranteed to be reachable at
      any time, and the identity of the processing entities operating on
      those endpoints is never guaranteed by the Bundle Protocol itself.
      Bundle authentication as defined by the Bundle Security Protocol
      is required for this purpose.





Burleigh                  Expires May 11, 2013                 [Page 10]

Internet-Draft                     IMC                     November 2012


   o  Malicious construction: malicious construction of a conformant
      IMC-scheme URI is limited to malicious selection of group number.
      That is, a maliciously constructed IMC-scheme URI could be used to
      direct a bundle to an endpoint whose member nodes might be damaged
      by the arrival of that bundle.  In that case (and indeed in all
      bundle processing) the node that receives a bundle should verify
      its authenticity and validity before operating on it in any way.

   o  Back-end transcoding: the limited expressiveness of URIs of the
      IMC scheme effectively eliminates the possibility of threat due to
      errors in back-end transcoding.

   o  Rare IP address formats: not relevant, as IP addresses do not
      appear anywhere in conformant IMC-scheme URIs.

   o  Sensitive information: because IMC-scheme URIs are used only to
      represent the identities of Bundle Protocol endpoints, the risk of
      disclosure of sensitive information due to interception of these
      URIs is minimal.  Examination of IMC-scheme URIs could be used to
      support traffic analysis; where traffic analysis is a plausible
      danger, bundles should be conveyed by secure convergence-layer
      protocols that don't expose endpoint IDs.

   o  Semantic attacks: the simplicity of IMC-scheme URI syntax
      minimizes the possibility of misinterpretation of a URI by a human
      user.

   Contact: Scott Burleigh, Jet Propulsion Laboratory, California
   Institute of Technology, scott.c.burleigh@jpl.nasa.gov, +1 (800) 393-
   3353.

   Author/Change controller: Scott Burleigh, Jet Propulsion Laboratory,
   California Institute of Technology, scott.c.burleigh@jpl.nasa.gov, +1
   (800) 393-3353.

   References: S. Burleigh, "CBHE-Compatible Bundle Multicast (IMC)",
   draft-burleigh-dtnrg-imc-00, October 2012.


4.  Security Considerations

   IMC introduces no new security considerations beyond those discussed
   in the DTN Bundle Protocol, Bundle Security Protocol, and CBHE
   specifications.


5.  References




Burleigh                  Expires May 11, 2013                 [Page 11]

Internet-Draft                     IMC                     November 2012


5.1.  Normative References

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

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

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC6260]  Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
              RFC 6260, May 2011.

5.2.  Informative References

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35,
              RFC 4395, February 2006.


Author's Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Drive, m/s 301-490
   Pasadena, CA  91109
   USA

   Phone: +1 818 393 3353
   Email: Scott.C.Burleigh@jpl.nasa.gov
















Burleigh                  Expires May 11, 2013                 [Page 12]