]> 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 allocation of an EtherType and multicast MAC address for Bundle Transfer Protocol - Unidirectional (BTP-U) to enable its use as a Convergence Layer on Ethernet networks. This provides an alternative to IP-based convergence layers for environments where Ethernet forwarding is operationally feasible but IP routing is unavailable or operationally undesirable. 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 This memo requests Ethernet parameters to enable BTP-U as a Convergence Layer for environments where Bundle Protocol nodes are connected by Ethernet or Ethernet-like technologies. Specifically:

• an EtherType to identify frames carrying BTP-U payloads ()
• a multicast MAC address for neighbor discovery and announcements ()

This convergence layer is applicable to:

• Physical Ethernet LANs
• Virtual Private Cloud (VPC) networks connecting bundle agents
• Ground-Station-as-a-Service (GSaaS) infrastructure
• Technologies supporting Ethernet framing, e.g., DVB-GSE (), 3GPP 5G Ethernet PDU Session types ( §5.6.10.2), and the US Space Development Agency's Optical Communications Terminal standard ( §3.4.8).

Primary use cases include mission modeling, testbed environments, and deployments where IP routing is unavailable or adds unnecessary complexity.

Applicability and Limitations

BTP-U Protocol Compliance This document specifies Ethernet encapsulation for . All protocol requirements, features, and recommendations defined in apply to this Ethernet profile. Implementations MUST implement all mandatory features and SHOULD implement all recommended features, including Segmentation for handling bundles that exceed the Ethernet MTU.

Congestion Control BTP-U lacks a congestion control mechanism and presumes sending rate is externally managed. Ethernet flow control mechanisms exist but, may not be operationally applicable in all situations (e.g. high delay links). 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 IP-based convergence layers (TCPCL , UDPCLv2 ) remain recommended where IP infrastructure exists. This Ethernet convergence layer addresses scenarios where:

• no operational IP addressing or routing is available
• only IPv4 or IPv6 link-local addresses exist and peer discovery is unspecified
• direct Ethernet operation simplifies deployment and management

Header overhead savings (28-48+ bytes) are secondary to operational utility in non-IP environments.

Conventions and Definitions 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. As this memo is Informational it uses BCP14 langauge only for clarity.

Assignment Considerations Allocation of the following Ethernet parameters is requested.

IEEE Assignment Considerations

EtherType (per ) The IESG is requested to approve applying to the IEEE Registration Authority for an EtherType for BTP-U. (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.) (if approved) The following entry has been added to the "ETHER TYPES" subregistry of the "IEEE 802 Numbers" registry : Ethertype (decimal): YYYY Ethertype (hex): YYYY Exp. Ethernet (decimal): - Exp. Ethernet (octal): - Description: BTP-U payloads References: RFC ZZZZ (this document)

IANA Considerations

Multicast MAC Address One multicast MAC address is requested to enable neighbor discovery and bundle availability announcements within a broadcast domain. This allows BTP-U senders to reach all capable receivers without prior knowledge of individual MAC addresses. 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

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 and its extensions.

BTP-U Virtual Channels Transfer Numbers are unique within a "virtual channel." For Ethernet, the virtual channel is identified by:

• Source MAC address (6 octets)
• Destination MAC address (6 octets)
• C-VLAN ID (12 bits, if 802.1Q tag present)

Each unique combination defines a separate virtual channel with independent Transfer Number sequencing. Other technologies that support Ethernet-like framing and use of this EtherType () but which lack the above virtual channel identifers MUST define the equivalent virtual channel identifiers, e.g. technology-specific source and/or destination as well as any protocol-specific channel discriminators. When using the multicast MAC address for transmitting to receivers whose MAC addresses have not yet been learned, all receivers in the broadcast domain share the same destination address (and therefore the same virtual channel). Implementations relying on multicast SHOULD use additional mechanisms, i.e. the Bundle destination EID, to determine whether received bundles are intended for local processing. Once a sender learns a peer's MAC address, implementations SHOULD switch to unicast transmission.

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 . Implementations MAY support jumbo frames with payload sizes up to 9000 octets or larger, but SHOULD only enable this capability when explicitly configured where operators have verified that the network path supports the larger frame size. Since has no path MTU discovery mechanism and Ethernet networks silently drop oversized frames, implementations SHOULD default to 1500 octets. Link Layer Discovery Protocol (LLDP) MAY be used to discover directly-connected link and neighbor parameters.

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 already documented in and .

Denial of Service BTP-U assumes the sending rate is controlled by a mechanism out of scope for the protocol and has no built-in 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.

Link-layer Security 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 (), which may be used restrict access to the link to authorized participants, and IEEE 802.1AE (), which offers confidentiality of the entire BTP-U payload.

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

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. The Johns Hopkins University Applied Physics Laboratory Science Applications International Corporation This document describes a UDP convergence layer (UDPCL) for Delay- Tolerant Networking (DTN). This version of the UDPCL protocol clarifies requirements of the earlier experimental RFC 7122, adds discussion of multicast addressing, congestion signaling, and updates to the Bundle Protocol (BP) contents, encodings, and convergence layer requirements in BP version 7. Specifically, the UDPCL uses CBOR-encoded BPv7 bundles as its service data unit being transported and provides an unacknowledged transport of such bundles. This version of UDPCL also includes security and extensibility mechanisms. 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. IANA n.d. IEEE IEEE IEEE ETSI 3GPP Space Development Agency

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