Internet DRAFT - draft-burleigh-dtn-rs-cbor

draft-burleigh-dtn-rs-cbor



Delay-Tolerant Networking Working Group                     S. Burleigh
Internet Draft                          JPL, Calif. Inst. Of Technology
Intended status: Standards Track                         April 29, 2016
Expires: October 2016

             Bundle Protocol CBOR Representation Specification
                     draft-burleigh-dtn-rs-cbor-01.txt


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on October 31, 2016.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.



Burleigh                 Expires October 2016                  [Page 1]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   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.

Abstract

   This Internet Draft presents a specification for the use of Concise
   Binary Object Representation (CBOR) in the representation of
   transmitted Bundle Protocol (BP) bundles.

Table of Contents


   1. Introduction...................................................3
   2. Conventions used in this document..............................3
   3. BP Data Structure Representations in CBOR......................3
      3.1. DTN Time..................................................3
      3.2. Creation Timestamp........................................4
      3.3. Endpoint ID...............................................4
      3.4. Bundle Processing Control Flags...........................4
      3.5. Fragment ID...............................................5
      3.6. CRC.......................................................5
      3.7. Block Processing Control Flags............................5
      3.8. Block-type-specific Data..................................6
   4. Bundle Representation in CBOR..................................6
      4.1. Bundle....................................................6
      4.2. Primary Block.............................................6
      4.3. Canonical Block...........................................7
   5. Block-type-specific Data Representations in CBOR...............8
      5.1. Payload Block (block type 1)..............................8
      5.2. Block Integrity Block (block type 2)......................8
      5.3. Block Confidentiality Block (block type 3)................8
      5.4. Manifest Block (block type 4).............................8
      5.5. Current Custodian Block (block type 5)....................9
      5.6. Flow Label Block (block type 6)...........................9
      5.7. Previous Node Block (block type 7)........................9
      5.8. Bundle Age Block (block type 8)...........................9
      5.9. Hop Count Block (block type 9)............................9
   6. Administrative Records.........................................9
      6.1. Bundle Status Report (record type 1).....................10
      6.2. Custody Signal (record type 2)...........................11


Burleigh                 Expires October 2016                  [Page 2]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   7. Security Considerations.......................................11
   8. IANA Considerations...........................................11
   9. References....................................................12
      9.1. Normative References.....................................12
      9.2. Informative References...................................12
   10. Acknowledgments..............................................12
   Appendix A. For More Information.................................13

1. Introduction

   The Bundle Protocol specification [BPBIS] states that it defines
   only the abstract structures of the "blocks" of which bundles are
   composed:

     "The specific bitstream that is emitted when a CLA sends a bundle
     will be dictated by the applicable bundle representation
     specification to which the sending and receiving nodes conform, an
     implementation matter....Bundle representation specifications are
     beyond the scope of this document."

   One bundle representation approach that has been suggested is to
   utilize Concise Binary Object Representation (CBOR [RFC7049]) for
   this purpose.  The design goals of CBOR appear to meet the
   operational requirements of a wide range of BP use cases.

   Accordingly, this document proposes specific rules for encoding and
   decoding bundles in CBOR representation.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS. Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3. BP Data Structure Representations in CBOR

3.1. DTN Time

   A DTN time is an unsigned integer indicating a count of seconds
   since the start of the year 2000 on the Coordinated Universal Time
   (UTC) scale [UTC].  Each DTN time SHALL be represented as a CBOR
   unsigned integer item; the unsigned integer following the item type
   byte SHALL contain the time value.


Burleigh                 Expires October 2016                  [Page 3]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


3.2. Creation Timestamp

   Each creation timestamp SHALL be represented as a CBOR array item
   with additional info 2, indicating that the item is a 2-tuple.

   The first item of the array SHALL be a DTN time.

   The second item of the array SHALL be the creation timestamp's
   sequence number, represented as a CBOR unsigned integer.

3.3. Endpoint ID

   Each BP endpoint ID (EID) SHALL be represented as a CBOR array with
   additional info 2, indicating that the item is a 2-tuple.

   The first item of the array SHALL be the code number identifying the
   endpoint's URI scheme [URI], as defined in the registry of URI
   scheme code numbers maintained by IANA as described in Section 7.
   [URIREG].  Each URI scheme code number SHALL be represented as a
   CBOR unsigned integer.

   The second item of the array SHALL be the applicable CBOR
   representation of the scheme-specific part (SSP) of the EID, defined
   as follows:

     . If the EID's URI scheme is "dtn" then the SSP SHALL be
        represented as a CBOR text string.
     . If the EID's URI scheme is "ipn" then the SSP SHALL be
        represented as a CBOR array with additional info 2, indicating
        that the item is a 2-tuple.  The first item of this array SHALL
        be the EID's node number represented as a CBOR unsigned
        integer.  The second item of this array SHALL be the EID's
        service number represented as a CBOR unsigned integer.
     . Definitions of the CBOR representations of the SSPs of EIDs
        encoded in other URI schemes are included in the specifications
        defining those schemes.

