Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries
Moving experimental protocol registries under official IANA management.
Scott, K. and M. Blanchet, "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", RFC 7116, DOI 10.17487/RFC7116, February 2014, <https://www.rfc-editor.org/info/rfc7116>.
@misc{rfc7116,
series = {Request for Comments},
number = 7116,
howpublished = {RFC 7116},
publisher = {RFC Editor},
doi = {10.17487/RFC7116},
url = {https://www.rfc-editor.org/info/rfc7116},
author = {K. Scott and M. Blanchet},
title = {{Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries}},
pagetotal = 10,
year = 2014,
month = feb,
} RFC text
Contents
Internet Research Task Force (IRTF) K. Scott
Request for Comments: 7116 The MITRE Corporation
Category: Informational M. Blanchet
ISSN: 2070-1721 Viagenie
February 2014
Licklider Transmission Protocol (LTP),
Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries
Abstract
The DTNRG Research Group has defined the experimental Licklider
Transmission Protocol (LTP) and the Compressed Bundle Header Encoding
(CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme).
Moreover, RFC 5050 defines values for the Bundle Protocol
administrative record type. All of these fields are subject to a
registry. For the purpose of its research work, the group has
created ad 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 necessary IANA actions.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related research
and development activities. These results might not be suitable for
deployment. This RFC represents the consensus of the Delay-Tolerant
Networking (DTNRG) Research Group of the Internet Research Task Force
(IRTF). Documents approved for publication by the IRSG are not a
candidate for any level of Internet Standard; see Section 2 of RFC
5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7116.
Copyright Notice
Copyright (c) 2014 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.
Table of Contents
1. Introduction ....................................................2
2. Security Considerations .........................................3
3. IANA Considerations .............................................3
3.1. Licklider Transmission Protocol ............................3
3.1.1. LTP Cancel Segment Reason Codes .....................3
3.1.2. LTP Engine ID .......................................4
3.1.3. LTP Client Service ID ...............................5
3.2. Compressed Bundle Header Encoding ..........................6
3.2.1. CBHE Node Numbers ...................................6
3.2.2. CBHE Service Numbers ................................7
3.3. Bundle Administrative Record Types .........................8
4. Acknowledgements ................................................8
5. References ......................................................9
5.1. Normative References .......................................9
5.2. Informative References .....................................9
1. Introduction
The DTNRG Research Group has defined the Licklider Transmission
Protocol (LTP) [RFC5326]. LTP contains certain fields that are
subject to a registry. For the purpose of its research work, the
group has created ad 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 actions that IANA needs to
take and uses the well-known IANA policy definitions as described in
Section 4.1 of [RFC5226].
The Compressed Bundle Header Encoding (CBHE) [RFC6260] specification
defines the concepts of 'Node Number' and 'Service Number' in the
'ipn' URI scheme. In this document, we request formation of IANA
registries for these fields.
Because of its association with space communication and the
Consultative Committee for Space Data Systems [CCSDS], portions of
the "CBHE Node Numbers", "CBHE Service Numbers", and "LTP Engine
Numbers" 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 with LTP.
3. IANA Considerations
IANA has created the registries described 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 other 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 the 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 registry is Specification Required.
The initial values (as defined by RFC 5326) for the "LTP Cancel
Segment Reason 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] |
| 6-255 | Unassigned | This document |
+-------+---------------------------------+---------------+
3.1.2. LTP Engine ID
The Licklider Transmission Protocol has an LTP Engine ID field
(Section 2 of [RFC5326]). IANA has set up 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 Expert Review 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 or Experimental Use.
(2**28) -- (2**42)-1 First Come First Served basis for requests for
less than or equal to 2**14 values to a single entity or
organization. Expert Review 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) in LTP, and no maximum is specified in the protocol
definition. SDNVs are described in Section 4.1 of the Bundle
Protocol specification [RFC5050] and in [RFC6256]. The initial
values for the "LTP Engine Numbers" registry are:
+--------------------+---------------------------+---------------+
| 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 3.2.1 of [RFC5326]). IANA has set up 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 or Experimental Use.
>= 32,768 Specification Required.
The LTP Client Service ID is expressed as a Self-Delimiting Numeric
Value (SDNV) in LTP, and no maximum value is specified in the
protocol definition. The initial values for the "LTP Client Service
Identifiers" 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/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 2.1 of [RFC6260]). IANA has set up 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 Expert Review 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 or Experimental Use.
(2**28) -- (2**42)-1 First Come First Served basis for requests for
less than or equal to 2**14 values to a single entity or
organization. Expert Review is required for requests of more than
2**14 values to a single entity or organization.
>= (2**42) Reserved.
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 the "CBHE
Node Number" registry shall be:
+--------------------+---------------------------+---------------+
| 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 2.1 of [RFC6260]). IANA has set
up 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-63 Specification 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 Specification Required.
>= 2**16 Private/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 the
"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. IANA has set up a registry
to manage these record types. This registry, titled "Bundle
Administrative Record Types", has been added to the list of
registries associated with the Bundle Protocol.
The registration policy for this registry is Specification Required.
The initial values for the "Bundle Administrative Record Type"
registry are:
+-------+----------------------+---------------+
| Value | Description | Reference |
+-------+----------------------+---------------+
| 0 | Reserved | This document |
| 1 | Bundle status report | [RFC5050] |
| 2 | Custody signal | [RFC5050] |
| 3-15 | Unassigned | This document |
+-------+----------------------+---------------+
4. Acknowledgements
The authors 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 Data Systems, "CCSDS File
Delivery Protocol Version 4 (CCSDS 727.0-B-4)",
January 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 Data
Systems", <http://www.ccsds.org>.
[SANA] SANA, "The CCSDS SANA Registry page",
<http://sanaregistry.org>.
Authors' Addresses
Keith Scott
The MITRE Corporation
7515 Colshire Drive
McLean, VA 22102
USA
Phone: +1-703-983-6547
Fax: +1-703-983-7142
EMail: kscott@mitre.org
Marc Blanchet
Viagenie
246 Aberdeen
Quebec G1R 2E1
Canada
Phone: +1-418-656-9254
EMail: marc.blanchet@viagenie.ca
AI ELI5
On this page
§1Moving Registries to IANA
The Delay-Tolerant Networking Research Group (DTNRG) defined three related protocols for communication in challenged environments: Licklider Transmission Protocol (LTP) [RFC5326], Compressed Bundle Header Encoding (CBHE) [RFC6260], and the Bundle Protocol [RFC5050]. These protocols contain fields with assigned numeric values that require registries to track.
During the research phase, the group maintained ad hoc registries for these values. As the specifications stabilized and gained multiple interoperable implementations, the group determined that these registries should be handed off to IANA for official, long-term management. This RFC describes the registries IANA has created, the registration policies that govern them, and the initial values for each registry.
When researchers are experimenting, they keep notes in a notebook. Once things work and people are using it, they hand the notebook to an official office that keeps it safe and organized.
§2LTP Registries
The Licklider Transmission Protocol defines three fields requiring registries. The first is Cancel Segment Reason Codes: when LTP cancels a data transfer, it includes a reason code. Values 0 through 5 are defined in RFC 5326 (client service canceled, unreachable service, retransmission limit exceeded, miscolored data, system error, and retransmission limit again). Values 6 through 255 are available for assignment using the Specification Required policy.
Second, LTP Engine IDs identify LTP service instances. The ID space is divided into ranges: 1 through 2^14-1 require Expert Review; 2^14 through 2^21-1 are allocated to CCSDS (space missions); 2^21 through 2^28-1 are private or experimental; 2^28 through 2^42-1 are available on a First Come First Served basis. Third, LTP Client Service IDs identify services using LTP (such as the Bundle Protocol, value 1, or LTP Service Data Aggregation, value 2). Ranges 4 through 2^14-1 are allocated to CCSDS, 2^14 through 32767 are private or experimental, and 32768 and above require specification.
LTP has three lists: why transfers are canceled, who the LTP engines are, and what services are talking over LTP. Each list has reserved slots for official things, space stuff, experiments, and anyone who asks.
§3CBHE and Bundle Protocol Registries
The Compressed Bundle Header Encoding specification requires two registries. CBHE Node Numbers identify network nodes in the 'ipn' URI scheme. Like LTP Engine IDs, the value space is segmented: 1 through 2^14-1 for Expert Review; 2^14 through 2^21-1 for CCSDS; 2^21 through 2^28-1 for private or experimental use; 2^28 through 2^42-1 for first-come-first-served; and 2^42 and above reserved. CBHE Service Numbers identify service types (Bundle Protocol Administrative Records, value 0; CCSDS File Delivery Service, value 1). Values 0-63 require specification; 64-1023 are allocated to CCSDS; 1024 to 2^16-1 require specification; 2^16 and above are private or experimental.
The Bundle Protocol itself defines Administrative Record Types, a 4-bit field. Values 0 is reserved, 1 is bundle status report, 2 is custody signal (all from RFC 5050), and 3-15 are unassigned and available via Specification Required.
CBHE needs two lists: which network nodes exist, and what services can run on them. Bundle Protocol adds a list of administrative message types. All three use a similar pattern: some are official, some are for space, some are free to claim.
§4Space Mission Delegation
A significant portion of the registry value spaces are delegated to the CCSDS Space Assigned Numbers Authority (SANA). CCSDS is the Consultative Committee for Space Data Systems, and SANA maintains registries for protocols used by its member agencies (space agencies and space organizations worldwide).
Delegating ranges to SANA recognizes that space communication is a specialized domain with different requirements. Missions often coordinate in advance, and having a dedicated authority for space-related values allows IANA to focus on terrestrial and general-purpose uses while SANA manages the space mission namespace. This document specifies the ranges handed to SANA for each registry, typically the mid-tier ranges that allow both official assignments and research use.
Space missions are special and coordinate together through CCSDS, so they get their own section of each list. IANA and SANA work together so neither one has to do the other's job.