Network Working GroupInternet Research Task Force (IRTF) K. ScottInternet-DraftRequest for Comments: 7116 The MITRE CorporationIntended status:Category: Informational M. BlanchetExpires: April 11, 2014ISSN: 2070-1721 ViagenieOctober 8, 2013February 2014 Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registriesdraft-dtnrg-ltp-cbhe-registries-07Abstract The DTNRGresearch groupResearch Group has defined the experimental Licklider Transmission Protocol (LTP)[RFC5326]and the Compressed Bundle Header Encoding (CBHE)[RFC6260]mechanism for the InterPlanetary Network(ipn('ipn' URI scheme). Moreover,RFC5050 [RFC5050]RFC 5050 defines values for the BundleAdministrative Record Type.Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has createdad-hocad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes theactions needed to be executed by IANA.necessary IANA actions. Status ofthisThis Memo ThisInternet-Draftdocument issubmitted in full conformance withnot an Internet Standards Track specification; it is published for informational purposes. This document is a product of theprovisionsInternet Research Task Force (IRTF). The IRTF publishes the results ofBCP 78Internet-related research andBCP 79. Internet-Drafts are working documentsdevelopment activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking (DTNRG) Research Group of the InternetEngineeringResearch 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(IRTF). Documents approved for publication by the IRSG are not amaximumcandidate for any level of Internet Standard; see Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 April 11, 2014.http://www.rfc-editor.org/info/rfc7116. Copyright Notice Copyright (c)20132014 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.Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................2 2. Security Considerations. . . . . . . . . . . . . . . . . . . . 3.........................................3 3. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3.............................................3 3.1. Licklider Transmission Protocol. . . . . . . . . . . . . . 3............................3 3.1.1. LTP Cancel Segment Reason Codes. . . . . . . . . . . . 4.....................3 3.1.2. LTP Engine ID. . . . . . . . . . . . . . . . . . . . . 4.......................................4 3.1.3. LTP Client Service ID. . . . . . . . . . . . . . . . . 5...............................5 3.2. Compressed Bundle Header Encoding. . . . . . . . . . . . . 6..........................6 3.2.1. CBHE Node Numbers. . . . . . . . . . . . . . . . . . . 6...................................6 3.2.2. CBHE Service Numbers. . . . . . . . . . . . . . . . . 7................................7 3.3. Bundle Administrative Record Types. . . . . . . . . . . . 8.........................8 4. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 9................................................8 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . 9......................................................9 5.1. Normative References. . . . . . . . . . . . . . . . . . . 9.......................................9 5.2. Informative References. . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9.....................................9 1. Introduction The DTNRGresearch groupResearch Group has defined the Licklider Transmission Protocol(LTP)[RFC5326].(LTP) [RFC5326]. LTP contains certain fields that are subject to a registry. For the purpose of its research work, the group has createdad-hocad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the actionsneeded to be executed bythat IANAusingneeds to take and uses theWell-Knownwell-known IANAPolicy Definitions definedpolicy definitions as described in Section 4.1 of [RFC5226]. The Compressed Bundle Header Encoding (CBHE) [RFC6260] specification defines the concepts ofNode Number'Node Number' andService Number'Service Number' in the 'ipn' URI scheme. In thisdocumentdocument, we request formation ofanIANAregistryregistries forthe Node Number field in the 'ipn' scheme.these fields. Because of its association with space communication and the Consultative Committeeonfor Space Data Systems [CCSDS],a portionportions of theCBHE"CBHE NodeNumber spaceNumbers", "CBHE Service Numbers", anda corresponding portion of the LTP"LTP EngineID space isNumbers" spaces are delegated by this document to the CCSDS Space Assigned Numbers Authority [SANA]. SANA functions similarly to IANA in that it maintains registries of managed values, with a focus on values used by protocols used by CCSDS member agencies. This document represents the consensus of the DTNRG. It has been discussed and reviewed by the research group and interested parties. 2. Security Considerations This document requests the creation of registries managed by IANA. There are no security issues involved. Refer to the Security Considerations section of [RFC5326] for security issues withthe LTP protocol.LTP. 3. IANA Considerations IANAis requested to createhas created the registriesasdescribed in this section. 3.1. Licklider Transmission Protocol The Licklider Transmission Protocol has fields requiring registries managed by IANA. This document requests the creation of the three registries in this section and requests that they be associated with the otherregistries for the Licklider Transmission protocol.LTP registries. 3.1.1. LTP Cancel Segment Reason Codes Section 3.2.4 of [RFC5326] defines the reason codes that may be present in Cancel Segments in LTP. IANA has set up a registry to manage theLTP protocol.cancel reason codes. This registry, titled "LTP Cancel Segment Reason Codes", has been added to the list of registries associated with the Licklider Transmission Protocol. The registration policy for this registryis:is SpecificationRequiredRequired. The initial values (as defined byRFC5326)RFC 5326) for theLTP"LTP Cancel Segment ReasonCodes registry shall be: LTP Cancel Segment Reason Codes Registry +-----------+---------------------------------+---------------+Codes" are: +-------+---------------------------------+---------------+ | Value | Description | Reference |+-----------+---------------------------------+---------------++-------+---------------------------------+---------------+ | 0 | Client service canceled session | [RFC5326] | | 1 | Unreachable client service | [RFC5326] | | 2 | Retransmission limit exceeded | [RFC5326] | | 3 | Miscolored data received | [RFC5326] | | 4 | System error caused termination | [RFC5326] | | 5 | Retransmission limit exceeded | [RFC5326] | |0x06-0xFF6-255 | Unassigned | This document |+-----------+---------------------------------+---------------++-------+---------------------------------+---------------+ 3.1.2. LTP Engine ID The Licklider Transmission Protocol has an LTP Engine ID field(section(Section 2 of [RFC5326]).AnIANAregistry shall behas set upas follows.a registry to manage the Engine IDs. This registry, titled "LTP Engine Numbers", has been added to the list of registries associated with the Licklider Transmission Protocol. The registration policy for this registry is: 1 -- (2**14)-1 ExpertreviewReview required. (2**14) -- (2**21)-1 Allocated to the Space Assigned Numbers Authority ([SANA]) for use by Consultative Committee for Space Data Systems (CCSDS) missions. (2**21) -- (2**28)-1 Private orexperimental use.Experimental Use. (2**28) -- (2**42)-1First-come, First-ServedFirst Come First Served basis for requests for less than or equal to 2**14 values to a single entity or organization. ExpertreviewReview is required for requests of more than 2**14 values to a single entity or organization. The LTP Engine ID is expressed as a Self-Delimiting Numeric Value (SDNV) inthe LTP protocolLTP, and no maximum is specified in the protocol definition. SDNVs are described in Section 4.1 of the Bundle Protocolinspecification [RFC5050] andare also describedinthe stand- alone document[RFC6256]. The initial values for theLTP"LTP EngineNumbersNumbers" registryshall be: LTP Engine Numbers Registryare: +--------------------+---------------------------+---------------+ | Value | Description | Reference | +--------------------+---------------------------+---------------+ | 0 | Reserved | This document | | 1--(2**14)-1 | Unassigned | This document | | (2**14)--(2**21)-1 | Allocated to CCSDS (SANA) | This document | | (2**21)--(2**28)-1 | Private/Experimental Use | This document | | (2**28)--(2**42)-1 | Unassigned | This document | | >=(2**42) | Reserved | This document | +--------------------+---------------------------+---------------+ 3.1.3. LTP Client Service ID The Licklider Transmission Protocol has a client service ID number field(section(Section 3.2.1 of [RFC5326]).AnIANAregistry shall behas set upas follows.a registry to manage LTP Client Service IDs. This registry, titled "LTP Client Service Identifiers", has been added to the list of registries associated with the Licklider Transmission Protocol. The registration policy for this registry is: 4 -- (2**14)-1 Allocated to the Space Assigned Numbers Authority ([SANA]) for use by Consultative Committee for Space Data Systems (CCSDS) missions. 2**14 -- 32,767 Private orexperimental use.Experimental Use. >= 32,768 Specificationrequired.Required. The LTP Client Service ID is expressed as a Self-Delimiting Numeric Value (SDNV) inthe LTP protocolLTP, and no maximum value is specified in the protocol definition. The initial values for theLTP Client Service Identifiers registry shall be: LTP"LTP Client ServiceIdentifiers RegistryIdentifiers" are: +-----------------+------------------------------+---------------+ | Value | Description | Reference | +-----------------+------------------------------+---------------+ | 0 | Reserved | [RFC5326] | | 1 | Bundle Protocol | This document | | 2 | LTP Service Data Aggregation | This document | | 3 | CCSDS File Delivery Service | This document | | 4--(2**14)-1 | Allocated to CCSDS (SANA) | This document | | (2**14)--32,767 |Private / ExperimentalPrivate/Experimental Use | This document | | >=32,768 | Unassigned | This document | +-----------------+------------------------------+---------------+ 3.2. Compressed Bundle Header Encoding The CBHE specification [RFC6260] defines concepts of 'Node Number' and 'Service Number' that require registries managed by IANA. 3.2.1. CBHE Node Numbers The CBHE specification defines a Node Number (node-nbr) field(section(Section 2.1 of [RFC6260]).AnIANAregistry shall behas set upas follows.a registry to manage CBHE Node Numbers. This registry, titled "CBHE Node Numbers", has been added to the list of registries associated with the Bundle Protocol. The registration policy for this registry is: 1 -- (2**14)-1 ExpertreviewReview required. (2**14) -- (2**21)-1 Allocated to the Space Assigned Numbers Authority ([SANA]) for use by Consultative Committee for Space Data Systems (CCSDS) missions. (2**21) -- (2**28)-1 Private orexperimental use.Experimental Use. (2**28) -- (2**42)-1First-come, First-ServedFirst Come First Served basis for requests for less than or equal to 2**14 values to a single entity or organization. ExpertreviewReview is required for requests of more than 2**14 values to a single entity or organization. >= (2**42)ReservedReserved. The CBHE Node Number is expressed as a Self-Delimiting Numeric Value (SDNV) in the CBHE specification. Allowable values for the Node Number range from 1 -- (2**64)-1. The initial values for theCBHE"CBHE NodeNumberNumber" registry shall be:CBHE Node Number Registry+--------------------+---------------------------+---------------+ | Value | Description | Reference | +--------------------+---------------------------+---------------+ | 0 | Reserved | This document | | 1--(2**14)-1 | Unassigned | This document | | (2**14)--(2**21)-1 | Allocated to CCSDS (SANA) | This document | | (2**21)--(2**28)-1 | Private/Experimental Use | This document | | (2**28)--(2**42)-1 | Unassigned | This document | | >=(2**42) | Reserved | This document | +--------------------+---------------------------+---------------+ 3.2.2. CBHE Service Numbers The Compressed Bundle Header Encoding specification defines a Service Number (service-nbr) field(section(Section 2.1 of [RFC6260]).AnIANAregistry shall behas set upas follows.a registry to manage CBHE Service Numbers. This registry, titled "CBHE Service Numbers", has been added to the list of registries associated with the Bundle Protocol. The registration policy for this registry is: 0-63RFC RequiredSpecification Required. 64-1023 Allocated to the Space Assigned Numbers Authority ([SANA]) for use by Consultative Committee for Space Data Systems (CCSDS) missions. 1024 - 2**16-1 SpecificationRequiredRequired. >= 2**16Private / Experimental UsePrivate/Experimental Use. The CBHE Service Number is expressed as a Self-Delimiting Numeric Value (SDNV) in the CBHE specification. Allowable values for the Service Number range from 1 -- (2**64)-1. The initial values for theCBHE"CBHE ServiceNumberNumber" registryshall be: CBHE Service Number Registry +--------------------+--------------------------------+-------------+are: +----------------+--------------------------------+---------------+ | Value | Description | Reference |+--------------------+--------------------------------+-------------++----------------+--------------------------------+---------------+ | 0 | Bundle Protocol Administrative | [RFC6260] | | | Record | | | 1 | CCSDS File Delivery Service | [CFDP] | | 2 | Reserved | This| | | |document | | 3-63 | Unassigned | This| | | |document | | 64-1023 | Allocated to CCSDS (SANA) | This| | | |document | | 1024 - 2**16-1 | Unassigned | This| | | |document | | >=2**16 | Private/Experimental Use | This| | | |document |+--------------------+--------------------------------+-------------++----------------+--------------------------------+---------------+ 3.3. Bundle Administrative Record Types Section 6.1 of the Bundle Protocol specification [RFC5050] specifies a 4-bit Administrative Record type code.AnIANAregistry shall behas set upas followsa registry to manage these record types. This registry, titled'Bundle"Bundle Administrative RecordType,' shall beTypes", has been added to the list of registries associated with the BundleProtcol.Protocol. The registration policy for this registryis:is SpecificationrequiredRequired. The initial values for theBundle"Bundle Administrative RecordTypeType" registryshall be: Bundle Protocol Administrative Record Type Registryare: +-------+----------------------+---------------+ | Value | Description | Reference | +-------+----------------------+---------------+ | 0 | Reserved | This document | | 1 | Bundle status report | [RFC5050] | | 2 | Custody signal | [RFC5050] | | 3-15 | Unassigned | This document | +-------+----------------------+---------------+ 4. Acknowledgements Theeditorsauthors would like to thank the following people, in no specific order: Scott Burleigh, Stephen Farrell, and John Buford. 5. References 5.1. Normative References [CFDP] Consultative Committee for Space DataSystems (http://www.ccsds.org),Systems, "CCSDS File Delivery Protocol Version 4 (CCSDS 727.0-B-4)", January2007.2007, <http://www.ccsds.org>. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008. [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, May 2011. [RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, May 2011. 5.2. Informative References [CCSDS] CCSDS, "The Consultative Committee for Space DataSystems at http://www.ccsds.org".Systems", <http://www.ccsds.org>. [SANA] SANA, "The CCSDS SANA Registrypage at http://sanaregistry.org".page", <http://sanaregistry.org>. Authors' Addresses Keith Scott The MITRE Corporation 7515 Colshire Drive McLean,VA, CaliforniaVA 22102 USA Phone: +1-703-983-6547 Fax: +1-703-983-7142Email:EMail: kscott@mitre.org Marc Blanchet Viagenie 246 AberdeenQuebec,Quebec G1R 2E1 Canada Phone: +1-418-656-9254Email:EMail: marc.blanchet@viagenie.ca