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

[Marc Blanchet <[e-mail]>]

Le 2014-04-25 à 13:03, Stephen Farrell <[e-mail]> a écrit :

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

- good to go into IETF. agreed.
- I'm interested in contributing.
- I would add a milestone item to the charter: Registry for service identifiers  
 (I wrote a draft on this sometime ago).

Marc.

> 
> 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
>> 
>> 
> 
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest