Network Working Group J. A. Zinky
Internet-Draft A. Caro
Intended status: Experimental Raytheon BBN Technologies
Expires: February 19, 2013 G. Stein
Laboratory for Telecommunications Sciences
August 20, 2012

Bundle Protocol Erasure Coding Basic Objects
draft-irtf-dtnrg-zinky-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 19, 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

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.

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

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

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:

File Data Object Format
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 Length 8 Octets Length of file in octets.
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.
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.

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.

Bundle Data Object 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.

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

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.

5. Security Considerations

No additional security considerations have been identified beyond those described in [ErasureCoding]

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:

7. References

7.1. Normative References

[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.
[ErasureCoding] Zinky, J., Caro, A. and G. Stein, "Bundle Protocol Erasure Coding Extension", Internet-Draft draft-irtf-dtnrg-zinky-erasure-coding-extension-00, Aug 2012.

7.2. Informative References

[RFC2045] Freed, N. and N.S. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.

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