]> Aalyria Technologies, Inc.

ek.ietf@gmail.com

Internet Delay/Disruption Tolerant Networking Delay and Distruption Tolerant Networking DTN Bundle Protocol BP BTP-U Ethernet BTPoE This memo requests Ethernet parameters for Bundle Transfer Protocol - Unidirectional for use on Ethernet and Ethernet-like links. This is not intended to replace existing IP-based Convergence Layer (CLs). Rather this makes it possible to use Ethernet with BTP-U as a CL in environments where Ethernet-like operation better matches the network infrastructure or operational constraints. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction When two Bundle nodes are connected by an Ethernet link, or by a technology that emulates Ethernet, it may be possible for a Bundle Protocol Agent to transmit Bundles in the payload of an Ethernet frame without higher layer protocol Convergence Layer (CL) overhead. Examples of "Ethernet-like" Technologies include Digital Video Broadcast Generic Stream Encapsulation ([DVB-GSE]). This memo recommends use of Bundle Transfer Protocol - Unidirectional for this purpose and requests some Ethernet parameters to support this. Specifically, it requests: an EtherType for identifying frames carrying BTP-U payloads () and a multicast MAC address, for indicating the frame is addressed to all BTP-U capable receivers (). While hypothetically applicable to a physical Ethernet LAN, it may be better utilized within Virtual Private Cloud (VPC) networks, which allow novel software-define connectivity among a set of cooperating Bundle processing cloud compute nodes (i.e. VMs). Such deployments can be useful for mission modeling, testbed activities, and may also integrate well with some Ground-Station-as-a-Service (GSaaS) network infrastructure.

Congestion Control BTP-U lacks a congestion control mechanism and presumes the sending rate is controlled by a lower layer or mechanism otherwise out of scope for BTP-U. Ethernet flow control mechanisms exist but, even if in use, they may not be sufficient to avoid significant loss of BTP-U frames in all situations. Additionally, a Bundle Protocol Agent may not be able to easily determine whether any Ethernet-level flow control mechanism is available. For deployments where congestion control cannot be managed by a mechanism outside of BTP-U, network operators must consider alternate Convergence Layers.

Relationship to IP-based Convergence Layers This Ethernet Convergence Layer is not intended to replace IP-based CLs where their use would be more appropriate. While use of direct encapsulation within an Ethernet frame avoids incurring some IP and UDP/TCP header overhead (28 to 48 bytes, or more, depending on Internet Protocol version and other options). These savings, however, are not the primary motivation. Rather, some Bundle Protocol deployments utilize links which may not have any operational IP addressing or routing. Convergence Layers like and have many useful features and remain recommended wherever deployable. This may include some links where only IPv6 Link-Local Addresses are available, though how a Bundle Protocol Agent obtains the IPv6 Link-Local Address of a peer is a deployment-specific matter.

Assignment of an EtherType by IEEE The IESG is requested to approve applying to the IEEE Registration Authority for an EtherType for BTP-Y. The IESG should communicate its approval to IANA and to those concerned with this document. IANA will forward the IESG Approval to the registry expert of the "EtherType" registry from the "IEEE 802 Numbers" registry group who will make the application to the IEEE Registration Authority, keeping IANA informed.

IANA Considerations Allocation of the following Ethernet parameters is requested.

EtherType (if approved) The following entry has been added to the "ETHER TYPES" subregistry of the "IEEE 802 Numbers" registry [IANA-IEEE802]: Ethertype (decimal): YYYY Ethertype (hex): YYYY Exp. Ethernet (decimal): - Exp. Ethernet (octal): - Description: BTP-U payloads References: RFC ZZZZ (this document)

Multicast MAC Address In order to identify "all Bundle Transfer Protocol - Unicast over Ethernet capable receivers" within a broadcast domain, IANA is requested to allocate one Multicast MAC address. Following the recommended format given as the EUI-48 Identifier template in : Applicant Name: IETF DTN Working Group Applicant Email: dtn@ietf.org Applicant Telephone: (none) Use Name: Bundle Transfer Protocol - Unidirectional Document: This memo is an application for one multicast EUI-48 identifier.

Operational Considerations In addition to issue around congenstion control and lack of feedback about excess sending rate noted above (), some addition operational considerations are noted below.

