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]