doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc6255.txt b/doc/rfc/rfc6255.txt
new file mode 100644
index 0000000..9549438
--- /dev/null
+++ b/doc/rfc/rfc6255.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+   IANA registry policies and wording used in this document are
+   described in [RFC5226].
+
+3.  Bundle Protocol
+
+   The Bundle Protocol (BP) [RFC5050] has fields requiring a registry
+   managed by IANA.
+
+3.1.  Bundle Block Types
+
+   The Bundle Protocol has a Bundle Block Type code field (Section
+   4.5.2) [RFC5050].  An IANA registry has been set up as follows.
+
+   The registration policy for this registry is:
+
+      0-191: Specification Required
+
+      192-255: Private or experimental use.  No assignment by IANA.
+
+   The Value range is: unsigned 8-bit integer.
+
+                        Bundle Block Type Registry
+
+    +--------------+---------------------------------+---------------+
+    |        Value | Description                     | Reference     |
+    +--------------+---------------------------------+---------------+
+    |            0 | Reserved                        | This document |
+    |            1 | Bundle Payload Block            | [RFC5050]     |
+    |        2-191 | Unassigned                      |               |
+    |      192-255 | Private and/or Experimental Use | [RFC5050]     |
+    +--------------+---------------------------------+---------------+
+
+   The value "0" was not defined in any document or in the ad hoc
+   registry.  As per consensus by the DTNRG research group, it is
+   reserved per this document.
+
+3.2.  Primary Bundle Protocol Version
+
+   The Bundle Protocol has a version field (see Section 4.5.1 of
+   [RFC5050]).  An IANA registry has been set up as follows.
+
+   The registration policy for this registry is: RFC Required
+
+   The Value range is: unsigned 8-bit integer.
+
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 3]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+                 Primary Bundle Protocol Version Registry
+
+                  +-------+-------------+---------------+
+                  | Value | Description | Reference     |
+                  +-------+-------------+---------------+
+                  |   0-5 | Reserved    | This document |
+                  |     6 | Assigned    | [RFC5050]     |
+                  | 7-255 | Unassigned  |               |
+                  +-------+-------------+---------------+
+
+   The value "0-5" was not defined in any document or in the ad hoc
+   registry.  As per consensus by the DTNRG research group, it is
+   reserved per this document.
+
+3.3.  Bundle Processing Control Flags
+
+   The Bundle Protocol has a Bundle Processing Control Flags field (see
+   Section 4.2 of [RFC5050]) encoded as an SDNV (see Section 2).  An
+   IANA registry has been set up as follows.
+
+   The registration policy for this registry is: Specification Required
+
+   The Value range is: Variable length.  Maximum number of flag bit
+   positions: 64
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 4]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+                 Bundle Processing Control Flags Registry
+
+   +--------------------+----------------------------------+-----------+
+   |       Bit Position | Description                      | Reference |
+   |    (right to left) |                                  |           |
+   +--------------------+----------------------------------+-----------+
+   |                  0 | Bundle is a fragment             | [RFC5050] |
+   |                  1 | Application data unit is an      | [RFC5050] |
+   |                    | administrative record            |           |
+   |                  2 | Bundle must not be fragmented    | [RFC5050] |
+   |                  3 | Custody transfer is requested    | [RFC5050] |
+   |                  4 | Destination endpoint is a        | [RFC5050] |
+   |                    | singleton                        |           |
+   |                  5 | Acknowledgement by application   | [RFC5050] |
+   |                    | is requested                     |           |
+   |                  6 | Reserved                         | [RFC5050] |
+   |                7-8 | Class of service: priority       | [RFC5050] |
+   |               9-13 | Class of service: reserved       | [RFC5050] |
+   |                 14 | Request reporting of bundle      | [RFC5050] |
+   |                    | reception                        |           |
+   |                 15 | Request reporting of custody     | [RFC5050] |
+   |                    | acceptance                       |           |
+   |                 16 | Request reporting of bundle      | [RFC5050] |
+   |                    | forwarding                       |           |
+   |                 17 | Request reporting of bundle      | [RFC5050] |
+   |                    | delivery                         |           |
+   |                 18 | Request reporting of bundle      | [RFC5050] |
+   |                    | deletion                         |           |
+   |                 19 | Reserved                         | [RFC5050] |
+   |                 20 | Reserved                         | [RFC5050] |
+   |              21-63 | Unassigned                       |           |
+   +--------------------+----------------------------------+-----------+
+
+3.4.  Block Processing Control Flags
+
+   The Bundle Protocol has a Block Processing Control Flags field (see
+   Section 4.3 of [RFC5050]).  An IANA registry has been set up as
+   follows.
+
+   The registration policy for this registry is: Specification Required
+
+   The Value range is: Variable length.  Maximum number of flag bit
+   positions: 64
+
+
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 5]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+                  Block Processing Control Flags Registry
+
+   +--------------------+----------------------------------+-----------+
+   |       Bit Position | Description                      | Reference |
+   |    (right to left) |                                  |           |
+   +--------------------+----------------------------------+-----------+
+   |                  0 | Block must be replicated in      | [RFC5050] |
+   |                    | every fragment                   |           |
+   |                  1 | Transmit status report if block  | [RFC5050] |
+   |                    | can't be processed               |           |
+   |                  2 | Delete bundle if block can't be  | [RFC5050] |
+   |                    | processed                        |           |
+   |                  3 | Last block                       | [RFC5050] |
+   |                  4 | Discard block if it can't be     | [RFC5050] |
+   |                    | processed                        |           |
+   |                  5 | Block was forwarded without      | [RFC5050] |
+   |                    | being processed                  |           |
+   |                  6 | Block contains an EID-reference  | [RFC5050] |
+   |                    | field                            |           |
+   |               7-63 | Unassigned                       |           |
+   +--------------------+----------------------------------+-----------+
+
+3.5.  Bundle Status Report Flags
+
+   The Bundle Protocol has a Status Report Status Flag field (see
+   Section 6.1.1 of [RFC5050]).  An IANA registry has been set up as
+   follows.
+
+   The registration policy for this registry is: RFC Required
+
+   The Value range is: 8 bits.
+
+                    Bundle Status Report Flags Registry
+
+   +----------+----------------------------------------+---------------+
+   |    Value | Description                            | Reference     |
+   +----------+----------------------------------------+---------------+
+   | 00000000 | Reserved                               | This document |
+   | 00000001 | Reporting node received bundle         | [RFC5050]     |
+   | 00000010 | Reporting node accepted custody of     | [RFC5050]     |
+   |          | bundle                                 |               |
+   | 00000100 | Reporting node forwarded the bundle    | [RFC5050]     |
+   | 00001000 | Reporting node delivered the bundle    | [RFC5050]     |
+   | 00010000 | Reporting node deleted the bundle      | [RFC5050]     |
+   | 00100000 | Unassigned                             |               |
+   | 01000000 | Unassigned                             |               |
+   | 10000000 | Unassigned                             |               |
+   +----------+----------------------------------------+---------------+
+
+
+
+Blanchet                      Informational                     [Page 6]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+   The value "00000000" was not defined in any document or in the ad hoc
+   registry.  As per consensus by the DTNRG research group, it is
+   reserved per this document.
+
+3.6.  Bundle Status Report Reason Codes
+
+   The Bundle Protocol has a Bundle Status Report Reason Codes field
+   (see Section 6.1.1 of [RFC5050]).  An IANA registry has been set up
+   as follows.
+
+   The registration policy for this registry is: Specification Required
+
+   The Value range is: unsigned 8-bit integer.
+
+                Bundle Status Report Reason Codes Registry
+
+   +-------+-------------------------------------------+---------------+
+   | Value | Description                               | Reference     |
+   +-------+-------------------------------------------+---------------+
+   |     0 | No additional information                 | [RFC5050]     |
+   |     1 | Lifetime expired                          | [RFC5050]     |
+   |     2 | Forwarded over unidirectional link        | [RFC5050]     |
+   |     3 | Transmission canceled                     | [RFC5050]     |
+   |     4 | Depleted storage                          | [RFC5050]     |
+   |     5 | Destination endpoint ID unintelligible    | [RFC5050]     |
+   |     6 | No known route to destination from here   | [RFC5050]     |
+   |     7 | No timely contact with next node on route | [RFC5050]     |
+   |     8 | Block unintelligible                      | [RFC5050]     |
+   | 9-254 | Unassigned                                |               |
+   |   255 | Reserved                                  | This document |
+   +-------+-------------------------------------------+---------------+
+
+   The value "255" was not defined in any document or in the ad hoc
+   registry.  As per consensus by the DTNRG research group, it is
+   reserved per this document.
+
+3.7.  Bundle Custody Signal Reason Codes
+
+   The Bundle Protocol has a Bundle Custody Signal Reason Codes field
+   (see Section 6.1.2 of [RFC5050]).  An IANA registry has been set up
+   as follows.
+
+   The registration policy for this registry is: Specification Required
+
+   The Value range is: unsigned 7-bit integer.
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 7]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+                Bundle Custody Signal Reason Codes Registry
+
+   +--------------+--------------------------------------+-------------+
+   |        Value | Description                          | Reference   |
+   +--------------+--------------------------------------+-------------+
+   |            0 | No additional information            | [RFC5050]   |
+   |          1-2 | Unassigned                           |             |
+   |            3 | Redundant reception (reception by a  | [RFC5050]   |
+   |              | node that is a custodial node for    |             |
+   |              | this bundle)                         |             |
+   |            4 | Depleted storage                     | [RFC5050]   |
+   |            5 | Destination endpoint ID              | [RFC5050]   |
+   |              | unintelligible                       |             |
+   |            6 | No known route to destination from   | [RFC5050]   |
+   |              | here                                 |             |
+   |            7 | No timely contact with next node on  | [RFC5050]   |
+   |              | route                                |             |
+   |            8 | Block unintelligible                 | [RFC5050]   |
+   |        9-126 | Unassigned                           |             |
+   |          127 | Reserved                             | This        |
+   |              |                                      | document    |
+   +--------------+--------------------------------------+-------------+
+
+   The value "127" was not defined in any document or in the ad hoc
+   registry.  As per consensus by the DTNRG research group, it is
+   reserved per this document.
+
+4.  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 the referenced protocols.
+
+5.  IANA Considerations
+
+   IANA has created the registries as described in the previous
+   sections.
+
+6.  Acknowledgements
+
+   The editor would like to thank the following people who have provided
+   comments and suggestions to this document, in no specific order:
+   Stephen Farrell, Daniel Ellard, Scott Burleigh, Keith Scott, and
+   Elwyn Davies.
+
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 8]
+
+RFC 6255                   DTN IANA Registries                  May 2011
+
+
+7.  References
+
+7.1.  Normative References
+
+   [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.
+
+7.2.  Informative References
+
+   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
+              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
+              Networking Architecture", RFC 4838, April 2007.
+
+   [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.
+
+Author's Address
+
+   Marc Blanchet
+   Viagenie
+   2875 boul. Laurier, suite D2-630
+   Quebec, QC  G1V 2M2
+   Canada
+
+   EMail: Marc.Blanchet@viagenie.ca
+   URI:   http://viagenie.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Blanchet                      Informational                     [Page 9]
+