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
• 2. Terminology
• 2.1. Definitions
• 2.2. Abbreviations
• 2.3. Requirements Notation
• 3. File Data Object Format Type = 1
• 4. Bundle Data Object Format Type = 2
• 4.1. Steps for Encoding a Bundle
• 4.2. Steps for Decoding a Bundle
• 4.3. Bundle Transfer Specification
• 5. Security Considerations
• 6. IANA Considerations
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

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

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

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:

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.

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:

• File = 1
• Bundle = 2

7. References

7.1. Normative References

7.2. Informative References

Authors' Addresses