DTN Research Group S. Symington Internet-Draft R. Durst Intended status: Experimental K. Scott Expires: February 13, 2010 The MITRE Corporation August 12, 2009 Delay-Tolerant Networking Custodial Multicast Extensions draft-symington-dtnrg-bundle-multicast-custodial-06 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 13, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Symington, et al. Expires February 13, 2010 [Page 1] Internet-Draft DTN Custodial Multicast Extensions August 2009 Abstract This document defines optional extensions to the Bundle Protocol [refs.DTNBP] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. Symington, et al. Expires February 13, 2010 [Page 2] Internet-Draft DTN Custodial Multicast Extensions August 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 2. The Basic Problems of Custodial Multicast . . . . . . . . . . 8 3. Objectives, Assumptions, and Design Principles . . . . . . . . 9 3.1. Receiver-driven versus Source-driven Multicast Models . . 9 3.2. Custodial Multicast Objectives . . . . . . . . . . . . . . 10 3.3. Assumptions and Design Principles for Custodial Multicast Extensions . . . . . . . . . . . . . . . . . . . 11 4. Multicast Routing Protocol Requirements and Desired Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Only CMC-nodes may be branching points . . . . . . . . . . 14 4.2. Every bundle copy must be able to be individually accounted for . . . . . . . . . . . . . . . . . . . . . . 14 4.3. If convergence layer multicast is used, the forwarding node must know the number of next-hop recipient nodes . . 16 4.4. CMC nodes should keep track of de-registration requests in order to be able to distinguish delayed de-registrations from routing failures . . . . . . . . . . 16 5. Overview of Mechanisms for Supporting Custodial Multicast . . 19 5.1. Special Responsibilities of Custodial Nodes . . . . . . . 21 5.2. Special Responsibilities of (Non-Custodial) Branching Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Identifying Bundle Copies . . . . . . . . . . . . . . . . . . 24 7. Proxy EID Extension Block . . . . . . . . . . . . . . . . . . 26 8. Bundle Protocol Extensions to Support Custody Transfer and Retransmission for Multicast Bundles . . . . . . . . . . . . . 28 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Bundle Processing Steps for Custodial Multicast Bundles . 28 8.2.1. Bundle Forwarding . . . . . . . . . . . . . . . . . . 28 8.2.2. Forwarding Contraindicated . . . . . . . . . . . . . . 31 8.2.3. Forwarding Failed . . . . . . . . . . . . . . . . . . 32 8.2.4. Bundle Reception . . . . . . . . . . . . . . . . . . . 32 8.2.5. Local Bundle Delivery . . . . . . . . . . . . . . . . 33 8.2.6. Custody Transfer . . . . . . . . . . . . . . . . . . . 33 8.2.7. Custody Acceptance . . . . . . . . . . . . . . . . . . 33 8.2.8. Custody Release . . . . . . . . . . . . . . . . . . . 34 8.2.9. Custody Transfer Success . . . . . . . . . . . . . . . 34 8.2.10. Custody Transfer Failure . . . . . . . . . . . . . . . 35 8.2.11. Bundle Deletion . . . . . . . . . . . . . . . . . . . 38 8.3. Reception of Custody Signals . . . . . . . . . . . . . . . 38 9. Custodial Multicast and the Retransmission Block . . . . . . . 39 10. Performance Impact . . . . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Symington, et al. Expires February 13, 2010 [Page 3] Internet-Draft DTN Custodial Multicast Extensions August 2009 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Symington, et al. Expires February 13, 2010 [Page 4] Internet-Draft DTN Custodial Multicast Extensions August 2009 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [refs.RFC2119]. Multicasting as defined in the DTN context is the ability of a source bundle node to transmit a bundle to a destination multicast endpoint without necessarily having to originate a separate bundle for each bundle node that is registered in that endpoint. The Bundle Protocol [refs.DTNBP] is designed to support delivery of bundles to all types of endpoints (singleton, anycast, and multicast), but it only supports custodial delivery (custody transfer and custody-based re- forwarding) of bundles that are sent to singleton endpoints. Its custodial delivery mechanisms are not applicable to bundles sent to multicast endpoints. This document defines optional extensions to the Bundle Protocol [refs.DTNBP] for supporting the custodial multicast delivery of bundles within a Delay-Tolerant Network (DTN). The protocol extensions described herein may be used to support custody transfer and custody-based reforwarding during the transmission of a bundle from a single source node to multiple destination nodes. The Bundle Protocol extensions to support custodial multicast that are described in this document are OPTIONAL for deployment with the Bundle Protocol. Use of these extensions is also OPTIONAL. Bundle Protocol implementations that claim to be custodial-multicast-capable (CMC) MUST support all of the features defined herein, as well as all of the features defined in the Bundle Protocol [refs.DTNBP]. In addition, in any given network that purports to support custodial multicast delivery, a multicast routing protocol is also required to set up the multicast distribution path. The extensions defined in this document are multicast-routing-protocol-independent in the sense that they are designed to work with any multicast routing protocol, providing that the multicast routing protocol meets certain requirements, which are defined in Section 4. 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 [refs.DTNarch] defines the architecture for delay-tolerant networks, but only briefly discusses multicasting. Symington, et al. Expires February 13, 2010 [Page 5] Internet-Draft DTN Custodial Multicast Extensions August 2009 - The Bundle Protocol Specification [refs.DTNBP] defines the format and processing of the blocks used to implement the basic bundle protocol. This document does not explicitly discuss DTN multicast, but it does define two concepts that are important for supporting multicast: 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, are explicitly stated to be applicable only to bundles that are destined for singleton endpoints and, therefore, by implication, not to be applicable to bundles that are destined for multicast endpoints. - Delay-Tolerant Networking Bundle-in-Bundle Encapsulation [refs.Encaps] defines an encapsulation-specific application agent capability and a bundle payload format for placing one or more bundles inside of the payload field of an encapsulating bundle's Bundle Payload Block. This capability is useful, for example, for encapsulating one or more multicast bundles inside of a singleton bundle for custodial retransmission to a specific downstream DTN node. 1.2. Terminology Multicast Endpoint - A bundle endpoint that is permitted to contain multiple nodes and that has as its minimum reception group (see [refs.DTNBP]) all of the nodes registered in that endpoint. Branching Point - A bundle's delivery path has a branching point at a particular node if in the course of delivering the bundle to its minimum reception set that node either: -delivers the bundle at that node and forwards it to at least one next hop node, or forwards the bundle to more than one next hop node. A node that is a branching point for a bundle is said to "branch" that bundle. Singleton Bundle - a bundle that has a singleton endpoint ID as its Symington, et al. Expires February 13, 2010 [Page 6] Internet-Draft DTN Custodial Multicast Extensions August 2009 destination. Multicast Bundle - a bundle that has a multicast endpoint ID as its destination. Custodial Multicast Bundle - a Bundle that has a multicast endpoint ID as its destination and that has its custody transfer requested flag (in the bundle processing flags field) set to 1. Custodial-multicast-capable (CMC) node - a node that implements all of the features defined in this document, as well as all of the features defined in the Bundle Protocol [refs.DTNBP]. Non-Custodial-multicast-capable (non-CMC) node - a node that does not implement all of the features defined in this document and all of the features defined in the Bundle Protocol [refs.DTNBP]. Symington, et al. Expires February 13, 2010 [Page 7] Internet-Draft DTN Custodial Multicast Extensions August 2009 2. The Basic Problems of Custodial Multicast Custody transfer and retransmission, which are defined for singleton bundles in the Bundle Protocol [refs.DTNBP], are fundamentally complicated when applied to multicast bundles. Upon receipt of a multicast bundle, a bundle node may deliver the bundle at that node, forward the bundle to one or more next-hop nodes, or both. If a node delivers a bundle and forwards it to at least one next hop node or forwards the bundle to more than one next hop node, then the bundle's path is said to have a branching point at that node. Branching points cause additional copies of a bundle to be created. A node that takes custody of a multicast bundle and then delivers and/or forwards it becomes responsible for all copies of that bundle that it delivers or forwards. In addition, nodes may be branching points for bundles without being custodians for those bundles, so a node that takes custody of a bundle is not only responsible for all copies of that bundle that it delivers or forwards; it also becomes responsible for all copies of the bundle that may be created as a result of downstream branching at other, non-custodial, branching nodes, until the copy is deleted, custody of the copy is transferred to another node, or the copy is delivered. Fulfilling this responsibility for all downstream copies is complicated by the fact that the custodian does not necessarily have any way of knowing whether or how many times a bundle that it forwards will be branched downstream. Therefore, to support custodial delivery of multicast bundles, this document defines mechanisms to enable a custodian of a multicast bundle to determine when all downstream copies of a bundle have either been delivered or have been taken custody of by a downstream node, and to determine when a specific downstream undelivered bundle may need to be retransmitted. In addition, for purposes of conserving bandwidth, it defines a mechanism to enable bundle copies to be reforwarded selectively, to only those downstream branches of the delivery path that have not yet received them, rather than being forwarded indiscriminately to all downstream nodes. Symington, et al. Expires February 13, 2010 [Page 8] Internet-Draft DTN Custodial Multicast Extensions August 2009 3. Objectives, Assumptions, and Design Principles 3.1. Receiver-driven versus Source-driven Multicast Models The protocol extensions described herein have been designed from the perspective of a receiver-driven multicast model. We believe that they are also applicable to a source-driven multicast model, though they might not be optimal for use in a source-driven model. We will explore the applicability of these extensions to source-driven multicast in future revisions of this I-D. A receiver-driven multicast model differs from a source-driven multicast model insofar as in a receiver-driven multicast model, the source node does not necessarily need any knowledge of the number or the identities of the nodes that are members of the multicast endpoint. In a source-driven multicast model, on the other hand, the source node needs to know the identity of each node in the multicast endpoint. In DTN terminology, this means that in a source-driven multicast model, the source node needs to know the EIDs of each of the singleton endpoints in which each of the nodes that are members of the multicast destination endpoint are also members. Because the source in a source-driven multicast transmission knows the identities of the nodes in the multicast destination endpoint, source-driven multicast can include a list of the destination node singleton EIDs in the bundle and use unicast routing information to route the bundle to these destination nodes. Receiver-driven multicast, on the other hand, requires the formation of a multicast tree along which the bundle will be routed from the source to the nodes that are members of the destination multicast endpoint. In terms of the source node being able to have certainty regarding the delivery of bundles delivered via custodial multicast, the source in a source-driven multicast model, because it knows the singleton EIDs of each intended destination node, can be notified as to whether or not each intended destination node actually received a copy of a given multicast bundle. The source in a source-driven multicast model, therefore, is able to determine whether or not all intended recipients of the multicast bundle actually received it. The source node in a receiver-driven multicast model, however, because it is unaware of the number of intended destination nodes and of the singleton EIDs of which they are members, is not able to determine whether all intended recipients of the bundle actually received it. On the other hand, using the receiver-driven model, if a node registers in a multicast endpoint after a bundle has been sent from the source to that endpoint, it is possible for the late-joining node to receive the multicast bundle. Using a source-driven model, however, the source must know the identity of each destination node before the source initiates the bundle transmission. If the source Symington, et al. Expires February 13, 2010 [Page 9] Internet-Draft DTN Custodial Multicast Extensions August 2009 knows the identity of a destination node in advance and includes this destination node in the list of intended recipients, it is possible for this late-joining node to receive the multicast bundle; however, if the source is made aware of an additional destination node to which a multicast bundle should be sent after transmission of the bundle has been initiated, the bundle cannot reach that destination node. A separate, unicast transmission of the bundle would have to be initiated to reach that node. 3.2. Custodial Multicast Objectives The objectives of the custodial multicast extensions defined in this document are to increase the likelihood that -each custodial multicast bundle that is sent will be delivered to as many of its destination nodes as possible prior to bundle expiration and, -if a custodial multicast bundle needs to be re-forwarded in the course of being transmitted from source to destination, the cost of reforwarding it from the custodian (in terms of the routing metric in use) will be less than the cost of reforwarding it from the source node or, ideally, though not necessarily, from any previous custodian nodes. A third objective of custodial multicast delivery, which is not an objective that is addressed in this document, is to enable delivery of bundles to a node whose registration request for the multicast endpoint may be late or delayed. Even though this registration request had not yet propagated through the network sufficiently to graft the destination node onto the distribution tree when the bundle was sent, a custodian of the bundle can forward the bundle toward the late-registering node when the custodian is notified of its registration. If a bundle has a singleton destination EID, then custodial delivery enables it to be stored in the network until the destination node registers to receive it and notification of this registration request is able to propagate to the custodian (providing the bundle doesn't expire first) so that the custodian can forward the bundle toward the destination. Once such a bundle that is sent to a singleton EID reaches the (single) node that registers with that EID, the bundle may be deleted at its current custodian because it will not need to be delivered to any other destination node. If a bundle has a multicast destination EID, on the other hand, there is no inherent limit to the number of such registrations that may be received. Custodians of multicast bundles may store those bundles in the network until they expire in order to ensure that the bundle will be Symington, et al. Expires February 13, 2010 [Page 10] Internet-Draft DTN Custodial Multicast Extensions August 2009 available for forwarding to every node that registers late or the registration request of which is delayed. As pointed out in [refs.wenruiZhao], due to the unique characteristics of frequent partitioning and consequently large transfer delays in DTNs, destination endpoint registration changes during data transfer may be the norm rather than the exception. The protocol extensions defined in this document focus only on defining mechanisms to meet the first two objectives presented above. They do not address the mechanics of re-forwarding multicast bundles to late-registering nodes. 3.3. Assumptions and Design Principles for Custodial Multicast Extensions As discussed in the introduction, these extensions address custodial multicast transmission for the receiver-driven multicast model. A node may be a branching point for a bundle without taking custody of that bundle. It is not feasible to expect or require that every branching point node will always take custody of a bundle. The extensions defined in this document, therefore, take into account the possibility that some branching point nodes may not become custodians of the custodial multicast bundles that they branch. Although we cannot require all branching nodes to become custodians for bundles that they branch, we do require all branching nodes to maintain a small amount of additional state for each custodially- transferred bundle that they branch. Maintaining this state information enables non-custodial branching nodes to keep track of the custody status of each copy of the bundles that they branch. Given that a bundle's custodian has no awareness of the existence of copies of the bundle that are created at non-custodial branching nodes downstream of it, the non-custodial branching nodes must act as "proxy custodian" in the sense that they must keep track of the custody status of each copy they create and in turn report this status upstream to the bundle's actual custodian. Custodial branching nodes must store a copy of the bundle, re-forward it if necessary, and maintain custody state per bundle copy that they branch rather than just per bundle (as currently defined in the Bundle Protocol). Non-custodial branching nodes are not required to retain a copy of the bundle or re-forward it, but they are, like custodial nodes, required to maintain custody state per bundle copy that they branch (see Section 5 and Section 8.2.1). If a node's forwarding information indicates that it must branch a multicast bundle but it does not have the storage capacity or other Symington, et al. Expires February 13, 2010 [Page 11] Internet-Draft DTN Custodial Multicast Extensions August 2009 resources necessary to pose as a proxy custodian by maintaining custody state per copy of the bundle that it branches then the node must report this difficulty to the previous upstream custodian or proxy custodian and it must not deliver or forward the bundle as a custodially transferred bundle (see Section 8.2.1). Unless a custodian is going to re-forward a bundle when needed, the custodian cannot be of any use in helping to achieve the two objectives that we have identified as our objectives for custodial multicast. Therefore, the extensions we define must include not only the capability to re-forward a multicast bundle when necessary, but the ability to determine when re-forwarding is necessary. In the singleton case, a custodian may receive an explicit notification (in the form of a "Failed" custody signal) or an implicit notification (in the form of an expired custody timer) that it should retransmit a bundle. In the singleton case, a custodian may also receive explicit notification (in the form of a "Succeeded" custody signal) when a bundle of which it has custody has been either delivered or taken custody of by another node. When enough time has elapsed, as measured by the custody timer timing out, during which the custodian has not received a "Succeeded" custody signal for a bundle, the custodian may re-forward the bundle. In the multicast case, in order for the custodian of a multicast bundle to know whether or not it needs to re-forward that bundle, the custodian need not necessarily know the delivery status of each downstream copy of the bundle. It does, however, need to know whether or not there is at least one downstream copy of the bundle that has not yet been delivered or taken custody of. If there is, and the custody timer for that copy expires, the custodian must re- forward the bundle copy downstream to at least the next-hop node(s) with which the expiring timer is associated. A major component of the extensions that we are defining, therefore, is a mechanism by which a custodian can be notified when all downstream copies of a bundle for which it is custodian have either been delivered or taken custody of. A second component is a mechanism whereby the custodian can be explicitly notified of an undelivered downstream copy of a bundle that has been deleted. In our extensions, analogous to the way that custody signals operate for the singleton case in the Bundle Protocol, receipt of a "Succeeded" custody signal for all copies of the bundle that a custodian has branched indicates that all downstream copies have either been delivered or taken custody of. Failure to receive a "Succeeded" custody signal before a custody timer times out indicates that one or more bundle copies associated with that timer has not yet been delivered or taken custody of (and thus may need to be retransmitted). Receipt of a "Failed" custody signal indicates that the referenced bundle copy was deleted before being delivered or taken custody of (and thus may need to be Symington, et al. Expires February 13, 2010 [Page 12] Internet-Draft DTN Custodial Multicast Extensions August 2009 retransmitted). There is an inherent tradeoff between robustness of delivery and bandwidth conservation when custody transfer is requested for a multicast bundle. These extensions give bandwidth conservation priority over robustness of delivery by default, but local policy may override this. Unless overridden by local policy that specifically attempts to adapt the multicast delivery path in response to network dynamism, custodians and non-custodial branching nodes, by default, should not forward a multicast bundle copy for which a successful custody signal has already been received. Bundles should only be re- forwarded to those next-hop nodes that have downstream copies of the bundle that have not yet been delivered or taken custody of. Because the multicast delivery path is assumed to be a tree (see Section 4), if a node receives a bundle of which it is currently custodian, the bundle is assumed to be in an unintentional loop and must be dropped without sending any concomitant custody signal to the asserted custodian of the received bundle. For a more detailed discussion of the objectives, assumptions, and design principles underpinning these protocol extensions for supporting custodial multicast, see [refs.IEEEcustMcast]. Symington, et al. Expires February 13, 2010 [Page 13] Internet-Draft DTN Custodial Multicast Extensions August 2009 4. Multicast Routing Protocol Requirements and Desired Features In order for the custodial multicast extensions defined in this document to work correctly, the multicast routing protocol that is used to set up the delivery path for custodial multicast bundles must meet certain requirements, which are discussed in the following subsections. 4.1. Only CMC-nodes may be branching points As discussed in Section 3.3 and Section 5.2, non-custodial branching nodes are required to have the capability to maintain state information per bundle copy that they branch. Because this special capability is required of all branching nodes, in order for custodial multicast transfer to work correctly, either: -the network used for custodial multicast delivery must consist only of CMC-nodes, or -the multicast routing protocols responsible for delivery path formation must be capable of distinguishing CMC-nodes from non- CMC-nodes and they must enforce the restriction that only CMC- nodes are permitted to be branching points. If there are nodes that serve as branching points for multicast bundles that do not have the capabilities defined in this document, the custody transfer procedures defined in this document will not work correctly. Therefore, in order to support custodial multicast in a network that consists of both CMC and non-CMC nodes, the multicast routing protocols used must enforce the restriction that only CMC nodes are permitted to be branching points in the delivery path. In order for multicast routing protocols to be able to distinguish CMC-nodes from non-CMC-nodes, when CMC-nodes register, they must make known their status as CMC-nodes and this information regarding their status as CMC-nodes must be propagated along with the registration information among the nodes that participate in multicast routing. 4.2. Every bundle copy must be able to be individually accounted for The extensions defined herein are based on the principle that if a bundle is branched because branching is required to enable the bundle to reach two different destination nodes, then both the original bundle and the branched bundle must be acknowledged with a successful custody signal. On the other hand, if a bundle is branched but both the original bundle and the branched bundle are destined for the same destination node, then only one of these copies of the bundle must be acknowledged with a successful custody signal. If a branching node Symington, et al. Expires February 13, 2010 [Page 14] Internet-Draft DTN Custodial Multicast Extensions August 2009 forwards two copies of a bundle that are not distinguishable from each other and some custodial downstream node receives both of these copies at the same time, then one of the copies will be deleted and will not be acknowledged with a successful custody signal. The custodian that had branched the bundle will received only one successful custody signal and, assuming it is expecting two, it will retransmit the unacknowledged bundle copy unnecessarily. On the other hand, if a branching node forwards two copies of a bundle that are distinguishable from one another and some custodial downstream node receives both of these copies at the same time, then because these copies are distinguishable the receiving node may generate two successful custody signals--one for each copy of the bundle that it receives. The extensions defined herein require that every bundle copy that is destined for its own destination node (such that no other bundle copy is destined for that same destination node) must be able to be individually accounted for in terms of custody signaling. This requirement may be achieved in one of two known ways: -DTN multicast routing protocols must operate over trees rather than meshes such that a multicast delivery path is always a tree. If the multicast distribution path is guaranteed to be a tree, then it is necessarily the case that every copy of a bundle that is branched is destined for its own destination node and the extensions defined herein are correct in requiring each copy to be acknowledged with a successful custody signal. Any copy that is not acknowledged with a successful custody signal must necessarily be retransmitted until it a successful custody signal is received for it. -Every bundle copy that is created must contain a unique custodian EID, and nodes receiving two copies of the same bundle that are identical except for their custodian EID fields must send a separate successful custody signal for each copy of the bundle that they receive (to be sent to the EID in the bundle's custodian EID field). In this case, if the multicast distribution path is a mesh rather than a tree, there is no danger that a bundle copy that is received will not be acknowledged with a successful custody signal in the event that the receiving node already has custody of a copy of that bundle that was received earlier, because the earlier copy will have a distinct custodian EID from the recently received copy. Note that this second method of ensuring that each bundle copy will be acknowledged requires receiving nodes to be able to distinguish between two copies of the same bundle that have different custodian EID values, but that are otherwise identical. This is a capability over and above what is required of basic bundle nodes in the Bundle Protocol Symington, et al. Expires February 13, 2010 [Page 15] Internet-Draft DTN Custodial Multicast Extensions August 2009 specification. 4.3. If convergence layer multicast is used, the forwarding node must know the number of next-hop recipient nodes If DTN multicast is running over an underlying convergence layer protocol that has inherent best-effort multicast transmission capabilities (e.g. a Local Area Network) and DTN multicast endpoint IDs are associated with underlying convergence layer multicast addresses, a bundle received at a DTN endpoint ID that is bound to an underlying convergence layer multicast address could in turn be multicast out toward its multiple destinations using that convergence layer. Using the best-effort multicast capabilities provided by some convergence layers, there is no way for the forwarder of such a multicast bundle to know in advance the expected number of recipients. Although from the standpoint of the DTN bundle protocol agent only a single copy of a bundle is being sent on a particular multicast-capable convergence layer, in effect there are multiple next-hop nodes that this single copy is intended to reach. When a best-effort multicast-capable convergence layer is used to distribute DTN multicast bundles such that the forwarding node does not know the number of expected next hops that are reachable via the convergence layer, it is impossible for the bundle's custodian to know if and when all destinations have received the bundle. If unicast forwarding is being used on a given convergence layer, the receipt of a "Succeeded" custody signal associated with a particular bundle copy forwarded using that convergence layer means that all downstream copies of that copy have been either delivered or taken custody of. If multicast forwarding is being used on a given convergence layer then, although only a single bundle is being forwarded, this bundle may have multiple next hops. Therefore, in order for such a configuration to be able to be used to support custodial multicast, the bundle node that is forwarding the bundle onto the convergence layer: -must be a CMC-node, and -must know the number of next-hop nodes that the bundle is expected to reach using that convergence layer, so that it can maintain state for this number of copies. 4.4. CMC nodes should keep track of de-registration requests in order to be able to distinguish delayed de-registrations from routing failures In the same way that there is a delay between when a node registers and when that registration propagates through the network to graft Symington, et al. Expires February 13, 2010 [Page 16] Internet-Draft DTN Custodial Multicast Extensions August 2009 that node onto the distribution tree, there may also be a delay between when a node de-registers with a multicast EID and when that de-registration propagates through the network to prune that node from the distribution tree. As a result, a situation may arise in which a de-registration request has reached some nodes but not others such that a bundle could be forwarded by a custodian (which has not yet received notice of the de-registration request) and later received at some downstream non-branching node (which has received the de-registration request) that does not have any next-hop nodes to which the bundle should be forwarded (because the node that recently de-registered was the only node downstream of this node that had been in the multicast endpoint). In this situation, the bundle cannot be forwarded because there is no known route to its destination. Nor should it be forwarded, because there is no longer an intended destination downstream of it. If the node at which this situation occurs has kept track of the fact that it received a de-registration notification for the multicast EID in question, it can distinguish this type of situation from a real routing failure. Instead of sending a "Failed" custody signal, the node that cannot forward the bundle because a downstream node has recently de-registered from the multicast EID should send a "Succeeded" custody signal for this multicast bundle, because a "Succeeded" custody signal indicates that there are no remaining copies of the bundle downstream of this node that need to be either delivered or taken custody of. If the node at which this situation occurs has not kept track of the de-registration notifications it has received and so cannot distinguish this situation from a real routing failure, it will send a "Failed" custody signal for this multicast bundle to the bundle's current custodian, and the custodian will re-forward the bundle toward the node at which the routing failure occurred. Eventually either the bundle will time out or the de-registration request notification will propagate to a branching point upstream such that the routing failure will no longer exist. Hence, having nodes in the multicast distribution tree keep track of de-registration requests is not required in order for the custodial multicast extensions to work correctly, but it does optimize bandwidth conservation by eliminating unnecessary custody signal transmissions and bundle retransmissions on the affected branches of the distribution tree. State on de- registration request notifications received does not have to be maintained indefinitely at any given node. De-registered endpoint IDs may be stored with a record of the time at which the de- registration request notification was received. The de-registered endpoint ID may be deleted from the state information when enough time has elapsed to allow the de-registration request to reasonably be assumed to have propagated through the network. Again, if this amount of time is not estimated correctly and the de-registered endpoint ID is deleted too soon from the state information, custody transfer will still work correctly; it will just not be optimized to Symington, et al. Expires February 13, 2010 [Page 17] Internet-Draft DTN Custodial Multicast Extensions August 2009 conserve bandwidth. Symington, et al. Expires February 13, 2010 [Page 18] Internet-Draft DTN Custodial Multicast Extensions August 2009 5. Overview of Mechanisms for Supporting Custodial Multicast The following are circumstances under which a custodian may want to re-forward a multicast bundle: -The custodian received a "Failed" custody signal for the bundle from a specific node, in which case it wants to retransmit the bundle to that node (and, assuming the network is relatively stable, it may want to conserve bandwidth by encapsulating [refs.Encaps] the multicast bundle in a singleton bundle for bandwidth-efficient transmission to the node that originally generated the "Failed" custody signal; this node can then de- encapsulate the multicast bundle and forward it further), or -One or more of the custodian's custody timers for the bundle timed out, in which case it wants to re-forward the bundle on (at least) all downstream branches of the distribution path that are associated with the expiring timer(s). -Notification of a new or delayed registration for a multicast EID is received. The protocol extensions defined in this document do not address the third circumstance listed above: re-forwarding bundles to newly- registering or delayed-registration nodes. They do, however, address the first two circumstances listed above by ensuring that the custodian will be able to: -receive "Failed" custody signals for arbitrary bundle copies from nodes downstream in the delivery path -be aware of whether or not there exists a downstream copy of that bundle that has not been delivered or taken custody of when its custody timer times out. Custody status notification is provided to each custodian of a multicast bundle in the same way that it is provided to each custodian of a singleton bundle: by having downstream nodes send either "Succeeded" or "Failed" custody signals to the custodian, as appropriate. In the multicast case, however, the custodian must keep track of the custody status of each copy of each bundle it forwards. When the custodian receives a "Succeeded" custody signal for each of the copies that it branched, the custodian is assured that every downstream copy has either been delivered or taken custody of. Until the custodian receives such a signal for any given copy that it forwarded, it must assume that there is at least one copy of the bundle on that copy's branch of the distribution tree that has neither been delivered nor taken custody of. Symington, et al. Expires February 13, 2010 [Page 19] Internet-Draft DTN Custodial Multicast Extensions August 2009 Although the custodian expects one "Succeeded" custody signal per bundle copy that it branched, there may be more copies of the bundle created downstream of it. These copies, however, must be kept track of by the non-custodial branching nodes that create them. When all copies created by a non-custodial branching node have either been delivered or taken custody of, the branching node sends a "Succeeded" custody signal to report this to the bundle's previous upstream custodian or non-custodial branching node, and so forth, until the status of every copy that the custodian branched is reported to the custodian. There is no need for the custodian itself to be made aware of every copy of the bundle that is created downstream of it. To achieve this "relayed" custody signal transmission, every non- custodial node that is a branching point for a multicast bundle, upon receipt of that bundle, takes note of its current custodian and then places its own EID into the bundle to list itself as custodian for that bundle before forwarding the bundle (even though it really is not the custodian of the bundle in the sense that it is not storing a copy of the bundle in permanent storage, nor does it consider itself responsible for retransmitting the bundle). In this way, each branching point node is assured that it will receive any custody signals that may be generated for the bundle copies that it branches. Note that in order for custody signals to be received at custodians, there must be connectivity from the node that is generating the custody signal back to the custodian. This is true for the custody transfer of both singleton and multicast bundles. In the multicast case, there must also be connectivity from the node that is generating the custody signal back to its nearest upstream proxy custodian (if there is one), and from each proxy custodian to its nearest upstream proxy custodian and so forth to the real custodian. If this connectivity does not exist, the protocol will still work, but the custodian may issue one or more custodial retransmissions that are unnecessary and therefore wasteful of bandwidth. Non-CMC and CMC nodes alike are permitted to originate and deliver custodial multicast bundles, to register in multicast EIDS, and to forward custodial multicast bundles to a single next-hop node. As is made clear in the Bundle Protocol, however, non-CMC nodes, are not permitted to take custody of multicast bundles. In order for a node to be able to become a custodian for a multicast bundle, the node must implement the procedures defined in this specification, which make it a CMC node. In addition, nodes that implement only the base bundle protocol are not permitted to be branching points in the distribution path for a custodially-transferred multicast bundle. In order for a node to be able to be a branching point in the distribution path of a custodially-transferred multicast bundle, the node must be a CMC Symington, et al. Expires February 13, 2010 [Page 20] Internet-Draft DTN Custodial Multicast Extensions August 2009 node. The following sub-sections discuss the specific responsibilities that CMC-nodes must fulfill in order to act as custodians or branching points in support of the delivery of custodial multicast bundles. 5.1. Special Responsibilities of Custodial Nodes When a CMC-node becomes custodian of a multicast bundle, that custodial node takes on responsibilities similar to those that are taken on by a custodian of a singleton bundle. The main difference, however, is that the custodian of a multicast bundle must maintain custody-related state information per copy of that bundle that it branches rather than just per bundle. Specifically, the custodian of a given multicast bundle: -MUST maintain a list of the copies of that bundle that it has branched along with the EID/convergence layer to which each copy was delivered or forwarded. -MUST keep track of which of these copies for which it has received a "Succeeded" custody signal. -MUST retain the multicast bundle that it takes custody of--in persistent storage if possible-- until the bundle expires or (assuming that accommodating late- or delayed-registering destination nodes is not a concern) until it receives a "Succeeded" custody signal for each of the copies of the bundle that it branched (which indicates that all downstream copies of that bundle have either been delivered or taken custody of). -MUST maintain at least one retransmission timer for the bundle; possibly one timer per copy it has branched. -SHOULD retransmit the copy (or copies) of the bundle corresponding to the retransmission timer when the retransmission timer expires. -SHOULD retransmit a copy of the bundle referred to by a received "Failed" custody signal, perhaps encapsulated (see [refs.Encaps]) in a unicast bundle sent to the "Failed" signal's source. -MUST destroy a retransmission timer when "Succeeded" custody signals for all bundle copies associated with that timer have been received -MUST delete a multicast bundle and all its associated custodial state information when the bundle expires Symington, et al. Expires February 13, 2010 [Page 21] Internet-Draft DTN Custodial Multicast Extensions August 2009 5.2. Special Responsibilities of (Non-Custodial) Branching Nodes If a node is a branching point for a custodial multicast bundle but it does not take custody of that custodial multicast bundle, the node must pose as a proxy custodian by inserting its own EID into the custodian field of the bundle so that it will receive custody signals (if sent) for all copies of the bundle that it branches. In particular, in order to support custodial delivery of a multicast bundle, a non-custodial branching node: -MUST maintain a list of the copies of that bundle that it has branched along with the EID/convergence layer to which each copy was delivered or forwarded. -MUST keep track of the "Succeeded" custody signals received. -MUST notify the appropriate upstream node (e.g. the node that had been listed as the bundle's custodian when the bundle was received, which is either the bundle's "real" custodian or the most recent proxy custodian that may in turn pass the signal upstream until it eventually reaches its real custodian) when a "Succeeded" custody signal is received for all of the copies of the bundle that it branched (which indicates that all downstream copies of that bundle have either been delivered or taken custody of). -If custody transfer failure is reported for any of the downstream copies that the bundle branched, the non-custodial branching node MUST generate a replacement "Failed" custody signal and send it to the appropriate upstream node, inserting a Proxy EID extension block (see Section 7) into this bundle (if there is not one in there already) that identifies the endpoint of the source of the original "Failed" custody signal. (If custody transfer failure is reported for multiple downstream copies that the bundle branched, the non-custodial node may aggregate these by inserting multiple corresponding Proxy EID extension blocks, each of which identifies a different source node, into the replacement "Failed" custody signal that it generates and sends to the appropriate upstream node.) -Upon receipt of a custodial multicast bundle, determine not only to which next-hop nodes the bundle should be forwarded in order to reach all of the nodes in its multicast endpoint, but also from which of these next-hop nodes (if any) the branching node has already received a "Succeeded" custody signal for this bundle. By default, but subject to network stability conditions and local policy, the bundle SHOULD be forwarded to only those next-hop nodes for which a "Succeeded" custody signal for the bundle has Symington, et al. Expires February 13, 2010 [Page 22] Internet-Draft DTN Custodial Multicast Extensions August 2009 not been received. (Forwarding the bundle to only those next-hop nodes for which a "Succeeded" custody signal for the bundle has not yet been received rather than to all next-hop nodes is an optimization for bandwidth conservation purposes; it is not a requirement.) -If the node does not have sufficient resources to maintain the state information required of it in order for it to branch a particular multicast bundle, it MUST send a "Failed" custody signal to the appropriate upstream node. It MAY (subject to policy) reset the custody transfer requested bit and branch the bundle. If the branching node resets the custody transfer requested bit and branches the bundle, the reason code in the "Failed" custody signal MUST be the new reason code, "Bundle Forwarded Non-Custodially". If the branching node does not reset the custody transfer requested bit and branch the bundle, the reason code in the "Failed" custody signal MUST be "Depleted Storage". In addition, if the node's resource depletion is expected to last a while, the node MAY change the way it represents itself to the multicast routing protocol (subject to the specifics of that protocol), thereby actively seeking to not be a branching point in any multicast distribution paths that are set up by that routing protocol. Symington, et al. Expires February 13, 2010 [Page 23] Internet-Draft DTN Custodial Multicast Extensions August 2009 6. Identifying Bundle Copies A main purpose of multicasting a bundle to several destination nodes rather than unicasting the bundle to each of those nodes individually is to conserve bandwidth. In keeping with this objective of bandwidth conservation, as mentioned in Section 3, if there is a custody transfer failure of one downstream copy of a bundle whereas all other downstream copies of that bundle have had successful custody transfers or deliveries, it would conserve bandwidth to retransmit the bundle only along those branches of the downstream delivery path that are necessary for the bundle to reach the node at which the custody transfer failure occurred, rather than having that bundle traverse all downstream branches of the delivery tree--even those leading to nodes that have already successfully taken custody of or delivered the bundle. Performing such bandwidth optimization, however, requires branching nodes to be able to distinguish the various copies of a given bundle that they deliver or forward from each other, so that when a custody signal is received, the receiving node can determine not only which bundle it refers to, but which particular copy of the bundle that was branched it refers to. Furthermore, in order to perform bandwidth-efficient retransmissions that target only those next-hop nodes that still have downstream copies of the bundle for which "Succeeded" custody signals have not been received, the node receiving a custody signal must be able to determine to which next-hop node the particular copy of the bundle referred to by that signal had been forwarded. Because we cannot rely on the fact that the custody signal for a given bundle copy will always be returned via the same route along which the bundle was forwarded, the requirement that branching nodes be able to distinguish among bundle copies requires the branching node to somehow mark each bundle copy uniquely. This marking could be accomplished using a to-be-defined bundle extension block, but such a technique would require each branching node to add such a block, thereby adding to the size of the bundle. It would also require that procedures be defined for determining when these blocks could be deleted from the bundle, and in general it would complicate the protocol. Instead, we recommend that a certain portion of the EID that the branching node inserts into the bundle's custodian field be used as a copy identifier. For example, suppose a node is forwarding a multicast bundle to two different next-hop nodes. This forwarding node could be registered in two singleton EIDs, e.g., NodeA:1 and NodeA:2 and it can be uniquely identified by only the scheme name (e.g., "NodeA:") portion the EID [refs.URI]. The forwarding node places EID "NodeA:1" in the current custodian field of the bundle that it forwards to the first next-hop node and EID "NodeA:2" in the current custodian field of the bundle that it forwards to the second next-hop node. When it receives a custody signal back for this bundle, it can use the EID to which the signal was sent to determine Symington, et al. Expires February 13, 2010 [Page 24] Internet-Draft DTN Custodial Multicast Extensions August 2009 to which copy of the bundle the signal refers. This technique of distinguishing the multicast bundle copies from each other is conserving of both bandwidth and protocol complexity. Ideally, it would be defined as part of the multicast EID naming scheme and integrated with the routing protocols to the extent that only one registration per node would have to be propagated because only a certain portion of the EID would be used to route to each node. Note, however, that as topology changes, new EIDS would need to be created to accommodate newly-discovered/encountered neighbors, and old EIDs would not be able to be recovered until after the latest expiration time of any bundle containing that EID. Hence, branching nodes that use this technique to distinguish among bundle copies would also have to keep track of the largest expiration time of the bundles associated with each next-hop EID. Note also that depending on the type of convergence layer being used to forward the bundle copy, the bundle copy may no longer be identified uniquely when it is received at its next-hop node. If a copy is forwarded on a unicast convergence layer, then it is expected to be received at exactly one next-hop node, and the EID placed in the current custodian field, for example, can be used to identify it uniquely both when it is forwarded and when it is received. If a copy is forwarded over a multicast convergence layer, however, then the EID that is placed in the current custodian field is only guaranteed to identify the copy uniquely when the copy is forwarded; there is no guarantee that this copy will still be uniquely identified by that current custodian EID when it is received, because it may be received at multiple next-hop nodes and thereby become several different copies, all of which have the same EID in the current custodian field. Therefore, if a custodial multicast bundle is forwarded over a multicast convergence layer, the forwarding node must know the number of next-hop nodes to which it is destined (as discussed in Section 4.3). The EID placed in the current custodial field will be the same in each copy of the bundle received at these next-hop nodes. Therefore, for purposes of keeping track of "Succeeded" custody signals received, the forwarding node must expect the appropriate number of custody signals referring to bundles with this particular current custodian EID. For purposes of retransmission as a result of the custody timer associated with these copies timing out or as a result of the receipt of a "Failed" custody signal associated with one of these copies, a copy re-forwarded on the multicast convergence layer will reach all next-hop nodes that are reachable via that convergence layer and will not be targeted to reach any specific one of these next-hop nodes in particular. Symington, et al. Expires February 13, 2010 [Page 25] Internet-Draft DTN Custodial Multicast Extensions August 2009 7. Proxy EID Extension Block This section defines the format of the Proxy EID Extension Block that a proxy custodian inserts into a "Failed" custody signal to inform the real custodian that eventually receives the "Failed" signal (or a replacement of the "Failed" signal) the endpoint ID of the node that was originally the source of the "Failed" signal. A bundle may contain multiple Proxy EID Extension Blocks, each of which identifies a node that was the source of a "Failed" custody signal for the identified bundle. For more discussion of when this block is inserted into a bundle containing a "Failed" custody signal and how it is processed, see Section 8.2.10. The Proxy EID Extension Block uses the Canonical Bundle Block Format as defined in the Bundle Protocol [refs.DTNBP]. That is, it is comprised of the following elements: -Block-type code (one byte) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). The block type code for the Proxy EID Extension Block is 0x06 -Block processing control flags (SDNV) - defined as in all bundle protocol blocks except the primary bundle block (as described in the Bundle Protocol). SDNV encoding is described in the bundle protocol. In order for custodial multicast transfer to be supported correctly in a network that consists of a mixture of CMC-nodes and non-CMC-nodes, the following block processing control flags MUST NOT be set: -Discard block if it can't be processed. -Discard bundle if block can't be processed. The following block processing control flag MUST be set: Block contains an EID-reference field. -EID references - composite field defined in [refs.DTNBP] containing references to one or more EIDs. Presence of EIDs is indicated by the "block contains an EID-reference field" flag in the block processing control flags, which must be set to 1. Each of the EIDs referenced in this field identify a node that originally generated a "Failed" custody signal for the indicated bundle. The sequence of the EIDs reference in this field correlates with the sequence of custodial signal information records that appears later in this block, insofar as the node identified by a given EID reference generated a "Failed" custody Symington, et al. Expires February 13, 2010 [Page 26] Internet-Draft DTN Custodial Multicast Extensions August 2009 signal for the indicated bundle with a custody signal reason code and generation time as indicated by the corresponding custody signal information record. -Block data length (SDNV) - defined as in all bundle protocol blocks except the primary bundle block. SDNV encoding is described in the bundle protocol. -Block-type-specific data field as follows: -Ordered sequence of custody signal information records, where a custody signal information record is defined to consist of a (1-byte) status field followed by a (DTN time) Time of signal field. These fields are as defined in the Custody Signals section of the Bundle Protocol [refs.DTNBP]. The Structure of a Proxy EID Extension Block is as follows: Proxy EID Extension Block Format: +-------+--------------+------------------------------+-----------+ | Type |Flags (SDNV) |EID ref count and list (comp) |Len (SDNV) | +-------+--------------+------------------------------+-----------+ |Status | Time of signal (a DTN time) | +-------+---------------------------------------------------------+ Figure 1 Symington, et al. Expires February 13, 2010 [Page 27] Internet-Draft DTN Custodial Multicast Extensions August 2009 8. Bundle Protocol Extensions to Support Custody Transfer and Retransmission for Multicast Bundles The Bundle Protocol defines custody transfer and retransmission only for singleton bundles. Nodes that implement only the bundle protocol are not capable of generally supporting the custody transfer and retransmission of multicast bundles. They are only capable of supporting the custodial delivery of multicast bundles if they serve neither as custodians nor as branching points in the delivery path. The sections below define the custody transfer and retransmission capabilities that a node must have in order to be CMC and to therefore be capable of supporting custodial transfer and retransmission for multicast bundles regardless of where that node is located in the delivery path. All nodes that are going to either take custody of a multicast bundle or serve as a branching point of a multicast bundle must implement not only the Bundle Protocol but also the following extensions to the Bundle Protocol in order to be able to support custodial multicast. Nodes that are neither custodians nor branching points may participate in the delivery of custodial multicast bundles without implementing these extensions. If custodial multicast is to be supported in a network that consists of both CMC nodes and non-CMC nodes, the multicast routing protocol is required to build the distribution path with only CMC nodes as branching points. 8.1. Definitions Custody - Custody of a bundle whose destination is a multicast endpoint is released when notification is received for each copy of the bundle that was delivered or forwarded by the custodian that some other node has accepted custody of the copy, the copy has been delivered at some destination node, or the bundle has been explicitly deleted for some reason, such as lifetime expiration. 8.2. Bundle Processing Steps for Custodial Multicast Bundles The specific steps for processing a custodial multicast bundle at each node are defined as follows. 8.2.1. Bundle Forwarding This section augments the Bundle Forwarding section of the Bundle Protocol [refs.DTNBP]. It defines those steps for forwarding bundles that are specific to custodial multicast bundles. If the bundle will be forwarded to more than one next-hop node and the forwarding node has not accepted custody of the bundle, then the Symington, et al. Expires February 13, 2010 [Page 28] Internet-Draft DTN Custodial Multicast Extensions August 2009 node MUST determine if it has sufficient resources to serve as a branching point for the bundle. If it cannot serve as a branching point, the node MUST send a "Failed" custody signal to the upstream node that is listed as the bundle's custodian (which is either the "real custodian" or the most recent proxy custodian that will in turn pass the signal upstream until it eventually reaches the real custodian). It may also (subject to policy) reset the custody transfer requested bit and deliver and/or forward the bundle. If the branching node is delivering or forwarding the bundle (non- custodially), the reason code in the "Failed" custody signal must be the new reason code, "Bundle Forwarded Non-Custodially". If the branching node is not delivering or forwarding the bundle, the reason code in the "Failed" custody signal must be "Depleted Storage". If the node does have sufficient resources to enable it to serve as a non-custodial branching point, then: -The node must note the endpoint ID of the bundle's current custodian and store it with the custodial state information associated with the bundle. -The node must change the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. In order to be able to identify each copy uniquely and associate each copy of the bundle with the next-hop node to which it will be delivered or forwarded, the node should use a separate custodian endpoint ID for each copy of the bundle that it delivers or forwards. Alternatively, it may mark the copy in some other as-yet-undefined way. (Note that if the node is forwarding a copy on a multicast convergence layer and this copy is expected to reach multiple next-hop endpoints, each of the copies received at each of these next-hop nodes will have the same custodian EID.) -The node must also keep track of whether the bundle is being delivered and each of the copies that is being forwarded (both explicit copies and copies that may be engendered by the use of a multicast convergence layer), along with whether or not a "Succeeded" custody signal has been received corresponding to each of these copies. (If a copy is being forwarded on a unicast convergence layer, a single custody signal related to that copy is expected. If a copy is forwarded on a multicast convergence layer, n custody signals associated with that copy are expected, where n is the number of next-hop nodes reachable via that convergence layer in the delivery tree.) In all, the custodial state information that a non-custodial branching point node is required to maintain for each multicast Symington, et al. Expires February 13, 2010 [Page 29] Internet-Draft DTN Custodial Multicast Extensions August 2009 bundle for which it is a branching point consists of: -an indication of whether or not the bundle was delivered at this node, -a list of the next-hop EIDs to which the bundle was forwarded (including the number of next-hop nodes associated with each EID for those next-hop EIDs that are reachable via multicast convergence layers) -a list of the next-hop nodes for which a corresponding "Succeeded" custody signal has been received, and -the endpoint ID that was in the current custodian field of the bundle when it was received. -the largest expiration time of all bundles associated with each next-hop EID (to ensure uniqueness when recovering custodian EID values to be used to distinguish among bundle copies). This custodial state information must be maintained for each branched bundle until the bundle expires or until the node itself sends a "Succeeded" custody signal for the bundle to the endpoint ID that was in the current custodian field of the bundle when it was received, at which time the information may be deleted. Note that even though the branching node is not becoming a true custodian for a given multicast bundle, it is inserting its own endpoint ID into the custodian field before forwarding the bundle, so that it may receive either a "Succeeded" or a "Failed" custody signal for each copy of the bundle that it forwards. If a node that is not the custodian of the multicast bundle receives a "Succeeded" custody signal, this MUST be noted in the custodial state information for the bundle, relative to the next-hop branch from which the custody signal was received. The processing steps to be taken next may be determined by policy, which would be influenced by network stability characteristics and would involve the tradeoff between bandwidth conservation versus robustness of delivery. In the absence of a policy to the contrary, custodial multicast is assumed to favor bandwidth conservation over robustness of delivery. So by default, when a bundle is received, the node must consult its custodial state information to determine for which of the next-hop endpoints to which it should be forwarded, if any, the node has already received a "Succeeded" custody signal for the bundle. If the bundle has already been delivered at this node and a "Succeeded" custody signal received back confirming this delivery, the bundle should not be delivered again. Similarly, the Symington, et al. Expires February 13, 2010 [Page 30] Internet-Draft DTN Custodial Multicast Extensions August 2009 bundle should not be re-forwarded to any next-hop endpoints for which all expected "succeed" custody signals have already been received for this bundle, because the prior receipt of either of these signals indicates that at some previous time there were no longer any copies of the bundle downstream of that next-hop endpoint that needed to be either delivered or have their custody transferred. If a policy to the contrary is in place that favors robustness of delivery over bandwidth conservation, then when a bundle is received, it should be forwarded out to all next-hop endpoints, even if it has previously been forwarded to some of those endpoints and "Succeeded" custody signals corresponding to one or more of those endpoints have been received back. 8.2.2. Forwarding Contraindicated This section augments the Forwarding Contraindicated section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for handling a forwarding contraindication for a bundle whose destination is a multicast endpoint. As described in [refs.wenruiZhao], there is a delay, which in a DTN could potentially be substantial, between when a node registers with a multicast EID and when that registration propagates fully throughout the network. (Although [refs.wenruiZhao] discusses this potentially substantial delay in terms of multicast EIDs, it exists relative to registration requests for singleton EIDs as well.) Analogously, there may also be a substantial delay between when a node de-registers with a (multicast or singleton) EID and when that de-registration propagates fully throughout the network. As a result, it might not be uncommon for a situation to arise in which a de-registration request has reached some nodes but not others such that a bundle could be forwarded by a custodian (which has not yet received notice of the de-registration request) and later received at some downstream node (which has received the de-registration request) that does not have any next-hop nodes to which the bundle should be forwarded (because the node that recently de-registered was the only node downstream of this node that had been in the multicast endpoint). In this situation, forwarding of the bundle is determined to be contraindicated because of the "No known route to destination from here" reason listed in the Status Report Reason Codes of the Bundle Protocol specification [refs.DTNBP]. According to the Bundle Protocol specification, the bundle protocol agent must determine whether or not to declare a failure in forwarding in this case. If the bundle protocol agent at which this situation occurs has recorded the fact that it recently received a deregistration request notification for the EID in question, it can distinguish this forwarding contraindication from a forwarding failure. Instead of Symington, et al. Expires February 13, 2010 [Page 31] Internet-Draft DTN Custodial Multicast Extensions August 2009 declaring a forwarding failure, the bundle protocol agent should send a "Succeeded" custody signal for this multicast bundle. A "Succeeded" custody signal indicates that there are no remaining copies of the bundle downstream of this node that need to be either delivered or taken custody of. In order to be able to distinguish this type of forwarding contraindication from a forwarding error, bundle protocol agents should keep track of de-registration request notifications received in addition to registration request notifications received. If the bundle protocol agent at which this situation occurs is not recording the de-registration request notifications it receives, it will not be able to distinguish this situation in which forwarding is contraindicated because a downstream node has recently de-registered from the bundle's destination endpoint from a real forwarding failure. Hence, it will declare a forwarding failure and will notify the custodian of the bundle of a custody transfer failure, possibly triggering a custodial retransmission of the bundle. 8.2.3. Forwarding Failed This section augments the Forwarding Failed section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for handling forwarding failure for a bundle whose destination is a multicast endpoint. Procedures for handling failure of custody transfer for a custodial multicast bundle are the same as those for a singleton bundle: the bundle protocol agent MUST generate a "Failed" custody signal for the bundle, destined for the bundle's current custodian; the custody signal MUST contain a reason code corresponding to the reason for which forwarding was determined to be contraindicated. 8.2.4. Bundle Reception This section augments the Bundle Reception section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for handling redundancy of custody transfer for a bundle whose destination is a multicast endpoint. step 1: When a custodial multicast bundle is received, if the bundle has the same source EID, creation timestamp, fragment offset and length (if any), and custodian EID as a bundle that the receiving node is currently custodian of, then by default the bundle's "Dispatch pending" retention constraint SHOULD be removed and the node SHOULD NOT send a "Succeeded" custody signal for this bundle. If the custodian EID of the received multicast bundle is different from that of the otherwise identical bundle of which the receiving Symington, et al. Expires February 13, 2010 [Page 32] Internet-Draft DTN Custodial Multicast Extensions August 2009 node is currently custodian, however, then the bundle's "Dispatch pending" retention constraint MUST be removed and the node MUST send a "Succeeded" custody signal for this bundle. 8.2.5. Local Bundle Delivery This section augments the Local Bundle Delivery section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for reporting custodial delivery for a bundle whose destination is a multicast endpoint. As soon as the bundle has been delivered, the bundle protocol agent must report custodial delivery for multicast bundles as it does for singleton bundles, namely, by generating a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian. 8.2.6. Custody Transfer This section augments the Custody Transfer section of the Bundle Protocol [refs.DTNBP]. It defines the conditions under which a node may accept custody of a bundle whose destination is a multicast endpoint. As with singleton bundles, the decision as to whether or not to accept custody of a bundle is an implementation matter; however, if the bundle protocol agent has committed to accepting custody of the bundle as described in step 1 of section 4.2 ("Bundle Transmission") of the Bundle Protocol [refs.DTNBP], then custody must be accepted. If the bundle protocol agent elects to accept custody of the bundle, then it must follow the custody acceptance procedure defined in Section 8.2.7 8.2.7. Custody Acceptance This section augments Custody Acceptance section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for acceptance of custody of a bundle whose destination is a multicast endpoint. The retention constraint "Custody Accepted" must be added to the bundle. If the "request custody acceptance reporting" flag in the bundle's class of service field is set to 1, this flag MAY be ignored. The bundle protocol agent must generate a "Succeeded" custody signal for the bundle, destined for the bundle's current custodian. The bundle protocol agent must assert the new current custodian for Symington, et al. Expires February 13, 2010 [Page 33] Internet-Draft DTN Custodial Multicast Extensions August 2009 the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered. The bundle protocol agent must establish and maintain state information to keep track of each of the copies of this bundle that it is either delivering or forwarding, the EIDs to which they are being delivered or forwarded, the number of next-hop nodes expected to be reached at each EID, and whether or not a "Succeeded" custody signal has been received corresponding to each of these copies. The bundle protocol agent MAY set one custody transfer countdown timer per bundle or it MAY set one custody transfer countdown timer per one or more copies of this bundle that it is branching; upon expiration of one or more of these timers prior to expiration of the bundle itself and prior to custody transfer success for the associated copy (or copies) of the bundle, the custody transfer failure procedure must be followed for that copy (or those copies) of the bundle. The manner in which the countdown interval for such timers is determined is an implementation matter. The bundle SHOULD be retained in persistent storage if possible. 8.2.8. Custody Release This section augments the Custody Release section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for release of custody of a bundle whose destination is a multicast endpoint. As with singleton bundles, when custody of a multicast bundle is released, the "Custody accepted" retention constraint must be removed from the bundle and all custody transfer timers and other state information that have been established for this bundle must be destroyed. 8.2.9. Custody Transfer Success This section augments the Custody Transfer Success section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for determining custody transfer success for a bundle whose destination is a multicast endpoint. Upon receipt of a "Succeeded" custody signal the receiving node MUST note in its custodial state information for this bundle the receipt of this signal in conjunction with the associated copy of the bundle that the node had branched, because the receipt of this signal means that there are no downstream copies of that copy of the bundle that still need to be either delivered or have their custody transferred. Symington, et al. Expires February 13, 2010 [Page 34] Internet-Draft DTN Custodial Multicast Extensions August 2009 When a node has noted in its custodial state information for a given bundle that such successful notification has been received for every copy of that bundle that the node branched, meaning that there are no downstream copies of any copy of the bundle that remain to be delivered or taken custody of, then the node MUST check its custodial state information for the referenced bundle to determine whether it is in fact the "real" custodian for that bundle or whether it is just a proxy custodian. If the node is the real custodian of the bundle then custody of the bundle must be released as described in Section 8.2.8. If the node is a proxy custodian of the bundle, then the node MUST generate a "Succeeded" custody signal for the bundle, destined for the node that it had noted in its custodial state information as being the bundle's current custodian when the bundle was received. It MAY destroy all custodial state information for the bundle. (The node may want to retain this custodial state information until the bundle expires so that if the node receives the bundle again it will know exactly to which next-hop nodes it was forwarded, assuming this information is useful for efficiently transmitting bundles to late- joining nodes.) 8.2.10. Custody Transfer Failure This section augments the Custody Transfer Failure section of the Bundle Protocol [refs.DTNBP]. It defines the procedures for determining custody transfer failure for a copy of a bundle whose destination is a multicast endpoint. Custody transfer for a multicast bundle copy is determined to have failed at a custodial node when either (a) that node's custody transfer timer that is associated with that copy of the bundle (if any) expires or (b) a "Failed" custody signal for the bundle copy is received at that node. Only custodial nodes have custody transfer timers for bundles; non-custodial branching nodes do not. Both non- custodial branching nodes and custodial nodes, however, may receive "Failed" custody signals. Upon receipt of a "Failed" custody signal, the receiving node must check its custodial state information for the referenced bundle copy to determine whether or not it is in fact the "real" custodian for that bundle copy or whether it is just a proxy custodian for that bundle copy. If the receiving node is a proxy custodian of the bundle, then it must start a signal aggregation timer for this bundle if one has not already been started. Symington, et al. Expires February 13, 2010 [Page 35] Internet-Draft DTN Custodial Multicast Extensions August 2009 If it has not already done so, the receiving node must generate a new bundle. The receiving node's own EID must be inserted as the new bundle's source, and the EID of the node that the receiving node had noted in its custodial state information as being the referenced bundle's current custodian when the bundle was received must be inserted as the new bundle's destination. The "Failed" custody signal administration record must be inserted as this new bundle's payload. If the bundle that contained the "Failed" custody signal that was received also included a Proxy EID extension block, this extension block must be included in the new bundle that is generated. If the bundle that contained the "Failed" custody signal that was received did not include a Proxy EID extension block, then the node must insert a Proxy EID extension block into the new bundle that is generated. In either case, the node must insert a custodial signal information record into the Proxy EID extension block of the new bundle that is generated. The procedures for inserting a custodial information record into a proxy EID extension block are as follows: -The value inserted into the Status field of the custodial signal information record must be the value of the status field of the "Failed" custody signal that was just received. -The value inserted into the Time of Signal field of the custodial signal information record must be the value of the Time of signal field of the "Failed" custody signal that was just received. -Strings for the Scheme and SSP of the source EID of the bundle containing the "Failed" custody signal that was just received must be inserted into the dictionary of the bundle containing the proxy EID extension block (if not already there). -Offsets to the above EID reference pair must be inserted into the EID references field of the Proxy EID extension block following all other such EID references that are in this block, and the EID references count must be incremented by one. If, on the other hand, the receiving node had already generated a new bundle, it must insert a custodial signal information record into the Proxy EID extension block of this new bundle using the procedures defined above. When the signal aggregation timer for this bundle expires or when custody signals corresponding to all copies of the bundle that were Symington, et al. Expires February 13, 2010 [Page 36] Internet-Draft DTN Custodial Multicast Extensions August 2009 branched at this node are received (whichever comes first), the node must forward the new bundle. Note that this new bundle contains a "Failed" custody signal that refers to a specific bundle and it is destined for the upstream node that had been noted as being the current custodian of the referenced bundle when the bundle was received. This new bundle that is forwarded will contain a Proxy EID extension block with one or more custody signal information records, each of which corresponds to the origination of a "Failed" custody signal for a different downstream copy of this bundle by the downstream nodes indicated in the EID references field. If the receiving node is the real custodian of the bundle copy then, as noted above, custody transfer of the referenced bundle copy is determined to have failed. If the "Failed" custody signal contains a Proxy EID extension block, then the EID of the node(s) that originally generated the "Failed" custody signal(s) is/are identified in the EID references field of the Proxy EID extension block; otherwise, the EID of the node that originated the custody signal is identified in the Source EID field of the bundle containing the "Failed" custody signal. Upon determination of a custody transfer failure for a particular multicast bundle copy, the action taken by the custodian depends on the nature of the failure: -If custody transfer failure is inferred from expiration of a custody transfer timer or is asserted by a "Failed" custody signal with the "Depleted storage", "No timely contact with next node on route", or "Bundle Forwarded Non-Custodially" reason code, the bundle protocol agent SHOULD retransmit the bundle. It may re- forward the bundle to all next hop nodes appropriate for reaching nodes in the multicast endpoint, it may re-forward the bundle only to the next hop node(s) to which the copy of the bundle referenced in the "Failed" custody signal or associated with the expired timer had been forwarded, or it may encapsulate the multicast bundle in a singleton bundle for bandwidth-efficient transmission to the node that originally generated the "Failed" custody signal if a "Failed" custody signal had been received (See [refs.Encaps]). -If custody transfer failure is asserted by a "Failed" custody signal with the "Redundant Reception", "Destination EID unintelligible", "Block unintelligible", or "No known route to destination from here" reason code, the node SHOULD NOT retransmit the bundle. Symington, et al. Expires February 13, 2010 [Page 37] Internet-Draft DTN Custodial Multicast Extensions August 2009 8.2.11. Bundle Deletion This section augments the Bundle Deletion section of the Bundle Protocol [refs.DTNBP]. It defines the steps in deleting a custodial bundle whose destination is a multicast endpoint. If the retention constraint "Custody accepted" currently prevents this bundle from being discarded, then: -Custody of the node is released as described in Section 8.2.8 -A bundle deletion status report citing the reason for deletion must be generated, destined for the bundle's report-to-endpoint ID. All custodial state information being stored for this bundle MUST be destroyed. 8.3. Reception of Custody Signals This section augments section 5.3 of the Bundle Protocol [refs.DTNBP]. It defines the procedures that must be followed when custody signals for multicast bundles are received. For each received custody signal for a multicast bundle that has the Custody Transfer Succeeded flag set to 1, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer success procedure in Section 8.2.9. For each received custody signal for a multicast bundle that has the Custody Transfer Succeeded flag set to 0, the administrative element of the application agent must direct the bundle protocol agent to follow the custody transfer failure procedure in Section 8.2.10. Symington, et al. Expires February 13, 2010 [Page 38] Internet-Draft DTN Custodial Multicast Extensions August 2009 9. Custodial Multicast and the Retransmission Block Use of the DTN Retransmission Block [refs.Retrans] to identify bundles that are custodial retransmissions so as to distinguish them from replays is optional. If a node receives a bundle that -has a multicast destination endpoint, -has its "custody transfer requested" Bundle Processing Flag set, and -includes a retransmission block then if that node will not become a custodian of the bundle but it will serve as a non-custodial branching point, then in addition to changing the current custodian endpoint ID in the bundle's primary block to the endpoint ID of one of the singleton endpoints in which the node is registered (as described in Bundle Forwarding Section 8.2.1), the node must also change the EID reference field in the Retransmission Block to refer to this same singleton EID in which the node is registered. Hence, both the custodian field and the Retransmission Block will refer to a singleton EID that identifies the Proxy Custodian rather than one that identifies the "real" custodian. Symington, et al. Expires February 13, 2010 [Page 39] Internet-Draft DTN Custodial Multicast Extensions August 2009 10. Performance Impact The mechanisms defined in this document attempt to conserve network bandwidth and minimize the complexity of enhancements to the Bundle Protocol. They increase the amount of state that will need to be maintained at those bundle nodes that support these mechanisms. The amount of state that a given custodial node or non-custodial branching node may have to maintain is potentially large. A node may not have sufficient storage space to store this state information for each bundle until the bundle expires. if a node runs out of room and cannot keep track of for which bundle copies it has received "Succeeded" custody signals and for which it has not, then if the node receives a retransmitted bundle, it will have to re-forward the bundle along all downstream branches of the delivery tree. This is not incorrect; just inefficient. Nodes should be provided with a default algorithm for defining how long state information must be maintained and, if they run out of room for state information, for determining which state information gets deleted and which gets saved. Symington, et al. Expires February 13, 2010 [Page 40] Internet-Draft DTN Custodial Multicast Extensions August 2009 11. Security Considerations Although there are two documents that pertain to providing security within DTN [refs.DTNBPsec], [refs.DTNsecOver], both of these documents 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. Therefore, how to extend the Bundle Security Protocol to provide end-to-end protection for bundles that are sent from a single source to multiple destinations is yet to be determined. The use of the Bundle Authentication Block (BAB) to provide hop-by-hop security protections for bundles is expected to remain largely unchanged when applied protecting multicast delivery. The Confidentiality Block (CB) and the Payload Security Block (PSB), however, because they provide end-to-end security, would be expected to require adaptation to provide protection between a single source at one end of the transmission and multiple destinations at the other end. This document does not consider the security aspects of enabling or preventing a node from registering or de-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 February 13, 2010 [Page 41] Internet-Draft DTN Custodial Multicast Extensions August 2009 12. IANA Considerations None at this time. If the bundle protocol becomes a standards track protocol, then we may want to consider having IANA establish a register of block types. Symington, et al. Expires February 13, 2010 [Page 42] Internet-Draft DTN Custodial Multicast Extensions August 2009 13. References 13.1. Normative References [refs.RFC2119] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [refs.DTNBP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [refs.Encaps] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", draft-irtf- dtnrg-bundle-encapsulation-06.txt, work-in-progress, August 2009. [refs.DTNBPsec] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-08.txt, work-in-progress, March 2009. [refs.Retrans] Symington, S., "Delay-Tolerant Networking Retransmission Block", draft-irtf-dtnrg-bundle-retrans-block- 05.txt, work-in-progress, April 2009. 13.2. Informative References [refs.DTNarch] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", RFC 4838, April 2007. [refs.DTNsecOver] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay-Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-06.txt, work-in-progress, March 2009. [refs.wenruiZhao] Zhao, W., Ammar, M., and E. Zegura, "Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms", August 2005. [refs.IEEEcustMcast] Symington, et al. Expires February 13, 2010 [Page 43] Internet-Draft DTN Custodial Multicast Extensions August 2009 Symington, S., Durst, R., and K. Scott, "Custodial Multicast in Delay Tolerant Networks", January 2007. [refs.URI] Burners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Symington, et al. Expires February 13, 2010 [Page 44] Internet-Draft DTN Custodial Multicast Extensions August 2009 Authors' Addresses Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Robert C. Durst The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7535 Email: durst@mitre.org URI: http://mitre.org/ Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-6547 Email: kscott@mitre.org URI: http://mitre.org/ Symington, et al. Expires February 13, 2010 [Page 45]