Delay-Tolerant Networking Bundle Protocol IANA Registries
RFC 6255
|
Document |
Type |
|
RFC - Informational
(May 2011; No errata)
|
|
Author |
|
Marc Blanchet
|
|
Last updated |
|
2015-10-14
|
|
Replaces |
|
draft-blanchet-dtnrg-iana-registries
|
|
Stream |
|
IRTF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
IRTF state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 6255 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jari Arkko
|
|
IESG note |
|
IRTF submission. Elwyn Davies (elwynd@dial.pipex.com) is the document shepherd.
|
|
Send notices to |
|
elwynd@dial.pipex.com
|
Internet Research Task Force (IRTF) M. Blanchet
Request for Comments: 6255 Viagenie
Category: Informational May 2011
ISSN: 2070-1721
Delay-Tolerant Networking Bundle Protocol IANA Registries
Abstract
The Delay-Tolerant Networking (DTN) Research Group research group has
defined many protocols such as the Bundle Protocol and Licklider
Transmission Protocol. The specifications of these protocols contain
fields that are subject to a registry. For the purpose of its
research work, the group 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
executed by IANA.
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
Network 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/rfc6255.
Copyright Notice
Copyright (c) 2011 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.
Blanchet Informational [Page 1]
RFC 6255 DTN IANA Registries May 2011
Table of Contents
1. Introduction ....................................................2
2. Treatment of Flag Fields Encoded Using SDNVs ....................2
3. Bundle Protocol .................................................3
3.1. Bundle Block Types .........................................3
3.2. Primary Bundle Protocol Version ............................3
3.3. Bundle Processing Control Flags ............................4
3.4. Block Processing Control Flags .............................5
3.5. Bundle Status Report Flags .................................6
3.6. Bundle Status Report Reason Codes ..........................7
3.7. Bundle Custody Signal Reason Codes .........................7
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
6. Acknowledgements ................................................8
7. References ......................................................9
7.1. Normative References .......................................9
7.2. Informative References .....................................9
1. Introduction
The DTNRG research group has defined many protocols relevant to the
DTN architecture [RFC4838] such as the Bundle Protocol [RFC5050] and
Licklider Transmission Protocol [RFC5326]. The specifications of
these protocols contain fields that are subject to a registry. For
the purpose of its research work, the group created ad hoc registries
(http://www.dtnrg.org/wiki/AssignedNamesAndNumbers). 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
executed by IANA.
2. Treatment of Flag Fields Encoded Using SDNVs
The DTN protocols use several extensible bit flag fields that are
encoded as Self-Delimiting Numeric Values (SDNVs) as defined in
Section 4.1 of [RFC5050]. For these fields, the registry specifies
the allocation and usage of bit positions within the unencoded field.
The SDNV encoding treats the ensemble of bits in the unencoded value
as a numeric value to be encoded on transmission and decoded on
reception as described in [RFC5050].
Processing of SDNV-encoded flags is discussed in [RFC6256].
Section 4.1 of [RFC5050] specifies that implementations are not
required to handle SDNVs with more than 64 bits in their unencoded
value. Accordingly, SDNV-encoded flag fields should be limited to 64
bit positions.
Blanchet Informational [Page 2]
Show full document text