DTN Research Group S. Symington Internet-Draft R. Durst Expires: February 2, 2007 K. Scott The MITRE Corporation August 1, 2006 Delay-Tolerant Networking Custodial Multicast Extensions draft-symington-dtnrg-bundle-multicast-custodial-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 2, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines optional extensions to the Bundle Protocol [2] 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 2, 2007 [Page 1] Internet-Draft DTN Custodial Multicast Extensions August 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. The Basic Problems of Custodial Multicast . . . . . . . . . . 7 3. Objectives, Assumptions, and Design Principles . . . . . . . . 8 3.1. Custodial Multicast Objectives . . . . . . . . . . . . . . 8 3.2. Assumptions and Design Principles for Custodial Multicast Extensions . . . . . . . . . . . . . . . . . . . 9 4. Multicast Routing Protocol Requirements and Desired Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Only CMC-nodes may be branching points . . . . . . . . . . 12 4.2. Multicast delivery paths must be trees . . . . . . . . . . 12 4.3. If convergence layer multicast is used, the forwarding node must know the number of next-hop recipient nodes . . 13 4.4. CMC nodes should keep track of de-registration requests in order to be able to distinguish delayed de-registrations from routing failures . . . . . . . . . . 14 5. Overview of Mechanisms for Supporting Custodial Multicast . . 16 5.1. Special Responsibilities of Custodial Nodes . . . . . . . 17 5.2. Special Responsibilities of (Non-Custodial) Branching Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Identifying Bundle Copies . . . . . . . . . . . . . . . . . . 21 7. Proxy EID Extension Block . . . . . . . . . . . . . . . . . . 23 8. Bundle Protocol Extensions to Support Custody Transfer and Retransmission for Multicast Bundles . . . . . . . . . . . . . 24 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 24 8.2. Bundle Processing Steps for Custodial Multicast Bundles . 24 8.2.1. Bundle Forwarding . . . . . . . . . . . . . . . . . . 24 8.2.2. Forwarding Contraindicated . . . . . . . . . . . . . . 27 8.2.3. Forwarding Failed . . . . . . . . . . . . . . . . . . 28 8.2.4. Bundle Reception . . . . . . . . . . . . . . . . . . . 28 8.2.5. Local Bundle Delivery . . . . . . . . . . . . . . . . 28 8.2.6. Custody Transfer . . . . . . . . . . . . . . . . . . . 29 8.2.7. Custody Acceptance . . . . . . . . . . . . . . . . . . 29 8.2.8. Custody Release . . . . . . . . . . . . . . . . . . . 30 8.2.9. Custody Transfer Success . . . . . . . . . . . . . . . 30 8.2.10. Custody Transfer Failure . . . . . . . . . . . . . . . 31 8.2.11. Bundle Deletion . . . . . . . . . . . . . . . . . . . 32 8.3. Reception of Custody Signals . . . . . . . . . . . . . . . 33 9. Performance Impact . . . . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Normative References . . . . . . . . . . . . . . . . . . . 37 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Symington, et al. Expires February 2, 2007 [Page 2] Internet-Draft DTN Custodial Multicast Extensions August 2006 Intellectual Property and Copyright Statements . . . . . . . . . . 39 Symington, et al. Expires February 2, 2007 [Page 3] Internet-Draft DTN Custodial Multicast Extensions August 2006 1. Introduction The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 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 [2] 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. 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 [2]. 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 [5] defines the architecture for delay-tolerant networks, but only briefly discusses multicasting. - The Bundle Protocol Specification [2] 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 Symington, et al. Expires February 2, 2007 [Page 4] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 [3] defines the format and processing of the Bundle-in-Bundle Encapsulation Administrative Record, which is used to enable the transmission of one or more bundles encapsulated in another bundle as part of that bundle's payload (e.g., one or more multicast bundles encapsulated in a singleton bundle). 1.2. Terminology Multicast Endpoint - A bundle endpoint that is permitted to contain multiple nodes and that has as its minimum reception group (see [2]) 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 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 Symington, et al. Expires February 2, 2007 [Page 5] Internet-Draft DTN Custodial Multicast Extensions August 2006 features defined in the Bundle Protocol [2]. 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 [2]. Symington, et al. Expires February 2, 2007 [Page 6] Internet-Draft DTN Custodial Multicast Extensions August 2006 2. The Basic Problems of Custodial Multicast Custody transfer and retransmission, which are defined for singleton bundles in the Bundle Protocol [2], 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 2, 2007 [Page 7] Internet-Draft DTN Custodial Multicast Extensions August 2006 3. Objectives, Assumptions, and Design Principles 3.1. 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 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 available for forwarding to every node that registers late or the registration request of which is delayed. As pointed out in [7], 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. Symington, et al. Expires February 2, 2007 [Page 8] Internet-Draft DTN Custodial Multicast Extensions August 2006 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.2. Assumptions and Design Principles for Custodial Multicast Extensions 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 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. 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 Symington, et al. Expires February 2, 2007 [Page 9] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 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 Symington, et al. Expires February 2, 2007 [Page 10] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 has already been or currently is a custodian, the bundle is assumed to be in an unintentional loop and should 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 [8]. Symington, et al. Expires February 2, 2007 [Page 11] Internet-Draft DTN Custodial Multicast Extensions August 2006 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.2 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 nodes that implement only the base Bundle Protocol (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 nodes that support only the base Bundle Protocol, 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. Multicast delivery paths must be trees DTN multicast routing protocols are required to operate over trees rather than meshes. This requirement serves two purposes: -the extensions defined herein are based on the principle that a bundle is only branched when that branching is required to enable the bundle to reach a destination node. Thus, every copy of the bundle created as a result of branching is assumed to be destined Symington, et al. Expires February 2, 2007 [Page 12] Internet-Draft DTN Custodial Multicast Extensions August 2006 for a unique destination node. For the extensions to work efficiently, it cannot be the case that two different copies are destined for the same destination node. Hence, the delivery path must be a tree. -requiring the multicast delivery path to be a tree facilitates the detection of unintentional loops, which can be extremely wasteful of bandwidth when multicast, and especially custodial multicast, is used. Because the multicast delivery path is required to be a tree, any bundle that is received a second time may be assumed either to have been re-forwarded by a custodian or to be in an unintentional loop. If such a bundle is received by a node that is or has already been a custodian of the bundle, it can be assumed to be in an unintentional loop. It may therefore be safely be dropped and there is no need to send a concomitant custody signal to its asserted custodian. 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 Symington, et al. Expires February 2, 2007 [Page 13] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 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 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 Symington, et al. Expires February 2, 2007 [Page 14] Internet-Draft DTN Custodial Multicast Extensions August 2006 distribution tree keep track of de-registration requests is not required in order for the custodial multicast extensions to work correctly, but it does eliminate unnecessary custody signal transmissions and bundle retransmissions. 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. Symington, et al. Expires February 2, 2007 [Page 15] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 [3] 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 mechanics of re-forwarding bundles to newly-registering or delayed- registration nodes. They do, however, enable a custodian to determine whether a bundle needs to be re-forwarded 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 2, 2007 [Page 16] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 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. 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 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 Symington, et al. Expires February 2, 2007 [Page 17] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 (assuming that accommodating late- or delayed-registering destination nodes is not a concern) or 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 [3]) 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 -MUST maintain a list of unexpired bundles for which it has ever been a custodian. 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: Symington, et al. Expires February 2, 2007 [Page 18] Internet-Draft DTN Custodial Multicast Extensions August 2006 -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, it 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. -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 not been received. -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". (Note that this new reason code must be defined in the Bundle Protocol Specification.) 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 Symington, et al. Expires February 2, 2007 [Page 19] Internet-Draft DTN Custodial Multicast Extensions August 2006 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. Symington, et al. Expires February 2, 2007 [Page 20] Internet-Draft DTN Custodial Multicast Extensions August 2006 6. Identifying Bundle Copies The node responsibilities described above require 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 header, but such a technique would require each branching node to add such a header, thereby adding to the size of the bundle. It would also require that procedures be defined for determining when these headers 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 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 [9]. The 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 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 Symington, et al. Expires February 2, 2007 [Page 21] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 2, 2007 [Page 22] Internet-Draft DTN Custodial Multicast Extensions August 2006 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. 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 [2]. 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 (one byte) - defined as in all bundle protocol blocks except the primary bundle block (as 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. -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: -Original Source EID - Contains the endpoint ID of the node that originally generated the "Failed" custody signal. The Structure of a Proxy EID Extension Block is as follows: Proxy EID Extension Block Format: +-----+------+-------+----------------+ |Type |Flags |Length |Original Source | | | | | Endpoint ID | +-----+------+-------+----------------+ Figure 1 Symington, et al. Expires February 2, 2007 [Page 23] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 section 4.4 of the Bundle Protocol [2]. 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 2, 2007 [Page 24] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 header 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 may 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 2, 2007 [Page 25] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 2, 2007 [Page 26] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 section 4.4.1 of the Bundle Protocol [2]. It defines the procedures for handling a forwarding contraindication for a bundle whose destination is a multicast endpoint. As described in [7], 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 [7] 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 Table 5 of the Bundle Protocol specification [2]. 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 received a deregistration request notification for the EID in question, it can distinguish this forwarding contraindication from a forwarding failure. Instead of declaring a forwarding failure, the bundle protocol agent should send Symington, et al. Expires February 2, 2007 [Page 27] Internet-Draft DTN Custodial Multicast Extensions August 2006 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. 8.2.3. Forwarding Failed This section augments section 4.4.2 of the Bundle Protocol [2]. 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 section 4.6 of the Bundle Protocol [2]. 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, and fragment offset as a bundle that the receiving node is currently or has previously been 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. 8.2.5. Local Bundle Delivery This section augments section 4.7 of the Bundle Protocol [2]. It defines the procedures for reporting custodial delivery for a bundle whose destination is a multicast endpoint. Symington, et al. Expires February 2, 2007 [Page 28] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 section 4.10 of the Bundle Protocol [2]. 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, 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 section 4.10.1 of the Bundle Protocol [2]. 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 the bundle. It does so by changing the current custodian endpoint ID in the bundle's primary header 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 Symington, et al. Expires February 2, 2007 [Page 29] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 section 4.10.2 of the Bundle Protocol [2]. 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, except for the fact that the node has been a custodian of this bundle, must be destroyed. 8.2.9. Custody Transfer Success This section augments section 4.11 of the Bundle Protocol [2]. 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. 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 or not 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 Symington, et al. Expires February 2, 2007 [Page 30] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 except for the fact that it has been a custodian 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 section 4.12 of the Bundle Protocol [2]. 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 generate a "Failed" custody signal for the bundle destined for the node that it had noted in its custodial state information as being the referenced bundle's current custodian when the bundle was received. The "Failed" custody signal that is generated must be identical to the "Failed" custody signal that was received, minus any hop-by-hop headers that are not designed to remain in the bundle for longer than one hop, and also with the source and destination EIDs modified as follows: -the node must insert its own EID as the "Failed" custody signal's source EID -the node must insert the EID of the node that it had noted in its custodial state information as being the referenced bundle's current custodian when the bundle was received as the "Failed" Symington, et al. Expires February 2, 2007 [Page 31] Internet-Draft DTN Custodial Multicast Extensions August 2006 custody signal's destination EID. If the "Failed" custody signal that was received included a Proxy EID extension block, the "Failed" custody signal that is generated must also include this extension block. If the "Failed" custody signal that was received did not include a Proxy EID extension block, then the node must insert one before sending the "Failed" custody signal. The EID that the node inserts into the Proxy EID block must be the EID that was listed as the source node in the "Failed" custody signal that was received. 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 that originally generated the "Failed" custody signal is identified in the Proxy EID extension block; otherwise, it 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" or "No timely contact with next node on route" 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 (See [3]). -If custody transfer failure is asserted by a "Failed" custody signal with the "Redundant Reception", "Destination EID unintelligible", "Header unintelligible", or "No known route to destination from here" reason code, the node SHOULD NOT retransmit the bundle. 8.2.11. Bundle Deletion This section augments section 4.13 of the Bundle Protocol [2]. It defines the steps in deleting a custodial bundle whose destination is a multicast endpoint. Symington, et al. Expires February 2, 2007 [Page 32] Internet-Draft DTN Custodial Multicast Extensions August 2006 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 [2]. 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 2, 2007 [Page 33] Internet-Draft DTN Custodial Multicast Extensions August 2006 9. 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. Symington, et al. Expires February 2, 2007 [Page 34] Internet-Draft DTN Custodial Multicast Extensions August 2006 10. Security Considerations Although there are two documents that pertain to providing security within DTN [4], [6], 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 2, 2007 [Page 35] Internet-Draft DTN Custodial Multicast Extensions August 2006 11. 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 header types. Symington, et al. Expires February 2, 2007 [Page 36] Internet-Draft DTN Custodial Multicast Extensions August 2006 12. References 12.1. Normative References [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997. [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", draft-irtf-dtnrg-bundle-spec-05.txt, work-in-progress, April 2006. [3] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant Networking Bundle-in-Bundle Encapsulation", draft-irtf-dtnrg-bundle-encapsulation-00.txt, work-in-progress, July 2006. [4] Symington, S., Farrell, S., and H. Weiss, "Bundle Security Protocol Specification", draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress, March 2006. 12.2. Informative References [5] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network Architecture", draft-irtf-dtnrg-arch-05.txt, work-in-progress, March 2006. [6] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant Network Security Overview", draft-irtf-dtnrg-sec-overview-01.txt, work-in-progress, March 2006. [7] Zhao, W., Ammar, M., and E. Zegura, "Multicasting in Delay Tolerant Networks: Semantic Models and Routing Algorithms", August 2005. [8] Symington, S., Durst, R., and K. Scott, "Custodial Multicast in Delay Tolerant Networks", to be submitted for presentation at the IEEE Consumer Communications and Networking Conference, January 2007. [9] 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 2, 2007 [Page 37] Internet-Draft DTN Custodial Multicast Extensions August 2006 Authors' Addresses Susan Flynn Symington The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7209 Email: susan@mitre.org URI: http://mitre.org/ Robert C. Durst The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-7535 Email: durst@mitre.org URI: http://mitre.org/ Keith L. Scott The MITRE Corporation 7515 Colshire Drive McLean, VA 22102 US Phone: +1 (703) 983-6547 Email: kscott@mitre.org URI: http://mitre.org/ Symington, et al. Expires February 2, 2007 [Page 38] Internet-Draft DTN Custodial Multicast Extensions August 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Symington, et al. Expires February 2, 2007 [Page 39]