]> Aalyria Technologies

rtaylor@aalyria.com

Aalyria Technologies

ek.ietf@gmail.com

INT Delay/Disruption Tolerant Networking DTN BPv7 QUIC Convergence Layer This document specifies a minimal convergence layer protocol for transferring Bundle Protocol version 7 (BPv7) bundles over QUIC. The protocol leverages QUIC's native capabilities for reliable streaming, connection management, and security. Reliable transfers use QUIC unidirectional streams carrying CBOR Sequences of definite-length byte strings, each containing exactly one bundle. A stream can carry successive bundles without closing between them. Unreliable transfers use the Bundle Transfer Protocol - Unidirectional (BTP-U) over QUIC datagrams. 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 Bundle Protocol version 7 (BPv7) requires Convergence Layer Adapters (CLAs) to transfer bundles between nodes. This document specifies the QUIC Bundle Protocol Convergence Layer, referred to in this document as "Qubicle", a minimal CLA using QUIC that embraces QUIC's native capabilities rather than layering additional protocol machinery. The design philosophy is simple: QUIC already provides reliable streams, multiplexing, flow control, congestion control, and integrated security. This specification adds only what is strictly necessary to transfer bundles. The protocol provides two services:

Reliable Service:

Bundles are transferred using reliable, ordered QUIC stream transport, with successive bundles permitted on each unidirectional stream. Each bundle is wrapped in a definite-length CBOR byte string. This does not guarantee successful completion across arbitrary contact loss or receiver failure.

Unreliable Service:

Bundles are transferred via QUIC datagrams using framing.

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.

BPA:

Bundle Protocol Agent, as defined in .

CLA:

Convergence Layer Adapter, as defined in . Also abbreviated "CL" where the context is clear.

Client:

The Qubicle peer that initiates the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.

Server:

The Qubicle peer that accepts the QUIC connection. This is a connection-level role and does not imply any restriction on bundle transfer direction.

Qubicle Session:

The period during which a QUIC connection is established between two Qubicle peers. A session begins when the QUIC handshake completes and ends when the QUIC connection closes. Both client and server are equal peers for the purpose of bundle transfer.

Applicability Statement Qubicle adds no transport machinery of its own, so its applicability to a given environment is that of QUIC itself: Qubicle SHOULD NOT be used where the QUIC transport cannot be expected to perform well. With the default transport parameters and timer values of general-purpose QUIC implementations, this primarily means deployments where round-trip times (RTTs) remain under a few seconds, so that QUIC's handshake and loss-recovery behavior are well matched to the path. This boundary is not fixed. QUIC's transport parameters and timers can be adjusted to longer-delay paths (), and a profile of QUIC developed for a particular environment, whether by tuning, by use of optional QUIC features such as 0-RTT resumption (), or by other means, applies to Qubicle sessions without modification. Where such a profile exists for an environment, Qubicle's applicability follows it. For extremely high-delay or disrupted environments such as deep space communications (e.g., Earth-Mars links with multi-minute RTTs) in the absence of such a profile, specialized protocols like the Licklider Transmission Protocol (LTP) may be more appropriate. Similarly, the SVCB-based DNS service discovery mechanism () SHOULD NOT be used in environments where DNS itself might not perform well. DNS-based discovery is NOT RECOMMENDED for use in DTN environments where DNS infrastructure is unavailable, network disruptions cause failed lookups or stale cached records, DNSSEC validation fails due to a mismatch between query RTT and valid signature lifetimes, or DNS query overhead is significant relative to available bandwidth. For such environments, implementations SHOULD support alternative CL provisioning mechanisms including manual configuration with pre-planned contact schedules, contact graph routing protocols that maintain topology independently of DNS, or out-of-band metadata distribution through mission management plane channels. A hybrid approach is RECOMMENDED for nodes bridging Internet and deep-space networks: use Qubicle with DNS discovery for Internet-side connections, and use alternate mission management planes for space-side connections.

Protocol Overview

Connection Establishment A Qubicle session is established by initiating a QUIC connection to a peer. The QUIC handshake authenticates both peers via TLS 1.3 as described in . The ALPN identifier for Qubicle is qbcl.

