Internet DRAFT - draft-blanchet-dtn-bp-application-framework
draft-blanchet-dtn-bp-application-framework
Network Working Group M. Blanchet
Internet-Draft Viagenie
Intended status: Standards Track 17 October 2022
Expires: 20 April 2023
Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework
draft-blanchet-dtn-bp-application-framework-00
Abstract
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.
Status of This Memo
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 Notice
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
Blanchet Expires 20 April 2023 [Page 1]
Internet-Draft Bundle Protocol Application Framework October 2022
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.
Table of Contents
1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2
1.1. No BP Payload Format Standardization . . . . . . . . . . 2
1.2. No Service Identifier Centralized Assignments . . . . . . 2
1.3. Need for an Application Framework . . . . . . . . . . . . 3
2. Bundle Protocol Application Framework . . . . . . . . . . . . 3
2.1. Bundle Protocol Application Protocol Specification . . . 3
2.2. Service Identifier Syntax . . . . . . . . . . . . . . . . 4
2.3. Bundle Protocol Service Identifiers Registry . . . . . . 4
2.4. The Bundle Protocol Ping Service . . . . . . . . . . . . 5
2.5. CCSDS Reserved Range . . . . . . . . . . . . . . . . . . 6
2.6. Re-use of the IP Service Names and Transport Port
Registry . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Problem Statement
1.1. No BP Payload Format Standardization
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.
1.2. No Service Identifier Centralized Assignments
The Bundle Protocol [RFC5050] uses Endpoint Identifiers to specify
the destination of the bundles. Up to now, two types of identifiers
have been defined:
* dtn: uri scheme defined in [RFC5050]
* ipn scheme defined in [RFC6260] using the CBHE extension header
Blanchet Expires 20 April 2023 [Page 2]
Internet-Draft Bundle Protocol Application Framework October 2022
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.
1.3. Need for an Application Framework
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.
2. Bundle Protocol Application Framework
The BP Application framework is specified as following:
* A requirement for BP application protocol specifications.
* A registry of BP service identifiers
2.1. Bundle Protocol Application Protocol Specification
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:
* Bundle payload format
Blanchet Expires 20 April 2023 [Page 3]
Internet-Draft Bundle Protocol Application Framework October 2022
* Bundle services and extension headers required, such as security,
custody or else. The context in which these services and
extensions are used must be fully defined to enable
interoperability between implementations.
* Service identifier for the dtn: scheme
* Service identifier for the ipn scheme
* Request to register the service identifiers in the registries
described in this document.
2.2. Service Identifier Syntax
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.
2.3. Bundle Protocol Service Identifiers Registry
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):
- dtn: service identifier. The dtn: service identifier syntax is
defined in section 4.4 of [RFC5050].
- ipn service identifier. The ipn service identifier syntax is
defined in section 2.1 of [RFC6260].
- Specification Reference: The referenced specification should
describe the bundle payload content.
* Service identifiers must be registered for both schemes at the
same time. If it can not be done, the specification must detail
why and the expert should review the rationale before accepting
that registration.
Blanchet Expires 20 April 2023 [Page 4]
Internet-Draft Bundle Protocol Application Framework October 2022
* Registration Policy:
- CCSDS book or IETF RFC required. Any other specification must
be reviewed by an nominated expert.
- For ipn number space, the XX range is delegated to CCSDS
registry service (SANA http://sanaregistry.org), therefore not
allocated by IANA. In the registry, IANA should point this
range to the corresponding SANA registry.
The registry should contain the following initial values:
* dtn: service identifier "none" shall be assigned. The semantic is
described in RFC5050
* ipn service identifier of value "0" shall be assigned for the same
semantic as dtn:none
* Specification Reference: RFC5050
* Mandatory Bundle Protocol service: none.
2.4. The Bundle Protocol Ping Service
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:
* dtn: service identifier "ping" shall be assigned to the ping
service.
* ipn service identifier of value "1" shall be assigned to the ping
service.
* Specification Reference: TBD.
* Mandatory Bundle Protocol service: none.
Blanchet Expires 20 April 2023 [Page 5]
Internet-Draft Bundle Protocol Application Framework October 2022
2.5. CCSDS Reserved Range
For the purpose of space networking, the CCSDS SDO
(http://www.ccsds.org) 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) (http://sanaregistry.org). 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.
2.6. Re-use of the IP Service Names and Transport Port Registry
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.
3. Security Considerations
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.
4. IANA Considerations
IANA is requested to create a registry as specified in this document.
5. Acknowledgements
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.
6. Normative References
Blanchet Expires 20 April 2023 [Page 6]
Internet-Draft Bundle Protocol Application Framework October 2022
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/info/rfc6260>.
Author's Address
Marc Blanchet
Viagenie
Email: Marc.Blanchet@viagenie.ca
URI: http://viagenie.ca
Blanchet Expires 20 April 2023 [Page 7]
