Network Working Group J. Zinky Internet-Draft A. Caro Intended status: Experimental Raytheon BBN Technologies Expires: February 24, 2013 G. Stein Laboratory for Telecommunications Sciences August 23, 2012 Bundle Protocol Erasure Coding Basic Objects draft-zinky-dtnrg-erasure-coding-objects-00 Abstract This document defines the Basic Data Objects formats for the Erasure Coding Extension [ErasureCoding] to the Delay and Disruption Tolerant Network (DTN) Bundle Protocol [RFC5050]. The File Data Object format is used to store a binary file and includes metadata for the file name and path name. The Bundle Data Object format is used to store a large DTN Bundle and to map its implicit Transfer Specification to the headers of the Encoding Bundles. 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 February 24, 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 Zinky, et al. Expires February 24, 2013 [Page 1] Internet-Draft DTN-EC-Objects August 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Notation . . . . . . . . . . . . . . . . . . 4 3. File Data Object Format Type = 1 . . . . . . . . . . . . . . . 5 4. Bundle Data Object Format Type = 2 . . . . . . . . . . . . . . 8 4.1. Steps for Encoding a Bundle . . . . . . . . . . . . . . . 8 4.2. Steps for Decoding a Bundle . . . . . . . . . . . . . . . 9 4.3. Bundle Transfer Specification . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Zinky, et al. Expires February 24, 2013 [Page 2] Internet-Draft DTN-EC-Objects August 2012 1. Introduction Data Object formats define how an Application Layer data structure will be stored as an array of octets that will be transmitted using the Erasure Coding Extension to the Bundle protocol. The octet array will be divided into equal length Chunks that are the input and output of the Coding Layer. The Coding Layer does not offer any fields for storing the Data Object Length in its headers. Data Object formats have the responsibility for storing the Data Object Length, the Data Object itself, associated metadata, and padding within the octet array. The Coding Layer offers a service that MAY deliver Chunks as they are decoded instead of waiting for all chunks to be decoded. But both Data Object types defined in this document can not make use this feature and MUST have every Chunk delivered all together. The Data Object Format MAY put requirements and constraints into the Data Object Layer's Transfer Specification. The File Data Object format does not define any restrictions. The Bundle Data Object format defines an actionable Transfer Specification that is based on the implicit transfer specification in the original Bundle Header. This document defines two Data Object formats; a File Data Object format and a Bundle Data Object format. The File Data Object format is used to transfer a binary file between two applications. The Bundle Data Object format is used by DTN Bundle Protocol Agents (BPAs) to divide large Bundles into Chunks to take advantage of Forward Error Correction services. Each format is described in its own section. Future documents could define, additional Data Object formats, such as mime [RFC2045], zip, or video. This document ends with discussions on Security and IANA considerations. Zinky, et al. Expires February 24, 2013 [Page 3] Internet-Draft DTN-EC-Objects August 2012 2. Terminology The terminology used in this document follows the terminology of the Erasure Coding Extension to the Bundle Protocol [ErasureCoding]. Only terms specific to the Basic Data Objects are described in this section. 2.1. Definitions Data Object Format Type is a field in the Erasure Coding Extension Block [ErasureCoding]. It specifies the format for the array of octets that hold the Data Object and its meta data. This document defines two Data Object Format Types and their type number. Data Object Chunks are ordered equal length pieces of the octet array that store the Data Object, metadata, and padding. Chunks are created in the Data Object Layer and passed to the Coding Layer where they are encoded, transfered, and decoded. 2.2. Abbreviations BPA: Bundle Protocol Agent [RFC5050] DTN: Delay/Disruption Tolerant Network [RFC5050] SDNV: Self-Delimiting Numeric Values, see [RFC6256] 2.3. Requirements Notation 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 [RFC2119]. Zinky, et al. Expires February 24, 2013 [Page 4] Internet-Draft DTN-EC-Objects August 2012 3. File Data Object Format Type = 1 The File Data Object format stores a binary data file and the associated metadata about its name and intended storage path at the destination. The file format contains three sections, the file header, the file data, and the padding. The First Chunk MUST contain the whole file header, which constrains the minimum Chunk Length to be at least as long as the file header. Note that the file header is variable length, thus this constraint is specific to the Data Object. Only the last Chunk MAY contain padding, all other Chunks MUST NOT contain Padding. Except for the constraint above, the File Data Object Format does not restrict the Transfer Specification, that is Application Layer is responsibility for creating the Transfer Specification. The encoding and decoding process follows the procedures in the Erasure Coding Extension [ErasureCoding]. The octet array has the following format: Zinky, et al. Expires February 24, 2013 [Page 5] Internet-Draft DTN-EC-Objects August 2012 +-------------+----------+------------------------------------------+ | Field | Type | Description | +-------------+----------+------------------------------------------+ | Type | 4 Octets | 0xECECECEC: File Data Object Format Type | | | | constant. A magic number used to check | | | | that the decode process was successful. | | | | | | Version | 4 Octets | 0x00000001: Version number of header | | | | which increments with newer versions. | | | | | | Format: | 4 Octets | 0x00000001: Format of the File Data | | | | Object content. A value of one (1) | | | | specifies the 8-bit binary format. Other | | | | formats could be defined in the future, | | | | such as compressed or radix-64. | | | | | | File UUID | 128 bits | Must match Data Object UUID in Erasure | | | | Coding Extension Block. | | | | | | File Data | 8 Octets | Length of file in octets. | | Length | | | | | | | | File Name | String | Name and extension of the File Data. | | | | | | | 4 Octets | File Name Length, not including null | | | | terminator. | | | | | | | Octets | Array of Octets for File Name, whose | | | | length is File Name Length. | | | | | | | Octet | x00: Null Terminator. | | | | | | Path Name | String | Path For the File Data. | | | | | | | 4 Octets | Path Name Length, not including null | | | | terminator. | | | | | | | Octets | Array of Octets for Path Name, whose | | | | length is Path Name Length. | | | | | | | Octet | x00: Null Terminator. | | | | | | File Data | Octets | Octet array for the File Data, whose | | | | length is File Data Length. | | | | | Zinky, et al. Expires February 24, 2013 [Page 6] Internet-Draft DTN-EC-Objects August 2012 | Padding | Octets | Extra Octets needed to pad the last | | | | Chunk to be the full Chunk Length. The | | | | sender MUST pad with x00. The receiver | | | | MUST ignored padding octets. | +-------------+----------+------------------------------------------+ Table 1: File Data Object Format Zinky, et al. Expires February 24, 2013 [Page 7] Internet-Draft DTN-EC-Objects August 2012 4. Bundle Data Object Format Type = 2 The Bundle Data Object Format is used to divide a large Bundle into many smaller Chunks and to transfer those Chunks as Encoding Bundles using the Forward Error Correcting (FEC) services of the Erasure Coding Extension. The bundle format contains only two sections, the binary format of the bundle and padding. The Bundle is stored into the octet array using its over-the-wire representation. This allows for easy capture and reinsertion into the DTN. The octet array has the following format. +-------------+----------+------------------------------------------+ | Field | Type | Description | +-------------+----------+------------------------------------------+ | Bundle Data | Octets | Octet array that is the over-the-wire | | | | binary format for the large Bundle. The | | | | destination MUST parse the large Bundle | | | | itself to obtain the Data Object Length | | | | of the large Bundle. | | | | | | Padding | Octets | Extra Octets needed to pad the last | | | | Chunk to be the full Chunk Length. The | | | | sender MUST pad with x00. The receiver | | | | MUST ignored these octets. | +-------------+----------+------------------------------------------+ Table 2: Bundle Data Object Format 4.1. Steps for Encoding a Bundle The Source Encoder in the Sending BPA performs the following steps to encode a large Bundle. Step 1: The Sending BPA receives a large-bundle with a source and destination EIDs addressed as: From: dtn://SourceBPA/SourceApp To: dtn://DestBPA/DestApp Step 2: The Source Encoder processes Bundles addressed to EIDs with the "dtn" scheme. The Transfer Specification for the large Bundle is derived from the large Bundle header, see Section 4.3. Note that the destination EID for the large Bundle is registered at the BPA, whose address is "DestBPA". Zinky, et al. Expires February 24, 2013 [Page 8] Internet-Draft DTN-EC-Objects August 2012 Step 3: Encoding Bundles are sent to the Destination Decoder at the "DestBPA" BPA using the Transfer Specification and EID addresses: From: ebr://SourceBPA/ebr To: ebr://DestBPA/ebr Step 4: The Source Encoder MAY delete the original large Bundle before its expiration time once the Encoding Bundles are sent. 4.2. Steps for Decoding a Bundle The following steps are performed by the Destination Decoder to decode a group of Encoding Bundles back into the original large Bundle. Step 1: The Destination Decoder acts as an DTN application and uses the "ebr" extension to the base EID for the destination BPA. Step 2: When Encoding Bundles arrive at the destination Decoder, they are sorted by UUID and stored in the corresponding Encoding Sets. Step 3: When enough Encoding Bundles are in an Encoding Set, the Encoding Set is decoded into a large bundle. Step 4: Destination Decoder injects the large Bundle back into the DTN routing layer, which determines further routing of the large Bundle. Step 5: The Destination Decoder MAY delete the Encoding Set and its Encoding Bundles once the large Bundle is delivered to the routing layer. Step 6: The Destination Decoder MAY send a "Stop" and/or a "Purge" end-to-end acknowledgement messages back to the Source Encoder using the EID, "ebr://SourceBPA/ebr" 4.3. Bundle Transfer Specification The Transfer Specification is derived from the header of the large Bundle. Fields are extracted from the bundle header and are copied into the primary block and extension blocks of the Encoding Bundles. The following fields in the large Bundle are used in the Transfer Specification: Zinky, et al. Expires February 24, 2013 [Page 9] Internet-Draft DTN-EC-Objects August 2012 Source EID is changed to ebr://SourceBPA/ebr. Where SourceBPA is the BPA of the Source Encoder. Destination EID is changed to ebr://DestBPA/ebr. Where DestBPA is the BPA of the Destination Decoder. Creation Timestamp is changed to the time the Encoding Bundle was created, not to the original large Bundle creation time. Life Time is changed to expire at the same time as the original large Bundle. Age Extension Block is processed as-if the original large Bundle is being fragmented. Class of Service bits from the Processing Control Flags is copied to the Encoding Bundles. Singleton Destination bit from the Processing Control Flags is copied to the Encoding Bundles. Request reporting bits from the Processing Control Flags MUST NOT be set in Encoding Bundles. Extension Blocks The Bundle fragmentation rules guide which extension blocks to include in the Encoding Bundles. If the "replicate" bit is set in the Block Processing Control Flags field of the extension block, then the Extension block MUST be put into the Encoding Bundles. If the replicate bit is zero, the Extension Block MUST NOT be put into the Encoding Bundles, but will still be part of the large Bundle sent as the Data Object octet array. Zinky, et al. Expires February 24, 2013 [Page 10] Internet-Draft DTN-EC-Objects August 2012 5. Security Considerations No additional security considerations have been identified beyond those described in [ErasureCoding] Zinky, et al. Expires February 24, 2013 [Page 11] Internet-Draft DTN-EC-Objects August 2012 6. IANA Considerations The Basic Data Object Formats define two types. The assigned IDs should be less than 128 in order to fit into one octet using SDNV values. The reference implementation uses the following Data Object Format Types: File = 1 Bundle = 2 Zinky, et al. Expires February 24, 2013 [Page 12] Internet-Draft DTN-EC-Objects August 2012 7. References 7.1. Normative References [ErasureCoding] Zinky, J., Caro, A., and G. Stein, "Bundle Protocol Erasure Coding Extension", draft-zinky-dtnrg-erasure-coding-extension-00 (work in progress), Aug 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007. [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric Values in Protocols", RFC 6256, May 2011. 7.2. Informative References [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. Zinky, et al. Expires February 24, 2013 [Page 13] Internet-Draft DTN-EC-Objects August 2012 Authors' Addresses John Zinky Raytheon BBN Technologies 10 Moulton St. Cambridge, MA 02138 US Email: jzinky@bbn.com Armando Caro Raytheon BBN Technologies 10 Moulton St. Cambridge, MA 02138 US Email: acaro@bbn.com Gregory Stein Laboratory for Telecommunications Sciences 8080 Greenmead Drive College Park, MD 20740 US Email: gstein@ece.umd.edu Zinky, et al. Expires February 24, 2013 [Page 14]