Peer Node Identification Qubicle does not exchange Node IDs in-band. A peer's Node ID is the Node ID carried in the BundleEID OtherName () of the certificate it presents during the TLS handshake. Accordingly, both client and server MUST present a certificate containing a BundleEID OtherName, and each peer MUST validate the certificate of the other as described in . The sole exception is a deployment in which a peer has already been configured with the Node ID of the remote peer by other means (e.g., a contact plan or manual configuration keyed on the remote address). Such a peer MAY accept a certificate lacking a BundleEID OtherName and associate the configured Node ID with the session instead. If the peer has a configured Node ID and the certificate also contains a BundleEID OtherName, the two MUST match; a mismatch MUST be treated as a certificate validation failure and the handshake terminated. The means by which a peer obtains the rendezvous information (address and port) for a remote Node ID, whether by manual configuration, contact plan, or DNS (see ), is independent of the identification mechanism above. Rendezvous information locates a candidate peer; only the authenticated certificate establishes which Node ID has actually been reached.

Reliable Bundle Transfer For reliable transfer, bundles are sent as successive items on QUIC unidirectional streams:

1. The sender selects an existing open sending stream at an item boundary, or creates a new unidirectional stream subject to .
2. The sender writes a complete bundle wrapped in a definite-length CBOR byte string as described in .
3. The sender MAY append another bundle after writing the complete preceding item, without closing the stream or waiting for acknowledgment of that item. Normal QUIC transmission constraints still apply.
4. When finished with the stream, the sender closes it at an item boundary by sending a STREAM frame with the FIN bit set.

Receivers MUST support multiple items per stream. Senders remain free to use a separate stream for each bundle. The receiver recognizes a complete bundle after consuming its byte-string head and all declared content bytes, and processes and hands off an accepted bundle to the BPA without waiting for FIN or the next item. The receiver MUST NOT deliver an incomplete bundle.

Transfer Completion QUIC provides reliable, in-order stream transport. This revision of Qubicle defines no convergence-layer acknowledgment; per-bundle reception reporting remains an open issue (). An individual bundle's transfer is complete from the sender's transport perspective when all stream bytes comprising its item, including the CBOR byte-string head, have been acknowledged by the peer's QUIC endpoint. Acknowledgment of FIN is not required for per-bundle transport completion. Implementations MUST associate each outgoing bundle with the stream-offset range occupied by its item and establish acknowledgment of every byte in that range before reporting Transmission Success. A successful write to the QUIC API, available flow-control credit, or acknowledgment of a later offset alone is not proof that the entire item was acknowledged. QUIC APIs vary in whether they expose sufficient acknowledgment information; not every implementation can provide immediate per-bundle completion indications. An implementation might have to defer a success indication until its API provides sufficient evidence. This revision does not specify a portable API mapping or an alternative completion signal for APIs that cannot provide that evidence. This completion signal is generated by the peer's QUIC transport implementation upon receipt of the data. It confirms that the data reached the peer's QUIC endpoint; it does not confirm that the peer's convergence layer has read the data, nor that the peer's BPA has accepted the bundle. In particular, data acknowledged by the QUIC endpoint but not yet consumed by the receiving application can be lost if the receiving process fails. Receivers SHOULD therefore read stream data promptly and pass each completed bundle to the BPA without unnecessary delay, so as to minimize the interval during which acknowledged data is held only in transport buffers. Transport completion is consequently distinct from complete reception and handoff by the remote CLA, and from reception processing by the remote BPA. It is not a sufficient basis for a sending BPA to conclude that the next-hop BPA has received a bundle. Where such assurance is required, it MUST come from an appropriate bundle-layer mechanism, not be inferred from transport completion. Ordinary status reporting () is not by itself a complete forwarding-node solution: the bundle source controls the primary-block report request and report-to destination. The integration needed for forwarding-node assurance remains unspecified in this revision; see . In terms of the convergence layer service model, Qubicle uses the following per-bundle indications to the BPA, subject to the API limitations above:

Transmission Success:

Acknowledgment of every byte in the item's stream-offset range, including its CBOR head, has been established. Neither stream closure nor acknowledgment of subsequent items is required.

Transmission Failure:

The stream was terminated through cancellation (), or the connection closed, before transport completion of this item could be established. This does not prove that the receiving BPA did not receive the bundle.

