One document matched: draft-irtf-dtnrg-zinky-erasure-coding-objects-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1112 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2045 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml'>
<!ENTITY rfc3171 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.xml'>
<!ENTITY rfc3376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY rfc3927 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
<!ENTITY rfc4122 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4122.xml'>
<!ENTITY rfc5050 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml'>
<!ENTITY rfc5052 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5052.xml'>
<!ENTITY rfc5053 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5053.xml'>
<!ENTITY rfc5170 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5170.xml'>
<!ENTITY rfc5445 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5445.xml'>
<!ENTITY rfc6256 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6256.xml'>
]>
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-zinky-erasure-coding-objects-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="DTN-EC-Objects">Bundle Protocol Erasure Coding Basic Objects</title>
<author initials='J. A.' surname="Zinky" fullname='John Zinky'>
<organization>
Raytheon BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>jzinky@bbn.com</email>
</address>
</author>
<author initials='A.' surname="Caro" fullname='Armando Caro'>
<organization>
Raytheon BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>acaro@bbn.com</email>
</address>
</author>
<author initials='G.' surname='Stein' fullname='Gregory Stein'>
<organization>
Laboratory for Telecommunications Sciences
</organization>
<address>
<postal>
<street>8080 Greenmead Drive</street>
<city>College Park</city> <region>MD</region>
<code>20740</code>
<country>US</country>
</postal>
<email>gstein@ece.umd.edu</email>
</address>
</author>
<date/>
<abstract>
<t>
This document defines the Basic Data Objects formats for the
Erasure Coding Extension <xref target="ErasureCoding"/> to the
Delay and Disruption Tolerant Network (DTN) Bundle
Protocol <xref target="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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC2045"/>, zip, or video. This document
ends with discussions on Security and IANA considerations.
</t>
</section>
<section title="Terminology">
<t>
The terminology used in this document follows the
terminology of the Erasure Coding Extension to the Bundle
Protocol <xref target="ErasureCoding"/>. Only terms
specific to the Basic Data Objects are described in
this section.
</t>
<section title="Definitions">
<t>
<list style="hanging">
<t hangText="Data Object Format Type">
is a field in the Erasure Coding Extension Block <xref
target="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.
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
<section title="Abbreviations">
<t>
<list>
<t>
BPA: Bundle Protocol Agent <xref target="RFC5050"/>
</t>
<t >
DTN: Delay/Disruption Tolerant Network <xref target="RFC5050"/>
</t>
<t >
SDNV: Self-Delimiting Numeric Values, see <xref target="RFC6256"/>
</t>
</list>
</t>
</section>
<section title="Requirements Notation">
<t>
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 <xref target="RFC2119"/>.
</t>
</section>
</section>
<section title="File Data Object Format Type = 1">
<t>
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 <xref
target="ErasureCoding"/>.
</t>
<t>
The octet array has the
following format:
</t>
<t>
</t>
<texttable anchor='file_format' title='File Data Object Format'>
<ttcol width="17%" align='left' >
Field
</ttcol>
<ttcol width="12%" align='center' >
Type
</ttcol>
<ttcol align='left' >
Description
</ttcol>
<c> Type </c>
<c> 4 Octets </c>
<c> 0xECECECEC: File Data Object Format Type constant.
A magic number used to check that the decode process was
successful.
</c>
<c> Version </c>
<c> 4 Octets </c>
<c> 0x00000001: Version number of header which increments with
newer versions.</c>
<c>Format:</c>
<c>4 Octets</c>
<c>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.</c>
<c>File UUID</c>
<c>128 bits</c>
<c>Must match Data Object UUID in Erasure Coding Extension
Block.</c>
<c>File Data Length</c>
<c>8 Octets</c>
<c>Length of file in octets.</c>
<c>File Name</c>
<c>String</c>
<c>Name and extension of the File Data.</c>
<c></c>
<c>4 Octets</c>
<c>File Name Length, not including null terminator.</c>
<c></c>
<c>Octets</c>
<c>Array of Octets for File Name, whose length is File Name
Length.</c>
<c></c>
<c>Octet</c>
<c>x00: Null Terminator.</c>
<c>Path Name</c>
<c>String</c>
<c>Path For the File Data.</c>
<c></c>
<c>4 Octets</c>
<c>Path Name Length, not including null terminator.</c>
<c></c>
<c>Octets</c>
<c>Array of Octets for Path Name, whose length is Path Name
Length.</c>
<c></c>
<c>Octet</c>
<c>x00: Null Terminator.</c>
<c>File Data</c>
<c>Octets</c>
<c>Octet array for the File Data, whose length is File Data
Length.</c>
<c>Padding</c>
<c>Octets</c>
<c>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.</c>
</texttable>
<t>
</t>
</section>
<section title="Bundle Data Object Format Type = 2">
<t>
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.
</t>
<texttable anchor='bundle_format' title='Bundle Data Object Format'>
<ttcol width="17%" align='left' >
Field
</ttcol>
<ttcol width="12%" align='center' >
Type
</ttcol>
<ttcol align='left' >
Description
</ttcol>
<c>Bundle Data</c>
<c>Octets</c>
<c>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.</c>
<c>Padding</c>
<c>Octets</c>
<c>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.</c>
</texttable>
<section title="Steps for Encoding a Bundle">
<t>
The Source Encoder in the Sending BPA performs the following steps
to encode a large Bundle.
<list style='format Step %d:'>
<t>
The Sending BPA receives a large-bundle with a source and
destination EIDs addressed as:
<vspace blankLines='1' />
From: dtn://SourceBPA/SourceApp
<vspace blankLines='0' />
To: dtn://DestBPA/DestApp
</t>
<t>
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
<xref target="transfer_spec"/>. Note that the destination
EID for the large Bundle is registered at the BPA, whose
address is "DestBPA".
</t>
<t>
Encoding Bundles are sent to the Destination
Decoder at the "DestBPA" BPA using the Transfer
Specification and EID addresses:
<vspace blankLines='1' />
From: ebr://SourceBPA/ebr
<vspace blankLines='0' />
To: ebr://DestBPA/ebr
</t>
<t>
The Source Encoder MAY delete the original large Bundle
before its expiration time once the Encoding Bundles are
sent.
</t>
</list>
</t>
</section>
<section title="Steps for Decoding a Bundle">
<t>
The following steps are performed by the Destination
Decoder to decode a group of Encoding Bundles back into
the original large Bundle.
<list style='format Step %d:'>
<t>
The Destination Decoder acts as an DTN application and
uses the "ebr" extension to the base EID
for the destination BPA.
</t>
<t>
When Encoding Bundles arrive at the destination Decoder,
they are sorted by UUID and stored in the corresponding
Encoding Sets.
</t>
<t>
When enough Encoding Bundles are in an Encoding Set,
the Encoding Set is decoded into a large bundle.
</t>
<t>
Destination Decoder injects the large Bundle back into
the DTN routing layer, which determines further routing of
the large Bundle.
</t>
<t>
The Destination Decoder MAY delete the Encoding Set
and its Encoding Bundles once the large
Bundle is delivered to the routing layer.
</t>
<t>
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"
</t>
</list>
</t>
</section>
<section anchor="transfer_spec" title="Bundle Transfer Specification">
<t>
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:
<list style="hanging">
<t hangText="Source EID">
is changed to ebr://SourceBPA/ebr. Where SourceBPA
is the BPA of the Source Encoder.
</t>
<t hangText="Destination EID">
is changed to ebr://DestBPA/ebr. Where DestBPA is the BPA of
the Destination Decoder.
</t>
<t hangText="Creation Timestamp">
is changed to the time the Encoding Bundle was created,
not to the original large Bundle creation time.
</t>
<t hangText="Life Time">
is changed to expire at the same time as the original
large Bundle.
</t>
<t hangText="Age Extension Block">
is processed as-if the original large Bundle is being
fragmented.
</t>
<t hangText="Class of Service">
bits from the Processing Control Flags is copied to the
Encoding Bundles.
</t>
<t hangText="Singleton Destination">
bit from the Processing Control Flags is copied to the
Encoding Bundles.
</t>
<t hangText="Request reporting">
bits from the Processing Control Flags MUST NOT be set in
Encoding Bundles.
</t>
<t hangText="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.
</t>
</list>
</t>
</section>
</section>
<section title="Security Considerations">
<t>
No additional security considerations have been identified
beyond those described in <xref target="ErasureCoding"/>
</t>
</section>
<section title="IANA Considerations">
<t>
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:
<list>
<t>
File = 1
</t>
<t>
Bundle = 2
</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc5050;
&rfc6256;
<reference anchor='ErasureCoding'>
<front>
<title>Bundle Protocol Erasure Coding Extension</title>
<author initials='J.' surname='Zinky'
fullname='John Zinky'>
<organization abbrev='BBN'>
Raytheon BBN Technologies
</organization>
</author>
<author initials='A.' surname='Caro'
fullname='Armando Caro'>
<organization abbrev='BBN'>
Raytheon BBN Technologies
</organization>
</author>
<author initials='G.' surname='Stein'
fullname='Gregory Stein'>
<organization abbrev='LTS'>
Laboratory for Telecommunications Sciences
</organization>
</author>
<date month='Aug' year='2012' />
</front>
<seriesInfo name='Internet-Draft' value='draft-irtf-dtnrg-zinky-erasure-coding-extension-00' />
</reference>
</references>
<references title="Informative References">
&rfc2045;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:05:14 |