The Johns Hopkins University Applied Physics Laboratory

11100 Johns Hopkins Rd. Laurel MD 20723 United States of America brian.sipos+ietf@gmail.com

Transport Delay-Tolerant Networking DTN This document explains how to use existing protocols, registries, code points, and algorithms to operate a Bundle Protocol (BP) edge node within a stable, non-challenged local underlayer IP network without the need for prior BP-layer configuration or long-term state. The purpose of this is to significantly lower the barrier to entry for lightweight BP edge nodes intended to act as endpoints for one (or only a few) BP applications.

Introduction The Delay-Tolerant Networking (DTN) architecture of and its realization in the Bundle Protocol (BP) Version 7 of do not directly address how an edge node can gain access to a BP network. Existing Bundle Protocol Agent (BPA) and Convergence Layer Adaptor (CLA) implementations treat BP-layer and network-layer configuration as externally supplied and managed data; this is the configuration burden to operate a BP node (including its BPA and various CLAs). A general-purpose BP node is designed to operate in environments with complex and diverse topologies, schedules, and underlayer networks. This provides an incredible power for a BP network to span large and complex physical and organizational domains, but this power comes at the cost of highly complex configuration on each node and a consistency of configurations between adjacent nodes. That necessary configuration represents a barrier to entry for deploying a simple edge node, e.g. one which is intended to mostly relay single-application data and rely on external BP routers to handle complexities associated with network topology and its time-variance. The situation which this document addresses is shown in , where one or more BP edge router acts as a gateway between an Internet Protocol (IP) local area network (LAN) and some larger BP core network. All edge nodes in the local network use the gateway router as a default bundle forwarding next-hop and a sole bundle previous-hop. The TCP Convergence Layer (TCPCL) is used on the IP LAN network due to it's favorable congestion control properties and it's ability to participate in DNS-based discovery without any new IANA allocations and without needing changes to BP or CLA behavior.

