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

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 'ipn' URI scheme. Finally, RFC5050 [RFC5050] defines values for the Bundle Administrative Record Type. All of these describe 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.

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 June 17, 2013.

Copyright Notice

Copyright (c) 2012 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. Licklider Transmission Protocol
• 2.1. LTP Cancel Segment Reason Codes
• 2.2. LTP Engine ID
• 2.3. LTP Client Service ID
• 3. Compressed Bundle Header Encoding
• 3.1. CBHE Node Numbers
• 3.2. CBHE Service Numbers
• 4. Bundle Administrative Record Types
• 5. Security Considerations
• 6. IANA Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.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 [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. 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.

2.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: RFC Required

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

LTP Cancel Segment Reason Codes Registry

2.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. The designated experts for the review are the chairs of the IRTF DTN Research Group (dtnrg) if the dtnrg is extant, or as determined by the IRSG.

(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. No assignment by IANA.

(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 designated experts for the review are the chairs of the IRTF DTN Research Group (dtnrg) if the dtnrg is extant, or as determined by the IRSG.

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

2.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; no assignment by IANA.

>= 32,768

Expert review required. The designated experts for the review are the chairs of the IRTF DTN Research Group (dtnrg) if the dtnrg is extant, or as determined by the IRSG.

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. Compressed Bundle Header Encoding

The CBHE specification defines concepts of 'Node Number' and 'Service Number' that require registries managed by IANA.

3.1. CBHE Node Numbers

The CBHE specification defnes 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

Allocatable by IANA; expert review required. The designated experts for the review are the chairs of the IRTF DTN Research Group (dtnrg) if the dtnrg is extant, or as determined by the IRSG.

(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. No assignment by IANA.

(2**28) -- (2**42)-1

Allocatable by IANA on a 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 designated experts for the review are the chairs of the IRTF DTN Research Group (dtnrg) if the dtnrg is extant, or as determined by the IRSG.

>= (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. 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-127

Allocated to the Space Assigned Numbers Authority ([SANA]) for use by Consultative Committee for Space Data Systems (CCSDS) missions.

128 - 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 Node Number range from 1 -- (2**64)-1. The initial values for the CBHE Node Number registry shall be:

CBHE Service Number Registry

4. 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:RFC required

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

Bundle Protocol Administrative Record Type Registry

5. 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.

6. IANA Considerations

IANA is requested to create the registries as described in Sections 2, 3, and 4 of this document.

7. Acknowledgements

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

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses