idnits 2.17.1 draft-irtf-dtnrg-iana-bp-registries-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2011) is 4803 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: Informational February 25, 2011 5 Expires: August 29, 2011 7 Delay-Tolerant Networks (DTN) Bundle Protocol IANA Registries 8 draft-irtf-dtnrg-iana-bp-registries-02.txt 10 Abstract 12 The DTNRG research group has defined many protocols such as Bundle 13 Protocol and Licklider. The specifications of these protocols 14 contain fields that are subject to a registry. For the purpose of 15 its research work, the group created adhoc registries. As the 16 specifications are stable and have multiple interoperable 17 implementations, the group would like to handoff the registries to 18 IANA for official custody. This document describes the actions 19 needed to be executed by IANA. 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 August 29, 2011. 38 Copyright Notice 40 Copyright (c) 2011 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Treatment of Flag Fields Encoded using SDNVs . . . . . . . . . 3 57 3. Bundle Protocol . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Bundle Block Types . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Primary Bundle Protocol Version . . . . . . . . . . . . . . 4 60 3.3. Bundle Processing Control Flags . . . . . . . . . . . . . . 4 61 3.4. Block Processing Control Flags . . . . . . . . . . . . . . 5 62 3.5. Bundle Status Report Flags . . . . . . . . . . . . . . . . 6 63 3.6. Bundle Status Report Reason Codes . . . . . . . . . . . . . 7 64 3.7. Bundle Custody Signal Reason Codes . . . . . . . . . . . . 7 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 The DTNRG research group has defined many protocols[RFC4838] such as 76 Bundle Protocol[RFC5050] and Licklider[RFC5326]. The specifications 77 of these protocols contain fields that are subject to a registry. 78 For the purpose of its research work, the group created adhoc 79 registries [1]. As the specifications are stable and have multiple 80 interoperable implementations, the group would like to handoff the 81 registries to IANA for official custody. This document describes the 82 actions needed to be executed by IANA. 84 2. Treatment of Flag Fields Encoded using SDNVs 86 The DTN protocols use several extensible bit flag fields that are 87 encoded as Self-Delimiting Numeric Values (SDNVs) as defined in 88 Section 4.1 of [RFC5050]. For these fields, the registry specifies 89 the allocation and usage of bit positions within the unencoded field. 90 The SDNV encoding treats the ensemble of bits in the unencoded value 91 as a numeric value to be encoded on transmission and decoded on 92 reception as described in [RFC5050]. 94 Processing of SDNV-encoded flags is discussed in 95 [I-D.irtf-dtnrg-sdnv]. 97 Section 4.1 of [RFC5050] specifies that implementations are not 98 required to handle SDNVs with more than 64 bits in their unencoded 99 value. Accordingly SDNV encoded flag fields should be limited to 64 100 bit positions. 102 IANA Registry policies and wording used in this document are 103 described in [RFC5226]. 105 3. Bundle Protocol 107 The Bundle Protocol(BP)[RFC5050] has fields requiring a registry 108 managed by IANA. 110 3.1. Bundle Block Types 112 The Bundle Protocol has a Bundle Block Type code field (section 113 4.5.2) [RFC5050]. An IANA registry shall be setup as follows. 115 The registration policy for this registry is: 116 0-191: Specification Required 117 192-255: Private or experimental use. No assignment by IANA. 119 The Value range is: unsigned 8 bit integer. 121 Bundle Block Type Codes Registry 123 +--------------+---------------------------------+---------------+ 124 | Value | Description | Reference | 125 +--------------+---------------------------------+---------------+ 126 | 0 | Reserved | This document | 127 | 1 | Bundle Payload Block | [RFC5050] | 128 | 2-191 | Unassigned | | 129 | 192-255 | Private and/or experimental use | [RFC5050] | 130 +--------------+---------------------------------+---------------+ 132 The value "0" was not defined in any document or in the adhoc 133 registry. As per concensus by the DNTRG research group, it is 134 reserved per this document. 136 3.2. Primary Bundle Protocol Version 138 The Bundle Protocol has a version field (section 4.5.1) [RFC5050]. 139 An IANA registry shall be setup as follows. 141 The registration policy for this registry is: RFC Required 143 The Value range is: unsigned 8 bit integer. 145 Primary Bundle Protocol Version Registry 147 +-------+-------------+---------------+ 148 | Value | Description | Reference | 149 +-------+-------------+---------------+ 150 | 0-5 | Reserved | This document | 151 | 6 | Assigned | [RFC5050] | 152 | 7-255 | Unassigned | | 153 +-------+-------------+---------------+ 155 The value "0-5" was not defined in any document or in the adhoc 156 registry. As per concensus by the DNTRG research group, it is 157 reserved per this document. 159 3.3. Bundle Processing Control Flags 161 The Bundle Protocol has a Bundle Processing Control flags field 162 (section 4.2) [RFC5050] encoded as an SDNV(see section (Section 2)). 163 An IANA registry shall be setup as follows. 165 The registration policy for this registry is: Specification Required 167 The Value range is: Variable length. Maximum number of flag bit 168 positions: 64 170 Bundle Processing Control Flags Registry 172 +--------------------+----------------------------------+-----------+ 173 | Bit Position | Description | Reference | 174 | (right to left) | | | 175 +--------------------+----------------------------------+-----------+ 176 | 0 | Bundle is a fragment | [RFC5050] | 177 | 1 | Application data unit is an | [RFC5050] | 178 | | administrative record | | 179 | 2 | Bundle must not be fragmented | [RFC5050] | 180 | 3 | Custody transfer is requested | [RFC5050] | 181 | 4 | Destination endpoint is a | [RFC5050] | 182 | | singleton | | 183 | 5 | Acknowledgement by application | [RFC5050] | 184 | | is requested | | 185 | 6 | Reserved | [RFC5050] | 186 | 7-8 | Class of service: priority | [RFC5050] | 187 | 9-13 | Class of service: reserved | [RFC5050] | 188 | 14 | Request reporting of bundle | [RFC5050] | 189 | | reception | | 190 | 15 | Request reporting of custody | [RFC5050] | 191 | | acceptance | | 192 | 16 | Request reporting of bundle | [RFC5050] | 193 | | forwarding | | 194 | 17 | Request reporting of bundle | [RFC5050] | 195 | | delivery | | 196 | 18 | Request reporting of bundle | [RFC5050] | 197 | | deletion | | 198 | 19 | Reserved | [RFC5050] | 199 | 20 | Reserved | [RFC5050] | 200 +--------------------+----------------------------------+-----------+ 202 3.4. Block Processing Control Flags 204 The Bundle Protocol has a Block Processing Control flags field 205 (section 4.3) [RFC5050]. An IANA registry shall be setup as follows. 207 The registration policy for this registry is: Specification Required 209 The Value range is: Variable length. Maximum number of flag bit 210 positions: 64 211 Block Processing Control Flags Registry 213 +--------------------+----------------------------------+-----------+ 214 | Bit Position | Description | Reference | 215 | (right to left) | | | 216 +--------------------+----------------------------------+-----------+ 217 | 0 | Block must be replicated in | [RFC5050] | 218 | | every fragment | | 219 | 1 | Transmit status report if block | [RFC5050] | 220 | | can't be processed | | 221 | 2 | Delete bundle if block can't be | [RFC5050] | 222 | | processed | | 223 | 3 | Last block | [RFC5050] | 224 | 4 | Discard block if it can't be | [RFC5050] | 225 | | processed | | 226 | 5 | Block was forwarded without | [RFC5050] | 227 | | being processed | | 228 | 6 | Block contains an EID-reference | [RFC5050] | 229 | | field | | 230 +--------------------+----------------------------------+-----------+ 232 3.5. Bundle Status Report Flags 234 The Bundle Protocol has a Status Report Status Flag field(section 235 6.1.1) [RFC5050]. An IANA registry shall be setup as follows. 237 The registration policy for this registry is: RFC Required 239 The Value range is: 8 bits. 241 Bundle Status Report Flags Registry 243 +----------+----------------------------------------+---------------+ 244 | Value | Description | Reference | 245 +----------+----------------------------------------+---------------+ 246 | 00000000 | Reserved | This document | 247 | 00000001 | Reporting node received bundle | [RFC5050] | 248 | 00000010 | Reporting node accepted custody of | [RFC5050] | 249 | | bundle | | 250 | 00000100 | Reporting node forwarded the bundle | [RFC5050] | 251 | 00001000 | Reporting node delivered the bundle | [RFC5050] | 252 | 00010000 | Reporting node deleted the bundle | [RFC5050] | 253 | 00100000 | Unassigned | | 254 | 01000000 | Unassigned | | 255 | 10000000 | Unassigned | | 256 +----------+----------------------------------------+---------------+ 258 The value "00000000" was not defined in any document or in the adhoc 259 registry. As per concensus by the DNTRG research group, it is 260 reserved per this document. 262 3.6. Bundle Status Report Reason Codes 264 The Bundle Protocol has a Bundle Status Report Reason Codes 265 field(section 6.1.1) [RFC5050]. An IANA registry shall be setup as 266 follows. 268 The registration policy for this registry is: Specification Required 270 The Value range is: unsigned 8 bit integer. 272 Bundle Status Report Reason Codes Registry 274 +-------+-------------------------------------------+---------------+ 275 | Value | Description | Reference | 276 +-------+-------------------------------------------+---------------+ 277 | 0 | No additional information | [RFC5050] | 278 | 1 | Lifetime expired | [RFC5050] | 279 | 2 | Forwarded over unidirectional link | [RFC5050] | 280 | 3 | Transmission canceled | [RFC5050] | 281 | 4 | Depleted storage | [RFC5050] | 282 | 5 | Destination endpoint ID unintelligible | [RFC5050] | 283 | 6 | No known route to destination from here | [RFC5050] | 284 | 7 | No timely contact with next node on route | [RFC5050] | 285 | 8 | Block unintelligible | [RFC5050] | 286 | 9-254 | Unassigned | | 287 | 255 | Reserved | This document | 288 +-------+-------------------------------------------+---------------+ 290 The value "255" was not defined in any document or in the adhoc 291 registry. As per concensus by the DNTRG research group, it is 292 reserved per this document. 294 3.7. Bundle Custody Signal Reason Codes 296 The Bundle Protocol has a Bundle Custody Signal Reason Codes 297 field(section 6.1.2) [RFC5050]. An IANA registry shall be setup as 298 follows. 300 The registration policy for this registry is: Specification Required 302 The Value range is: unsigned 7 bit integer. 304 Bundle Custody Signal Reason Codes Registry 306 +--------------+--------------------------------------+-------------+ 307 | Value | Description | Reference | 308 +--------------+--------------------------------------+-------------+ 309 | 0 | No additional information | [RFC5050] | 310 | 1-2 | Unassigned | | 311 | 3 | Redundant reception (reception by a | [RFC5050] | 312 | | node that is a custodial node for | | 313 | | this bundle) | | 314 | 4 | Depleted storage | [RFC5050] | 315 | 5 | Destination endpoint ID | [RFC5050] | 316 | | unintelligible | | 317 | 6 | No known route to destination from | [RFC5050] | 318 | | here | | 319 | 7 | No timely contact with next node on | [RFC5050] | 320 | | route | | 321 | 8 | Block unintelligible | [RFC5050] | 322 | 9-126 | Unassigned | | 323 | 127 | Reserved | This | 324 | | | document | 325 +--------------+--------------------------------------+-------------+ 327 The value "127" was not defined in any document or in the adhoc 328 registry. As per concensus by the DNTRG research group, it is 329 reserved per this document. 331 4. Security Considerations 333 This document requests the creation of registries managed by IANA. 334 There is no security issues involved. Refer to Security 335 Considerations of the referenced protocols. 337 5. IANA Considerations 339 IANA is requested to create the registries as described in the 340 previous sections. 342 6. Acknowledgements 344 The editor would like to thank the following people who have provided 345 comments and suggestions to this document, in no specific order: 346 Stephen Farrell, Daniel Ellard, Scott Burleigh, Keith Scott, Elwyn 347 Davies. 349 7. References 351 7.1. Normative References 353 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 354 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 355 Networking Architecture", RFC 4838, April 2007. 357 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 358 Specification", RFC 5050, November 2007. 360 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 361 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 362 May 2008. 364 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 365 Transmission Protocol - Specification", RFC 5326, 366 September 2008. 368 7.2. Informative References 370 [I-D.irtf-dtnrg-sdnv] 371 Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 372 Values in Protocols", draft-irtf-dtnrg-sdnv-09 (work in 373 progress), February 2011. 375 URIs 377 [1] 379 Author's Address 381 Marc Blanchet 382 Viagenie 383 2875 boul. Laurier, suite D2-630 384 Quebec, QC G1V 2M2 385 Canada 387 Email: Marc.Blanchet@viagenie.ca 388 URI: http://viagenie.ca