Network Edge Topology ---- Core Network ----|------- IP LAN ---------- __ _ _( )_( )_ +--------+ BP/ +--------+ ( ) BP | Edge | TCP | Edge |-+ ) nodes (<=====>| Router |<------>| Node | | (_ _ _) +--------+ +--------+ | (_) (__) | +--|------+ | | +---- mDNS ----+ or DNS

This type of situation is expected to be present within LANs on the edge of a mostly-non-terrestrial BP wide area network (WAN). Each of those LANs can have an isolated address space and potentially even use purely link-local addressing (which would create a situation similar to the Autonomic Control Plane (ACP) of ). While the methods of this document can provide an easy way for an edge node to access a BP network, there are many situations listed in where these methods do not apply along with some potential relaxations discussed in . These caveats to use do not diminish the utility in situations where the methods described here do apply.

Scope This document applies to a common but somewhat overlooked situation where an edge node is well-connected, via a non-challenged IP LAN, to one or more edge router of a BP network. The zero-configuration CLA method defined in does not apply to the following situations:

Non-IP Networks:

The mechanisms in this document rely on functions specific to IP networks which are non-challenged and can operate protocols like mDNS and TCP . When needing to operate a node with a non-IP underlayer network, these protocols will not function out-of-the-box. See for discussion of non-IP networks.

Non-TCP Convergence Layers:

The mechanisms in this document rely on a router to offer a single CL service which can transfer bundles in both directions between the router and edge nodes based on just the edge node discovering the network parameters of the router. When needing to operate a node with CL(s) other than the TCPCL this unidirectional discovery may not work. See for discussion of other CL types.

Multiple Connectivity:

When a BP node is functioning as a router, it will necessarily need to configure multiple connectivity to peer nodes along with likely complex policy related to forwarding and storage between those peers. Even for an edge node there, are situations where multiple types or instances of connectivity exist into a single BP network. This document might apply in these situations, but might be an overly-simple method to handle them.

Time-Variant Connectivity:

Even when an edge node has a single form of connectivity into a BP network, there may be time-variant aspect to that connectivity. This document does not directly address time-variance and relies on the application using the BP node to manage how wall-clock and scheduled time applies to the node's operations. See for some alternatives when the edge router connectivity is not persistent.

Peer Discovery:

In cases where a BP network already provides a neighbor or neighborhood discovery mechanism that is available to the edge nodes, that network-specific mechanism is likely to be more applicable and more efficient than the DNS-based method of .

The zero-state BPA method described in does not apply to the following situations:

Time-Variant Connectivity:

The stateless BPA is allowed to be stateless because it uses immediate pass-through of payload-to-bundle flow. In a situation where an application needs to transmit bundles but the CLA to the router is not available, this document does not define a "correct" behavior but relies on the application to manage scheduled activities. See for some alternatives when the edge router connectivity is not persistent.

Independent Applications:

The stateless mode of operating a BPA requires that the BPA itself does not need to retain received bundles. This is accomplished by operating the BPA only while the overlaying application itself is capable of having bundles delivered to it via all registered EIDs. If there are multiple independent applications with time-varying registrations that do not coincide then this method will not apply. See for some alternatives when multiple applications are needed.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document distinguishes between cases where a BP node is expected to function as an intermediate "router" (either on a network edge or in its interior) versus an "edge node" with a more straightforward workload to source from and deliver to overlayer applications. In the zero-configuration mechanism of the edge router is the entity which offers its service and the edge node enumerates and uses the service. This document also distinguishes between a "core network" which extends up to, but not beyond, its edge routers from the overall "network" which includes all nodes sourcing, delivering, or forwarding bundles. When discussing behaviors between the edge routers and edge nodes, this document uses the term "IP LAN" to distinguish that IP-based edge topology from whatever means other nodes in the core network have to exchange bundles. The IP LAN is assumed to have the expected properties of an IP network, and not behave as a "challenged network" as described in . For the zero-state agent of , there is a separation between "TX session" used solely to transmit bundles and "RX session" used to receive bundles. Both of these use the same TCPCL mechanism just with different session parameters to control what transfers are acceptable in each session.

Protocol Description For a truly zero-configuration edge node, the network layer and below needs to be automatically configured. This is something which can already be achieved using methods such as the Dynamic Host Configuration Protocol (DHCP) of and , Stateless Address Autoconfiguration of and Neighbor Discovery Protocol of , and link-local addressing of and . There MAY be link- and network-level authentication and authorization applied to edge nodes. The need for and form of these access control methods is a network policy matter. Once an edge node has an IP address and local network configuration, the method of is used to lookup TCPCL connection parameters from the edge router(s) in the LAN. Using those parameters, the methods of can be used when an application wants to send or receive bundles via some edge router.

Edge Router Requirements The methods defined in this document rely on a local BPA willing to act as an edge router for associated BP edge nodes within the same IP LAN. The edge router SHALL act as a TCPCL passive listener in accordance with . The edge router MAY act as the active or passive roles of any number of other convergence layers, but those are immaterial to the functioning of these methods. More specific requirements about how the edge router interacts with the edge nodes via TCPCL are included in . One side effect of those required behaviors is that edge nodes on the LAN can also send bundles between each other (via the edge router) without any prior configuration. A key assumption of that behavior is that the applications are aware of each other's EIDs from configuration outside of the BP or IP networks. Future work on BP node and service discovery could be used to avoid this assumption; once an edge node is able to communicate at the BP layer it could discover BP services via BP itself.

High-Availability Configurations The service parameters for priority and weight described in allow for a large variety of possible network configurations with multiple edge routers providing access to a core network. Due to the need for edge routers to queue bundles destined for edge nodes and the possibility of an edge router serving an unbounded number of edge nodes, it is RECOMMENDED to provide high-availability of service within a single edge router rather than using multiple separate routers. When multiple edge routers are used on an IP LAN it is RECOMMENDED to give them distinct SRV priority fields so that one router is the active provider and the other(s) act as warm standby providers. The risk when multiple routers are offered as TCPCL listeners with the same priority is that a single edge node with limited connectivity (e.g., for power saving purposes) would choose different router instances at different times and require that the edge routers themselves coordinate and forward queued bundles to the currently-connected router. Although this is an acceptable and allowed situation, it adds hops to a bundle's path, increases resource burdens on the edge routers, and complicates the ways that bundle forwarding could fail before delivery.

Zero-Configuration CLA Discovery This section defines a method to allow BP routers to advertise (offer) their presence in an IP LAN and for edge nodes to discover (enumerate and use) those routers, all via DNS-based Service Discovery (DNS-SD) as defined in . One aspect of DNS-SD is that it works equivalently over multicast DNS (mDNS) and traditional unicast DNS, or both simultaneously, but does not require both to be operating in the IP LAN. It is a network policy issue to determine which DNS strategy is more appropriate in any particular deployment, and it is an implementation detail on both edge node and router side to determine which (or both) DNS strategy to enumerate on and offer on respectively. It is important to understand that the router defined in this document only applies to nodes willing to act as a gateway BP router for their IP LAN. Any BP node which does not intend to forward bundles (both to and from) other nodes in a LAN SHALL NOT offer TCPCL over DNS-SD.

Parameters The DNS-SD naming convention of combined with the service name registered in for the TCPCL by results in the following relative domain name (RDN):

DNS-SD Relative Domain Name _dtn-bundle._tcp

When used with the mDNS reserved local domain of results in the following FQDN:

Local Network FQDN _dtn-bundle._tcp.local.

The RDN can also be used with one or more search domain in accordance with . For example, using a search domain of example.com results in the following FQDN:

Example Domain FQDN _dtn-bundle._tcp.example.com.

In addition to the registered service name this document defines additional TXT RR parameters, as hints about the TCPCL listener, in accordance with of:

txtvers (TXT RR Version):

This required key has a value indicating the current TXT RR version as an integer. This document defines version 1.

protovers (Protocol Version):

This optional key has a value indicating the latest supported TCPCL version as an integer. When not present the default version is 4.

Service Offering When an edge router desires to offer its willingness via mDNS, the FQDN of SHALL be offered using DNS PTR and/or SRV resource records (RRs) with fields defined in and corresponding to its TCPCL listening configuration. An example of this for a router instance name rtr1 operating with service priority 0, weight 0, DNS name host-name, and standard TCPCL port is below, with multiple parameter strings in accordance with , and with TTL and class fields elided. _dtn-bundle._tcp.local. PTR rtr1._dtn-bundle._tcp.local. rtr1._dtn-bundle._tcp.local. SRV 0 0 4556 host-name.local. rtr1._dtn-bundle._tcp.local. TXT "txtvers=1" "protovers=4" When edge routers are managed via unicast DNS, the RDN of SHALL be offered in the local domain zone using a DNS SRV RR with fields defined in corresponding to its TCPCL listening configuration. Multiple edge routers MAY be present in an IP LAN and identified with SRV RR containing different priority fields (see ). An example of multiple SRV RRs in the same domain with different priorities is below, with TTL and class fields elided. _dtn-bundle._tcp.example.com. PTR rtr1._dtn-bundle._tcp.example.com. _dtn-bundle._tcp.example.com. PTR rtr2._dtn-bundle._tcp.example.com. rtr1._dtn-bundle._tcp.example.com. SRV 10 0 4556 primary.example.com. rtr1._dtn-bundle._tcp.example.com. TXT "txtvers=1" "protovers=4" rtr2._dtn-bundle._tcp.example.com. SRV 20 0 4556 backup.example.com. rtr2._dtn-bundle._tcp.example.com. TXT "" Edge routers MAY update DNS RRs via an in-band protocol such as DNS Update . Edge nodes MAY monitor RR changes via an in-band protocol such as DNS Push .

Service Enumeration For the edge node wanting BP network access, the method is as simple as retrieving the SRV RR for the RDS of , either in the mDNS local domain or some other search domain, and using the SRV fields for a TCPCL session establishment. When an edge node desires to look up a local BP router it SHALL attempt to resolve the SRV and TXT RRs in accordance with by one or both of the following:

1. Query the FQDN of via mDNS in accordance with .
2. Query the RDN of within one or more search domains via DNS in accordance with or equivalent protocol.

If a SRV or TXT query fails (which includes a query result with a target name of ".") the edge node SHALL treat the associated edge router as currently unavailable from the IP LAN. If a SRV or TXT query fails, the edge node MAY attempt future queries based on a schedule configured on the node. The specifics of reattempts at SRV or TXT record retrieval are an implementation matter (see for possible alternatives). If the SRV query succeeds, the edge node SHALL use the priority and weight fields of each SRV record fields in accordance with to choose an instance to use.

Service Use This section discusses how an edge node can use a chosen router from an enumerated list of available routers. Detailed requirements for how an edge node and router configure and operate TCPCL sessions are given in . When a TCPCL session is needed for transfers and one or more service instances are available, the edge node SHALL use SRV and TXT records of a chosen instance to identify a specific DNS name to connect to using the active role of . When needing to establish a TCPCL session, an edge node SHOULD use the same service instance for all TCPCL sessions until there is some failure to keep up an existing session or failure in establishing a new session. An edge node MAY use different service instances at the same time for different TCPCL sessions. It is an implementation matter to determine which service instance, or what combination of instances, to use for needed TCPCL sessions. Part of that connection to a DNS name involves resolving the name into one or more IP addresses using an mDNS or DNS query. An edge node SHALL NOT assume DNS name resolution to IP address(es) for a service instance is unchanging over time. The edge node SHOULD use methods of Happy Eyeballs Connection Setup when resolving a DNS name and attempting TCP connections.

Zero-State BPA Operation Beyond achieving CLA discovery for an edge router, an edge node can be operated in compliance with without needing to use long-term BP-layer storage or state. The method defined in this section uses specifically parameterized TCPCL sessions to send bundles to and receive from an edge router discovered via the method of , but could use any other method to define how to connect to the edge router. Both the and procedures can be operated simultaneously or sequentially depending on how the overlaying application uses the BPA. It is an implementation matter for how the application indicates these policies to the BPA. Using this method, the BPA can be implemented as a pure software library or middleware under a BP-aware application. Either the application or BPA could perform the procedures in a multi-threaded form, but neither BP, nor TCPCL, nor this document require that the various protocol processing be performed in parallel. The overall bundle flows are shown in , which indicates how the transmission is handled fully independently from the reception, and how reception can cause status reports but these can be sourced synchronously and handled separately from application-caused transmission. This diagram does not show possible security processing within the flows between sessions and the application or administrative element.

Zero-State BPA Flows -- Network --|------- CLA ------|------- BPA ------|----- App ------ +---------+ +------------+ Bundle TX +-------------+ | |<----| TX session |<----------------------| | | | +------------+ | User | | | | Application | | Edge | +------------+ Bundle RX | | | Router |---->| RX session |------------+--------->| | | | +------------+ : +-------------+ | | v | | +------------+ +----------------+ | |<----| TX session |<--| Administrative | +---------+ +------------+ | Element | +----------------+

Bundle Transmission When the application indicates the need to send one or more bundles, a "TX" TCPCL session SHALL be established in accordance with with the following initialization parameters:

Keepalive Interval:

Set to zero to indicate no keepalive behavior is wanted.

Transfer MRU:

Set to zero to indicate that the edge node is not willing to receive bundles within the session.

Node ID:

Set to the Node ID associated with the edge node.

All other TX session initialization parameters are left as an implementation matter. After TX session establishment the bundle(s) requested by the application SHALL be transferred immediately. After all transfers are finished, the TX session SHALL be terminated with a Reason Code of Unknown (0x00). If TX session establishment fails, the application SHALL be informed that the associated bundles were not sent. It is an implementation matter for how to handle this kind of failure (e.g., queuing within the BPA as in or within the application).

Bundle Reception When the application indicates the desire to receive available bundles, an "RX" TCPCL session SHALL be established in accordance with with the following initialization parameters:

Keepalive Interval:

Set to some non-zero interval to indicate keepalive behavior is wanted.

Transfer MRU:

Set to some non-zero limit to indicate that the edge node is willing to receive bundles within the session.

Node ID:

Set to the Node ID associated with the edge node.

All other RX session initialization parameters are left as an implementation matter. After session establishment and until the application indicates otherwise, the RX session SHALL be kept up. When the application indicates that reception is to stop, the RX session SHALL be terminated with a Reason Code of Unknown (0x00). When a transfer is received in the RX session it SHALL be immediately processed in accordance with . If the received bundle has a Destination to be delivered to the overlying application it SHALL be delivered immediately to the listening application. Otherwise, the bundle SHALL be deleted. In any case if during the processing of the received bundle it is necessary to send any administrative record (e.g., bundle status report), the transmission procedure of SHALL be followed for those bundles. If RX session establishment fails, the application SHALL be informed that listening cannot be performed at the requested time. It is an implementation matter for how to handle this kind of failure (e.g., waiting for service connectivity as in ).

Router Side When a request to establish a TCPCL session is received, the edge router SHALL respond with the following initialization parameters:

Transfer MRU:

Set to some non-zero limit to indicate that the router is willing to receive bundles within the session.

Node ID:

Set to the Node ID associated with the router.

All other session initialization parameters are left as an implementation matter. At the BPA level, the edge router SHALL be willing to forward and store bundles sourced by and destined for all of the edge nodes for which it establishes TCPCL sessions. The fact of being a "router" implies all of the activities required by will be done for those edge-node-related bundles. It is an implementation matter for the router to decide if and when to limit new TCPCL sessions or transfers to conserve resources. After establishing a TCPCL session with an edge node, the edge router SHALL treat contact with the edge node as persistent for any interior routing or discovery protocols within the BP network. Even if contact with the edge node is not truly persistent, when it establishes TCPCL sessions with the edge node the edge router assumes responsibility for queuing bundles destined for that edge node. The assumption here is that the IP network between edge router and node is persistent enough to appear continuous over time to the core BP network.

Relaxed Assumptions for More Situations This section discusses the assumptions from and how some of them can be relaxed at the expense of added configuration or internal state.

Relaxation of IP LAN Assumption The assumption allows the zero-configuration mechanism to make use of IP-based technologies such as mDNS and DNS and ultimately the logic of DNS-SD for router discovery. In a non-IP LAN the DNS-SD discovery method will not work (as there is no DNS) but there may be other, network-specific methods of discovery or out-of-band CLA configuration will be needed. In this situation it is still possible to use the zero-state BPA as defined in .

Relaxation of TCPCL Assumption This assumption is that edge routers use TCPCL as a reliable, bi-directional, and flow-controlled convergence layer for all edge nodes. In environments where some other converge layer is used which operates over a protocol with a registered well-known service name the same DNS-SD technique can be used with that alternative service name. Because the DNS-SD is not symmetric with respect to the nodes using it, with routers offering a service and edge nodes using it, this mechanism still requires that the convergence layer provide bi-directional bundle transfers based on just one node knowing the network parameters to access another node. The CL in this case need not be session-oriented but reliable sessions do make it easier to detect transmission failures and report them to the application. It is also important that there be some kind of flow control mechanism within the LAN so that one edge node cannot starve others of network resources.

Relaxation of Router Connectivity Assumption The assumption of immediate connectivity to a gateway router whenever an application needs to send a bundle results in the need for router availability to be visible to the application sourcing bundles and for that to act as an implied flow control mechanism for the application. If the router is not available or transfers are not proceeding quickly enough, the application will need to hold-off or back-off on sourcing new bundles. Because there can be periods of time when no router is willing to offer or establish TCPCL sessions or when a TX transfer is already in progress, a BPA can keep an "egress" queue of bundles to be transmitted and wait for an indication of edge router connectivity before beginning the transfer. This is similar to how current stateful BPAs operate, where the bundle source processing is in a different thread of operation from the bundle forwarding processing. When such an egress queue is present, there is added state within the BPA and also risk of resource exhaustion if that state grows too large. Because of this, even if an egress queue is used it is useful for the application to have some visibility into the queue for flow control purposes.

Relaxation of Single Application Assumption This assumption allows a BPA to immediately and synchronously receive and deliver bundles to a listening application. When there is only a single application there is never the possibility of one application listening on an endpoint and another application not listening for some interval of time. A BPA can be used to host more than one independent application if there is a "delivery" queue of bundles destined for endpoints registered to known but non-listening applications. This is similar to how current stateful BPAs operate, where the bundle reception processing is in a different thread of operation from the bundle delivery processing. When such an delivery queue is present, there is added state within the BPA and also risk of resource exhaustion if that state grows too large. Because of this, even if a delivery queue is used it could be useful for the application to have some visibility into the queue for flow control purposes.

IANA Considerations This specification uses many existing IANA registries, but does not make updates to any registries.

Security Considerations To establish a local network address and network parameters, the edge node might be required to supply link- or network-layer credentials. For some existing protocols such as MACSec or IPSec, it is possible to use the Extensible Authentication Protocol (EAP) of with PKIX certificates for authentication and authorization. For other protocols such as SEcure Neighbor Discovery (SEND) , PKIX certificates can be used directly. It is a network policy for how access is granted and network addresses are allocated or authorized. Within the zero-configuration specification of there is no prohibition on the use of network-layer, DNS, or TCPCL security. If required by network policy, an edge router will authenticate its peer node's Node ID using the TLS security and PKIX certificate profile of . If required by network policy, an edge node will authenticate its peer router's Node ID using the TLS security and PKIX certificate profile of . A RECOMMENDED policy is to use mutual authentication of TCPCL when not on an isolated network with its own link-layer or network-layer security. Within the zero-state specification of there is no prohibition on the use of BP-layer security. If required by network policy, an edge node will provide BP integrity or confidentiality using the BPSec facilities of either as a security source or a security acceptor. A RECOMMENDED policy is to have the edge node source and process BPSec directly when possible, and to have the associated edge router act as BPSec gateway otherwise. This consideration is not specific to the methods of this document, but when an edge router serves as a gateway for many edge nodes it is important that the router implement quotas (hard limits) and prioritization (soft limits) for both storage size and forwarding throughput for each edge node. If quotas are not present, it could be possible for a single edge node to monopolize either storage or LAN throughput on the router and cause denial-of-service to other edge nodes. The algorithms or techniques used to allocate per-node quotas or priorities are outside the scope of this document.

References Normative References IANA Informative References

Acknowledgments Thanks to Marc Blanchet for early feedback on this document.