Reception Success:

The complete byte-string head and exactly the declared content length have been consumed, and the accepted bundle has been passed to the BPA, without waiting for FIN or another item. This handoff is distinct from the BPA's reception processing.

Reception Failure:

The item was rejected, truncated at clean stream end, or interrupted by stream cancellation or connection loss before completion and handoff; any partial bundle data has been discarded.

A later truncated, malformed, or interrupted item does not revoke Reception Success for bundles already completed and handed off. Likewise, a later stream reset or connection loss does not revoke an established Transmission Success for an earlier item. Transport success still does not establish remote CLA handoff or BPA reception. A sender MUST NOT issue both Transmission Success and Transmission Failure for the same transmission attempt. Once either terminal indication has been issued, later transport events, including delayed acknowledgments after cancellation, do not reverse it. A retry is a separate transmission attempt. Qubicle does not provide intermediate progress indications; a BPA requiring them can observe stream-level flow control state where the QUIC implementation exposes it.

Open Issue: Bundle Reception Reporting TODO: Specify how a forwarding BPA obtains a positive, bundle-by-bundle indication that the next-hop BPA has received a bundle, beyond acknowledgment of its bytes by QUIC. Evaluate incorporation of, or a reference to, the Bundle Protocol Hop Reception Report Request Block proposal: https://github.com/ekline/draft-dtn-hop-reception-report. Resolve applicability, correlation, peer authentication, and behavior when reports are unsupported, declined, delayed, or lost. This revision does not yet specify that integration. The candidate mechanism requests an ordinary Bundle Status Report addressed using the Previous Node block. It complements transport completion and does not transfer custody. The repository link is informational; the proposal is not a normative dependency of this revision, which adds neither an acknowledgment frame nor a requirement for reception reporting. A missing reception report does not establish failure. Transport success without a report does not distinguish unsupported reporting from receiver failure after transport acknowledgment.

Stream Content Each reliable-transfer stream carries a CBOR Sequence whose items MUST be definite-length CBOR byte strings. Each byte string MUST contain the complete encoding of exactly one bundle. Its declared length is the encoded bundle length in octets, excluding the byte string head (). The sender MUST know the outgoing encoded bundle's length before writing the head. The sequence has no enclosing array, bundle count, or separator. QUIC STREAM frame boundaries have no significance for this framing. A sender MUST NOT interleave bytes of different bundle items within one stream. Unwrapped bundles, indefinite-length byte strings, and other outer CBOR types are protocol errors. An empty byte string cannot contain a bundle and is a protocol error. The first octet of each item is interpreted as follows: Stream Content Dispatch

First Octet	Interpretation
0x40 - 0x5b	Definite-length CBOR byte string head; a zero content length is a protocol error
any other value	Protocol error

The receiver consumes the byte-string head and exactly the declared number of content octets to recognize a complete bundle. It processes and hands off an accepted bundle without waiting for FIN or the next item. Bytes following a complete item begin the next item. FIN is valid at an item boundary, including before any item: an empty, cleanly closed stream is an empty sequence. A clean stream end partway through a byte-string head or its declared content is malformed framing. A clean stream end requires FIN and receipt of all bytes preceding the final stream offset; FIN alone does not establish that missing bytes have arrived. For malformed framing, the receiver MUST close the connection with QBCL_PROTOCOL_ERROR. Stream reset or connection loss instead interrupts any incomplete transfer (); it is not a clean but malformed stream end. The receiver MUST NOT deliver an incomplete bundle. Bundles already completed and handed off remain completed even if a later item is truncated, malformed, or interrupted. Within each byte string, the first content octet identifies BPv7 by 0x9f (the indefinite-length outer array, ), or BPv6 by its version octet 0x06 (). Content that does not begin with a recognized bundle version encoding is a protocol error, and the receiver MUST close the connection with QBCL_PROTOCOL_ERROR. Qubicle implementations MUST support BPv7 bundles. Support for other bundle versions, including BPv6, is OPTIONAL; a receiver that recognizes but does not support the version of an incoming bundle SHOULD cancel the stream with QBCL_UNSUPPORTED_BUNDLE_VERSION rather than treating it as a protocol error. This cancellation affects the stream, not just that item; see . The wrapper does not change the inner BPv7 encoding, including its indefinite-length outer array. Declaring the bundle length before its content allows the receiver to make admission and storage decisions while transfers compete for stream slots, flow-control credit, and processing resources. The declaration supports these decisions but does not guarantee progress or prevent starvation. Streaming, including cut-through forwarding, remains possible when the exact outgoing encoded length is known before transmission. Forwarding an unknown-length outgoing encoding is not supported. The framing requirement applies only to reliable stream transfers; unreliable transfers retain encapsulation ().

