Network Working Group                                        M. Blanchet
Internet-Draft                                                  Viagenie
Intended status: Standards Track                          March 12, 2012
Expires: September 13, 2012


 Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework
          draft-blanchet-dtnrg-bp-application-framework-01.txt

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.

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 September 13, 2012.

Copyright Notice

   Copyright (c) 2012 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



Blanchet               Expires September 13, 2012               [Page 1]


Internet-Draft    Bundle Protocol Application Framework       March 2012


   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.


Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  No BP Payload Format Standardization  . . . . . . . . . . . 3
     1.2.  No Service Identifier Centralized Assignments . . . . . . . 3
     1.3.  Need for an Application Framework . . . . . . . . . . . . . 3
   2.  Bundle Protocol Application Framework . . . . . . . . . . . . . 4
     2.1.  Bundle Protocol Application Protocol Specification  . . . . 4
     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  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7



























Blanchet               Expires September 13, 2012               [Page 2]


Internet-Draft    Bundle Protocol Application Framework       March 2012


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:
   o  dtn: uri scheme defined in [RFC5050]
   o  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 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



Blanchet               Expires September 13, 2012               [Page 3]


Internet-Draft    Bundle Protocol Application Framework       March 2012


   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:
   o  A requirement for BP application protocol specifications.
   o  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:
   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.  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:
   o  Structure (aka columns):





Blanchet               Expires September 13, 2012               [Page 4]


Internet-Draft    Bundle Protocol Application Framework       March 2012


      *  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 <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:
   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.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:
   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.





Blanchet               Expires September 13, 2012               [Page 5]


Internet-Draft    Bundle Protocol Application Framework       March 2012


   o  Specification Reference: TBD.
   o  Mandatory Bundle Protocol service: none.

2.5.  CCSDS Reserved Range

   For the purpose of space networking, the CCSDS SDO [1] 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) [2].  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.







Blanchet               Expires September 13, 2012               [Page 6]


Internet-Draft    Bundle Protocol Application Framework       March 2012


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

   [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.

   [1]  <http://www.ccsds.org>

   [2]  <http://sanaregistry.org>


Author's Address

   Marc Blanchet
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Email: Marc.Blanchet@viagenie.ca
   URI:   http://viagenie.ca





















Blanchet               Expires September 13, 2012               [Page 7]