3.4. Bundle Processing Control Flags

   The bundle processing control flags SHALL be represented as a CBOR
   unsigned integer item with additional info 25; the 16-bit unsigned
   integer following the item type byte SHALL be a bit field indicating
   the control flag values as follows:

     . Bit 0 (the high-order bit, 0x8000): reserved.
     . Bit 1 (0x4000): reserved.
     . Bit 2(0x2000): reserved.


Burleigh                 Expires October 2016                  [Page 4]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


     . Bit 3(0x1000): bundle deletion status reports are requested.
     . Bit 4(0x0800): bundle delivery status reports are requested.
     . Bit 5(0x0400): bundle forwarding status reports are requested.
     . Bit 6(0x0200): custody acceptance status reports are requested.
     . Bit 7(0x0100): bundle reception status reports are requested.
     . Bit 8(0x0080): bundle contains a Manifest block.
     . Bit 9(0x0040): status time is requested in all status reports.
     . Bit 10(0x0020): user application acknowledgement is requested.
     . Bit 11(0x0010): destination is a singleton endpoint.
     . Bit 12(0x0008): custody transfer is requested.
     . Bit 13(0x0004): bundle must not be fragmented.
     . Bit 14(0x0002): payload is an administrative record.
     . Bit 15 (the low-order bit, 0x0001: bundle is a fragment.

3.5. Fragment ID

   Fragment ID SHALL be omitted from the primary block if and only if
   the value of the "bundle is a fragment" flag in the bundle
   processing control flags is zero.

   Otherwise, the bundle's fragment ID SHALL be represented as a CBOR
   array with additional info 2, indicating that the item is a 2-tuple.
   The first item of this array SHALL be the fragment offset of the
   bundle's payload, represented as a CBOR unsigned integer.  The
   second item of this array SHALL be the total (original) application
   data unit length, represented as a CBOR unsigned integer.

3.6. CRC

   CRC SHALL be omitted from a block if and only if the block's CRC
   type code is zero.

   When not omitted, the CRC SHALL be represented as a CBOR unsigned
   integer.

3.7. Block Processing Control Flags

   The block processing control flags SHALL be represented as a CBOR
   unsigned integer item with additional info 24; the 8-bit unsigned
   integer following the item type byte SHALL be a bit field indicating
   the control flag values as follows:

     . Bit 0 (the high-order bit, 0x80): reserved.
     . Bit 1 (0x40): reserved.
     . Bit 2(0x20): reserved.
     . Bit 3(0x10): reserved.



Burleigh                 Expires October 2016                  [Page 5]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


     . Bit 4(0x08): bundle must be deleted if block can't be
        processed.
     . Bit 5(0x04): status report must be transmitted if block can't
        be processed.
     . Bit 6(0x02): block must be removed from bundle if it can't be
        processed.
     . Bit 7(the low-order bit, 0x01): block must be replicated in
        every fragment.

3.8. Block-type-specific Data

   Block-type-specific data in each block (other than the primary
   block) SHALL be the applicable CBOR representation of the content of
   the block.  Details of this representation are included in the
   specification defining the block type.

4. Bundle Representation in CBOR

4.1. Bundle

   Each bundle SHALL be represented as a CBOR indefinite-length array
   (major type 4 with additional info 31).  The first item of this
   array SHALL be the CBOR representation of a Primary Block.  Every
   other item of the array except the last SHALL be the CBOR
   representation of a Canonical Block.  The last item of the array
   SHALL be a CBOR "break" stop code (major type 7 with additional
   information 31).

4.2. Primary Block

   Each primary block SHALL be represented as a CBOR array with
   additional info either 8 (if the bundle is not a fragment and CRC
   type is zero) or 9 (if the bundle is a fragment or CRC type is non-
   zero, but not both) or 10 (if the bundle is a fragment and CRC-type
   is non-zero).  The items of this array SHALL be as indicated in
   Table 1, appearing in the order shown in this table.

   +-------------+-----------------+---------------------------------+
   |             | Item Type Byte  |          Content Bytes          |
   |             |                 |                                 |
   |             | Major           |                                 |
   |             | Item   | Add'l  |                                 |
   |             | Type   | Info   |                                 |
   |    Item     | 3 bits | 5 bits | Size | Value                    |
   +=============+========+========+======+==========================+
   | version     |   4    |   7    | n/a  | n/a                      |
   +-------------+--------+--------+------+--------------------------+


Burleigh                 Expires October 2016                  [Page 6]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   | bundle      |   See 3.4. above                                   |
   | processing  |        |        |      |                          |
   | control     |        |        |      |                          |
   | flags       |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | CRC type    |   4    |  type  | n/a  | n/a                      |
   |             |        |  code  |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | destination |   See 3.3. above                                   |
   | EID         |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | source node |   See 3.3. above                                   |
   | ID          |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | report-to   |   See 3.3. above                                   |
   | EID         |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | creation    |   See 3.2. above                                   |
   | timestamp   |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | lifetime    |   4    |   as required to contain value           |
   +-------------+--------+--------+------+--------------------------+
   | fragment ID |   See 3.5. above                                   |
   +-------------+--------+--------+------+--------------------------+
   | CRC         |   See 3.6. above                                   |
   +-------------+--------+--------+------+--------------------------+

                     Table 1: Primary Block Data Items

4.3. Canonical Block

   Each block other than the primary block SHALL be represented as a
   CBOR array with additional info either 5 (if CRC type is zero) or 6
   (otherwise).  The items of this array SHALL be as indicated in Table
   2, appearing in the order shown in this table.

   +-------------+-----------------+---------------------------------+
   |             | Item Type Byte  |          Content Bytes          |
   |             |                 |                                 |
   |             | Major           |                                 |
   |             | Item   | Add'l  |                                 |
   |             | Type   | Info   |                                 |
   |    Item     | 3 bits | 5 bits | Size | Value                    |
   +=============+========+========+======+==========================+
   | block type  |   4    |   as required to contain value           |
   | code        |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+


Burleigh                 Expires October 2016                  [Page 7]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   | block number|   4    |   as required to contain value           |
   +-------------+--------+--------+------+--------------------------+
   | block       |   See 3.7. above                                   |
   | processing  |        |        |      |                          |
   | control     |        |        |      |                          |
   | flags       |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | CRC type    |   4    |  type  |  n/a | n/a                      |
   |             |        |  code  |      |                          |
   +-------------+--------+--------+------+--------------------------+
   | CRC         |   See 3.6. above                                   |
   +-------------+--------+--------+------+--------------------------+
   | block-type- |   See 3.8. above                                   |
   | specific    |        |        |      |                          |
   | data        |        |        |      |                          |
   +-------------+--------+--------+------+--------------------------+

                    Table 2: Canonical Block Data Items

5. Block-type-specific Data Representations in CBOR

5.1. Payload Block (block type 1)

   The block-type-specific data in a payload block is an application
   data unit, or some contiguous extent thereof, which SHALL be
   represented as a CBOR byte string.

5.2. Block Integrity Block (block type 2)

   The representation of the block-type-specific data in a block
   integrity block is provided in the Bundle Security Protocol
   specification, a work in progress.

5.3. Block Confidentiality Block (block type 3)

   The representation of the block-type-specific data in a block
   confidentiality block is provided in the Bundle Security Protocol
   specification, a work in progress.

5.4. Manifest Block (block type 4)

   The representation of the block-type-specific data in a manifest
   block is provided in the Manifest Extension Block specification,
   TBD.





Burleigh                 Expires October 2016                  [Page 8]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


5.5. Current Custodian Block (block type 5)

   The block-type-specific data in a current custodian block is a node
   ID, which takes the form of an endpoint ID represented as described
   in Section 3.3. above.

5.6. Flow Label Block (block type 6)

   The representation of the block-type-specific data in a flow label
   block is provided in the Flow Label Extension Block specification,
   TBD.

5.7. Previous Node Block (block type 7)

   The block-type-specific data in a previous node block is a node ID,
   which takes the form of an endpoint ID represented as described in
   Section 3.3. above.

5.8. Bundle Age Block (block type 8)

   The block-type-specific data in a bundle age block is the age of the
   bundle in seconds, which SHALL be represented as a CBOR unsigned
   integer.

5.9. Hop Count Block (block type 9)

   The block-type-specific data in a hop count block SHALL be
   represented as a CBOR array (major type 4) with additional info 2,
   indicating that the item is a 2-tuple.  The first item of this array
   SHALL be the bundle's hop limit, represented as a CBOR unsigned
   integer.  The second item of this array SHALL be the bundle's hop
   count, represented as a CBOR unsigned integer.

6. Administrative Records

   Each BP administrative record SHALL be represented as a CBOR array
   (major type 4) with additional info 2 indicating that the item is a
   2-tuple.

   The first item of the array SHALL be a record type code, which SHALL
   be represented as a CBOR unsigned integer.

   The second element of this array SHALL be the applicable CBOR
   representation of the content of the record.  Details of the CBOR
   representations of administrative record types 1 and 2 are provided
   below.  Details of the CBOR representations of other types of



Burleigh                 Expires October 2016                  [Page 9]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   administrative record type are included in the specifications
   defining those records.

6.1. Bundle Status Report (record type 1)

   Each bundle status report SHALL be represented as a CBOR array
   (major type 4) with additional info either 5 (if the subject bundle
   is a fragment) or 4 (otherwise).

   The first item of the bundle status report array SHALL be bundle
   status information represented as a CBOR array (major type 4) with
   additional info 5.  The five items of the bundle status information
   array shall provide information on the following five status
   assertions, in this order:

     . Reporting node received bundle.
     . Reporting node accepted custody of bundle.
     . Reporting node forwarded the bundle.
     . Reporting node delivered the bundle.
     . Reporting node deleted the bundle.

   Each item of the bundle status information array SHALL be a bundle
   status item represented as a CBOR array (major type 4) with
   additional info either 2 (if the value of the first item of this
   bundle status item is 1) or 1 (otherwise).  The first item of the
   bundle status item array SHALL be a Boolean value, indicating
   whether or not the corresponding bundle status is asserted,
   represented as a CBOR unsigned integer (major type 0).  The second
   item of the bundle status item array, if present, SHALL be a DTN
   time as described in Section 3.1. above.

   The second item of the bundle status report array SHALL be the
   bundle status report reason code, represented as a CBOR unsigned
   integer.

   The third item of the bundle status report array SHALL be the source
   node ID of the subject bundle, taking the form of an endpoint ID and
   represented as described in Section 3.3. above.

   The fourth item of the bundle status report array SHALL be the
   creation timestamp of the subject bundle, represented as described
   in Section 3.2. above.

   The fifth item of the bundle status report array, if present, SHALL
   be the subject bundle's fragment reference represented as a CBOR
   array (major type 4) with additional info 2 indicating that the item
   is a 2-tuple.  The first item of this array SHALL be the fragment


Burleigh                 Expires October 2016                 [Page 10]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


   offset of the subject bundle's payload, represented as a CBOR
   unsigned integer.  The second item of this array SHALL be the length
   of the payload of the subject bundle, represented as a CBOR unsigned
   integer.

6.2. Custody Signal (record type 2)

   Each custody signal SHALL be represented as a CBOR array (major type
   4) with additional info either 5 (if the subject bundle is a
   fragment) or 4 (otherwise).

   The first item of the custody signal array SHALL be a Boolean value,
   indicating whether or not custody was accepted, represented as a
   CBOR unsigned integer.

   The second item of the custody signal array SHALL be the bundle
   status report reason code, represented as a CBOR unsigned integer.

   The third item of the custody signal array SHALL be the source node
   ID of the subject bundle, taking the form of an endpoint ID and
   represented as described in Section 3.3. above.

   The fourth item of the custody signal array SHALL be the creation
   timestamp of the subject bundle, represented as described in Section
   3.2. above.

   The fifth item of the custody signal array, if present, SHALL be the
   subject bundle's fragment reference represented as a CBOR array
   (major type 4) with additional info 2 indicating that the item is a
   2-tuple.  The first item of this array SHALL be the fragment offset
   of the subject bundle's payload, represented as a CBOR unsigned
   integer.  The second item of this array SHALL be the length of the
   payload of the subject bundle, represented as a CBOR unsigned
   integer.

7. Security Considerations

   Representation of DTN bundles in CBOR introduces no security
   considerations beyond those introduced by the Bundle Protocol.

8. IANA Considerations

   A registry of URI scheme type numbers will be required.






Burleigh                 Expires October 2016                 [Page 11]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


9. References

9.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object
   Representation (CBOR)", RFC 7049, October 2013.

   [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
   Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
   January 2005.

   [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and
   Registration Procedures for URI Schemes", RFC 7595, BCP 35, June
   2015.

9.2. Informative References

   [BPBIS] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
   Work In Progress, March 2016.

   [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC:
   historical background and perspectives" in "Journees systemes de
   reference spatio-temporels", 2004.

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.



















Burleigh                 Expires October 2016                 [Page 12]

Internet-Draft     Proposed Revised Bundle Protocol          April 2016


Appendix A.                 For More Information

   Please refer comments to dtn@ietf.org. The Delay Tolerant Networking
   Research Group (DTNRG) Web site is located at http://www.dtnrg.org.

   Copyright (c) 2016 IETF Trust and the persons identified as authors
   of the code. All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in Section
   4.c of the IETF Trust's Legal Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info).

Authors' Addresses

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Dr.
   Pasadena, CA 91109-8099
   US
   Phone: +1 818 393 3353
   Email: Scott.Burleigh@jpl.nasa.gov


























Burleigh                 Expires October 2016                 [Page 13]