Bundle Flow in Both Directions Both peers can send bundles simultaneously. Each peer creates unidirectional streams to send its bundles. QUIC stream IDs inherently separate client-initiated streams (IDs 2, 6, 10...) from server-initiated streams (IDs 3, 7, 11...), ensuring no collision between the two directions of bundle flow. Qubicle uses only unidirectional streams. Peers SHOULD set the initial_max_streams_bidi transport parameter to 0. A peer that nonetheless receives a bidirectional stream MUST treat this as a protocol error and close the connection with QBCL_PROTOCOL_ERROR.

Stream Selection and Priority A sender MAY implement bundle priority by scheduling data across multiple open streams and selecting which pending bundle to append to each stream, or whether to open a new stream. It MAY also use stream-priority facilities exposed by its QUIC implementation (). Qubicle defines no priority signaling on the wire. Scheduling remains subject to available stream and connection flow-control credit and QUIC congestion control. Supplying data to a QUIC implementation does not guarantee immediate transmission or preemption of data already queued inside it. A stream can serve as a persistent scheduling lane for successive bundles; "lane" is explanatory, not a separate protocol object. Bundles on one stream are serialized: a subsequent bundle cannot overtake an earlier item, and bytes of different items MUST NOT be interleaved. Independent scheduling requires different streams. Queued priority classes are distinct from these lanes. The number of lanes and their relationship to priority classes are implementation policy within QUIC's limits (); there is no mandatory priority-to-stream mapping. If every usable stream has lower-priority items ahead of a newly arrived higher-priority bundle and no new stream can be opened, that bundle can be delayed. Strict priority can indefinitely defer lower-priority transfers. If favored streams cannot progress, refusing to service other eligible streams can leave usable contact capacity idle. Fairness, admission policy, and any reservation of capacity for urgent traffic are implementation matters; Qubicle neither fixes the number of priority classes nor requires fair scheduling.

Flow Control and Stream Limits Qubicle defines no additional stream-count negotiation or parallelism limit. For each sending direction, stream creation follows the peer's initial_max_streams_uni and subsequent MAX_STREAMS, as specified in . These are cumulative stream-opening limits, not merely limits on the number currently open. Closing a stream does not by itself grant permission to open another; the receiver supplies additional credit. The two peers' advertisements govern opposite sending directions. Implementations may choose to use fewer streams. Permission to open a stream is distinct from the ability to transmit data. Active streams remain subject to stream-level and connection-level flow control (), congestion control, and sender scheduling. QUIC's initial_max_stream_data_uni and MAX_STREAM_DATA limit cumulative stream data, while initial_max_data and MAX_DATA limit cumulative data across streams. These are not fixed limits on data in flight or total bundle storage. A receiver that is temporarily unable to accept more data can withhold additional credit, causing the sender to pause once available credit is exhausted, without error. Receivers SHOULD grant credit based on the resources actually available for admitted transfers; see . Persistent streams reduce dependence on replenishment of stream-opening credit, but still require replenishment of stream-level and connection-level byte credit. If further streams cannot be opened, a sender can continue appending items to existing sending streams subject to these constraints.

