Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries
draft-dtnrg-ltp-cbhe-registries-06

Abstract

The DTNRG research group has defined the experimental Licklider Transmission Protocol (LTP) [RFC5326] and the Compressed Bundle Header Encoding (CBHE) [RFC6260] mechanism for the InterPlanetary Network (ipn URI scheme). Moreover, RFC5050 [RFC5050] defines values for the Bundle 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 custody. This document describes the actions needed to be executed by IANA.

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 March 01, 2014.

Copyright Notice

Copyright (c) 2013 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
• 2. Security Considerations
• 3. IANA Considerations
• 3.1. Licklider Transmission Protocol
• 3.1.1. LTP Cancel Segment Reason Codes
• 3.1.2. LTP Engine ID
• 3.1.3. LTP Client Service ID
• 3.2. Compressed Bundle Header Encoding
• 3.2.1. CBHE Node Numbers
• 3.2.2. CBHE Service Numbers
• 3.3. Bundle Administrative Record Types
• 4. Acknowledgements
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Authors' Addresses

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 custody. This document describes the actions needed to be executed by IANA using the Well-Known IANA Policy Definitions defined 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 an IANA registry for the Node Number field in the 'ipn' scheme.

Because of its association with space communication and the Consultative Committee on Space Data Systems [CCSDS], a portion of the CBHE Node Number space and a corresponding portion of the LTP Engine ID space is 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.

2. Security Considerations

This document requests the creation of registries managed by IANA. Thera are no security issues involved. Refer to the Security Considerations section of [RFC5326] for security issues with the LTP protocol.

3. IANA Considerations

IANA is requested to create registries as 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 that they be associated with the other registries for the Licklider Transmission protocol.

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 the LTP protocol.

The registration policy for this registry is: Specification Required

The initial values(as defined by RFC5326) for the LTP Cancel Segment Reason Codes registry shall be:

LTP Cancel Segment Reason Codes Registry

3.1.2. LTP Engine ID

The Licklider Transmission Protocol has an LTP Engine ID field (section 2 of [RFC5326]). An IANA registry shall be set up as follows.

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 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 the LTP protocol and no maximum is specified in the protocol definition. SDNVs are described in Section 4.1 of the Bundle Protocol in [RFC5050] and are also described in the stand-alone document [RFC6256]. The initial values for the LTP Engine Numbers registry shall be:

LTP Engine Numbers Registry

3.1.3. LTP Client Service ID

The Licklider Transmission Protocol has a client service ID number field (section 3.2.1 of [RFC5326]). An IANA registry shall be set up as follows.

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 the LTP protocol and no maximum value is specified in the protocol definition. The initial values for the LTP Client Service Identifiers registry shall be:

LTP Client Service Identifiers Registry

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]). An IANA registry shall be set up as follows.

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

CBHE Node Number Registry

3.2.2. CBHE Service Numbers

The Compressed Bundle Header Enoding specification defnes a Service Number (service-nbr) field (section 2.1 of [RFC6260]). An IANA registry shall be set up as follows.

The registration policy for this registry is:

0-63

RFC 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 shall be:

CBHE Service Number Registry

3.3. Bundle Administrative Record Types

Section 6.1 of the Bundle Protocol specification[RFC5050] specifies a 4-bit Administrative Record type code. An IANA registry shall be set up as follows to manage these record types. This document requests the addition of an additional registry titled 'Bundle Administrative Record Type' be added to the list of registries associated with the Bundle Protcol.

The registration policy for this registry is: Specification required

The initial values for the Bundle Administrative Record Type registry shall be:

Bundle Protocol Administrative Record Type Registry

4. Acknowledgements

The editors would like to thank the following people, in no specific order: Scott Burleigh, Stephen Farrell, John Buford.

5. References

5.1. Normative References

5.2. Informative References

Authors' Addresses