[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-irtf-dtnrg-zinky-erasure-coding-extension) 00

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 Extension
             draft-zinky-dtnrg-erasure-coding-extension-00

Abstract

   This document describes an extension to the Delay and Disruption
   Tolerant Networking (DTN) Bundle Protocol specification [RFC5050]
   which describes a protocol that enables the transfer of relatively
   large Data Objects over disrupted networks.  The Erasure Coding
   Extension is a mechanism that extends the ability of the existing DTN
   bundle fragmentation mechanism to handle situations where bundles
   have a high probability of being dropped.  An example use case is a
   situation where no communication contact period will ever be long
   enough to send the whole Data Object.  In this case the object must
   be partitioned into smaller chunks and these chunks are sent in
   multiple bundles.  The Erasure Coding Extension provides a recovery
   mechanism that allows many of these bundles to be dropped and still
   allow the whole Data Object to be successfully sent.

   This document describes an Erasure Coding Extension Block and a
   framework for integrating Forward Error Correction (FEC) into the
   bundle protocol.  The Erasure Coding Extension is designed to support
   multiple FEC schemes and content object types.  This is the framework
   document for a series of documents about erasure coding for DTN.
   Companion documents describe specific FEC schemes [RandBinary] and
   specific Data Object types [EcObjects].

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



Zinky, et al.           Expires February 24, 2013               [Page 1]


Internet-Draft                 DTN-EC-Arch                   August 2012


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
































Zinky, et al.           Expires February 24, 2013               [Page 2]


Internet-Draft                 DTN-EC-Arch                   August 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
       2.1.1.  Delay and Disruption Tolerant Network Terms  . . . . .  6
       2.1.2.  Forward Error Correcting Terms . . . . . . . . . . . .  6
       2.1.3.  Erasure Coding Protocol Terms  . . . . . . . . . . . .  7
     2.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  8
     2.3.  Requirements Notation  . . . . . . . . . . . . . . . . . .  8
   3.  Erasure Coding Architecture  . . . . . . . . . . . . . . . . .  9
     3.1.  Erasure Coding Process . . . . . . . . . . . . . . . . . .  9
     3.2.  Erasure Coding Functions . . . . . . . . . . . . . . . . . 11
     3.3.  Erasure Coding Component Configurations  . . . . . . . . . 12
   4.  Data Object Content Layer  . . . . . . . . . . . . . . . . . . 14
     4.1.  Data Object Transfer Specification . . . . . . . . . . . . 15
     4.2.  Creating Chunks  . . . . . . . . . . . . . . . . . . . . . 18
   5.  Coding Layer . . . . . . . . . . . . . . . . . . . . . . . . . 19
     5.1.  Erasure Coding Extension Block . . . . . . . . . . . . . . 19
   6.  Intermediate Regulating Layer  . . . . . . . . . . . . . . . . 23
     6.1.  Traffic Shaping  . . . . . . . . . . . . . . . . . . . . . 23
     6.2.  Handling Specification . . . . . . . . . . . . . . . . . . 24
     6.3.  Feedback Messages  . . . . . . . . . . . . . . . . . . . . 25
     6.4.  Intermediate Recoder . . . . . . . . . . . . . . . . . . . 26
   7.  Bundle Forwarding Layer  . . . . . . . . . . . . . . . . . . . 28
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   9.  Refinement of the Erasure Coding Extension . . . . . . . . . . 30
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 31
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
     11.2. Informative References . . . . . . . . . . . . . . . . . . 32
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34



















Zinky, et al.           Expires February 24, 2013               [Page 3]


Internet-Draft                 DTN-EC-Arch                   August 2012


1.  Introduction

   Delay and Disruption Tolerant Networks (DTNs) [RFC4838] have extreme
   communication constraints.  DTNs can include high link delays, such
   as hours to reach another planet, or no guarantee of a
   contemporaneous end-to-end path between source-destination pairs,
   such as a bus with a DTN Bundle Protocol Agent ferrying data to a
   remote village.  These constraints limit the timeliness of feedback
   that can be sent from the receiver back to the sender to acknowledge
   receipt or to control the data flow.  Forward Error Correction (FEC)
   techniques are a potentially important mechanism for DTN networks,
   especially if a large Data Object must be partitioned into multiple
   bundles [Erasure_Wang].  While the base Bundle Protocol [RFC5050] has
   a fragmentation feature to partition a large bundle into multiple
   smaller bundles, there is no support for FEC, i.e. all bundle
   fragments must be received to reconstruct the original bundle.

   To correct for this lack, this document describes an extension to the
   Bundle Protocol to support FEC mechanisms.  The extension allows for
   large Data Objects to be partitioned into smaller Chunks.  A FEC
   coding scheme is used to encode the Chunks into Encoding Bundles.
   Redundant Encoding Bundles are transmitted to allow recovery of
   Bundles that where dropped.  The specification allows for different
   tradeoffs in the level of protection, overhead, and computation
   needed to encode and decode large Data Objects, based on the kind of
   FEC coding scheme, the network characteristics, and the type of Data
   Object.

   This document describes a FEC framework for the encoding, decoding,
   forwarding, and recoding within a DTN network.  A Bundle Protocol
   Extension Block is defined to send the parameters needed for several
   FEC coding schemes.  The Erasure Coding extension is flexible and
   supports multiple FEC coding schemes and Data Object types.  Separate
   documents define how specific FEC coding schemes [RandBinary] and
   Data Object formats [EcObjects] support this extension.  Future
   documents will describe protocols for erasure coding flow control,
   routing, and recoding.

   This document assumes familiarity with Forward Error Control
   techniques and the FEC framework described in "Forward Error
   Correction (FEC) Building Blocks" [RFC5052], this paper uses the
   Bundle Protocol as a "Content Delivery Protocol" that will use FEC
   schemes to insure reliable delivery of Data Objects.  Many FEC coding
   schemes MAY be supported, such as Random Binary Codes [RandBinary],
   block-oriented parity [RFC5445], Raptor Codes [RFC5053], Reed-Solomon
   [RFC5510], and Low Density Parity Check (LDPC) [RFC5170].  The exact
   coding scheme used depends on the DTN network environment, as no one
   coding scheme works optimally in all situations.  The Erasure Coding



Zinky, et al.           Expires February 24, 2013               [Page 4]


Internet-Draft                 DTN-EC-Arch                   August 2012


   extension could also support Network Coding techniques.


















































Zinky, et al.           Expires February 24, 2013               [Page 5]


Internet-Draft                 DTN-EC-Arch                   August 2012


2.  Terminology

   The following definitions describe terms used in the Bundle Protocol
   Erasure Coding Extension.  The terminology for Delay and Disruption
   Tolerant Networks (DTNs) follows [RFC4838],[RFC5050], and Forward
   Error Coding (FEC) terminology follows [RFC5052].

2.1.  Definitions

   Terms are grouped by a common domain.  Terms within a domain have
   relationships with other terms in that domain and not with other
   domains.

