| Internet-Draft | Bundle Protocol Application Framework | October 2022 |
| Blanchet | Expires 20 April 2023 | [Page] |
The current Bundle Protocol specifications define the syntax of service identifiers but do not identify how to make them interoperable. For example, there are currently no way to map a service identifier to a specific Bundle payload format for an application agent. This document proposes an application framework enabling interoperable implementations and deployments of the Bundle Protocol. It also creates a service identifier registry for the Bundle Protocol. Warning: this draft was initially done in 2012 against RFC5050 in DTNRG; some parts may need to be updated.¶
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.¶
The Bundle Protocol (BP) [RFC5050] specifies how to carry bundles over a delay and disruption tolerant network. Up to now, the various BP implementations have defined their own payload format for the applications they support, without any specification. Therefore, between two implementations, there is no garantee that the payloads will be properly processed. This prohibits interoperability between application agents of the various implementations.¶
The Bundle Protocol [RFC5050] uses Endpoint Identifiers to specify the destination of the bundles. Up to now, two types of identifiers have been defined:¶
Both schemes syntax carry the service identifier so that the bundle payload is sent to the right application agent and that application agent knows how to process it. Up to now, no definition of these service identifiers exist, therefore, each implementation does not know to which application agent it should send the received bundle payload.¶
From the point of view of implementations and end-users, the service identifier shall be common to both types of identifiers and the payload format should be identical for the same service identifiers. Therefore, there is a need to normalize the service identifiers as well as the payload formats. This is similar to service and port numbers registry for IP protocols and applications protocols specifications.¶
As with IP application protocols specifications, some applications require services at the IP layer, such as IPsec. In such cases, the application specification defines the usage and requirements of IPsec for carrying the application packets. Similarly, Bundle protocol applications may require specific bundle protocol services, such as custody, security, quality of service or else.¶
This document defines a framework by which Bundle Protocol applications should be specified, what bundle services they require and a registry of service identifiers. All together, implementations will interoperate at the application level, instead of just at the bundle forwarding level. Moreover, deployments will be eased by normalized behaviors of BP protocol stacks and applications.¶
The BP Application framework is specified as following:¶
A BP application is defined by a protocol and a bundle payload format. When a BP application protocol is specified in a document, it should be specified with the following information:¶
While the generic syntax of the dtn: uri is defined, the usage up to now in trials, deployments and implementations has been dtn:node_identifier/service_identifier. For the ipn scheme, the syntax is ipn:node_identifier.service_identifier. This document registers the service_identifier part values but makes no recommendation on the node identifier part.¶
For implementations and for interoperability between various BP network deployments, it is highly preferable that the service identifiers are identical for all deployments and all implementations.¶
This document requests IANA to create a registry for the service identifiers for both the ipn and the dtn: space. The common service identifiers will be identical for both schemes and for all deployments. The structure of the registry is:¶
Structure (aka columns):¶
Registration Policy:¶
The registry should contain the following initial values:¶
This section is requesting a registration for the above registry. It also serves as a simple example on how registration requests should be done.¶
The Ping service is similar to the IP ICMP Echo request/reply service where a source node sends a simple query to the destination node and the destination node replies. This helps troubleshooting the network and knowing if a node is reachable and up.¶
The ping service has the following Bundle Protocol payload format: TBD.¶
This document request the registration of the ping service in the above registry as follows:¶
For the purpose of space networking, the CCSDS SDO needs service identifier assignments for its own deployments. For the management of these assignments, registries for the node and service identifier part of the ipn scheme are managed by the CCSDS Registry Authority, Space Assigned Number Authority (SANA). This CCSDS registry of node and service identifiers is specific to space networks. However, for implementations and for interoperability between various network deployments, it is highly preferable that the service identifiers are identical for all deployments. Therefore, this document requests IANA to set aside a range of ipn service identifiers to be used by CCSDS and managed by its registry authority SANA.¶
The IP Services Names and Port Registry (IPSNPR) is used to list the service and port identifiers for IP packets. Within some DTN deployments, some IP protocols such as HTTP and SMTP have been transported inside the Bundle Protocol payloads. Some other DTN deployments are using non IETF protocols. Therefore, there is some overlap but also some specific DTN applications. The number of IP protocols that will be carried directly as BP payloads are most likely very small, and would not include the vast majority of the port numbers found in the IPSNPR. Therefore, it is proposed to start a new registry from scratch instead of trying to overload or sync with the IPSNPR.¶
Establishing a registry of service identifiers so that implementations and deployments can interoperate does not bring any specific security concerns and does not add any security. As with the IP services and port registry, the existence of such registry have not brought any security concerns.¶
IANA is requested to create a registry as specified in this document.¶
The editor would like to thank the following people who have provided comments and suggestions to this document, in no specific order: Stephen Farrell, Keith Scott, Scott Burleigh.¶