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]