2.1.1.  Delay and Disruption Tolerant Network Terms

    Delay and Disruption Tolerant Networks  (DTNs) use the bundle
      protocol suite [RFC5050] to send data over networks with extreme
      constraints, such as high-delay space channels with propagation
      delays in hours or networks with no contemporaneous end-to-end
      path.

   Bundle  is a DTN protocol data unit (PDU) as defined in [RFC5050].

   Bundle Node  is any entity that can send and/or receive bundles as
      defined in [RFC5050].  In the context of this document, a Bundle
      Node may be either a DTN Application or a Bundle Protocol Agent.

    Bundle Protocol Agent  (BPA) offers DTN services and executes the
      procedures of the bundle protocol.  A BPA performs a store and
      forward function, receives, processes, and sends bundles as
      defined in [RFC5050].  A BPA may have any Erasure Coding process,
      e.g.  Encoder, Decoder, Intermediary Regulator or an Intermediary
      Recoder.

   DTN Application  generates and receives bundles in order to create an
      end-user application.  A DTN application may have only an Erasure
      Coding Encoder or Decoder process.

2.1.2.  Forward Error Correcting Terms

   Data Object  is an ordered sequence of octets that is transferred as
      a single unit as defined in the FEC Framework [RFC5052].  The
      object has a defined format, such as a file, a large bundle, a
      stream, or a mime type.  A Data Object has a UUID, which marks all
      Encodings that belong to the same Data Object.






Zinky, et al.           Expires February 24, 2013               [Page 6]


