DTN Research Group S. Symington Internet-Draft R. Durst Expires: August 25, 2006 K. Scott The MITRE Corporation February 25, 2006 Non-Custodial (Best-Effort) Multicasting Support in DTN draft-symington-bundle-multicast-noncustodial-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines the requirements and constraints that must be imposed when using the Bundle Protocol [2] in order to support the best-effort multicast delivery of bundles within a Delay-Tolerant Network (DTN). The capabilities described herein enable a source node to transmit a bundle to multiple destination nodes without having to originate a separate bundle for each destination node. These capabilities do not support custody transfer of bundles that Symington, et al. Expires August 25, 2006 [Page 1] Internet-Draft Non-Custodial Multicast in DTN February 2006 are being delivered via multicast. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview of Components for Supporting Multicast . . . . . . . 6 3. Group Addressing and Group Membership Management . . . . . . . 8 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Custodial Multicast Transfer and Retransmission . . . . . 10 4.2. Group Membership and Temporal Semantics . . . . . . . . . 10 4.3. Multicast Route Formulation and Maintenance . . . . . . . 11 4.4. Detecting Unintentional Loops . . . . . . . . . . . . . . 12 5. Binding DTN multicast to underlying network-specific multicast services . . . . . . . . . . . . . . . . . . . . . . 13 6. Multicast Delivery and Mitigating the Impact of Status Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Previous Hop EID Extension Header . . . . . . . . . . . . . . 15 8. Unique Identifiability of All Multicast-Capable Nodes . . . . 18 9. Supporting Best-Effort Multicast in a Mixed-node Network . . . 19 9.1. Flooding Bundle Distribution Strategies for Supporting Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2. The Multicast Overlay . . . . . . . . . . . . . . . . . . 20 10. Bundle-in-Bundle Encapsulation Administrative Record Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 27 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . . . . 30 Symington, et al. Expires August 25, 2006 [Page 2] Internet-Draft Non-Custodial Multicast in DTN February 2006 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 [1]. This document defines the requirements and constraints that must be imposed when using the Bundle Protocol [2] in order to support the best-effort multicast delivery of bundles within a Delay-Tolerant Network (DTN). The capabilities described herein enable a source node to use the Bundle Protocol to transmit a bundle to multiple destination nodes without having to originate a separate bundle for each destination node. These capabilities do not support custody transfer of bundles that are being delivered via multicast. We anticipate the eventual development of a separate document that will define the additional capabilities needed to support custody transfer during multicasting. The bundle protocol is used in DTNs, which overlay on top of multiple networks, some of which may be challenged by limitations such as intermittent and possibly unpredictable loss of connectivity, long or variable delay, low bandwidth, asymmetric data rates, and high error rates. The purpose of the bundle protocol is to support interoperability across such stressed networks. The bundle protocol is layered on top of underlay-network-specific convergence layers, on top of network-specific lower layers, to enable an application in one network to communicate with an application in another network, both of which are spanned by the DTN. The bundle protocol includes some features that are needed to support the ability to multicast bundles, but it does not specify all the necessary protocol mechanisms for doing so, nor does it attempt to. Multicasting will be an important capability for DTNs. The stressed environments of the underlying networks over which the bundle protocol will operate makes it important that resources of the DTN be used as efficiently as possible. Data transfer situations requiring a source that does not have multicast capability to transmit a bundle to multiple destinations can potentially be very wasteful of network bandwidth and persistent storage. The extent of the inefficiency depends on the number of destinations, their distribution throughout the DTN, and the amount of disconnection the network suffers [4]. The requirements and constraints defined in this document are intended to support a best-effort multicast delivery service that can work with a variety of multicast routing protocols in an environment that may suffer from intermittent disconnections, low bandwidth, long and/or variable delay, asymmetric data rates, or high error rates. These capabilities support only a best-effort multicast delivery Symington, et al. Expires August 25, 2006 [Page 3] Internet-Draft Non-Custodial Multicast in DTN February 2006 service in the sense that they do not provide for custody transfer of bundles that are being delivered via multicast. Custody transfer, including retransmission, release of custody, and taking custody of bundles is fundamentally complicated by the introduction of multicasting into the Bundle Protocol because when a bundle is being delivered via multicast, it may be copied and forwarded along multiple paths, and the number of times it will be copied and the nodes at which it will be copied are not necessarily known beforehand by a sending or forwarding node. It is anticipated that fairly complicated mechanisms will have to be used to enable a given custodian to determine when all downstream copies of a bundle have either been delivered or have been taken custody of. Hence, this document defines the requirements and constraints needed to support only best-effort multicast delivery. The Bundle Protocol requirements and constraints to support multicast that are described in this document are RECOMMENDED for deployment with the Bundle Protocol. Use of these requirements and constraints is OPTIONAL. Bundle Protocol implementations that claim to be best- effort multicast-capable MUST support all of the features defined herein. [Comment.1] 1.1. Related Documents This document is best read and understood within the context of the following other DTN documents: - The Delay-Tolerant Network Architecture [3] defines the architecture for delay-tolerant networks, but only briefly discusses multicasting. In particular, it makes the three following DTN multicast-related points: - Group join operations are initiated at the receiver (via the registration of multicast endpoint IDs), - Nodes may wish to receive data sent to a group during a time interval that occurred before they joined the group; in order to support this, data may need to be stored in the network, and - The meaning and design of custody transfer for multicast delivery remains to be fully explored. - The Bundle Protocol Specification[2] defines the format and processing of the headers used to implement the basic bundle protocol. This document does not explicitly discuss DTN multicast, but it does define two mechanisms that are important for supporting multicast: Symington, et al. Expires August 25, 2006 [Page 4] Internet-Draft Non-Custodial Multicast in DTN February 2006 the concept of endpoints that contain multiple nodes, all of which are intended recipients of a bundle, and the concept that a node may both deliver and forward a bundle and, when forwarding a bundle, may forward it to multiple next- hop nodes. The Bundle Protocol also defines custody transfer procedures that apply to bundles that are destined for singleton endpoints; these custody transfer procedures, however, do not apply to multicast bundles. The existing DTN security documents do not address DTN multicast. 1.2. Terminology Multicast Endpoint - an endpoint that may contain multiple bundle nodes and that has as its minimum reception group (see the Bundle Protocol [2]) all of the bundle nodes that are registered in that endpoint. Multicast Bundle - a Bundle that has a multicast endpoint as its destination. Node ID - Strictly speaking, nodes do not have IDs. Endpoints are sets of nodes, and endpoints, not nodes, have IDs. This document relaxes this terminology somewhat in the case of singleton endpoints, which are endpoints that have exactly one node in them. In this case, we refer to the endpoint ID of this singleton endpoint as the "node ID" of the node that is in the endpoint. According to the Bundle Protocol [2], every node must be a member of at least one singleton endpoint, but a node may also be a member of multiple endpoints (singleton or otherwise). Therefore, a given node always has at least one node ID, and it may have multiple node IDs. Symington, et al. Expires August 25, 2006 [Page 5] Internet-Draft Non-Custodial Multicast in DTN February 2006 2. Overview of Components for Supporting Multicast Multicasting as defined in the DTN context is the ability of a source bundle node to transmit a bundle to a multicast endpoint without necessarily having to send a separate bundle for each bundle node that is registered in that endpoint. The DTN multicasting architecture is designed to enable bundles to be delivered to as many destination nodes as possible even in the face of intermittent or unexpected network partitioning. Because these requirements and constraints are best-effort, they do not involve bundle-layer retransmissions of multicast bundles. They do not require that or necessarily work best when the topology of the network is stable rather than in flux. Instead, they are designed to work well in a variety of conditions. The components of DTN multicast support and related issues that will be addressed are: - Group Addressing - Group Membership Management - Custody Transfer and Retransmission during Multicast - Temporal Semantics of Group Membership - Route Formulation and Maintenance - Loop Detection - Binding DTN Multicast to Underlying Network-specific Multicast - Multicast Delivery and Mitigating the Impact of Status Reporting - Identifying the Previous Hop Endpoint ID - Unique Identifiability of Multicast Nodes - Supporting Multicast in a Mixed-node Network - Encapsulation of Multicast Bundles into Unicast Bundles Of the above list of multicast-related mechanisms, requirements, and issues, the first two have been addressed to some extent in the Bundle Protocol Specification [2]. These are discussed in Section 3. The next four are open issues that are discussed in Section 4 but are to be addressed elsewhere. The last 6 issues are addressed in this document, in Section 5, Section 6, Section 7, Section 8, Section 9, Symington, et al. Expires August 25, 2006 [Page 6] Internet-Draft Non-Custodial Multicast in DTN February 2006 and Section 10, respectively. Symington, et al. Expires August 25, 2006 [Page 7] Internet-Draft Non-Custodial Multicast in DTN February 2006 3. Group Addressing and Group Membership Management The Bundle Protocol Specification defines what could be called a multicast endpoint type. A multicast endpoint is an endpoint that may contain multiple nodes and that has as its minimum reception group all nodes in the endpoint. Such multicast endpoints are the mechanisms that enable a group of destination nodes to be the recipients of a particular bundle. The Bundle Protocol Specification [2] also provides group management mechanisms that enable specific nodes to join and leave endpoints. These mechanisms are provided via the commence registration and terminate registration services that are offered by the Bundle Protocol Agent to its Application Agent. The act of joining or leaving a group is receiver-initiated. If a given endpoint ID is a multicast endpoint ID rather than a singleton endpoint ID, then by registering using that multicast endpoint ID, a node is including itself in the endpoint denoted by that endpoint ID, effectively joining the multicast group represented by that endpoint ID. Although the services of commencing and terminating registrations enable a node to join and leave multicast groups, there is room for enhancement. In particular, there is currently no mechanism whereby a node can be prevented from joining a multicast group. In addition, upon such a registration by a node using a multicast endpoint ID, the registration information MAY be disseminated to other nodes, as needed, to ensure that bundles destined for that endpoint ID will be delivered to the newly-registered node. No mechanisms for disseminating this group membership information (e.g. no multicast routing protocols), however, have yet been defined. In fact, no mechanism for disseminating registration information for singleton EIDs (e.g. unicast routing protocols) have yet been defined. Depending on the multicast routing protocols ultimately defined for DTN, additional information may need to be provided with the commence registration service request and/or disseminated to other nodes along with the information that a particular node has registered using a particular multicast EID. For example, - if multicast in DTN is handled in a manner similar to the way it is handled using the Internet Group Management Protocol, then upon a multicast registration commencement, multicast routing protocols need only inform upstream nodes that there is at least one downstream node that has joined the multicast group; there is no need to disseminate information regarding the identity or number of the downstream nodes that are group members. Symington, et al. Expires August 25, 2006 [Page 8] Internet-Draft Non-Custodial Multicast in DTN February 2006 - if upstream nodes must be informed regarding the identity of downstream nodes that have joined the multicast group rather than just be informed that at least one downstream node of unspecified identity has joined the group, then the node ID of the joining node and possibly some security credentials must be promulgated along with fact that a node had registered, - if there is instead a need to indicate the number of downstream nodes that belong to a particular multicast group (rather than the identity of each downstream node), this number would have to be distributed, - if both non-custodial multicast-capable nodes (the behavior of which is being defined by this specification) and custodial multicast-capable nodes (the behavior of which may someday be defined), are permitted to register with multicast EIDs, then in order to support custodial transfer to those nodes that are custodial-multicast capable while supporting non-custodial transfer to those nodes that are only non-custodial multicast- capable or not multicast-capable at all, the registration information that is distributed must include an indication of whether or not the joining node is custodial-multicast capable, - if group membership is made explicitly dependent on temporal semantics, then a commence registration request for a particular multicast EID must be explicitly accompanied by the time of registration or some other such indicator of which bundles the joining member is interested in. If the time of registration were used, for example, it would serve as the demarcation point that distinguishes bundles that should not be sent to the joining node (e.g., bundles with creation timestamps that precede the time of registration) from bundles that should be sent to the joining node (e.g., bundles with creation timestamps later than the time of registration). Many different types of temporal semantics are imaginable [4]. Whatever information is required to implement the chosen temporal semantics will not only need to be distributed to other nodes along with the registration information; it may also need to be included as additional parameters to the registration commencement service. Symington, et al. Expires August 25, 2006 [Page 9] Internet-Draft Non-Custodial Multicast in DTN February 2006 4. Open Issues Four multicast-related open issues are introduced in the following subsections. Solutions for these issues are yet to be determined. 4.1. Custodial Multicast Transfer and Retransmission The Bundle Protocol currently supports custodial delivery of bundles that are sent to singleton endpoints, but its custody transfer mechanisms are explicitly stated not to be applicable to the support of custodial delivery of multicast bundles, which may be sent to multiple-node endpoints. This document, which defines the requirements and constraints necessary to support multicast in DTN, explicitly limits itself to supporting best-effort and not custodial multicast. The additional mechanisms that are necessary to provide custodial multicast delivery still need to be defined. 4.2. Group Membership and Temporal Semantics As pointed out in "Multicasting in Delay Tolerant networks: Semantic Models and Routing Algorithms" [4], due to the unique characteristics of frequent partitioning and consequently large transfer delays in DTNs, membership changes during data transfer may be the norm rather than the exception. Under such delay-tolerant circumstances, there are many different ways in which the receivers of a multicast bundle may be defined relative to the group membership over time. According to some definitions, it may be desirable to enable a node to receive bundles that were sent to a multicast endpoint ID during a time interval that occurred before that node became a member of that endpoint. Special mechanisms may need to be defined in order to accommodate various group membership/temporal semantic models. For example, even after a bundle has been delivered to all nodes that are currently members of a multicast endpoint, it may be necessary to archive that bundle until it expires so that if any additional nodes register in the multicast endpoint they may have a copy of the bundle sent to them. Mechanisms to support group membership and temporal semantics have not yet been defined, but one way to specify them would be to require that each multicast bundle that is sent, in addition to being transmitted to all of the nodes in the destination multicast EID, must also be transmitted to an "archive" node for storage and possible future distribution to nodes that subsequently join the group. Whether such archive nodes have a role in multicast routing would depend on the objectives that are trying to be achieved through the use of multicast. If, for example, maximizing the efficient use of network bandwidth were considered to be the main objective of using multicast distribution, but temporal group membership semantics must Symington, et al. Expires August 25, 2006 [Page 10] Internet-Draft Non-Custodial Multicast in DTN February 2006 also be supported, then it would not make sense for archive nodes to have a role in multicast routing. Instead, bandwidth-efficient source-based trees could be computed from high-volume sources, with an archive node always included as one of the destination nodes. If, on the other hand, supporting such an archive, as opposed to conserving network bandwidth, were considered to be the main objective of using multicast distribution, then it might make sense to have sources send each multicast bundle to an archive node and then have the archive node be responsible for distributing the bundle to all destination nodes. (In PIM-Sparse Mode terminology, the archive nodes would be rendezvous points.) This way, computation of multicast distribution trees could be simplified by always having those trees originate at an archive node. 4.3. Multicast Route Formulation and Maintenance The multicast distribution path consists of all hops from one DTN bundle node to the next over which a given bundle must traverse in order to travel from its source bundle node to every bundle node in its destination multicast endpoint to which it is able to be delivered. This distribution path is determined by the multicast routing protocol/strategy that is used, but it is at least a tree that spans the source node and all destination nodes; it may have additional links as well. In fact, it may have many more links, as might be the case when a flooding distribution strategy is used. The Bundle Protocol [2] supports multicast routing insofar as it enables bundles to be both delivered locally and forwarded, and insofar as it enables bundles to be forwarded to multiple next hops. If a destination group were to be associated with a bundle using an enumerated list of endpoint IDs or if a flooding strategy were used, no multicast-specific routing protocol for setting up the distribution path would be required. The bundle could be routed according to the unicast route to each endpoint ID listed or flooded on every link. The use of a single endpoint ID to denote the entire destination group, however, along with a desire to distribute bundles bandwidth-efficiently, engenders a requirement for a multicast routing protocol to set up a bandwidth-efficient multicast distribution path. Many different multicast routing strategies are possible, ranging from those that seek to increase bandwidth- efficiency, possibly at the cost of decreased robustness or increased delay, to those that seek to increase robustness and more timely delivery, possibly at the cost of using increased bandwidth. The DTN multicasting architecture is not restricted to use of a single multicast routing protocol. On the contrary, the DTN multicasting architecture is designed to support a variety of routing approaches, so that whatever multicast routing strategy best meets the Symington, et al. Expires August 25, 2006 [Page 11] Internet-Draft Non-Custodial Multicast in DTN February 2006 requirements of the application may be used. Such multicast routing protocols for DTN, however, have yet to be defined. 4.4. Detecting Unintentional Loops Detecting unintentional routing loops is not necessarily straightforward in DTN. Bundles are uniquely identified by their source EID, creation timestamp, and fragment offset (if present), so as a local issue, any given node may maintain state regarding which bundles it has received and thereby detect when a given bundle is received a second time. The difficulty does not lie in detecting routing loops, therefore, but in detecting unintentional ones. Receiving a bundle multiple times is not necessarily bad within DTNs. There may be cases in which routing loops are intentional or in which the receipt of a bundle multiple times is expected due to bundles being retransmitted by custodians. Unintended loops, however, can quickly use up significant DTN bandwidth. If multicast distribution is being used, the consequences of an unintended loop can be even more severe, due to the potentially replicative nature of multicast routing. Being able to detect unintentional loops will be an important capability when using multicast. The need for this capability, however, is not restricted to the use of multicast. It is a more general requirement that, although important, is not addressed in this document. Symington, et al. Expires August 25, 2006 [Page 12] Internet-Draft Non-Custodial Multicast in DTN February 2006 5. Binding DTN multicast to underlying network-specific multicast services Some networking technologies, for example Local Area Networks (LANs), have inherent broadcast or multicast transmission capabilities. Because the Bundle Protocol is an overlay on top of multiple underlying networks, increased scalability of DTN multicast delivery could be achieved by binding DTN destination endpoint IDs with underlying subnetwork-native multicast or broadcast addresses. In this way, best-effort DTN multicasting would be able to make use of underlying network-native multicast or broadcast capabilities. Assuming that any group-membership, security, or other requirements that may be met by DTN multicasting mechanisms can also be met when using the subnetwork-native multicast capability, the ability to bind DTN endpoint IDs to an underlying native multicast or broadcast capability enables efficient DTN multicast distribution of best- effort (non-custodial) multicast bundles. Symington, et al. Expires August 25, 2006 [Page 13] Internet-Draft Non-Custodial Multicast in DTN February 2006 6. Multicast Delivery and Mitigating the Impact of Status Reporting If a bundle's Status Report Request Flags indicate that a bundle reception status report must be generated when the bundle is received or when it is forwarded, for example, then a bundle reception status report will be generated at each node that receives or forwards any copy of the bundle. Because any multicast bundle may be copied an arbitrary number of times at any intermediate node, if a multicast group is large or very dispersed, the traffic generated by the Bundle Status Reports resulting from a single multicast bundle could be enormous. There is a risk of bundle status report implosion at the report-to endpoint, because a report-to endpoint may receive status reports from not just every destination node, which in itself could be many nodes, but from every node in the distribution path. To mitigate the risk of status report implosion at the report-to endpoint, local policy for multicast-capable nodes MUST be able to override all requests for status reporting and/or reset the Status Report Request Flags for multicast bundles. That is, if dictated by local policy, the bundle protocol agent at a multicast-capable node MUST NOT generate specified types of status reports and/or MUST reset the specified Status Report Request Flags to zero. Other techniques for mitigating the impact of status reporting for multicast bundles on report-to endpoints could be considered as well. For example, nodes could rate-limit the status reports that they forward to one report per some time interval. In addition, if multiple status reports become available at a given node to be forwarded to the same report-to endpoint, an administrative record for holding concatenated status reports could be defined and used to reduce the total number of status reports that the report-to endpoint will receive. Symington, et al. Expires August 25, 2006 [Page 14] Internet-Draft Non-Custodial Multicast in DTN February 2006 7. Previous Hop EID Extension Header An issue that is related to, but more specifically relevant to multicast than the general loop detection problem discussed previously, is the ability to identify a bundle's previous hop. If the multicast routing protocol being used builds non-source-specific distribution trees for delivering bundles to multicast endpoints, then a node's forwarding table entry for a given multicast EID may consist of a list of next hop node IDs that lead to all members of that multicast endpoint. If a node receives a bundle that is destined for a particular multicast endpoint from one of the next-hop nodes that is listed in the forwarding table entry for that multicast endpoint and then that node simply forwards the bundle to all next- hop nodes listed for that endpoint, an undesirable loop will be produced. To avoid this situation, it will be necessary for a node that receives a bundle to be able to determine which previous-hop node forwarded the bundle to it, so that the receiving node can avoid inadvertently forwarding the bundle back to the previous-hop node. Such an ability to identify the previous-hop node will be important for supporting non-source-specific, tree-shaped multicast delivery paths as well as some flooding strategies. The Bundle Protocol [2], does not include any bundle fields for carrying previous hop endpoint ID information. Relying on the convergence layer alone to enable a receiving node to determine the sender of a bundle is not expected to be sufficient because a node cannot necessarily determine the identity of a previous-hop node using just the knowledge of the convergence layer service access point on which a bundle was received. There may be more than one convergence layer protocol service access point pair over which the sending and receiving nodes can exchange messages. Receipt of a bundle at one convergence layer protocol service access point does not necessarily enable identification of the node that sent the bundle. Bundles received on one convergence layer protocol service access point do not necessarily have a different sending node than bundles received on a different convergence layer protocol service access point. The actual node ID of the previous hop node, which is a bundle layer construct, must be used to identify the previous-hop node uniquely. We define a new Previous Hop EID extension header to carry the endpoint ID of the previous-hop node along with the bundle. The header type value of this header type is 0x05, and the header processing flags value is 00000000. The Format of the Previous Hop EID header's header-type-specific data fields is as follows: Symington, et al. Expires August 25, 2006 [Page 15] Internet-Draft Non-Custodial Multicast in DTN February 2006 Format of Previous Hop EID Header's Header-Type-Specific Data Fields: +----------+-----+ |EID-length| EID | | | | +----------+-----+ Figure 1 The header-type-specific data fields of a Previous HOP EID header consist of two fields: -EID-length - contains the length of the next field (EID) and is encoded as an SDNV. -EID - contains the endpoint ID of the sending node which, when the bundle is received at its next-hop node, will be the EID of the previous-hop node. If the routing protocol being used to support multicast transfer requires each sending node to provide its EID to a given receiving node, then: -when multicast bundles are transmitted over a connectionless convergence layer, this Previous Hop EID Header MUST be included with every bundle that is transmitted between the sending node and that receiving node, -when multicast bundles are transmitted over a connection-oriented convergence layer, this header MUST be included with the first bundle that is sent on the connection, but it need not necessarily be included for subsequent bundle transfers on that connection. In this way, the statefulness of connection-oriented convergence layers MAY be exploited to enable the receiving node to know the EID of the sending node without having to include the sending node's EID with every bundle sent on the association, -when multicast bundles are encapsulated in other bundles (see Section 10), this Previous Hop EID Header must be included as part of the encapsulated multicast bundle. [Comment.2] Upon receipt of a multicast bundle that includes a Previous Hop EID header: -the bundle protocol agent SHALL remove the Previous Hop EID header before forwarding the bundle, and Symington, et al. Expires August 25, 2006 [Page 16] Internet-Draft Non-Custodial Multicast in DTN February 2006 -the bundle protocol agent SHALL NOT forward the multicast bundle to the EID that was in the Previous Hop EID header. Symington, et al. Expires August 25, 2006 [Page 17] Internet-Draft Non-Custodial Multicast in DTN February 2006 8. Unique Identifiability of All Multicast-Capable Nodes Every node that participates in multicast delivery MUST have a single, designated node ID that it always uses for the purpose of supporting multicast delivery. If a node has more than one node ID, one of these node IDs must be the node ID that it always uses for the purpose of supporting multicast delivery; none of the node's other node IDs may be used, despite the fact that they also identify the node uniquely. This requirement enables each multicast-capable node to be uniquely identifiable by a single, designated node ID. For example, if a node has three different node IDs, one of which is designated for use in supporting multicast delivery, then that multicast-specific node ID is the only node ID for that node that: -will be found in the multicast forwarding tables of other nodes, and -would be provided in the Previous Hop EID header of a multicast bundle that that node forwards. This requirement ensures that if a node receives a multicast bundle with a Previous Hop EID Header and the receiving node does not forward the bundle to the EID carried in this header but it does forward the bundle to all other EIDs listed in its multicast forwarding table, the receiving node will not forward the bundle to the node identified in the Previous Hop EID Header. Symington, et al. Expires August 25, 2006 [Page 18] Internet-Draft Non-Custodial Multicast in DTN February 2006 9. Supporting Best-Effort Multicast in a Mixed-node Network Given that implementation of the requirements and constraints to support multicast is currently defined as optional, a DTN could be comprised of some nodes that do support multicast delivery and some nodes that do not. In particular, a DTN could be comprised of both: - Multicast-capable nodes, which we define as nodes that - Implement not only the basic Bundle Protocol [2], but also implement the requirements and constraints defined in this document, which are designed to support best-effort multicasting, - May both initiate multicast EID registrations and disseminate registration information for multicast EIDs to other multicast- capable nodes, and - May originate the transmission of bundles destined for multicast EIDs - May deliver bundles destined for multicast EIDs for which they have registrations (and such bundles would be expected to reach them), - Are capable of either - participating in one or more multicast routing protocols that are used to populate their forwarding table with entries for multicast EIDs, or - participating in a general flooding protocol. - Forward multicast bundles based on the flooding strategy (if that is in use) or based on the dynamically populated entries for multicast EIDs in their forwarding tables - Non-multicast-capable nodes, which we define as nodes that - Implement only the basic Bundle Protocol [2] but no additional capabilities to support multicast, - May initiate multicast EID registrations but do not disseminate registration information for multicast EIDs to other nodes, - May originate the transmission of bundles destined for multicast EIDs Symington, et al. Expires August 25, 2006 [Page 19] Internet-Draft Non-Custodial Multicast in DTN February 2006 - May deliver bundles destined for multicast EIDs for which they have registrations, if those bundles manage to reach them via either flooding or static/default routes that have been set up in other nodes - Do not participate in any multicast routing protocols and so have no routing table entries for multicast EIDs (other than possibly static or default routes), but may participate in a general flooding protocol. - Forward multicast bundles based on the flooding strategy (if that is in use) or based on static or default routes for multicast EIDs that are in their forwarding tables We would like multicast delivery to be supported in a mixed-node DTN that consists of both multicast-capable and non-multicast-capable nodes. This section discusses how this support can be provided with as full a functionality as possible in such a heterogeneous DTN. 9.1. Flooding Bundle Distribution Strategies for Supporting Multicast In any DTN network (whether it consists of only multicast-capable nodes, only non-multicast-capable nodes, or a mixture of both), multicast distribution could be accomplished by having all nodes participate in a flooding protocol that involves forwarding all multicast bundles to all neighbors (with an appropriate pruning strategy to eliminate unintentional loops). Using such a flooding forwarding strategy, best-effort multicast distribution could be provided such that all nodes in the network, whether they are multicast-capable or not, would be capable of originating, forwarding, receiving, and delivering multicast bundles without the need for static or default routes to be set up to effect this distribution. Flooding forwarding strategies generate a lot of traffic, however, so such a distribution approach may not be appropriate for all DTN networks. In addition, if bundle status reporting were requested on flooded multicast bundles in a situation in which a significant number of non-multicast-capable nodes are involved in the bundle distribution, the fact that non-multicast- capable nodes are neither able to override status report requests nor reset the Status Report Request Flags for multicast bundles could leave report-to endpoints vulnerable to status report implosion. 9.2. The Multicast Overlay To support delivery of multicast bundles in a mixed-node network using any sort of multicast routing algorithm other than flooding, however, multicast routing must be defined as an overlay. The overlay will be comprised of the multicast-capable nodes in the DTN, Symington, et al. Expires August 25, 2006 [Page 20] Internet-Draft Non-Custodial Multicast in DTN February 2006 and these nodes must participate in at least one multicast routing protocol that serves to populate their forwarding tables with entries for multicast EIDs. Because the network consists of both multicast- capable nodes and non-multicast capable nodes, there is no guarantee that each of the nodes in the multicast overlay will be adjacent to at least one other node in the overlay. In those cases in which the topology of the network is such that bundle would have to pass through one or more non-multicast-capable nodes in order to get from one multicast-capable node to another, a tunnel would have to be set up between these two multicast-capable nodes, through the intervening non-multicast-capable nodes, in order to enable the bundle to be transferred. Defining the network of multicast-capable routers as a DTN overlay in this manner both enables multicast bundles to pass through non-multicast-capable nodes as required by network topology and it also enables multicast bundles to take advantage of the storage capabilities available at non-multicast-capable nodes through which they pass. The forwarding table for a multicast-capable DTN node in such an overlay, therefore, will have three types of entries for multicast EIDs: - Forwarding: The entry for a multicast EID may list one or more adjacent multicast-capable nodes to which a multicast bundle must be forwarded. Bundles are forwarded from a multicast-capable node to one or more adjacent multicast-capable nodes that are on the path to one or more destination nodes. - Tunneling: The entry for a multicast EID may list one or more multicast-capable nodes to which the multicast bundle must be tunneled. Bundles are tunneled from a multicast-capable node through a sequence of one or more non-multicast-capable nodes to another multicast-capable node in the multicast overlay that is on the path to one or more destination nodes. When a multicast bundle is tunneled, it becomes the content of a new Bundle-in- Bundle Encapsulation administrative record type that is defined in Section 10. (Note: administrative records are used for Bundle-in- Bundle encapsulation so as to cause the encapsulated bundles to be delivered to the administrative element of the receiving node's application agent, which implements the relevant de-encapsulation procedures defined in this document, rather than to the application-specific element.) This Bundle-in-Bundle Encapsulation administrative record becomes the payload of the "encapsulating" bundle. The destination EID of the encapsulating bundle is the singleton EID of the multicast-capable node in the multicast overlay to which the multicast bundle is being tunneled. When the non-multicast-capable nodes that are located between the multicast-capable node at the sending end of the tunnel and the Symington, et al. Expires August 25, 2006 [Page 21] Internet-Draft Non-Custodial Multicast in DTN February 2006 multicast-capable node at the receiving end of the tunnel receive the encapsulated bundle, they forward it as they would any bundle destined for a singleton EID. When the encapsulated bundle is delivered at its destination node, the receiving multicast-capable node extracts the original multicast bundle from the administrative record of the received payload and processes this multicast bundle as if it had just been received from another node. That is, it processes any headers (e.g., the Previous Hop EID Extension Header, if present), delivers the multicast bundle (if appropriate) and/or forwards the multicast bundle as indicated by the node's forwarding table (which may, once again, involve a combination of forwarding the bundle to adjacent multicast capable nodes, tunneling the bundle through one or more non-multicast- capable nodes to a multicast-capable node in the multicast overlay, or forwarding the bundle via a static route to a non- multicast-capable node). - Static Routes: The entry for the multicast EID may list one or more adjacent non-multicast-capable nodes to which the multicast bundle must be forwarded. The forwarding table for a non-multicast-capable node in such an overlay, on the other hand, will have only one type of entry for multicast EIDs: Static Routes: The entry for the multicast EID may list one or more adjacent nodes to which the multicast bundle must be forwarded. Assuming that a flooding distribution strategy is not being used in such an overlay, all bundles that are destined for multicast EIDs, if they must pass through non-multicast-capable nodes, will be either forwarded via a static route or encapsulated within a singleton bundle and then tunneled rather than forwarded through the non- multicast-capable nodes to reach an adjacent multicast-capable node in the multicast overlay. While both non-multicast-capable nodes and multicast-capable nodes may originate, forward, and deliver all types of bundles in such an overlay, their ability to do so is subject to the constraints of their forwarding tables as well as the fact that non-multicast-capable nodes do not disseminate registration information for multicast EIDs. The forwarding tables of non-multicast-capable nodes are limited by the fact that those nodes do not participate in the multicast routing protocols. In order for non-multicast-capable nodes to be able to originate transmission of a multicast bundle, its routing table would need to have a default or static route set up for that bundle's multicast EID. Similarly, in order for a non-multicast-capable node Symington, et al. Expires August 25, 2006 [Page 22] Internet-Draft Non-Custodial Multicast in DTN February 2006 to be able to receive a multicast bundle, a default or static route must be set up from another node to the non-multicast-capable node to enable the transfer. Furthermore, both non-multicast-capable nodes and multicast-capable nodes may register multicast EIDs, but because the registration information regarding a multicast EID will not be disseminated by non-multicast-capable nodes, no effort will be made by any (non- flooding) protocol to enable bundles destined for that multicast EID to reach the registering node. If a multicast bundle with the registered EID does manage to reach that non-multicast-capable node, however (perhaps as a result of the bundle being sent via a static route or via flooding), the multicast bundle will be delivered at that non-multicast-capable node. If a flooding distribution strategy is being used, the multicast overlay is irrelevant and the constraints discussed in this subsection have no impact. The ability of a multicast bundle to reach non-multicast-capable nodes would not be impaired. If multicast bundles are being distributed according to some other type of routing strategy, however, delivery will be accomplished using the overlay and will be subject to the static and default routes and the tunnels that are defined at various nodes in the network. Symington, et al. Expires August 25, 2006 [Page 23] Internet-Draft Non-Custodial Multicast in DTN February 2006 10. Bundle-in-Bundle Encapsulation Administrative Record Definition The following new type of administrative record type, known as a Bundle-in-Bundle Encapsulation, is defined to support the transmission of multicast bundles encapsulated in unicast bundles: Bundle-in-Bundle Encapsulation Administrative Record Type +---------------+--------------+ | Length of the | Encapsulated | | next field | Bundle | +---------------+--------------+ Figure 2 The Bundle-in-Bundle Encapsulation administrative record type code has a value of 0x06. [Comment.3] The Bundle-in-Bundle Encapsulation administrative record type has the following 2-field format: -Length of the next field - contains the length of the next field, which contains the encapsulated bundle, and is encoded as an SDNV. -Encapsulated Bundle field - contains a bundle that is to be extracted from this header for further processing (delivery and/or forwarding). Upon delivery of a bundle with a payload that is a Bundle-in-Bundle Encapsulation administrative record, the administrative element of the application agent of the node at which the bundle was delivered SHALL extract the encapsulated bundle from the bundle-in-bundle encapsulation administrative record and pass the multicast bundle in its entirety to its bundle protocol agent. The bundle protocol agent SHALL process the multicast bundle as if it had just been received from another node. Some of these processing steps include: -the bundle protocol agent SHALL deliver the multicast bundle, if appropriate, -if the bundle has a Previous Hop EID header, the bundle protocol agent SHALL NOT forward the multicast bundle to the EID that is in the Previous Hop EID header, -if the bundle has a Previous Hop EID header, the bundle protocol agent SHALL remove this header before forwarding the bundle, and -the bundle protocol agent SHALL forward the bundle to all EIDs that are appropriate for enabling the multicast bundle to reach all of the nodes in its destination multicast endpoint (with the Symington, et al. Expires August 25, 2006 [Page 24] Internet-Draft Non-Custodial Multicast in DTN February 2006 exception of the EID in the Previous Hop EID header, if present). All multicast-capable nodes MUST be capable of both: -generating and sending bundles containing Bundle-in-Bundle Encapsulation administrative records, and -receiving and processing bundles containing Bundle-in-Bundle Encapsulation administrative records. Symington, et al. Expires August 25, 2006 [Page 25] Internet-Draft Non-Custodial Multicast in DTN February 2006 11. Security Considerations As mentioned earlier, there are two documents that pertain to providing security within DTN. Both of these documents, however, address the security of the Bundle Protocol when used to transmit bundles from a single source to a single destination. They do not address the security of multicast delivery within the bundle protocol. The feasibility of and methods for extending the Bundle Security Protocol to protect multicast bundles are yet to be determined. The use of the Bundle Authentication Header (BAH) to provide hop-by-hop security could probably remain largely unchanged and would be applicable to protecting multicast delivery. The Confidentiality Header (CH) and the Payload Security Header (PSH), however, because they provide end-to-end security, will probably require adaptation to provide protection between a single source and multiple destinations. This document does not consider the security aspects of enabling or preventing a node from registering with a particular multicast endpoint ID, and thereby joining and leaving a particular multicast group, although we acknowledge that security considerations regarding joining and leaving groups are present and significant. Symington, et al. Expires August 25, 2006 [Page 26] Internet-Draft Non-Custodial Multicast in DTN February 2006 12. References 12.1. Normative References [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-04.txt , December 2005. 12.2. Informative References [3] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", draft-irtf-dtnrg-arch-04.txt , December 2005, . [4] Zhao, W., Ammar, M., and E. Zegura, "Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms", August 2005. Symington, et al. Expires August 25, 2006 [Page 27] Internet-Draft Non-Custodial Multicast in DTN February 2006 Editorial Comments [Comment.1] Editors: Actually, the "bundle protocol requirements and constraints to support multicast are RECOMMENDED/ OPTIONAL" statement needs to be in the core Bundle Protocol spec and not here. But for now, let's put it here until we get agreement with the larger group. [Comment.2] If it is determined that there are purposes in addition to multicast routing support for which the previous-hop node ID information is useful, then this new Previous Hop EID extension header for transmitting previous-hop node ID information from sending to receiving nodes should be defined elsewhere, in a more generally- applicable document. For now, however, for the purpose of defining support for multicast, we have defined this mechanism here. [Comment.3] If it is determined that there are additional purposes within DTN for which bundle-in-bundle encapsulation is useful, then this new bundle-in-bundle encapsulation administrative record type could be defined elsewhere, in a more generally-applicable document. For now, however, for the purpose of defining support for multicast, we have defined this mechanism here. Symington, et al. Expires August 25, 2006 [Page 28] Internet-Draft Non-Custodial Multicast in DTN February 2006 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 25, 2006 [Page 29] Internet-Draft Non-Custodial Multicast in DTN February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Symington, et al. Expires August 25, 2006 [Page 30]