Network Working Group M. Blanchet Internet-Draft Viagenie Intended status: Standards Track June 15, 2011 Expires: December 17, 2011 Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework draft-blanchet-dtnrg-bp-application-framework-00.txt Abstract The Bundle Protocol documents specify the syntax of service identifiers but do not identify how to make them interoperable. Moreover, there are currently no way to map a service identifier to a specific Bundle payload format. This document attempt to address these issues. 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 http://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 December 17, 2011. Copyright Notice Copyright (c) 2011 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Blanchet Expires December 17, 2011 [Page 1] Internet-Draft Bundle Protocol Application Framework June 2011 Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 2. Bundle Protocol Application Framework . . . . . . . . . . . . . 3 2.1. Bundle Protocol Application Protocol Specification . . . . 4 2.2. Service Identifier Syntax . . . . . . . . . . . . . . . . . 4 2.3. Coordination with CCSDS . . . . . . . . . . . . . . . . . . 4 2.4. Bundle Protocol Service Identifiers Registry . . . . . . . 5 2.5. The Bundle Protocol Ping Service . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Blanchet Expires December 17, 2011 [Page 2] Internet-Draft Bundle Protocol Application Framework June 2011 1. Problem Statement 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. Two types of identifiers have been defined: the dtn: uri scheme defined in [RFC5050] and the ipn: scheme defined in [RFC6260] using the CBHE extension header. Both schemes syntax carry the service identifier so that the bundle payload is sent to the right application agent and it knows how to process it. Up to now, no definition of these service identifiers exist, therefore, each implementation does not know in a way 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 applications. 2. Bundle Protocol Application Framework The BP Application framework is specified in the following sections. Blanchet Expires December 17, 2011 [Page 3] Internet-Draft Bundle Protocol Application Framework June 2011 2.1. Bundle Protocol Application Protocol Specification A bundle protocol application is defined by a protocol and a bundle payload format. It should be specified in a document with the following information: o Bundle payload format o 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. o Service identifier for the dtn: scheme o Service identifier for the ipn: scheme o 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. Coordination with CCSDS For the purpose of space networking, the CCSDS SDO xref target="http://www.ccsds.org" is creating registries xref target="CCSDS-bundle-protocol-book"/ for the node and service identifier part of the ipn: scheme, managed by the CCSDS Registry Authority, named Space Assigned Number Authority (SANA) xref target="http://sanaregistry.org"/. This 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. 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. By way of reserving range of assignments for each SDO, each SDO can perform their own specific assignments. Blanchet Expires December 17, 2011 [Page 4] Internet-Draft Bundle Protocol Application Framework June 2011 2.4. Bundle Protocol Service Identifiers Registry The IANA is requested to create a "Bundle Protocol Service Identifiers" registry with the following requirements. o 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. o 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. o 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), 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: o dtn: service identifier "none" shall be assigned. The semantic is described in RFC5050 o ipn: service identifier of value "0" shall be assigned for the same semantic as dtn:none o Specification Reference: RFC5050 o Mandatory Bundle Protocol service: none. 2.5. 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: Blanchet Expires December 17, 2011 [Page 5] Internet-Draft Bundle Protocol Application Framework June 2011 o dtn: service identifier "ping" shall be assigned to the ping service. o ipn: service identifier of value "1" shall be assigned to the ping service. o Specification Reference: this section of this document which describes the payload of the ping service. o Mandatory Bundle Protocol service: none. 3. Security Considerations TBD 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: TBD. 6. Normative References [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, May 2011. Author's Address Marc Blanchet Viagenie 2875 boul. Laurier, suite D2-630 Quebec, QC G1V 2M2 Canada Email: Marc.Blanchet@viagenie.ca URI: http://viagenie.ca Blanchet Expires December 17, 2011 [Page 6]