Re: [dtn-interest] DTN BoF Proposal for IETF90

["Kruse, Hans" <[e-mail]>]

Fred, I am not sure if I can make it to IETF90 in person, but I am very willing to support a WG effort in whatever capacity makes sense.

Hans Kruse, Professor
J. Warren McClure School of Information and Telecommunication Systems
Adjunct Associate Professor of Electrical Engineering and Computer Science
Chief Operating Officer, GRID Lab
31 S. Court, Room 150, Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

On Apr 25, 2014, at 11:33 AM, Templin, Fred L <[e-mail]> wrote:

> Dear DTNRG,
> 
> Boeing has been actively tracking the DTNRG activities, and we believe
> that the time is now at hand to develop some of the more mature technologies
> in an IETF standards-track working group. Active, innovative research in DTN
> continues to be vital, but for Boeing's business purposes it is becoming
> important to lock the DTN protocols down in Internet standards.
> 
> To that end, Boeing is proposing to request a DTN BoF at the next IETF.
> Please see below for a draft BoF agenda and a proposed working group charter.
> Comments?  Suggestions?
> 
> Fred Templin
> [e-mail]
> 
> ---
> 
> Draft BoF Agenda (2.5hrs):
> **************************
> 1) Problem statement (IETF wg motivation) - 30min
> 
> 2) RFC5050(bis) - 30min
> 
> 3) Streamlined Bundle Security Protocol (SBSP) - 30min
> 
> 4) Bundle-in-Bundle Encapsulation - 30 min
> 
> 5) DTN Security Key Management - 30min
> 
> 
> Proposed working group charter:
> *******************************
> Working group name:
> 
>      Delay/Disruption Tolerant Networking Working Group (DTNWG)
> 
> Chair(s):
> 
>      TBD
> 
> Area and Area Director(s):
> 
>      Transport Area: ADs Spencer Dawkins <[e-mail]>,
>                          Martin Stiemerling <[e-mail]>
> 
> Responsible Area Director:
> 
>      TBD
> 
> Mailing list:
> 
>      General Discussion: [e-mail] (note: until wg formed)
>      To Subscribe: https://www.ietf.org/mailman/listinfo/dtn-interest
>      Archive: http://www.ietf.org/mail-archive/web/dtn-interest/current/maillist.html
> 
> Description of Working Group:
> 
>      The Delay/Disruption Tolerant Network Working Group (DTNWG) specifies
>      mechanisms for data communications in the presence of long delays
>      and/or intermittent connectivity. The work is motivated by well known
>      limitations of standard Internet protocols that expect end-to-end
>      connectivity between communicating endpoints, sub-second transmission
>      delays and robust packet delivery ratios. In environments where these
>      favorable conditions do not apply, existing mechanisms such as reliable
>      transport protocols and routing protocols can fail to converge resulting
>      in communication failures. Furthermore, classical end-to-end security
>      associations cannot be coordinated when communicating endpoints cannot
>      conduct multi-message keying exchanges in a timely fashion. These
>      limitations suggest the need for a new approach.
> 
>      Delay-Tolerant Networking (DTN) protocols have been the subject of
>      extensive research and development in the Delay-Tolerant Networking
>      Research Group of the Internet Research Task Force since 2002.  In
>      particular, the DTN Bundle Protocol (RFC 5050) and Licklider
>      Transmission Protocol (RFC 5326) have been shown to address the
>      issues identified above.  In 2008, BP/LTP was deployed on the EPOXI
>      spacecraft in deep space and was used to conduct reliable, automated
>      communication for four weeks over a network of 10 nodes in which the
>      bottleneck router in the network (the spacecraft) was up to 100 light
>      seconds from all other nodes and connectivity with the router was
>      subject to periods of disconnection lasting several days.
> 
>      The success of the BP/LTP protocol stack -- the core protocols of the
>      "DTN Architecture" originally described in RFC 4838 -- in this
>      demonstration may be attributed to the following fundamental design
>      principles:
> 
>        - There is never any expectation of contemporaneous end-to-end
>       connectivity between any two network nodes.  Where such connectivity
>       is sustained, the protocols leverage it to optimize performance,
>       but the possibility of transient but sustained disconnection at
>       any time, anywhere in the network, is always recognized.
> 
>        - Because end-to-end connectivity can never be assumed, each node
>          on the path between source and destination must be prepared to
>          handle incoming "bundles" of data that cannot immediately be
>          forwarded.  Such bundles must either be stored for future trans-
>          mission or discarded; in the latter case, the network must
>          be informed of this data loss so that an alternative path may
>          be selected, to avoid impairing the usability of the network.
> 
>        - Again because end-to-end connectivity can never be assumed,
>          end-to-end conversational data exchange can never be assumed to
>          complete in a timely manner; protocol features that rely on
>          timely conversational data exchange must be excluded from the
>          architecture.  This principle makes the DTN architecture
>          suitable not only for network environments characterized by
>          lengthy disconnection but also for those that are characterized
>          by long signal propagation delays (such as underwater communication
>          by acoustic signals or, worse, interplanetary communication) even
>          when connectivity is continuous.
> 
>      The DTNWG believes that protocols adhering to these principles offer
>      opportunities for enhancing the functionality of the Internet - in
>      particular, for facilitating the extension of the Internet into
>      environments such as the ocean floor and deep space in which the core
>      Internet protocols operate sub-optimally for the reasons discussed
>      earlier.  We believe that the extensive research, demonstration, and
>      pilot operations performed to date using the DTNRG protocols, both
>      before and after the EPOXI experiment, provides a firm basis for
>      publishing Internet standards derived from that work.
> 
>      Work items related to Delay/Disruption Tolerant Networking include:
> 
>      o A mechanism for the exchange of protocol data units, termed
>        "bundles", that are designed to obviate conversational communications
>        by containing values for all potentially relevant configuration
>        parameters.  These protocol data units are typically larger than
>        network-layer packets.  We expect to derive this bundle exchange
>        mechanism from the DTN Bundle Protocol (BP) documented in RFC 5050.
> 
>      o A security protocol for ensuring that the network in which bundles
>        are exchanged is secured against unauthorized access and denial of
>        service attacks, and to ensure data integrity and confidentiality
>        in that network where necessary.  We expect to derive this security
>        protocol from a "streamlined" adaptation of the DTN Bundle Security
>        Protocol documented in RFC 6257.
> 
>      o An encapsulation protocol for "tunneling" BP traffic within bundles
>        that are secured and/or routed in different way from the encapsulated
>        bundles.
> 
>      o A delay-tolerant security key management scheme for ensuring that
>        public keys are certified by a globally trusted authority to protect
>        the integrity of the infrastructure.
> 
>    The working group will consider extending the current milestones based on
>    new information and knowledge gained while working on the initial charter,
>    as well as to accommodate new work items beyond the scope of the initial
>    phase.  For example, we expect that transport protocols uniquely suited
>    to the various communication environments that may need to be traversed
>    by a single DTN end-to-end path (operating under BP, at what is termed
>    the DTN "convergence layer") will need to be standardized in a second
>    phase of the working group's charter; LTP and the Saratoga protocol are
>    among the candidates for work in this phase.  These adjustments will be
>    accommodated in a working group recharter, assuming the initial
>    chartered activities meet their delivery milestones. Possible new work
>    items must then still fit into the (rechartered) DTNWG charter scope.
> 
> Goals and Milestones:
>  start+3mos - Submit 'Bundle Protocol Specification (RFC5050bis)' as a
>                      working group document. To be Proposed Standard.
>  Start+3mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' as a
>                       working group document. To be Proposed Standard.
>  start+6mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' as a working
>                      group document. To be Proposed Standard.
>  start+9mos - Submit 'Delay Tolerant Networking Security Key Management' as
>                      a working group document. To be Proposed Standard.
>  start+9mos - Submit 'Bundle Protocol Specification (RFC5050bis)' to the
>                      IESG. To be Proposed Standard.
>  start+9mos - Submit 'Streamlined Bundle Security Protocol (SBSP)' to the
>                      IESG. To be Proposed Standard.
>  start+10mos - Submit 'Bundle In Bundle Encapsulation (BIBE)' to the IESG.
>                       To be Proposed Standard.
>  start+11mos - Submit 'Delay Tolerant Networking Security Key Management' to
>                       the IESG. To be Proposed Standard.
>  start+12mos - Recharter to accommodate new work items or close Working Group
> 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest