Internet DRAFT - draft-zinky-dtnrg-erasure-coding-objects

draft-zinky-dtnrg-erasure-coding-objects






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]