| Internet-Draft | BPv7 CLA Services | October 2022 |
| Sipos | Expires 20 April 2023 | [Page] |
This document attempts to harmonize the services expected of a Convergence Layer Adapter (CLA) by an overlaying Bundle Protocol Agent (BPA). This harmonization is based on combining the various existing CLA behaviors into a set of minimum expected service interfaces.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Before this document, each convergence layer (CL) definition included (or implied) its own set of specific services and primitives that would be supported by an associated convergence layer adapter (CLA). From the perspective of capabilities and behaviors of an individual CLA this is sensible, but from the perspective of the Bundle Protocol Agent (BPA) this lack of consistency in both capability and naming makes the logical interface between BPA and its CLAs difficult to manage and in many cases implementation dependent (both in capability and in terminology).¶
The task of this document is thus to harmonize the CLA interface into a set of distinct and consistently named services, each composed of primitives inspired by the ISO naming convention of "request" meaning a service user intending to invoke an activity on the service provider and "indication" meaning the service provider giving status of an activity to a service user.¶
Because the wide variety of transport mechanisms used across the various CLs and their differing aspects (see Section 2) many of the requests or indications do not apply and are not used or usable by any particular CLA (see Appendix A for some examples).¶
This document is based on existing CLs which transport over UDP [RFC7122] [CCSDS-BP], TCP [RFC9174], LTP/UDP [RFC5326] [RFC7122], and BIBE [I-D.ietf-dtn-bibect].¶
This document does not specify any additional services needed of existing CL specifications. In cases where existing CLs deviate from these service definitions it represents a possible future enhancement to the CL to harmonize it with these idealized services.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following are definitions necessary to understand the services and functions in this document.¶
This section attempts to categorize existing CLs by a few different critical aspects of their behavior. This expands on the general terminology of Section 1.2 with definitions specific to those aspects.¶
There is currently no concept of a "streaming" CL. All CLAs must operate with bundles as their service data unit (SDU) so must behave as a datagram service to the BPA. In the case where the underlying transport is an octet stream (e.g., the TCPCL using TCP) the CL itself must encapsulate the encoded bundles into the transport stream.¶
The reliability of a CL is determined by whether or not the CLA transmitting a bundle has a positive indication of the reception of the bundle above the transport itself. For example, it is not enough for TCP to acknowledge that the TCP/IP stack has received the segment; the CLA MUST have feedback from the receiving BPA that the bundle has progressed all the way "into the receiving node."¶
Although the reliability of a CL is at the level of the entire bundle, some CLs also provide segmentation of the bundle data in order to provide additional capabilities such as selective retransmission, intermediate progress, or interleaving of transfers on the same stream. In the absence of segmentation a CL performs its transfers atomically; either all or nothing.¶
Some CLs operate over transports that require establishment of connections before transfers can be made, while other CLs operate on connectionless transports which can transfer datagrams unsolicited. In some cases a security association can necessitate a connection-like shared state between peers. Even for connectionless transports there can be recommendations about "conversation" state keeping to allow the transport to operate consistently through middleboxes.¶
The BPv7 specification [RFC9171] does not impose an upper-bound on either the size of the payload data or the size of the overall encoded bundle. Despite this, some CLs have a natural upper bound on the size of bundle which can be transferred. In other cases, a profile of the CL can reduce the effective upper bound of bundle size.¶
While the LTPCL and TCPCL technically allow a 64-bit transfer size, the UDPCL by its nature is limited to 64KiB on IPv4 and only in certain circumstances can be enlarged on IPv6 jumbograms Section 4 of [RFC2675]. Large datagram sizes however will run into path MTU and fragmentation issues [RFC8900].¶
Each of the following subsections defines an independent service provided by a CLA to a BPA. Depending on the mechanics of the specific CLA, not all of the requests or indications listed here will be meaningful or used.¶
The principal purpose of any CLA is to allow a BPA to transmit bundle data to a peer node's BPA. Because of this, all CLAs SHALL support the Bundle Transmission service.¶
Each transmission is a time-bounded activity to transfer a bundle from the local CLA to a peer CLA. Transmissions are always initiated by the local BPA, and it is out of scope of this document to determine when a bundle is ready for transmission over a particular CLA to a particular peer.¶
Each transmission is identified by a CLA-defined transmission ID which is unique within the context of a single BPA--CLA association. The bundle identity is not a sufficient transmission ID because a CLA can request duplicated transmissions (across time or simultaneously) of the same bundle from the same CLA.¶
+---------------+ error
| Begin +------------+ before
| Transmission | v start
| Request | +---------------+
+-------+-------+ | Transmission |
| | Failure |
v | Indication |
+---------------+ +---------------+
| Transmission | ^
+--+ Started | | error
| | Indication +------------+ after
| +-------+-------+ | start
| | |
| v |
| +---------------+ |
| | Transmission | |
| | Progress +------------+
| | Indication | |
| +-------+-------+ +-------+-------+
| | | Interrupt |
| v |> Transmission |
| +---------------+ | Request |
| | Transmission | +---------------+
+->| Success |
| Indication |
+---------------+
The primitives associated with this service are in the following subsections.¶
The BPA requests transfer of an individual encoded bundle with parameters indicating to what CLA peer the transmission is destined. Any queueing of transmissions is the obligation of the BPA, as soon as the request is made to the CLA the transmission MAY begin.¶
Each transmission SHALL include an absolute time deadline based on at least the bundle lifetime. The BPA MAY expand or reduce the deadline based on other factors including: the bundle size, the expected or estimated network throughput and loss rate, the expected or estimated one-way light time (OWLT) to and from the peer.¶
Parameters to this request include:¶
Along with the bundle data itself, the BPA provides requirements about the transport security such as: the required identity of the peer, requirement for authentication, if the transport must be confidential or integrity-checked, etc.¶
Many of the needs are optional rather than purely boolean in that some aspects of security can be labeled as "don't care" to allow opportunistic security [RFC7435].¶
The result of this request SHALL be a unique transmission ID used to correlate later interactions with the request.¶
Following this request exactly one of the following SHALL be indicated: Transmission Started, if the transmission is in fact started, or Transmission Failure if the CLA cannot accommodate the request for whatever reason.¶
Even for unreliable transports, the CLA indicates to the BPA when the transmission is actually started. Because of contention for resources (e.g., socket writes or rate-limiting tokens) the actual start of transmission can be delayed from the request to begin transmission.¶
Parameters to this indication include:¶
Not all CLAs will support the notion of a segmented transfer. For those that do, this indication provides information to the BPA about how far along a transmission has progressed since the start. If a transmission is completed in a single unit, either the whole data atomically or as a single segment, this indication SHALL NOT be provided. The size in this indication SHALL be relative to the bundle data being transmitted and not include any segmentation or transport overhead. When the CLA is reliable, this indication SHALL include only peer acknowledged progress.¶
Parameters to this indication include:¶
This indication concludes a transmission and informs the BPA that it was a success. An unreliable CL will always indicate success upon completion. When the CLA is reliable, this indication SHALL include only peer acknowledged progress.¶
Parameters to this indication include:¶
This indication concludes a transmission and informs the BPA that a failure occurred. The reason for the failure is CL-dependent and MAY be absent if a CL has non-specific failures.¶
Parameters to this indication include:¶
This request provides a way for the BPA to cancel transmission any time after it is started and before its deadline has expired.¶
Parameters to this request include:¶
Following this request the Transmission Failure MAY be indicated if the interruption applied before the transmission finished.¶
A necessary part of any CLA is the ability to receive from peer nodes BPA in an asynchronous manner. Because of this, all CLAs SHALL support the Bundle Reception service.¶
Each reception is a time-bounded activity to transfer a bundle from a peer CLA to the local CLA. Receptions are always initiated by a peer CLA, so the start of a reception is an indication. Before a reception can be started the local CLA needs to either be in an established session (where applicable, see Section 3.3) or listening for datagrams (where applicable, see Section 3.4).¶
Each reception is identified by a CLA-defined reception ID which is unique within the context of a single BPA--CLA association. The bundle identity is not a sufficient reception ID because a CLA can receive duplicated transmissions (across time or simultaneously) of the same bundle and also the reception ID is needed before any bundle primary block data is received.¶
+---------------+
| Passive |
| Listening | +---------------+
+-------+-------+ | Reception |
| | Failure |
v | Indication |
+---------------+ +---------------+
| Reception | ^
+--+ Started | |
| | Indication +------------+
| +-------+-------+ |
| | |
| v |
| +---------------+ |
| | Reception | |
| | Progress +------------+
| | Indication | |
| +-------+-------+ +-------+-------+
| | | Interrupt |
| v |> Reception |
| +---------------+ | Request |
| | Reception | +---------------+
+->| Success |
| Indication |
+---------------+
The primitives associated with this service are in the following subsections.¶
The CLA indicates to the BPA when a reception is started.¶
Parameters to this indication include:¶
Not all CLs will support the notion of a segmented transfer. For those that do, this indication provides information to the BPA about how far along a reception has progressed since the start. If a reception is completed in a single unit, either the whole data atomically or as a single segment, this indication SHALL NOT be provided. The size in this indication SHALL be relative to the bundle data being transmitted and not include any segmentation or transport overhead. When the CL is reliable, this indication SHALL include only peer acknowledged progress.¶
Parameters to this indication include:¶
This indication concludes a reception and informs the BPA that it was a success as well as providing the actual bundle data received.¶
Parameters to this indication include:¶
This indication concludes a reception and informs the BPA that a failure occurred. The reason for the failure is CL-dependent and MAY be absent if a CL has non-specific failures.¶
Parameters to this indication include:¶
This request provides a way for the BPA to refuse reception any time after it is started.¶
If a CLA indicates current data head in its Reception Progress indication, this can be used to inspect the bundle's primary block before a large payload is received and preemptively refuse the bundle to save time and network volume.¶
Parameters to this request include:¶
Following this request the Reception Failure MAY be indicated if the interruption applied before the reception finished.¶
An optional service provided by connection-oriented CLs, such as the TCPCL of [RFC9174], is the ability to establish a session with a peer node before any bundles need to be sent to that peer. The distinction between a connection and session is that the connection is a service provided by the underlying transport while the session is a service of the convergence layer itself. Additionally, sessions can include a security association between peers which can amortize much of the processing time associated with authenticating and authorizing a peer connection.¶
Sessions MAY be initiated by the local CLA or as a response to passive listening by the local CLA to peer initiations. In either case, the Session State Changed indication is produced by the CLA as the sessions progress through to an established (or a failed or terminated) state.¶
Whether or not a CLA requires a session to perform the actual transfer of bundles does not affect the way in which the bundle-data-focused services in Section 3.1 and Section 3.2 operate. A CLA which uses sessions SHOULD transparently create a sessions as needed to perform a Bundle Transmission; the Transmission Started indication would just be delayed until after the session is established and ready for use. In the case where a session can not be established in a timely manner, the Transmission Failure indication would be used to inform the BPA that the bundle was not able to be sent.¶
In order to fit this service model, CLAs SHALL include pseudo-states which are associated with the session ending. Doing so avoids the need for a separate "session ended" indication.¶
+---------------+
| Attempt | +---------------+
|> Session | | Passive |
| Request | | Listening |
+-------+-------+ +-------+-------+
| |
+---------+---------+
|
v
+---------------+
| Session State |
| Changed |<-+
| Indication | |
+-------+-------+ |
| |
+----------+
|
+---------------+ |
| Terminate | |
|> Session +--+
| Request |
+---------------+
The primitives associated with this service are in the following subsections.¶
This request allows the local BPA to initiate a session with a peer. The attempt to create a session will not necessarily result in a session eventually having an established state with the desired peer. Configuration of the local or peer BPA can result in a session not being able to become established.¶
Parameters to this request include:¶
The result of this request SHALL be a unique session ID used to correlate later interactions with the session. The peer transport parameters are not a sufficient session identifier because a CLA can request and/or establish multiple sessions with the same peer.¶
This request allows the BPA to preemptively terminate a session with a peer. In the case where a CLA allows a clean termination procedure that will avoid transmission or reception failures, it is better to terminate than to simply stop the CLA.¶
Parameters to this request include:¶
The CLA indicates to the BPA when the state of a session changes in a way that would be visible to the BPA. The available states are specific to the CLA but can include pre-established handshaking states and pre-termination cleanup states.¶
Parameters to this indication include:¶
This optional request allows a BPA to poll the status of existing connections to peer nodes. This includes connections in which the local node was the active entity (i.e., the client) and in which the local node was the passive entity (i.e., the server).¶
The result of this request is list of session summaries, each containing:¶
In order to support the Bundle Reception service of Section 3.2 and/or the Persistent Session service of Section 3.3, a BPA must passively listen for network datagrams or connection attempts in accordance with the CL specifics. Because of this, all CLAs SHALL support the Passive Listening service.¶
The primitives associated with this service are in the following subsections.¶
This request informs the CLA when it is to begin passive listening on a transport. Because a single CLA would either not be able to listen concurrently with the same parameters, or not logically gain anything by doing so, there is no concept here of a listening identifier; the transport parameters used to listen are the identifier.¶
Parameters to this request include:¶
The result of this request SHALL be an indication of whether or not the request succeeded. There are many reasons why a set of parameters will not be able to listened for, including local network address assignments or other processes on the same host using the same transport parameters for listening.¶
This request informs the CLA when it is to end passive listening on a transport. This request SHALL be coupled with an earlier Begin Listening request, as there is no concept of ending listening before beginning.¶
Parameters to this request include:¶
This document does not define any requirements or structures which introduce new security considerations. All of the security considerations of specific convergence layers following this service model are all still applicable, including activities that are not covered by this model.¶
The parameters available as "Security Needs" in Begin Transmission or as "Security Metadata" in Reception Success are specific to the combination of the security capabilities of a CL and the security policy configured on a CLA.¶
This document does not affect any IANA registries.¶
This section explains how existing CLs relate to the idealized service model defined in this document. In some cases a CL can simply omit optional and non-applicable parts of this model. In other cases the CL can deviate from this model in meaningful ways, some by specification and some because of lack of specification of such detail in the CL definition.¶
There are two different "current" definitions of the UDPCL: one in Section 3.2.2 of [RFC7122] which is very vague on details of network addressing and port numbers, and another in Appendix B4 of [CCSDS-BP] which is more specific on some details but still ignores the effects of network middleboxes.¶
The UDPCL does not have any notion of a partial transmission or reception so no so will never indicate intermediate Transmission Progress or Reception Progress and has no ability to Interrupt Transmission or Interrupt Reception. The UDPCL is unreliable so will never indicate Transmission Failure. The UDPCL will never indicate Reception Started with a total size.¶
The peer transport parameters for the UDPCL are a network host name or address and a UDP port number.¶
The UDPCL does not have a concept of a persistent session, but implementations are encouraged to re-use source port numbers when transmitting to the same peer in order to be compatible with firewalls and other middleboxes.¶
Because they both share the same overall logic and workflow, this section applies to both the current TCPCL version 4 [RFC9174] and the earlier version 3 [RFC7242].¶
Although the TCPCL provides a reliable transfer between transmitter CLA and receiver CLA, there is no current requirement that mandates the receiver sending a final XFER_ACK only after the BPA has fully processed it (i.e. it will be either delivered, forwarded, or deleted but not silently dropped).¶
The TCPCL does not include a Begin Transmission deadline or the ability to interrupt a transmission. There is an assumption in its operation that a single transfer will complete in a short enough time that it will be insignificant compared to a bundle's lifetime. This is applicable for small bundles with long lifetimes, but can cause logical issues for large bundles and short lifetimes (relative to the network throughput).¶
The TCPCL will only indicate Reception Started with a total size if the sender of the bundle provided a size in an optional mechanism. For TCPCLv3 this is a separate pre-transfer message and for TCPCLv4 this is a transfer extension item.¶
The peer transport parameters for the TCPCL are a network host name or address and a TCP port number. A CLA SHOULD NOT make correlation assumptions between sessions to the same network host name or address. Only a session-reported Node ID MAY be used by a to correlate between TCPCL sessions.¶
The TCPCL has a concept of a persistent session which agrees with the service model of Section 3.3. While the TCPCL definition is more focused on the mechanics of session keeping and transfers as distinct activities, this document treats session keeping as a subordinate activity to transmissions (i.e., a CLA is free to transparently reuse a session or establish a new session in support of a transmission request with the same transport parameters).¶
Current LTP implementations do not universally have the concept of a Begin Transmission deadline and the version zero specification in [RFC5326] [RFC7122] do not mention reasons why a client would cancel a transmitting session. LTP has several types of internal segment-to-segment timers for reliable transport, but outside of an explicit transmission deadline a CLA provides no guarantee to the BPA about the aggregate effect of timer durations, backoff durations, OWLT assumptions or retry counts.¶
The peer transport parameters for the LTPCL-over-UDP are a network host name or address and a UDP port number. In some implementations, the peering logic is based on LTP Engine ID rather than transport parameters but ultimately there must be some mapping down to the transport parameters.¶
Although LTP transfers are associated with an "LTP session" this is not a persistent session as defined by Section 3.3; LTP has no persistent sessions.¶
The proposed bundle-in-bundle encapsulation (BIBE) service [I-D.ietf-dtn-bibect] acts as an administrative record type above the Administrative Entity [RFC9171] of a BPA as well as a CLA transport below a BPA.¶
The proposed BIBE transport is atomic (any fragmentation of the encapsulating bundle is not considered to be part of the BIBE layer), so the BIBE will never indicate intermediate Transmission Progress or Reception Progress. Also because of that any Transmission Failure will occur immediately after start (as the encapsulating bundle is assembled) and any Reception Failure will occur immediately after start (as the encapsulating bundle payload is decoded).¶