Internet DRAFT - draft-irtf-dtnrg-zinky-erasure-coding-objects
draft-irtf-dtnrg-zinky-erasure-coding-objects
Network Working Group J. Zinky
Internet-Draft A. Caro
Intended status: Experimental Raytheon BBN Technologies
Expires: February 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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 21, 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-irtf-dtnrg-zinky-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 21, 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 21, 2013 [Page 14]