Checksums To reiterate the observation in §3.5 of , the Bundle Protocol specifications assume that Bundles "are transmitted over an erasure channel, i.e., a channel that either delivers packets correctly or not at all". Ethernet's Frame Check Sequence (FCS) minimally meets this requirement to ensure Bundles are not corrupted in transmission. Use of stronger integrity checks are left to BTP-U.

BTP-U Channels All Transfers are implicitly scoped to a "virtual channel" within which a given Transfer Number is unique (modulo 32-bit roll-over). In the case of an Ethernet frame containing the EtherType value given in , the virtual channel is identified by the combination of the Source MAC address, Destination MAC address, and optional C-VLAN ID (if present). Other Ethernet-like link-layer protocols must define the combination of elements that identify a virtual channel whenever specifying use of this EtherType . In principle this would comprise a source identifier, a destination identifer, and any additional elements or extensions specific to the given protocol that distinguish one logical link-layer "channel" from another. The exact details are out of scope of this document.

MTU and Jumbo Frames Implementations must support transmission and reception of frames with payload sizes up to 1500 octets (standard Ethernet MTU minus Ethernet header), as required by [IEEE802dot3]. Implementations may support jumbo frames with payload sizes up to 9000 octets or larger, but should only enable this capability when explicitly configured by operators who have verified that the network path supports the larger frame size. MTU mismatches in Ethernet networks result in frame drops, and does not have any mechanism to probe for Path MTU. Implementations may use Ethernet-specific protocols, like Link Layer Discovery Protocol (LLDP), to discover supported frame sizes on directly connected links, but should default to conservative MTU values (1500 octets).

Fragmentation and Segmentation When transmitting Bundles that exceed the Ethernet CL's MTU, a BP agent must decide how to break up a Bundle into multiple transmissible frames. Both Fragmentation and Segmentation may be viable options. However, Bundle Fragmentation may not always result in a transmissible frame: Bundle Processing Control Flags may prohibit fragmentation, and Block Processing Control Flags may require extension blocks to be replicated with every fragment, either of which may result in Bundle Fragments that exceed the Ethernet MTU. For this reason, Segmentation is recommended.

Filtering A common security paradigm is to "default deny" all traffic patterns that, broadly, do not conform to operator expectations. In such environments it may be that the BTP-U EtherType needs to be added to an allowlist or otherwise explicitly permitted to be used on a given Ethernet segment before BTP-U messages can be successfully delivered.

Security Considerations This document requests assignment of an EtherType and Multicast MAC address for BTP-U datagrams. It has no incremental implications for security beyond those in the relevant protocols. BTP-U assumes the sending rate is controlled by a mechanism out of scope for the protocol and has no builtin mechanism for identifying or mitigating any congestion a sender might cause. Use of this protocol on some networks, a shared LAN segment for example, may cause a Denial-of-Service by flooding Ethernet switches and stations. Any attacker with access to the link, or with sufficient knowledge of local Bundle forwarding configuration so as to inject BTP-U frames and cause them to be sent to an Ethernet peer, may overwhelm the receiver to the point of Denial of Service to other onlink senders. IEEE standards include several security mechanisms that may be used in Ethernet networks. Examples of recommended Ethernet-level security mechanisms a network might deploy include: IEEE 802.1X (TODO: reference), which may be used restrict access to the link to authorized participants, and IEEE 802.1AE (TODO: reference), which would offers confidentiality of the entire BTP-U payload.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. Aalyria Technologies This document defines a protocol for the unidirectional transfer of large binary objects, typically Bundle Protocol version 7 bundles, between two nodes connected by a unidirectional, unreliable, frame- based link-layer protocol, without requiring IP services. The protocol does not require a return path for acknowledgements, but instead supports data repetition as a mechanism to protect against data loss. It fully supports the disaggregation of flows of binary objects of different priority, preventing head-of-line blocking impacting performance. The wire format of the protocol is designed to enable performant implementation in hardware or software, with the aim of enabling protocol implementations to run at the line-rate of the underlying link-layer protocol. This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several aspects of such parameters and their use in IETF protocols, specifies IANA considerations for assignment of points under the IANA Organizationally Unique Identifier (OUI), and provides some values for use in documentation. This document obsoletes RFC 7042.

Acknowledgments Thanks to Wes Eddy, Jeorg Ott, Brian Sipos, and Rick Taylor for numerous discussions and contributions.