Internet-Draft                 DTN-EC-Arch                   August 2012


   Chunks  are ordered pieces of a Data Object before it is encoded.
      All Chunks are the same length with the last Chunk being padded
      when necessary.  A Chunk is called a Source Symbol in the FEC
      Framework[RFC5052] .

   Encoding Vector  is the coefficients for the coding formula used to
      create an Encoding.  An Encoding Vector carries the FEC Payload ID
      as defined in the FEC framework [RFC5052].

   Encoding Data  is the result of applying a coding formula to the
      Chunks of a Data Object.  The Encoding Data is the same length as
      the Chunks.  An Encoding Data may carry either a Source Symbol or
      a Repair Symbol as defined in the FEC framework [RFC5052].

   Encoding  contains the corresponding Encoding Vector and Encoding
      Data, with a Transfer Specification.

   Encoding Set  is a group of Encodings that all belong to the same
      Data Object (same UUID).  The Encodings in an Encoding Set
      represent a set of linear equations.  When the rank of the
      Encoding Set is equal to the number of Chunks in the Data Object,
      the Encoding Set linear equations can be solved to decode ALL of
      the Chunks for the Object.

   Innovative Encoding:  When an Encoding is added to an Encoding Set,
      the Encoding is said to be "Innovative" relative to the Encoding
      Set, if the new Encoding adds new information to the Encoding Set
      (i.e., increases the Encoding Set's rank).

   Redundant Encoding:  When an Encoding is added to an Encoding Set,
      the Encoding is said to be "Redundant" relative to the Encoding
      Set if the new Encoding does not add new information to the
      Encoding Set (i.e., the Encoding Set's rank stays the same).

   Duplicate Encoding:  Two Encodings are equivalent or duplicate, if
      they belong to the same Data Object (same UUID) and have the same
      Encoding Vector and hence the same Encoding Data.

2.1.3.  Erasure Coding Protocol Terms

   Encoding Bundle  contains the information necessary to send an
      Encoding using the Bundle Protocol.  Some information is put in
      the bundle primary block, such as the Data Object's Transfer
      Specification.  Some information is put in the Erasure Coding
      Extension Block, such as the Encoding Vector.  Some information is
      put in the Bundle payload, such as the Encoding Data.





Zinky, et al.           Expires February 24, 2013               [Page 7]


Internet-Draft                 DTN-EC-Arch                   August 2012


   Erasure Coding Extension Block  exposes Encoding information that is
      needed by Intermediate Regulators.  Specifically, it includes the
      Encoding Vector and Handling Specification.

   Erasure Payload  stores the part of an Encoding that is not exposed
      to Intermediate Regulators.  Specifically, it includes the
      Encoding Data.

   Handling Specification  defines the importance of forwarding Encoding
      Bundles relative to its Encoding Set or other Encoding Sets.  The
      Handling Specification MAY change the order, priority, or rate for
      sending Encoding Bundles.

2.2.  Abbreviations

      BPA: Bundle Protocol Agent, see [RFC5050]

      DTN: Delay and Disruption Tolerant Network, see [RFC5050]

      EID: End-point Identifier, see [RFC5050]

      FEC: Forward Error Correction, see [RFC5052]

      UUID: Universally Unique Identifier, see [RFC4122]

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


Internet-Draft                 DTN-EC-Arch                   August 2012


3.  Erasure Coding Architecture

   The goal of the Erasure Coding extension is to enable the transfer of
   large Data Objects over disrupted links.  The Erasure Coding
   Architecture defines protocol layers, protocol functions, and
   components that achieve this goal in a modular and extensible manner.
   Besides defining terms and relationships, when realized the
   architecture forms a distributed system that executes at multiple
   locations, cross cuts multiple protocol layers, and reuses services
   from external components in a DTN network.

   Erasure Coding happens at multiple locations across a DTN.  At the
   end points, Data Objects are divided into Chunks, which are Encoded
   at the sender and Decoded at the receiver.  Along the way between the
   sender and the receiver Intermediate Regulator, Intermediate Recoders
   and Bundle Forwarders may process the Encoding Bundles to ensure the
   end-to-end delivery of a Data Object, despite the poor communication
   channel between the sender and receiver.

   This section describes the end-to-end Erasure Coding process,
   including the functions that need to be performed and the layers at
   which they are performed.  This section also describes several
   configuration use cases and how the components carry out their roles.
   Subsequent sections describe each of the protocol layers: Data Object
   Content Layer, the Coding Layer, the Intermediate Regulating Layer,
   and the Bundle Forwarding Layer.

3.1.  Erasure Coding Process

   A Data Object goes through a series of transformations as it is
   transmitted using the Erasure Coding protocol: from a Data Object to
   Encodings to Bundles and back again from Bundles, to Encodings, to a
   copy of the Data Object at the receiver.  The transmission process
   has the following steps:

   Step 1:  A Data Object has content that needs to be transferred
            across a DTN as a single whole.  If any part of the content
            is missing the Data Object is not considered transferred.

   Step 2:  The Data Object's list of Octets is divided into Chunks of
            equal length.  The last Chunk MUST be padded so that it is
            the same length as the other Chunks.  The order of the
            Chunks MUST be preserved to retain the ordering of the Data
            Object octets.  The ordered list of Chunks that represent
            the Data Object is given an unique identifier (UUID).






Zinky, et al.           Expires February 24, 2013               [Page 9]


Internet-Draft                 DTN-EC-Arch                   August 2012


   Step 3:  Chunks are coded into an Encoding.  Some Combination of
            Chucks are combined using one of serval possible FEC
            schemes.  The coefficients of the coding formula are stored
            in an Encoding Vector.  The results of the combination are
            stored in an Encoding Data, which is an ordered list of
            octets that is the same length as a Chunk.  Together the
            Encoding Data, Encoding Vector, the coding scheme, and the
            Data Object UUID form an Encoding.  All Bundle FEC coding
            schemes MUST create Encodings with this structure.

   Step 4:  All the Encodings generated for a Data Object share the same
            UUID and may be grouped into an Encoding Set. A Full
            Encoding Set has enough Encodings to extract the Data
            Object.  Note that an Encoding Set may have Redundant
            Encodings so that not all the Encodings in the set need to
            be received.  The level of redundancy is determined by the
            FEC scheme, the application Quality of Service requirements,
            and the expected transmission characteristic across the DTN.

   Step 5:  Each Encoding is placed in an Encoding Bundle.  The Encoding
            Vector, UUID, and FEC Scheme are formatted into the Erasure
            Coding Extension Block defined in this document.  The
            Encoding Data is formatted into the Bundle Payload.

   Step 6:  Transfer specification is added to the Encoding Bundle to
            help resolve trade offs in the transfer of this Encoding
            Bundle relative to other bundles.  The transfer
            specification cross cuts multiple layers by adding
            parameters to the bundle header, extension blocks, and Data
            Object's internal metadata.

   Step 7:  When Encoding Bundles arrive at a destination, they are
            added to a Encoding Set based on their UUID.  Duplicate
            Encodings have the same Encoding Vector as an Encoding
            already in the set and should be dropped.  Redundant
            Encodings do not add any new information to the Encoding Set
            and may be dropped by the Decoder, but may be used by
            Recoders.

   Step 8:  The Data Object is reconstructed at a destination as an
            array of octets from the decoded Chunks.  When an Encoding
            Set has enough Encodings to decode some of the Chunks.  The
            Chunks are extracted and sent to the application.  Some FEC
            schemes may decode some Chunks as Encodings arrive, but
            other FEC schemes may not be able to decode any Chunks until
            nearly all Encodings have arrived.  For some FEC schemes,
            the decode operation may consume substantial cpu and memory
            resources.



Zinky, et al.           Expires February 24, 2013              [Page 10]


Internet-Draft                 DTN-EC-Arch                   August 2012


3.2.  Erasure Coding Functions

   The Erasure Coding process performs several functions that happen at
   different protocol layers and may happen at different locations
   within the DTN network.

    Encoder  converts a Data Object into Encodings Bundles and sends the
      bundles into the DTN.  The Encoder is responsible for converting
      the Data Object into Chunks, coding the Chunks into Encodings,
      packing the Encoding into a Bundle, and setting the Bundle header
      parameters, to meet the transfer specification requirement.  The
      Encoder MUST send enough Encodings to allow a Decoder to
      reconstruct the Data Object.

   Decoder  receives Encodings Bundles, extracts Encodings, and stores
      the Encodings into an Encoding Set. The Decoder solves the coding
      equations to reconstruct Chunks for the Data Object.  When enough
      Encodings arrive to solve the Encoding Set, the resulting Chunks
      are given to the consumer of the Data Object.  Note, some FEC
      schemes may allow solving for some Chunks before solving for all
      Chunks.  In this case, the Chunks MAY be delivered as they are
      solved or as a complete Data Object.

   Intermediate Regulator  is a process on the path between the Encoder
      and Decoder.  It may change the order of Encoding Bundles to give
      one Data Object priority over other Data Objects.  It may
      manipulate how Encoding Bundles are sent between BPAs, based on
      fields in the Encoding Extension Block, such as UUID, handling
      spec, and Encoding Vector.  Also, it may round-robin through
      Encoding Bundles in a Encoding Set to increase the diversity of
      Encodings being forwarded during different contacts.  Some
      forwarding rules may depend on not sending Redundant Encodings to
      neighbors that have been met on previous contacts.

   Intermediate Recoder  is a source of Redundant Encodings that may be
      manipulated and forwarded by the Intermediate Regulator.  The
      Intermediate Recoder creates new Encodings from an Encoding Set
      held within the Intermediate Node.  The new Encodings are
      redundant, but not duplicate to the other Encodings in the
      Encoding Set. The Intermediate Regulator MAY send these Redundant
      Encodings across different paths to the destination.  Note that
      the Intermediate Recoder does not have to solve the Encoding Set.
      A generated Encoding is created by just combining multiple
      Encodings from the Encoding Set.







Zinky, et al.           Expires February 24, 2013              [Page 11]


Internet-Draft                 DTN-EC-Arch                   August 2012


   Bundle Forwarder  is a legacy DTN BPA that does not understand the
      Erasure Coding Extension.  It routes and forwards Bundles based on
      fields in the standard Bundle primary block header.

   These functions are grouped into four layers.  The Data Object
   Content layer is the external consumer of the DTN services and is
   concerned with transferring a Data Object from the source to the
   destination(s).  The Coding Layer encodes and decodes the Data Object
   into Encodings Bundles.  The Intermediate Regulating Layer regulates
   the Encoding Bundle flows across the DTN.  The Bundle Forwarding
   Layer routes and forwards the Bundles along the path from the source
   to the destination(s).

3.3.  Erasure Coding Component Configurations

   Erasure Coding architectural components are locations that execute
   the Erasure Coding functions.  The architectural components are
   contained inside either DTN Applications or DTN Bundle Protocol
   Agents (BPAs).  The end-to-end Encoders and Decoders may be located
   in either DTN Applications or DTN BPAs.  Intermediate Regulators and
   Intermediate Recoders may only be located in DTN BPAs.  The links
   between components are either through internal interfaces or across a
   DTN.

   Different configurations of the Erasure Coding Components allow for
   the creation of distributed systems that meet different end-user
   application requirements, within the constraints of the DTN.  These
   configurations help integrate legacy DTN applications and BPAs with
   Erasure Coding Components, selectively adding or removing
   functionality depending on availability.

   Erasure Coding-aware DTN Applications  preform the Encoding and
      Decoding functions with in the application itself.  The
      application has knowledge of the end-to-end transfer specification
      and sets the fields in the Bundle primary block and Handling
      Specification to best meet the requirements.  Also, if the FEC
      scheme allows for decoding some Chunks before all Chunks are
      ready, these early Chunks may be consumed by the application.

   Legacy DTN Applications  that send large bundles, the Encoding
      functions may be located in the BPA.  In this case, a large Bundle
      is encapsulated as a Data Object and sent to the destination BPA
      where the large Bundle is decoded and reinserted into the DTN
      routing layer.







Zinky, et al.           Expires February 24, 2013              [Page 12]


Internet-Draft                 DTN-EC-Arch                   August 2012


   Erasure Coding-aware BPAs  The use of Intermediate Regulators and
      Intermediate Recoders enables traffic shaping based on the UUID,
      detection of Redundant Encodings, and changing the order of Bundle
      transmission.  The use of intermediate Recoders allows sending
      more diverse Encodings, substantially reducing the number of
      Encoding Bundles that need to be received before the Encoding Set
      can be solved for a Data Object.

   Legacy BPAs  are not aware of the Erasure Coding Extension, but they
      may still forward bundles.  No Erasure Coding specific processing
      may be done along the path to improve the importance and urgency
      of the transfer.  Only the existing Bundle-layer Quality of
      Service mechanisms may be used, such as lifetime, priority, and
      duplicate detection.

   All combinations are possible including running Erasure Coding-aware
   Applications over Erasure Coding Aware BPAs with Encoders and
   Decoders.  In this case, the BPA MUST check for the Erasure Encoding
   Extension Block on all Bundles inserted by the application.  The BPA
   MUST NOT attempt to encode an Bundle that has already been encoded by
   the application.






























Zinky, et al.           Expires February 24, 2013              [Page 13]


Internet-Draft                 DTN-EC-Arch                   August 2012


4.  Data Object Content Layer

   The goal of the Data Object Content Layer is to transfer a Data
   Object from a source to a destination within some application
   specific Quality of Service requirements.  It uses the DTN Bundle
   protocol with Erasure Coding Extension to accomplish the transfer.

   The Data Object Content Layer is concerned with Data Objects and a
   Transfer Specification for that Data Object.  The Erasure Coding
   Extension expects to transfer an ordered array of octets across a
   DTN.  The job of the Data Object layer is to map the Data Object and
   its Transfer Specification into the mechanisms available from the
   Erasure Coding Extension.  This mapping is complex and very
   application and Data Object type specific, but mappings share some
   common features described in this section.

   The Data Object type defines the internal representation of a Data
   Object's content and meta data as an ordered array of bytes.  Many
   Data Object types are supported.  A companion document [EcObjects]
   defines the Data Object types for files and large bundles.

   The Data Object layer has to interact with all three other layers.

   For the Bundle Forwarding Layer, the Data Object layer MUST set
   Bundle service delivery parameters, such as lifetime and priority, so
   that all Encoding Bundles for a Data Object have the same value.  We
   do not recommend requesting delivery notifications, especially
   custody notification as these administrative services generate
   feedback traffic at the Bundle Layer and not at the Coding Layer.
   The destination is specified in the form of an DTN EID.  The transfer
   specification may require multiple destinations, which may be
   satisfied by some configurations of the DTN BPAs routing protocols.
   For example epidemic routing attempts to flood Bundles to all nodes
   in the DTN or alternatively Geo-role routing forwards Bundles to all
   nodes playing a role within a geographic region.  The Bundle
   Destination EID is used to specify the routing protocol and its
   parameters.  Features from other DTN extensions may be used by the
   Data Object Layer.  For example, the Bundle Security Protocol MAY be
   used to protect the authenticity of the Bundle extension blocks and
   payload.

   For the Coding Layer, the Data Object and its meta data MUST be
   converted into an ordered array of octets.  The Transfer
   Specification MAY have meta data that needs to be sent end-to-end
   with the Data Object.  The representation of the meta data depends on
   the Data Object type.  Likewise, some Data Object types may want
   control over how Chunks are made and whether Chunks are delivered
   early.  For example, a video Data Object may want to align Chunks on



Zinky, et al.           Expires February 24, 2013              [Page 14]


Internet-Draft                 DTN-EC-Arch                   August 2012


   video frame boundaries and may want to have the key frames delivered
   early.  These Data Object format issues are addressed by companion
   documents for each Data Object Type, such as [EcObjects]

   For the Intermediate Regulating Layer, the Data Object Layer SHOULD
   set parameter values to the Handling Specification.  Intermediate
   Regulators MAY use the parameters to tradeoff resource consumption
   and delivered service among competing Data Objects.

4.1.  Data Object Transfer Specification

   The transfer specification is an abstract representation for _how_ a
   Data Object should be transferred from the source to the destination.
   It gives hints to the Erasure Coding architectural components on how
   to create, combine, transfer, and decode Encoding Bundles.  The
   transfer specification takes end-to-end quality of service
   requirements and translates them into the Bundle Protocol mechanisms
   necessary to meet those requirements.  A transfer specification MAY
   be manifested physically in an Erasure Coding implementation, but its
   main role is to illustrate the control points available at each
   protocol layer and how they interact.

   The transfer specification is not monolithic.  It cross cuts
   different protocol layers and its content is spread among different
   fields in the bundle header, extension block, and the bundle payload.
   At the bundle layer, it specifies how Encoding Bundles are handled
   relative to other DTN traffic.  At the Regulating layer, it specifies
   how Encoding Bundles are handled relative to other Encodings Bundles
   for the same Data Object UUID or relative to other Data Object UUIDs.
   Finally at the Data Object layer, it specifies the properties of a
   copy of the Data Object at the destination.

   In the current state of the Bundle Protocol, the BPA has no means for
   advertising its constraints to the Erasure Coding components and the
   components can not make active measurements of these constraints
   because the poor quality of the communication channel makes any
   measurements obsolete before enough samples can be collected.  The
   process of choosing transfer parameters, such as Chunk Size, is thus
   an open loop process and depends on external oracles to predict the
   transfer constraints.  As the Bundle Protocol evolves and adds
   capabilities for detecting and advertising its environmental
   constraints, the transfer specification will become more powerful and
   more formal.  For example, the Bundle Security Protocol [RFC6257]
   should be used to meet the Erasure Coding requirement to authenticate
   the creator of Encoding Bundles.  The functionality should be reused
   by the Erasure Coding extension and their is no need to redefine it
   here.




Zinky, et al.           Expires February 24, 2013              [Page 15]


Internet-Draft                 DTN-EC-Arch                   August 2012


   The following table lists some transfer specification parameters that
   are actionable in the context of the current Bundle Protocol
   [RFC5050] and the Erasure Coding extension.

   +----------------+-------+-----------+-------------+----------------+
   | Parameter      |  Type |   Header  |    Field    | Description    |
   +----------------+-------+-----------+-------------+----------------+
   | Destination    |  EID  |   Bundle  | Destination | DTN endpoint   |
   |                |       |           |             | destination(s) |
   |                |       |           |             | for Data       |
   |                |       |           |             | Object. The    |
   |                |       |           |             | endpoint may   |
   |                |       |           |             | be a singleton |
   |                |       |           |             | or have        |
   |                |       |           |             | multiple       |
   |                |       |           |             | destinations.  |
   |                |       |           |             |                |
   | Class of       | Flags |   Bundle  |   Priority  | Priority       |
   | Service        |       |           |             | relative to    |
   |                |       |           |             | other Data     |
   |                |       |           |             | Objects        |
   |                |       |           |             |                |
   | Life Time      |  SDNV |   Bundle  |  Life Time  | Time when the  |
   |                |       |           |             | Data Object    |
   |                |       |           |             | should be      |
   |                |       |           |             | deleted, if    |
   |                |       |           |             | not delivered  |
   |                |       |           |             |                |
   | Report         | Flags |   Bundle  |  Processing | Quality of     |
   | Progress       |       |           |   Control   | Service        |
   |                |       |           |             | feedback for   |
   |                |       |           |             | Data Object    |
   |                |       |           |             |                |
   | UUID           |   Id  | Extension |  Unique Id  | A Universally  |
   |                |       |           |             | Unique         |
   |                |       |           |             | Identifier     |
   |                |       |           |             | that is        |
   |                |       |           |             | associated     |
   |                |       |           |             | with the Data  |
   |                |       |           |             | Object         |
   |                |       |           |             | transfer.      |
   |                |       |           |             |                |









Zinky, et al.           Expires February 24, 2013              [Page 16]


Internet-Draft                 DTN-EC-Arch                   August 2012


   | Number of      |  SDNV | Extension |  Number of  | The number of  |
   | Chunks         |       |           |    Chunks   | Chunks that    |
   |                |       |           |             | the Data       |
   |                |       |           |             | Object was     |
   |                |       |           |             | divided into.  |
   |                |       |           |             | Fewer Chunks   |
   |                |       |           |             | reduce the     |
   |                |       |           |             | reassembly     |
   |                |       |           |             | time at        |
   |                |       |           |             | destination.   |
   |                |       |           |             |                |
   | Chunk Length   |  SDNV |  Payload  |    Length   | The size of    |
   |                |       |           |             | the Chunks     |
   |                |       |           |             | that the Data  |
   |                |       |           |             | Object was     |
   |                |       |           |             | divided into.  |
   |                |       |           |             | Smaller Chunks |
   |                |       |           |             | reduce chance  |
   |                |       |           |             | of             |
   |                |       |           |             | bundle-layer   |
   |                |       |           |             | fragmentation. |
   |                |       |           |             |                |
   | Handling Spec  | Flags | Extension |   Handling  | Handling hints |
   |                |       |           |     Spec    | for            |
   |                |       |           |             | Intermediate   |
   |                |       |           |             | Regulators for |
   |                |       |           |             | this bundle    |
   |                |       |           |             | relative to    |
   |                |       |           |             | other Encoding |
   |                |       |           |             | Bundles with   |
   |                |       |           |             | same Data      |
   |                |       |           |             | Object UUID    |
   |                |       |           |             |                |
   | Authentication |   ID  |   Bundle  |   Signing   | The level of   |
   |                |       |  Security |             | trust in the   |
   |                |       | Extension |             | Encoding       |
   |                |       |           |             | components.    |
   |                |       |           |             |                |
   | Data Object    | Flags |  Payload  | Data Object | Meta Data      |
   | Metadata       |       |           |  Header in  | about Data     |
   |                |       |           | first Chunk | Object's       |
   |                |       |           |             | systemic       |
   |                |       |           |             | properties,    |
   |                |       |           |             | such as        |
   |                |       |           |             | authenticity,  |
   |                |       |           |             | validity, and  |
   |                |       |           |             | permissions    |
   +----------------+-------+-----------+-------------+----------------+



Zinky, et al.           Expires February 24, 2013              [Page 17]


Internet-Draft                 DTN-EC-Arch                   August 2012


                      Table 1: Transfer Specification

4.2.  Creating Chunks

   The Data Object Layer formats the Data Object and meta data as an
   octet array that is used as input to the Coding Layer.  The Data
   Object octet array is divided into an ordered array of equal length
   Chunks.  Chunks are identified with an index.  The Chunk with the
   index of '0' contains the octet with index '0'.

   The Data Object Layer must add padding octets to the last Chunk, so
   that all Chunks are the same length.  The Data Object Layer is
   responsable for storing the exact length of the Data Object without
   padding, because the Coding Layer does not have a field for the Data
   Object Length.

   The exact number_of_chunks is determined at transfer time and is
   based on the Data Object Layer Transfer Specification and path
   characteristics of the DTN network.  Decoders SHALL handle any
   number_of_chunks, but practical limits MAY be in the 1000's of
   Chunks.  The chunk_length SHOULD be a multiple of 8.  This will allow
   efficient octet array operations to be performed when encoding and
   decoding Chunks and Encoding Data.




























Zinky, et al.           Expires February 24, 2013              [Page 18]


Internet-Draft                 DTN-EC-Arch                   August 2012


5.  Coding Layer

   The goal of the Coding Layer is to divide a Data Object that is
   formated as an ordered array of octets into a group of Encodings.
   The Encodings MUST form a full Encoding Set and MAY have Redundant
   Encodings.  The Erasure Coding Process (Section 3.1) is followed to
   encode Data Objects into Encodings and to decode an Encoding Set back
   into a Data Object.  In this process, a FEC scheme is applied to the
   Chunks of a Data Object to form an Encoding.  The FEC scheme uses a
   coding formula to convert the Chunks to an Encoding Data.  The
   coefficients for the coding formula are stored in the Encoding
   Vector.  The Encoding Vector and Encoding Data together form the
   Encoding.  The exact format of the Encoding Vector and Encoding Data
   is defined by the FEC scheme.  The Erasure Coding Extension supports
   multiple FEC schemes, such as the Random Binary FEC scheme defined in
   the companion document [RandBinary].

   An Encoding is packed into an Encoding Bundle.  In order for
   Intermediate Regulators to detect Redundant Encodings and group
   Encoding Bundles into Encodings Sets, some Encoding parameters are
   exposed in the Erasure Coding Extension Block (Section 5.1), such as
   the Encoding Vector and Data Object UUID.  The Encoding Data is not
   needed by Intermediate Regulators and is put into the Bundle Payload.
   Intermediate Recoders need access to the content of both the Erasure
   Coding Extension Block and the Bundle Payload in order to generate
   new Encodings.

5.1.  Erasure Coding Extension Block

   The Erasure Coding Extension Block marks the Bundle containing an
   Encoding.  The format of the Erasure Coding Extension Block is as
   follows:



















Zinky, et al.           Expires February 24, 2013              [Page 19]


Internet-Draft                 DTN-EC-Arch                   August 2012


   +---------------+------------+--------------------------------------+
   | Field         |    Type    | Description                          |
   +---------------+------------+--------------------------------------+
   | Block Type    | Octet=0xEC | Bundle Protocol Extension Block Type |
   |               |            | is the constant 0xEC.                |
   |               |            |                                      |
   | Block         |    SDNV    | See Section 4.3 of [RFC5050] for bit |
   | Processing    |            | settings                             |
   | Flags         |            |                                      |
   |               |            |                                      |
   | Block Length  |    SDNV    | Length of extension block data, not  |
   |               |            | including the padding.               |
   |               |            |                                      |
   | Version       |    SDNV    | Erasure Coding Extension Block       |
   |               |            | version that increments with newer   |
   |               |            | versions                             |
   |               |            |                                      |
   | Data Object   |    SDNV    | Type number for the format of Data   |
   | Format Type   |            | Object. Defines format for decoded   |
   |               |            | Chunks, see [EcObjects].             |
   |               |            |                                      |
   | Data Object   |    UUID    | Universally Unique ID for a specific |
   | UUID          |  (128bits) | Data Object transfer. The UUID       |
   |               |            | SHOULD be in the format specified in |
   |               |            | [RFC4122]. The Data Object Format    |
   |               |            | specification MAY define a hash      |
   |               |            | function to map the Data Object's    |
   |               |            | name to a UUID. [NOTE: The reference |
   |               |            | implementation uses two SVDN fields  |
   |               |            | to pack the upper and lower 64       |
   |               |            | bits.]                               |
   |               |            |                                      |
   | Handling      |    SDNV    | Number of SDNV Parameters in the     |
   | Specification |            | Handling Specification. As the       |
   | Length        |            | Erasure Protocol matures, parameters |
   |               |            | will be added to the Handling        |
   |               |            | Specification. Version 1 of the      |
   |               |            | Erasure Coding Extension does not    |
   |               |            | define any Handling Specification    |
   |               |            | parameters, so this field value is   |
   |               |            | 0. Version 1 implementations MUST    |
   |               |            | treat this field as a length of the  |
   |               |            | next field, even though the content  |
   |               |            | SHOULD be ignored.                   |
   |               |            |                                      |






Zinky, et al.           Expires February 24, 2013              [Page 20]


Internet-Draft                 DTN-EC-Arch                   August 2012


   | Handling      |  SDNV List | Hints on how Intermediate Regulators |
   | Specification |            | should order, prioritize, limit      |
   | Parameters    |            | rate, or drop this Encoding relative |
   |               |            | to other Encoding bundles with the   |
   |               |            | same Data Object UUID. No Handling   |
   |               |            | Specification Parameters are defined |
   |               |            | for Version 1, so this field is      |
   |               |            | null.                                |
   |               |            |                                      |
   | Number of     |    SDNV    | Number of Chunks that the Data       |
   | Chunks        |            | Object was divided into.             |
   |               |            |                                      |
   | FEC Scheme    |    SDNV    | The type number of the FEC Scheme    |
   | Type          |            | used to interpret Coding Scheme      |
   |               |            | Parameters, for example see          |
   |               |            | [RandBinary].                        |
   |               |            |                                      |
   | FEC Scheme    |   Octets   | Format of the octet array is         |
   | Parameters    |            | determined by FEC Scheme. This field |
   |               |            | ends at the Block Length of the      |
   |               |            | extension block data.                |
   |               |            |                                      |
   | Padding       |   Octets   | Extra octets so that the total       |
   |               |            | length the whole extension block is  |
   |               |            | a multiple of 4 octets.              |
   +---------------+------------+--------------------------------------+

                  Table 2: Erasure Coding Extension Block

   The Data Object UUID field identifies the Data Object for the
   Encoding Bundle.  The UUID MUST be unique in the DTN network over the
   life time of the bundle.  While the UUID is treated just as a number,
   the UUID SHOULD be in the format specified in [RFC4122].  All the
   received Encoding Bundles with the same UUID form an Encoding Set for
   a Data Object.

   The Data Object Format Type specifies the format used at the Data
   Object Layer.  A Data Object format MUST define the headers and
   padding for the decoded Data Object.  A Data Object format MAY define
   a format for the bundle payload, but by default the bundle payload
   contains just the Encoding Data.  Several Data Object formats are
   defined in [EcObjects] and future documents.

   The Handling Specification gives hints on how Intermediate Coders
   SHOULD process this bundle relative to other bundles in the same
   Encoding Set. For example, how many Redundant Encoding Bundles should
   be forwarded or what order to send Encoding Bundles across multiple
   contact points.  The values of Handling Specification depend on both



Zinky, et al.           Expires February 24, 2013              [Page 21]


Internet-Draft                 DTN-EC-Arch                   August 2012


   the type of FEC scheme and the characteristics of the expected DTN
   communication path.  The parameters (flags) of the Handling
   Specification MUST be actionable by Intermediate Regulators.  For
   Version #1 of the Erasure Coding Extension Block, this handling
   parameters are undefined and Handling Specification Length MUST be
   zero (0).

   The Encoding Vector is part of the extension block because
   Intermediate Regulators MAY want to determine the rank of an Encoding
   Set to detect Redundant Encodings.  Calculating the rank is a less
   computationally expensive operation than decoding the Encoding Set
   for its Chunks.  Calculating the rank only needs the Encoding Vector
   sand not the Encoding Data.  Decoding needs to XOR multiple Encoding
   Datas together to decode each Chunk, a computationally expensive
   operation.  The format of the Encoding Vector depends on the type of
   FEC scheme used.  The common field among all FEC schemes is the
   Number of Chunks in the Data Object.  The other two fields specify
   the type of FEC scheme and the bytes for the Encoding Vector itself.
   Several FEC schemes are defined in [RandBinary] and future documents.

   More than one Erasure Coding Extension Block MAY be present in the
   same bundle.  The interpretation of multiple extension blocks is to
   treat them as a composite formula that are merging Chunks from
   multiple Data Objects.  The merged Encoding Vector adds the
   coefficients from the component Encoding Vectors.  The merged
   Encoding Data (bundle payload) is the XOR of the composite Encoding
   Data.  Intermediate Regulators MAY use the handling specification
   from either extension block to determine the handling procedures.
   The Handling Specification SHOULD be equivalent for all Erasure
   Coding Extension blocks in the bundle.  The multiple extension block
   option supports experimentation in Network Coding.




















Zinky, et al.           Expires February 24, 2013              [Page 22]


Internet-Draft                 DTN-EC-Arch                   August 2012


6.  Intermediate Regulating Layer

   The goal of the Intermediate Regulating layer is to control the flow
   of Encoding Bundles as they move from the source to the destination.
   Intermediate Regulators decide on which Encoding Bundles should be
   sent next during a contact period with a neighbor BPA.  Given the
   dynamic and complex nature of DTN topologies and the tradeoffs
   between competing DTN traffic flows, the traditional first come first
   serve queueing discipline is rarely adequate.  Also, in the most
   general case the traffic shaping function in the Intermediate
   Regulators needs to work without feedback from neighbors or the end-
   to-end destinations.

   *Note:* No reference implementation of the Intermediate Regulator
   have been completed at the time of this document publication.  More
   research is necessary to determine the functionality of the Handling
   Specification and the policies used by Intermediate Regulators.  This
   section is a place holder and lays out the issues.  A future version
   of this section will capture the conclusions of the future research
   results.

6.1.  Traffic Shaping

   Traffic Shaping MAY improve the efficiency of resource consumption
   and the fairness between DTN traffic flows in the case where feedback
   is impractical between neighbors or between the destination and the
   source.  Traffic shaping may determine when to stop forwarding
   Encoding Bundles from a Data Object, limit the rate, redundancy, or
   the order between bundles.  The traffic shaping parameters may be
   calculated per Data Object UUID, per neighbor, or per contact.

   A basic no feedback traffic shaper MAY be based on the following
   policy and parameters.  During a contact the candidate Data Objects
   are ordered by importance (priority field in Bundle Primary Block)
   and urgency (lifetime in Bundle Primary Block).  The highest priority
   with the earliest expiration is sent first.  Sending a Data Object is
   divided into two phases; an Innovative Send Phase and a Redundant
   Send Phase.  The Innovative Send phase sends only enough Encodings to
   form a full Encoding Set at the Receiver, while the Redundant Send
   Phase sends extra Redundant Encodings for FEC purposes.

   Each phase has a limit on the number of Encodings in that phase and a
   limit on the rate for which Encodings are sent during that phase.
   Encoding Bundles are sent in Data Object order, sending all the
   Innovative Encoding Bundles for _all_ the Data Objects and then
   starting the redundant phase.  While sending a Data Object during a
   phase, the next Data Object will start when the Max Number of
   Encodings for that phase is exceeded or the rate is exceeded.  When



Zinky, et al.           Expires February 24, 2013              [Page 23]


Internet-Draft                 DTN-EC-Arch                   August 2012


   all the Redundant Encoding Bundles have been sent for all Data
   Objects, transmission stops.

   The following are basic traffic shaping parameters that MAY be put
   into the Handling Specification.  Version 1 of the Handling
   Specification does not allow these parameters to be specified
   dynamically, but defines a default Handling Specification based on
   these parameters.

   Encoding Order  defines the order to send Encodings for the same Data
      Object.  The order may be changed based on the requirements of the
      transmission specification.  The order MAY be Oldest First, Oldest
      Last, Round-Robin, or Random.

   Send State  defines the level of detail for sending a Data Object
      across contacts.  For example, the encoding order MAY be be
      maintained for each time a Data Object is sent to a unique
      neighbor, or for each contact regardless of the neighbor, or no
      send state is maintained at all (Random).

   Max Number of Innovative Encodings  defines the number of Encodings
      in the Innovative Phase.  For example, this limit MAY be greater
      than the Number of Chunks, if some Redundant Encodings should be
      included in the Innovative Send Phase.  Conversely, the limit MAY
      be lower, if the contact periods are very short and Data Objects
      are expected to be sent over multiple contacts.

   Max Number of Redundant Encodings  defines the number of Encoding
      Bundles in the Redundant Phase.

   Rate Limit for Innovative Encoding  defines a limit on how quickly
      Encodings are sent rate limit during the Innovative phase.  The
      rate MAY be specified using leaky bucket parameters, such as input
      period and initial fullness.  Alternatively, a processor sharing
      model parameter MAY limit the maximum number Encodings to send
      before moving to the next Data Object with the same priority.

   Rate Limit for Redundant Encodings  defines a rate limit during the
      Redundant phase.

6.2.  Handling Specification

   The Handling Specification is a field in the Erasure Coding Extension
   Block that defines the parameters for traffic shaping and feedback
   messages.  The format of this field is that of a length followed by a
   list of parameters with 'length' entries.  The length and parameters
   are SDNV values, making the entire Handling Specification field have
   variable length.  As Version #1 of the Erasure Coding Extension does



Zinky, et al.           Expires February 24, 2013              [Page 24]


Internet-Draft                 DTN-EC-Arch                   August 2012


   not define any Handling Specification Parameters, the length MUST
   currently be zero (0) for Version #1 and the parameter list null.  As
   the Erasure Coding Extension matures, parameters will be added to the
   Handling Specification.  The Handling Specification Length has the
   dual role of determining the number of parameters and as version
   indicator for the meaning of each parameter.

   When the Handling Specification Length is zero (0), then the
   Intermediate Regulator and Recoder MAY use the following default
   policy.  The order of sending Data Objects is based on the Priority
   and Lifetime fields in the Bundle Primary Block, with the highest
   priority first, then the earliest expiration.  The order of sending
   Encodings within a specific Data Object is Round-Robin between
   contacts.  The send state for a Data Object is saved for the whole
   Data Object regardless of neighbors.  The maximum number of Encodings
   in the Innovative Phase is equal to the Number of Chunks.  The
   maximum number of Encodings in the Redundant Phase should be the
   maximum of 10 and the square root of the Number of Chunks.  There is
   no rate limit for sending Innovative Encodings or Redundant
   Encodings.

6.3.  Feedback Messages

   Feedback messages MAY be defined to increase the efficiency of
   resource usage for the case where feedback is possible between
   neighbors or between the destination and the source.  The following
   types of feedback messages would enhance the exchange protocol.

   Stop or End-to-End Acknowledgement  messages that are sent back from
      the Destination Decoder to the Source Encoder to indicate that the
      Data Object has been received.  The Source Encoder may use this
      acknowledgement to stop sending Redundant Encodings.  Also, this
      could prompt the sending of a PURGE message, that is signed by the
      Encoder.  The Stop message MUST expire no later than the original
      Data Object.

   Purge  messages to indicate that intermediate routers may remove all
      Encoding Bundles for a Data Object UUID.  Encoding Bundles are
      valid until the Lifetime of the Bundle expires.  The Purge
      mechanism allows for the early removal of Encoding Bundles to save
      storage and transmission resources in Intermediate Regulators.
      Purge messages MAY be ignored by Intermediate Routers, without
      loss of correct transmission.  Purge messages may be initiated
      either by the Encoder or Decoder and travel along the path from
      the message sender to the message destination.  Because the DTN
      path form the Encoder to Decoder may be different than the path
      from Decoder to Encoder, initiating Purge messages only from the
      Decoder may not be adequate to reach all the Intermediate Encoders



Zinky, et al.           Expires February 24, 2013              [Page 25]


Internet-Draft                 DTN-EC-Arch                   August 2012


      that have a copy of the Encoding Bundles for a Data Object.  Purge
      messages MUST be authenticated before triggering the removal of
      Encoding Bundles, in order to avoid denial of service attacks.
      The Purge message MUST expire not later than the original Data
      Object.

   Data Object Status  messages that are exchanged between neighbors to
      indicate the availability of Encoding Bundles for Data Objects.
      During a contact in an opportunistic DTN network topology,
      neighbors must quickly determine which Bundles to exchange.
      Erasure Encoding helps this process, by allowing reasoning about a
      group of bundles based on Data Object UUID.  The existence of a
      Data Object, rank of it's Encoding Set, and level of redundancy
      may be exchanged between neighbors.  This information may be used
      to increase the efficiency of the exchange.  For example, the
      following exchange policies MAY be enacted.  If the neighbor
      already has the full Data Object, no bundles from that group need
      to be exchanged.  Likewise, if the rank of the Encoding Set is
      almost full, then only missing Encoding Bundles need to be sent
      during the Innovative Send Phase.  Redundant Encoding Bundles may
      be delayed until after other Data Objects are completed their
      Innovative Send Phase.

6.4.  Intermediate Recoder

   Early research suggests that sending Encodings that are Redundant but
   not Duplicates will increase the probability of receiving a full
   Encoding Set at the destination.  In the case where the DTN topology
   is highly dynamic with contact transmissions much smaller than a
   whole Data Object, the interactions along the intermediate path mixes
   and copies Encodings in flight so that receiving Duplicates is
   common.  The overall receive process can be similar to a random draw
   from the senders Encoding Set with replacement.  Avoiding Duplicates
   being propagated on alternate paths avoids the "coupon collector
   problem" at the receiver.  That is, there is a low probability of
   getting the last missing coupon that is not a duplicate of a previous
   coupon.  If Duplicates are allowed to propagate on intermediate
   paths, many Encodings must be received before the Encoding Set can be
   solved, thus wasting bandwidth.  The goal of the Intermediate Recoder
   is to introduce Redundant Encodings on the intermediate paths that
   are not Duplicates.

   An Intermediate Recoder includes all of the functionality of an
   Intermediate Regulator.  The Recoder adds the functionality of
   generating additional Encoding Bundles for Data Objects.
   Intermediate Recoders do not directly forward Encodings that they
   receive, but would produce a new Encoding from all of the previously
   received Encodings for the same Data Object.  This new Encoding would



Zinky, et al.           Expires February 24, 2013              [Page 26]


Internet-Draft                 DTN-EC-Arch                   August 2012


   be Redundant relative to the previously received Encoding Set, but it
   would not be a Duplicate of any Encoding in the Encoding Set. Thus as
   the Encodings for a Data Object are propagated over the DTN, few if
   any Duplicates would be present over the whole DTN.  In other words,
   if Intermediate BPAs transmitted copies of received Encoding Bundles,
   then Bundles that took different paths might be Duplicates.  If two
   Duplicates are received, then at least one will be Redundant.  But if
   two Recoded Encodings are receive, even if they come from the same
   partial Encoding Set, there is a chance that both will be Innovative.

   Some FEC schemes allow the generation of Redundant Encodings from
   previously received Encodings.  The exact mechanism for the
   generation is FEC scheme dependent, but the basic mechanism is to
   linearly combine multiple Encodings to form a new Recoded Encoding.
   The Recoded Encoding will always be Redundant relative to the
   Encoding Set. It adds no innovative information about the Data
   Object's Chunks.  Instead the Recoded Encoding is not a Duplicate of
   previous Encodings.

   More research is necessary to determine the mechanisms for Recoding.
   The Erasure Coding Extension supports this research by defining the
   architectural functions and basic policies for Recoding.  Some issues
   to be addressed include: how to recode without raising the hamming
   weight; how to reduce the number of Encoding Data XORs during
   generation of a new Encoding; how to reduce the XORs during solving
   the Encoding Set; and how to generate a new Encoding that can be
   authenticated as if it is coming from the original Encoder.
























Zinky, et al.           Expires February 24, 2013              [Page 27]


Internet-Draft                 DTN-EC-Arch                   August 2012


7.  Bundle Forwarding Layer

   The goal of the Bundle Forwarding Layer is to transfer Bundles using
   all the DTN features and services available to the BPA.  Legacy BPAs
   that are not aware of the Erasure Coding Extension MUST still forward
   Bundles between components, ignoring the Erasure Coding Extension,
   but adhering to Bundle forwarding procedures.  DTN Bundle Forwarding
   is adequately defined and characterized in other documents and does
   not have too be defined here.

   In order to meet the Transfer Specification at the Data Object layer,
   the special characteristics of the particular DTN network must be
   taken into account.  DTN can support networks that have extreme
   communication models, including the following: Besides the high
   delay-bandwidth products found in space networks and the non-
   contemporaneous end-to-end paths found in opportunistic mobile
   networks, DTN can support transmission to selective destinations.
   The DTN transmission links between coding components can be either
   unicast or multicast.  DTN supports bundles being delivered to
   multiple destinations.  DTN also supports multiple routing protocols,
   that can flood bundles through out the DTN network.  These DTN
   features may be used by Erasure Coding to support a wide variety of
   end-user applications.  For example, reliable multicast of large Data
   Objects over a DTN is an illustrative use case for Erasure Coding,
   because FEC is an effective technique for overcoming the difficulty
   of feedback between the multiple receivers and the sender, and FEC
   may exploit the ability of the DTN to deliver Encoding Bundles among
   peers.























Zinky, et al.           Expires February 24, 2013              [Page 28]


Internet-Draft                 DTN-EC-Arch                   August 2012


8.  Security Considerations

   The basic Erasure Coding protocol does not provide authentication for
   the Encoding Vector or the Encoding Data.  This means that a rogue
   entity on the path between the sender and the receiver could view,
   delete, reorder, copy, modify, and inject new Encoding Bundles into
   the bundle flow.  In this section we describe how to overcome this
   issue using the Bundle Security Protocol (BSP) [RFC6257].

   The Encoding Vector is stored in the Erasure Coding Extension Block
   and the Encoding Data is stored in the Payload Block.  The only
   method available in BSP to authenticate both the Payload Block and an
   Extension Block is through the use of a Bundle Authentication Block
   (BAB).  This is a symmetric key-based algorithm, meaning both parties
   must share a secret bit-string that is not known to any other
   entities.  BSP does not specify the method in which this secret bit-
   string should be established.

   It should be noted that the Extension Security Block (ESB) option in
   BSP does not provide authentication of an Extension Block.  Since ESB
   utilizes AES in Galois/Counter Mode (GCM), it does provide data
   integrity.  If the AES-GCM key was the output of a key agreement
   protocol that authenticated the sender of the bundle, then AES-GCM
   encryption may provide implicit authentication.  However, the ESB-
   RSA-AES128-EXT cipher suite that ESB utilizes does not provide this
   authentication.

   Another issue is guaranteeing the authenticity of feedback messages
   (Section 6.3) generated in by the destination.  This issue is not
   resolved because the actual need and format of the feedback messages
   is not defined in this document.




















Zinky, et al.           Expires February 24, 2013              [Page 29]


Internet-Draft                 DTN-EC-Arch                   August 2012


9.  Refinement of the Erasure Coding Extension

   This document defines the framework for an Erasure Coding Extension
   for DTN.  The document defines the terms, function, architectural
   components, and the extension block format.  Some details of some
   features have be purposely left out, because we expect that the
   Erasure Coding Extension will have multiple options for these
   features.  Specifically, a FEC scheme has not been defined in this
   document.  The companion document [RandBinary] defines the
   specification for the Random Binary Forward Error Correcting Scheme.
   Other FEC schemes will be added in the future.  Also, the format for
   Data Objects has not been defined in this document.  The companion
   document [EcObjects] defines the specification of File and Large
   Bundle Data Objects.  Other Data Object formats will be added in the
   future and each will have its own document.  We also anticipate a
   refinement of the Handling Specification and the forwarding and
   traffic shaping policies of Intermediate Regulators.  While this
   document recommends default policies, other Handling Specification
   definition will be added in the future and each will have their own
   document.































Zinky, et al.           Expires February 24, 2013              [Page 30]


Internet-Draft                 DTN-EC-Arch                   August 2012


10.  IANA Considerations

   Erasure Coding extension defines the following well known numbers:

      Bundle Protocol extension block number is the constant 0xEC.

      Identifier numbers for FEC schemes in extension block are defined
      in [RandBinary] and future FEC scheme documents.

      Identifier numbers for Data Object Format type in extension block
      are defined in [EcObjects] and future Data Object Format
      documents.







































Zinky, et al.           Expires February 24, 2013              [Page 31]


Internet-Draft                 DTN-EC-Arch                   August 2012


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4838]  Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
              R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
              Networking Architecture", RFC 4838, April 2007.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [RFC5052]  Watson, M., Luby, M., and L. Vicisano, "Forward Error
              Correction (FEC) Building Block", RFC 5052, August 2007.

   [RFC6256]  Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
              Values in Protocols", RFC 6256, May 2011.

11.2.  Informative References

   [EcObjects]
              Zinky, J., Caro, A., and G. Stein, "Bundle Protocol
              Erasure Coding Basic Objects",
              draft-zinky-dtnrg-erasure-coding-objects-00 (work in
              progress), Aug 2012.

   [Erasure_Wang]
              Wang, Y., Jain, S., Martonosi, M., and K. Fall, "Erasure-
              coding based routing for opportunistic networks", ACM
              SIGCOM Workshop on Delay-tolerant networking (WDTN 05),
              Aug 2005.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              July 2005.

   [RFC5053]  Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
              "Raptor Forward Error Correction Scheme for Object
              Delivery", RFC 5053, October 2007.

   [RFC5170]  Roca, V., Neumann, C., and D. Furodet, "Low Density Parity
              Check (LDPC) Staircase and Triangle Forward Error
              Correction (FEC) Schemes", RFC 5170, June 2008.

   [RFC5445]  Watson, M., "Basic Forward Error Correction (FEC)
              Schemes", RFC 5445, March 2009.



Zinky, et al.           Expires February 24, 2013              [Page 32]


Internet-Draft                 DTN-EC-Arch                   August 2012


   [RFC5510]  Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo,
              "Reed-Solomon Forward Error Correction (FEC) Schemes",
              RFC 5510, April 2009.

   [RFC6257]  Symington, S., Farrell, S., Weiss, H., and P. Lovell,
              "Bundle Security Protocol Specification", RFC 6257,
              May 2011.

   [RandBinary]
              Zinky, J., Caro, A., and G. Stein, "Random Binary Coding
              Scheme for Bundle Protocol",
              draft-zinky-dtnrg-random-binary-fec-scheme-00 (work in
              progress), Aug 2012.






































Zinky, et al.           Expires February 24, 2013              [Page 33]


Internet-Draft                 DTN-EC-Arch                   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 34]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/