]> Spacely Packets, LLC

46 High Ridge Road Daytona Beach FL 32117 US 386-888-7311 scott@spacelypackets.com

General Internet Engineering Task Force DTN Delay Tolerant Networks (DTNs) are typically characterized by high latency and lack of constant end to end connectivity, consistent with their use in deep space communications. This, however, is not the limit of application of Bundle Protocol (BP) and related DTN enabling technologies. Through a collection of Convergance Layer Adapters (CLAs), deployment overlaying the terrestrial Internet is a core component of DTN implementations. IPN is a integer based naming scheme for DTN networks. Nothwithstanding cryptographic considerations, three basic components are necessary to make a BP overlay network connection, the IP address of the node, the CBHE Node Number (IPN component), and the CLA which providing IP connectivity. This document describes additions to DNS to enable terrestrial BP resource look up.

Introduction Terrestrial use of DTNs across reliable, low latency paths introduces the opportunity to leverage the existing DNS infrastructure to distribute connectivity related data. While is it not technically feasible to ensure delivery of non-stale data to spaceborne DTN nodes in response to a DNS lookup request, there is no such barrier to deploying DNS records which describe those core datasets necessary to enable connection of DTN nodes overlaying IPv4 or IPv6 networks.

RRTYPES for Delay Tolerant Networks

IPN A popular naming scheme for BP nodes is the IPN naming scheme, defined in . The fundamental unit of this scheme is the Endpoint Identifier (EID) which is comprised of two 64 bit unsigned integers delineated by . as described in section 4.2.5.1.2 of . Of the components of an EID, only the (node-nbr) component identifies the node, while the (service-nbr) component generally is analagous to the port number bound to an IP socket. Therefore, a DNS RRTYPE is requested to represent the (node-nbr) component of an EID as a character array of no more than 21 characters, encoded in US-ASCII. Wire and presentation formats are identical and interchangable. Suitable syntax, encoded as character arrays, for these resource records are either a 64 bit unsigned integer, or two 32 bit unsigned integers delimited by a period.

CLA BP supports a wide range of CLAs; some IP based and others interfacing at different layers or via different network layer protocols . Those treated here represent the subset designed to operate overlaying IP networks, and hence have DNS services generally constantly available in a low latency environment. Primary among these are TCP, UDP and LTP over UDP CLAs operating over both IPv4 and IPv6 links. Table 1 describes an initial list of of valid values for a CLA RRTYPE, to be encoded as US-ASCII character arrays for both presentation and wire formats. It is possible for a node to deploy multiple CLAs using a single Node Number and IP address; TCP-v4 and UDP-v4 can work side by side on the same node, for example. To address this capability in the CLA RRTYPE, records may be expressed as a lone entry (i.e TCP-v6) or in a comma delimited format, expressing multiple values (i.e. TCP-v4,TCP-v6,LTP-v6).

Convergence Layer Adapters

Valid CLA RRTYPE Values
TCP-v4
TCP-v6
UDP-v4
UDP-v6
LTP-v4
LTP-v6
STCP-v4
STCP-v6
BSSP-v4
BSSP-v6
IPND-v4
IPND-v6

IANA Considerations IANA is requested to create CLA and IPN RRTYPES in the Domain Name System (DNS) Resource Record (RR) TYPEs registry.

Security Considerations This document should not affect the security of the Internet.

References Normative References