idnits 2.17.1 draft-blanchet-dtnrg-bp-application-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 5050 ** Downref: Normative reference to an Experimental RFC: RFC 6260 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet 3 Internet-Draft Viagenie 4 Intended status: Standards Track March 12, 2012 5 Expires: September 13, 2012 7 Delay-Tolerant Networking (DTN) Bundle Protocol Application Framework 8 draft-blanchet-dtnrg-bp-application-framework-01.txt 10 Abstract 12 The current Bundle Protocol specifications define the syntax of 13 service identifiers but do not identify how to make them 14 interoperable. For example, there are currently no way to map a 15 service identifier to a specific Bundle payload format for an 16 application agent. This document proposes an application framework 17 enabling interoperable implementations and deployments of the Bundle 18 Protocol. It also creates a service identifier registry for the 19 Bundle Protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. No BP Payload Format Standardization . . . . . . . . . . . 3 57 1.2. No Service Identifier Centralized Assignments . . . . . . . 3 58 1.3. Need for an Application Framework . . . . . . . . . . . . . 3 59 2. Bundle Protocol Application Framework . . . . . . . . . . . . . 4 60 2.1. Bundle Protocol Application Protocol Specification . . . . 4 61 2.2. Service Identifier Syntax . . . . . . . . . . . . . . . . . 4 62 2.3. Bundle Protocol Service Identifiers Registry . . . . . . . 4 63 2.4. The Bundle Protocol Ping Service . . . . . . . . . . . . . 5 64 2.5. CCSDS Reserved Range . . . . . . . . . . . . . . . . . . . 6 65 2.6. Re-use of the IP Service Names and Transport Port 66 Registry . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 6. Normative References . . . . . . . . . . . . . . . . . . . . . 7 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Problem Statement 75 1.1. No BP Payload Format Standardization 77 The Bundle Protocol (BP) [RFC5050] specifies how to carry bundles 78 over a delay and disruption tolerant network. Up to now, the various 79 BP implementations have defined their own payload format for the 80 applications they support, without any specification. Therefore, 81 between two implementations, there is no garantee that the payloads 82 will be properly processed. This prohibits interoperability between 83 application agents of the various implementations. 85 1.2. No Service Identifier Centralized Assignments 87 The Bundle Protocol [RFC5050] uses Endpoint Identifiers to specify 88 the destination of the bundles. Up to now, two types of identifiers 89 have been defined: 90 o dtn: uri scheme defined in [RFC5050] 91 o ipn scheme defined in [RFC6260] using the CBHE extension header 93 Both schemes syntax carry the service identifier so that the bundle 94 payload is sent to the right application agent and that application 95 agent knows how to process it. Up to now, no definition of these 96 service identifiers exist, therefore, each implementation does not 97 know to which application agent it should send the received bundle 98 payload. 100 1.3. Need for an Application Framework 102 From the point of view of implementations and end-users, the service 103 identifier shall be common to both types of identifiers and the 104 payload format should be identical for the same service identifiers. 105 Therefore, there is a need to normalize the service identifiers as 106 well as the payload formats. This is similar to service and port 107 numbers registry for IP protocols and applications protocols 108 specifications. 110 As with IP application protocols specifications, some applications 111 require services at the IP layer, such as IPsec. In such cases, the 112 application specification defines the usage and requirements of IPsec 113 for carrying the application packets. Similarly, Bundle protocol 114 applications may require specific bundle protocol services, such as 115 custody, security, quality of service or else. 117 This document defines a framework by which Bundle Protocol 118 applications should be specified, what bundle services they require 119 and a registry of service identifiers. All together, implementations 120 will interoperate at the application level, instead of just at the 121 bundle forwarding level. Moreover, deployments will be eased by 122 normalized behaviors of BP protocol stacks and applications. 124 2. Bundle Protocol Application Framework 126 The BP Application framework is specified as following: 127 o A requirement for BP application protocol specifications. 128 o A registry of BP service identifiers 130 2.1. Bundle Protocol Application Protocol Specification 132 A BP application is defined by a protocol and a bundle payload 133 format. When a BP application protocol is specified in a document, 134 it should be specified with the following information: 135 o Bundle payload format 136 o Bundle services and extension headers required, such as security, 137 custody or else. The context in which these services and 138 extensions are used must be fully defined to enable 139 interoperability between implementations. 140 o Service identifier for the dtn: scheme 141 o Service identifier for the ipn scheme 142 o Request to register the service identifiers in the registries 143 described in this document. 145 2.2. Service Identifier Syntax 147 While the generic syntax of the dtn: uri is defined, the usage up to 148 now in trials, deployments and implementations has been dtn: 149 node_identifier/service_identifier. For the ipn scheme, the syntax 150 is ipn:node_identifier.service_identifier. This document registers 151 the service_identifier part values but makes no recommendation on the 152 node identifier part. 154 2.3. Bundle Protocol Service Identifiers Registry 156 For implementations and for interoperability between various BP 157 network deployments, it is highly preferable that the service 158 identifiers are identical for all deployments and all 159 implementations. 161 This document requests IANA to create a registry for the service 162 identifiers for both the ipn and the dtn: space. The common service 163 identifiers will be identical for both schemes and for all 164 deployments. The structure of the registry is: 165 o Structure (aka columns): 167 * dtn: service identifier. The dtn: service identifier syntax is 168 defined in section 4.4 of [RFC5050]. 169 * ipn service identifier. The ipn service identifier syntax is 170 defined in section 2.1 of [RFC6260]. 171 * Specification Reference: The referenced specification should 172 describe the bundle payload content. 173 o Service identifiers must be registered for both schemes at the 174 same time. If it can not be done, the specification must detail 175 why and the expert should review the rationale before accepting 176 that registration. 177 o Registration Policy: 178 * CCSDS book or IETF RFC required. Any other specification must 179 be reviewed by an nominated expert. 180 * For ipn number space, the XX range is delegated to CCSDS 181 registry service (SANA ), therefore 182 not allocated by IANA. In the registry, IANA should point this 183 range to the corresponding SANA registry. 185 The registry should contain the following initial values: 186 o dtn: service identifier "none" shall be assigned. The semantic is 187 described in RFC5050 188 o ipn service identifier of value "0" shall be assigned for the same 189 semantic as dtn:none 190 o Specification Reference: RFC5050 191 o Mandatory Bundle Protocol service: none. 193 2.4. The Bundle Protocol Ping Service 195 This section is requesting a registration for the above registry. It 196 also serves as a simple example on how registration requests should 197 be done. 199 The Ping service is similar to the IP ICMP Echo request/reply service 200 where a source node sends a simple query to the destination node and 201 the destination node replies. This helps troubleshooting the network 202 and knowing if a node is reachable and up. 204 The ping service has the following Bundle Protocol payload format: 205 TBD. 207 This document request the registration of the ping service in the 208 above registry as follows: 209 o dtn: service identifier "ping" shall be assigned to the ping 210 service. 211 o ipn service identifier of value "1" shall be assigned to the ping 212 service. 214 o Specification Reference: TBD. 215 o Mandatory Bundle Protocol service: none. 217 2.5. CCSDS Reserved Range 219 For the purpose of space networking, the CCSDS SDO [1] needs service 220 identifier assignments for its own deployments. For the management 221 of these assignments, registries for the node and service identifier 222 part of the ipn scheme are managed by the CCSDS Registry Authority, 223 Space Assigned Number Authority (SANA) [2]. This CCSDS registry of 224 node and service identifiers is specific to space networks. However, 225 for implementations and for interoperability between various network 226 deployments, it is highly preferable that the service identifiers are 227 identical for all deployments. Therefore, this document requests 228 IANA to set aside a range of ipn service identifiers to be used by 229 CCSDS and managed by its registry authority SANA. 231 2.6. Re-use of the IP Service Names and Transport Port Registry 233 The IP Services Names and Port Registry (IPSNPR) is used to list the 234 service and port identifiers for IP packets. Within some DTN 235 deployments, some IP protocols such as HTTP and SMTP have been 236 transported inside the Bundle Protocol payloads. Some other DTN 237 deployments are using non IETF protocols. Therefore, there is some 238 overlap but also some specific DTN applications. The number of IP 239 protocols that will be carried directly as BP payloads are most 240 likely very small, and would not include the vast majority of the 241 port numbers found in the IPSNPR. Therefore, it is proposed to start 242 a new registry from scratch instead of trying to overload or sync 243 with the IPSNPR. 245 3. Security Considerations 247 Establishing a registry of service identifiers so that 248 implementations and deployments can interoperate does not bring any 249 specific security concerns and does not add any security. As with 250 the IP services and port registry, the existence of such registry 251 have not brought any security concerns. 253 4. IANA Considerations 255 IANA is requested to create a registry as specified in this document. 257 5. Acknowledgements 259 The editor would like to thank the following people who have provided 260 comments and suggestions to this document, in no specific order: 261 Stephen Farrell, Keith Scott, Scott Burleigh. 263 6. Normative References 265 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 266 Specification", RFC 5050, November 2007. 268 [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", 269 RFC 6260, May 2011. 271 [1] 273 [2] 275 Author's Address 277 Marc Blanchet 278 Viagenie 279 246 Aberdeen 280 Quebec, QC G1R 2E1 281 Canada 283 Email: Marc.Blanchet@viagenie.ca 284 URI: http://viagenie.ca