Unreliable Bundle Transfer For unreliable transfer, bundles are sent using QUIC datagrams with framing. Support for the unreliable service is OPTIONAL. An implementation offering it MUST advertise the max_datagram_frame_size transport parameter. The unreliable service is available on a session only if both peers have advertised this parameter; otherwise neither peer sends DATAGRAM frames and only the reliable service is available. Implementations SHOULD make the availability of the unreliable service known to the BPA so that it can select an appropriate service for each bundle. Each QUIC DATAGRAM frame carries one or more messages, and plays the role of the Link-layer PDU in the model: it is delivered in its entirety or not at all. A sender MUST NOT construct a datagram larger than the peer's advertised max_datagram_frame_size, and SHOULD size datagrams to fit within the current path MTU so that they are not dropped by the QUIC layer. segmentation, reassembly, transfer identification, and optional repetition apply unchanged. The Transfer Window size () MUST be configured consistently at both peers; how this is done is out of scope for this document. QUIC DATAGRAM frames are subject to QUIC congestion control (), satisfying the requirement that it not be deployed without congestion control where congestion may occur. The mapping of bundle priority to transfer interleaving is an implementation matter.

Connection Termination A session ends when the QUIC connection closes, whether by an explicit CONNECTION_CLOSE from either peer or by expiry of the idle timeout (). Idle timeout is a normal way for a session to end, not an error; a peer with further bundles to send simply establishes a new session. A peer wishing to end a session gracefully SHOULD stop opening new streams, starting new bundle items on existing streams, and initiating new transfers. It SHOULD finish current items where feasible, close its sending streams at item boundaries, and allow outstanding reliable transfers in both directions to complete before closing the connection with QBCL_NO_ERROR. This revision defines no session-level shutdown signal to prevent the remote peer from starting further items or streams, so a peer SHOULD bound this wait with a local timer. A peer MAY instead close the connection immediately at any time. If it does so deliberately while transfers are in progress it SHOULD use QBCL_SHUTTING_DOWN; other codes in apply for error conditions. When a connection closes for any reason, the receiver MUST discard any partially received bundle data, as in . Bundles already completed and handed off remain completed. The sender reports Transmission Failure for outstanding items whose transport completion could not be established, subject to the acknowledgment/API limitations in ; established Transmission Success indications are not revoked. Re-forwarding is subject to BPA policy, since a failure to establish transport completion does not prove non-reception by the remote BPA. Any incomplete transfers on the session are likewise lost. Two peers may establish connections to each other concurrently, resulting in more than one session between the same pair of Node IDs. This is permitted and is not an error. A peer MAY choose to gracefully close a redundant session, but MUST accept bundles received on any established session.

Transfer Cancellation Either peer may cancel a reliable-transfer stream. RESET_STREAM and STOP_SENDING affect the stream, not one selected bundle item. This revision defines no per-bundle cancellation protocol. A sender cancels a stream by sending RESET_STREAM with an appropriate error code (), subject to QUIC's stream-state rules (). A sender might do this when a bundle's lifetime expires or the BPA withdraws a bundle whose item has already been started. A sender MUST NOT truncate an item and then append another item on the same stream: that would corrupt framing. It must finish the item or terminate the stream. A receiver cancels a stream by sending STOP_SENDING with an appropriate error code, for example when a bundle exceeds its storage or policy limits, or when its BPA is shutting down. The sender MUST handle STOP_SENDING according to and the stream-state rules in . In particular, a stream in the Send state still requires RESET_STREAM even if all item bytes written so far have been acknowledged; per-bundle transport completion does not close the stream. Cancelling a stream can abandon its current partial bundle and later queued or outstanding bundles. On receiving RESET_STREAM, a receiver MUST discard any partially received bundle data for that stream and MUST NOT deliver a partial bundle to the BPA. A receiver that has sent STOP_SENDING MUST likewise discard partial data and any subsequently received data on that stream. Cancellation does not revoke bundles already handed to the receiving BPA. An application error code describes a reason for stream cancellation; it does not identify the item that caused it. The sender may have queued multiple items ahead of the receiver. Cancellation can also race with transport acknowledgment and is not a reliable per-bundle rejection notification. The sender reports failure for affected items whose transport completion has not been established, as described in , without revoking established transport success. Bundles MAY be re-forwarded subject to BPA policy; a failure indication does not establish that they were not received. A receiver enforcing a maximum receivable bundle size can reject a bundle based on its declared length as soon as it has read the byte string head (), cancelling the stream with QBCL_BUNDLE_TOO_LARGE. Payload bytes, including later items, may already have been sent or received at that point. A receiver whose available storage cannot accommodate a transfer can cancel the stream with QBCL_STORAGE_EXHAUSTED. Admission and credit policies SHOULD consider the declared sizes of active bundles and allow admitted transfers to progress toward completion, rather than leaving many partial transfers unable to complete (). If a receiver elects to skip a rejected item and continue parsing instead of cancelling the stream, it MUST consume exactly the declared content length before reading the next head. This does not save transmission bandwidth or notify the sender of rejection, and does not relax the connection-close requirement for malformed framing. The initial stream flow-control allowance is not an advertised maximum bundle size. Receivers need sufficient available stream and connection credit to read each head, which can occupy up to nine octets and itself consumes credit. They can consume or spool data and replenish credit incrementally; they need not grant credit for an entire bundle at once. Cancellation of unreliable transfers is governed by .

