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

["Templin, Fred L" <[e-mail]>]

Hi Stephen,

Thanks for the initial input, which we should be able to
accommodate. For myself, I am willing to work in whatever
capacity would best serve the activity, e.g., work on
drafts, assist in working group administration, etc.

Thanks - Fred
[e-mail]

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Friday, April 25, 2014 10:03 AM
> To: Templin, Fred L; [e-mail]
> Subject: Re: [dtn-interest] DTN BoF Proposal for IETF90
> 
> 
> Hi Fred,
> 
> Thanks for proposing this.
> 
> My initial comments on the proposal are:
> 
> - I'd be delighted to see this happen if there are enough
>   folks interested, willing, etc. I'm not sure there are
>   enough folks interested enough though.
> - I think a 5050bis really has to put a far higher priority
>   on being deployable based on tooling that many Internet
>   developers commonly use, but at the same time a 5050bis
>   protocol should be easy to gateway to a 5050 DTN in order
>   to not damage all the work the space folks have done
>   based on 5050
> - I'd say maybe merge agenda items (2) and (3), and the
>   5050bis and "SBSP" work - it  was IMO a mistake to do the
>   BSP separate from and later than the BP, which was part
>   of what lead to the BSP being such a complex monster
> - I'm not sure that postponing all work on CLs makes
>   sense, how would we get interop for a 5050bis without
>   some CL? So I'd say at least one CL would have to be
>   part of the initial charter. (I don't really care much
>   if that's a "new" CL or not.)
> 
> But I'll definitely turn up if this BoF happens, and will
> be very interested to see who else is interested.
> 
> Cheers,
> S.
> 
> 
> On 04/25/2014 04:33 PM, Templin, Fred L 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 w
> 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?
> 
> hen 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
> >
> >