Keepalive Qubicle relies on QUIC's native idle timeout mechanism. Peers negotiate the max_idle_timeout transport parameter during connection establishment. See for guidance on selecting this and related values. Where a session must be kept alive across periods with no bundles to send, implementations MAY use QUIC PING frames () where the QUIC implementation exposes such a facility. Keepalives should be balanced against the idle timeout guidance in : a session that is deliberately allowed to time out and re-established later can be preferable to keeping one alive through a scheduled link outage.

Error Codes Qubicle defines a single space of application error codes, used in the QUIC CONNECTION_CLOSE frame (with the application-level frame type, see ), RESET_STREAM frame, and STOP_SENDING frame. QUIC application error codes are 62-bit unsigned integers. Qubicle Error Codes

Code	Name	Description
0x00	QBCL_NO_ERROR	Graceful connection closure, no error
0x01	QBCL_PROTOCOL_ERROR	Peer violated this specification
0x02	QBCL_TRANSFER_CANCELLED	Transfer aborted for a reason not otherwise specified (e.g., bundle lifetime expired, BPA withdrew the bundle)
0x03	QBCL_BUNDLE_TOO_LARGE	Incoming bundle exceeds the receiver's maximum receivable bundle size
0x04	QBCL_STORAGE_EXHAUSTED	Receiver temporarily cannot accept bundles; the sender MAY retry later
0x05	QBCL_SHUTTING_DOWN	Peer is deliberately closing the session; no fault is implied
0x06	Reserved
0x07	QBCL_UNSUPPORTED_BUNDLE_VERSION	Receiver does not support the version of the bundle being transferred

QBCL_NO_ERROR is only meaningful on CONNECTION_CLOSE. A cancelled transfer always has a cause, so peers MUST NOT use QBCL_NO_ERROR in RESET_STREAM or STOP_SENDING; a peer receiving it there SHOULD treat it as QBCL_TRANSFER_CANCELLED. When a peer closes the session deliberately while transfers are still in progress, it SHOULD use QBCL_SHUTTING_DOWN on CONNECTION_CLOSE rather than QBCL_NO_ERROR, so that the remote peer can distinguish an orderly shutdown with collateral transfer failures from an idle close. A peer receiving an unrecognized error code MUST treat it as QBCL_PROTOCOL_ERROR on CONNECTION_CLOSE and as QBCL_TRANSFER_CANCELLED on RESET_STREAM or STOP_SENDING.

Security Considerations

Transport Security QUIC mandates TLS 1.3 for all connections, providing confidentiality, integrity, and authentication. Qubicle inherits these security properties. As specified in , Qubicle requires mutual certificate authentication: both client and server present certificates, and each peer validates the other's certificate before exchanging bundles. Certificate validation, including the BundleEID OtherName checks and the applicable certificate profile, SHOULD follow . Automated certificate provisioning is available via the ACME extensions defined in .

Bundle Security Transport security protects bundles in transit between adjacent nodes. For end-to-end bundle security, implementations SHOULD use BPSec .

Denial of Service QUIC provides built-in protection against many denial-of-service attacks, including address validation and amplification prevention. QUIC flow control () is the primary means of bounding the resources a peer can consume; receivers SHOULD configure it accordingly rather than accepting unbounded data and discarding it afterwards.

0-RTT Considerations QUIC 0-RTT data is not protected against replay. Because a replayed bundle transfer could cause a bundle to be received and forwarded more than once, implementations SHOULD NOT send bundles as 0-RTT data, and servers MAY decline to accept 0-RTT altogether. 0-RTT resumption could nonetheless materially reduce session establishment cost on long-delay paths between peers that reconnect frequently. The consequence of a replayed transfer is duplicate receipt of a bundle, which a BPA can detect from the combination of source node ID and creation timestamp () together with any fragment offset, except for anonymous bundles, and whose impact is bounded where BPSec () protects the bundle. Whether this risk is acceptable in a given environment is a matter for operational experience and for any QUIC profile applicable to that environment (); a deployment that does permit 0-RTT SHOULD ensure that its BPAs perform duplicate bundle detection.

Operational Considerations

Version Negotiation To resist ossification, Qubicle endpoints are RECOMMENDED to support QUIC version 2 and compatible version negotiation . Qubicle operates identically over any QUIC version providing the features used in this document.

Timer and Transport Parameter Tuning QUIC connection behavior is governed by a number of timers. Some are negotiated via transport parameters during the handshake (e.g., max_idle_timeout and max_ack_delay), while others are derived locally from measured path characteristics (e.g., the Probe Timeout (PTO) computed from RTT estimates per , seeded by an implementation's initial RTT value). In many deployments, particularly those on the terrestrial Internet, the default values recommended by and and used by general-purpose QUIC implementations are expected to be adequate, and Qubicle implementations MAY use them unchanged. However, Qubicle peers may possess knowledge of end-to-end path characteristics that is unavailable to the QUIC transport itself, for example from contact plans, orbital mechanics, or link scheduling information in non-terrestrial deployments. Such information may indicate expected propagation delays, predictable link outages, or highly asymmetric paths for which Internet defaults are inappropriate (e.g., an idle timeout short enough to be tripped by a scheduled link gap, or an initial RTT small enough to cause spurious PTO retransmissions during the handshake). Implementations SHOULD allow these timers and transport parameters to be configured on a per-peer basis so that they can be adjusted using such knowledge. The means by which such path knowledge is obtained, and the specific adjustments derived from it, are out of scope for this document and may be the subject of environment-specific QUIC profiles.

Flow Control Sizing Stream-opening credit, per-stream data credit, and connection-level data credit () interact with receiver admission and sender scheduling. Partial transfers can collectively occupy storage, stream slots, and connection credit without any bundle completing. This can stall useful progress or waste a finite contact. Receiver admission and credit policies SHOULD consider the declared sizes of active bundles and allow admitted transfers to progress toward completion. The length prefix supplies information for that policy; it is not a deadlock-prevention mechanism and does not prevent starvation. The receiver needs sufficient initial stream and connection credit to read the first CBOR byte-string head, which can occupy up to nine octets, and sufficient replenished credit for subsequent heads. Each head itself consumes both kinds of flow-control credit. A receiver need not grant credit for an entire bundle at once: it can consume or spool data and replenish credit incrementally. Granting credit SHOULD reflect actual available resources, including storage retained for partial bundles even after data has been consumed from transport buffers. Declared lengths are untrusted input and MUST NOT cause unchecked allocation. The initial flow-control allowance is not an advertised maximum bundle size; size and resource-based rejection are described in . On a persistent stream, completing an item neither closes the stream nor replenishes byte credit automatically. Successive items reduce the need for new stream-opening credit but still depend on replenishment of byte credit. Receiver admission policies must also account for later items that the sender may already have queued on the same stream. Throughput depends on available credit and how promptly it is replenished relative to the path RTT, not on treating QUIC's cumulative limits as fixed receive windows. Too little available credit, or replenishment that arrives too late, can leave a high-bandwidth, high-delay path underutilized. The appropriate balance between storage commitment, parallelism, and throughput is deployment-specific, and the same out-of-scope path knowledge discussed in can inform it.

Convergence Layer Fallback As noted in , some networks block UDP traffic such that Qubicle connections cannot be established. Bundle Protocol Agents that employ Qubicle are RECOMMENDED to support additional Convergence Layers, e.g. TCPCLv4 .

Coexistence With Other UDP-based Convergence Layers It is RECOMMENDED that Qubicle implementations use a dedicated UDP port for operational simplicity. Bundle Protocol Agents that employ Qubicle and other UDP-based Convergence Layers on the same UDP port MUST be able to disambiguate received datagrams in order to route them to the correct CLA. For UDP CLs that use DTLS, provides the required guidance to disambiguate QUIC traffic from DTLS-encapsulated CL traffic.

Finding a Qubicle Endpoint Via DNS Qubicle senders may be manually provisioned with a hostname (or IP addresses) and UDP port corresponding to the listening Qubicle endpoint for a peer Bundle Protocol Agent. If only a hostname is known but a port is not, SVCB Resource Records may be looked up to find a listening UDP port and confirm expected ALPN configuration. Consider this zone file for example.: A BPA supporting both TCPCLv4 and Qubicle may attempt to resolve an SRV record for the _dtn-bundle._tcp prefixed hostname. A BPA that supports Qubicle might also issue DNS SVCB queries for the prefix "_qbcl". The sample above indicates that mars-orbiter.example. has an SVCB record in AliasMode referring to cloud-agent.example. The SVCB record associated with cloud-agent.example. contains all required QUIC transport rendezvous information.

IANA Considerations

ALPN Identifier IANA is requested to register the following ALPN identifier in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry: ALPN Registration

Protocol	Identification Sequence	Reference
Qubicle	0x71 0x62 0x63 0x6C ("qbcl")	This document

AttrLeaf Node Name Per , IANA is requested to add the following entry to the DNS "Underscored and Globally Scoped DNS Node Names" registry: AttrLeaf Registration

RR Type	_NODE NAME	Reference
SVCB	_qbcl	this document

Application Error Codes IANA is requested to create a new registry "Qubicle Error Codes". Values in this registry are 62-bit unsigned integers, matching the range of QUIC application error codes. Each entry consists of a Code, a Name, a brief Description, and a Reference. The registration policy for this registry is Specification Required for codes in the range 0x00 to 0x3FFFFFFF. Codes in the range 0x40000000 to 0x3FFFFFFFFFFFFFFF are reserved for Private Use and are not assigned by IANA. The initial contents of the registry are: Error Code Registry

Code	Name	Description	Reference
0x00	QBCL_NO_ERROR	Graceful connection closure, no error	This document
0x01	QBCL_PROTOCOL_ERROR	Peer violated this specification	This document
0x02	QBCL_TRANSFER_CANCELLED	Transfer aborted, unspecified reason	This document
0x03	QBCL_BUNDLE_TOO_LARGE	Bundle exceeds receiver's maximum size	This document
0x04	QBCL_STORAGE_EXHAUSTED	Receiver temporarily cannot accept bundles	This document
0x05	QBCL_SHUTTING_DOWN	Peer is deliberately closing the session	This document
0x06	Reserved		This document
0x07	QBCL_UNSUPPORTED_BUNDLE_VERSION	Receiver does not support the bundle version	This document
0x08-0x3FFFFFFF	Unassigned
0x40000000-0x3FFFFFFFFFFFFFFF	Reserved for Private Use		This document

References Normative References Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services. 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 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. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. 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. This document describes how Transport Layer Security (TLS) is used to secure QUIC. 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. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. This document describes loss detection and congestion control mechanisms for QUIC. RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC and implementors of these application protocols. This document describes the Licklider Transmission Protocol (LTP), designed to provide retransmission-based reliability over links characterized by extremely long message round-trip times (RTTs) and/or frequent interruptions in connectivity. Since communication across interplanetary space is the most prominent example of this sort of environment, LTP is principally aimed at supporting "long-haul" reliable transmission in interplanetary space, but it has applications in other environments as well. This document is a product of the Delay Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This memo defines an Experimental Protocol for the Internet community. This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol that allows an ACME server to validate the Delay-Tolerant Networking (DTN) Node ID for an ACME client. A DTN Node ID is an identifier used in the Bundle Protocol (BP) to name a "singleton endpoint": an endpoint that is registered on a single BP Node. The DTN Node ID is encoded both as a certificate Subject Alternative Name (SAN) identity of type otherName with an Other Name form of BundleEID and as an ACME Identifier type "bundleEID".

Acknowledgments The authors thank Carlo Caini for discussions of QUIC stream concurrency, sender scheduling, and flow control that helped clarify the prioritization and framing requirements in this document.