Re: [dtn] Draft Charter Discussion

["Birrane, Edward J." <[e-mail]>]

Stephen,

  I certainly can't answer those questions for Boeing or for Fred, but I have my own answer that I'm willing to share. Having never been an acorn, I am not certain if I am thinking like one, but here goes.

  For years, there have been sample deployments and experiments that show the feasibility and functionality of DTN, specifically BP. There have also been a smaller set of experiments that identified limitations with BP.  From speaking with government, university, and small businesses my accumulated opinions are as follows.

So, why DTN in non-space cases?

- Some like the protocol bits (blocks, custody xfer, queuing, reporting structure) as a consolidated standard and not a layered set of standards and best practices.
- Some like the automation for delay/disrupted and scaled deployments - it cuts down on their one-off app point solutions.
- Some feel that their analyses indicate DTN overlays can simplify complex architectures such as TCP PEPs, including how to integrate differing networks using different queuing models.
- Some sensor networks behave quite similarly to space networks regarding disruption. Underwater scenarios also look similar in terms of delay.

Not an exhaustive list, but the highlights from why people are interested in a standard that pulls these bits together.

Separately, the line between space providers and space users is blurring. LEO constellations that want to interact seamlessly with terrestrial infrastructure as first-class nodes in a network should not be lumped as "space" in the sense of deep space missions or older, sparser near-earth deployments.


So, why no scaled DTN deployments yet outside of NASA baselines?

- The security mechanism looked overly complex and hard to verify.
- There was no progress on management, especially in access-denied and open-loop areas.
- The protocol specs are described in experimental RFCs, with discussion of a bis.


So, why now?

- There has been progress on simplifying the security implementations based on lessons learned.
- There is some promising progress (yes, through NASA, but not NASA centric) on disruption-scaling management concepts.
- There is a set of lessons learned informing  5050bis/BPv7. To Fred's schedule, this can be resolved in relatively short order.

I know of a few companies and some non-commercial entities that have no issue with BP and are not worried about building a BPA.  But an operational deployment needs a non-experimental spec, security, and management. There is much more it needs in the general case, but these seem to be driving requirements.

I am unsure of what is sufficient proof for your question. Does it have to be 10 companies interested and not 8? 25 nodes instead of 18? 100? Is the deployment horizon 1 year and not 3?

So, I naively ask the opposite question: why not standardize this work in the IETF?

You have the community of people who are willing to do the work, with backing from industry and government. The charter, as I see it, addresses clear needs for operational deployment, and to Will's points, the DTNRG persists to continue inspection of the fundamental research issues surrounding more exotic deployments.

-Ed

---
Ed Birrane
Principal Professional Staff, Space Department
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839



> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Stephen Farrell
> Sent: Tuesday, June 17, 2014 4:32 PM
> To: Templin, Fred L; [e-mail]
> Subject: Re: [dtn] Draft Charter Discussion
>
>
> Hi Fred,
>
> On 17/06/14 21:12, Templin, Fred L wrote:
> > Hi Stephen,
> >
> >> -----Original Message-----
> >> From: Stephen Farrell [mailto:[e-mail]]
> >> Sent: Tuesday, June 17, 2014 1:05 PM
> >> To: Templin, Fred L; [e-mail]
> >> Subject: Re: [dtn] Draft Charter Discussion
> >>
> >>
> >> Fred and others,
> >>
> >> I think I've asked this before so apologies if I just forget the good
> >> answer;-)
> >>
> >> We have the space use-case and some fairly well known niche
> >> terrestrial use-cases, which are fine. But we've known these for
> >> years and the DTNRG didn't want to move to the standards track until
> >> now.
> >
> > Yes, a diverse set of use cases and not a single use case. That means
> > that in the early days there may be many purpose-built DTNs that may
> > at a later time be joined together to form larger DTNs.
> > A "DTN-of-DTNs" in the same way that the Internet is a "network-
> > of-networks".
> >
> > The whole reason the Internet was able to join together smaller
> > networks to form larger networks is that the Internet had
> > interoperable standards from the very beginning. It is now time for us
> > to do that for DTN.
>
> I'm familiar with DTN. But I find the above a pretty complete non-answer to
> the question asked (in that it answers no part of my question:-) So I'll try
> again, in a more direct fashion...
>
> I do not know why specifically Boeing want a standards track RFC5050bis, nor
> why you want it now.
>
> And I'm wondering and would like to know. I have not heard your use-case
> (or business case, whatever) explained so far.
> Nor have I heard someone say "can't/won't tell, sorry."
> So I'm curious.
>
> And I'll note once again that successful BoFs tend to involve explaining why
> this, now, specifically. As an IESG member it makes it much easier for me to
> evaluate proposals for forming a WG.
>
> (BTW, any answer that asks me to think like an acorn won't really work for
> this question, sorry:-)
>
> If someone else has a new answer to this question that would also be
> interesting. By new, I mean a use-case or business-case that hasn't
> previously been discussed in the DTNRG.
>
> Cheers,
> S.
>
> PS: In case there's confusion. My question is very much not the same as
> Will's, despite your answer being very similar.
>
> >
> > Thanks - Fred
> > [e-mail]
> >
> >> I think it'd help the IESG to decide whether to approve a WG if there
> >> were more information available about what has changed to motivate
> >> moving to the standards track.
> >>
> >> If (say for Boeing) those are such that you can't say and there
> >> aren't any others who can, then that's a pity, since it does make it
> >> harder to get why a 5050bis on the standards track is attractive.
> >>
> >> I'm just noting this again because I think many recent successful
> >> BoFs have tended to have this topic as part of the agenda, but it
> >> seems missing in yours, which just assumes that the room knows that
> >> RFC5050 needs a bit of work. (I'm exaggerating a bit there, but I
> >> hope you get what I mean.)
> >>
> >> S.
> >>
> >> On 17/06/14 18:40, Templin, Fred L wrote:
> >>> Please see below for an updated version of the draft charter based
> >>> on list discussions, and post any further comments in follow-up.
> >>> (See also attached for diffs relative to the previous version.)
> >>>
> >>> Thanks - Fred
> >>> [e-mail]
> >>>
> >>> ---
> >>>
> >>> Draft BoF Agenda (2.5hrs):
> >>> **************************
> >>> 1) Problem statement (IETF wg motivation) - 30min
> >>>
> >>> 2) RFC5050(bis) - 15min
> >>>
> >>> 3) Streamlined Bundle Security Protocol (SBSP) - 15min
> >>>
> >>> 4) Security Key Management - 10min
> >>>
> >>> 5) Network Management - 10min
> >>>
> >>> 6) Contact Graph Routing and Contact Plan Update Protocol - 10min
> >>>
> >>> 7) Bundle-in-Bundle Encapsulation - 5min
> >>>
> >>> 8) Registry for Service Identifiers - 5min
> >>>
> >>> 9) Open Discussion - 50min
> >>>
> >>>
> >>> Draft 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 <spencerdawkins.ietf at
> gmail.com>,
> >>>                           Martin Stiemerling <mls.ietf at gmail.com>
> >>>
> >>> Responsible Area Director:
> >>>
> >>>       TBD
> >>>
> >>> Mailing list:
> >>>
> >>>       General Discussion: dtn at ietf.org
> >>>       To Subscribe: https://www.ietf.org/mailman/listinfo/dtn
> >>>       Archive:
> >>> http://www.ietf.org/mail-archive/web/dtn/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 encounter
> problems
> >>>       such as reliable transport protocol handshakes timing out and routing
> >>>       protocols failing 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 suggested 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 (DTNRG) of the Internet Research Task Force since
> 2002.
> >>>       The DTNRG has developed the Delay-Tolerant Networking
> Architecture
> >>>       (RFC 4838) that the DTNWG uses as the basis for its work.  The key
> >>>       components of the this architecture are the bundle concept for
> >>>       encapsulating data units, the bundle transmission protocol and the
> >>>       underlying convergence layer architecture.
> >>>
> >>>       The experimental DTN Bundle Protocol (RFC 5050) and Licklider
> >>>       Transmission Protocol (RFC 5326) have been shown to address the
> >>>       issues identified above in substantial fielded deployments in the
> space
> >>>       sector [1].  RFC 5050 in conjunction with TCP- and UDP-based
> convergence
> >>>       layers has been used successfully in a number of experiments both in
> >>>       communications challenged environments around the edges of the
> Internet
> >>>       and as an Internet overlay where applications require delay- and/or
> >>>       disruption-tolerance [refs needed].
> >>>
> >>>       The success of the BP over convergence layer protocol stack -- the
> core
> >>>       protocols of the "DTN Architecture" described in RFC 4838 -- 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.
> >>>
> >>>   - 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.
> >>>
> >>>   - 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.
> >>>
> >>>       The DTNWG believes that protocols adhering to these principles offer
> >>>       opportunities for enhancing the functionality of the Internet,
> >>> including
> >>>
> >>>         - 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;
> >>>
> >>>         - extending the Internet into communications challenged terrestrial
> >>>           environments where it is not possible to provide continuous, low
> >>>           delay Internet connections; and
> >>>
> >>>         - supporting Internet applications that need DTN capabiliies.
> >>>
> >>>       We believe that the extensive research, demonstration, and
> >>>       pilot operations performed to date using the DTNRG protocols
> 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 will derive this bundle exchange
> mechanism
> >>>         from the DTN Bundle Protocol (BP) documented in RFC 5050 by
> publishing
> >>>         a new document for which [2] is a proposed first draft (where
> >>>         appendix A provides a summary of the proposed changes).
> >>>
> >>>       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 will derive this security
> >>>      protocol from a "streamlined" adaptation of the DTN Bundle
> Security
> >>>      Protocol documented in RFC 6257.
> >>>
> >>>        o A delay-tolerant security key management scheme that can protect
> >>>          the integrity of a DTN network.
> >>>
> >>>       o A simple datagram convergence layer protocol for adaptation of the
> >>>         bundle protocol to underlying internetworks. We expect to derive
> >>>         this convergence layer protocol from the Datagram Convergence
> >>>         protocol documented in RFC 7122.
> >>>
> >>>       o A protocol for remote status monitoring, configuration, and
> >>>         administration of network nodes in the presence of long delays
> >>>         and/or intermittent connectivity.
> >>>
> >>>       o A functional specification of Contact Graph Routing (CGR) specifying
> >>>         the inputs (global contact schedules, traffic demands, etc.) and
> >>>         outputs (node specific transmission and reception schedules,
> >>>         notifications, etc.).  CGR is a centralized, oracle-based bundle
> >>>         transmission and reception scheduling scheme used in space
> segment
> >>>         DTN deployments.
> >>>
> >>>       o An adjunct to the management protocol that will allow the contact
> >>>         schedules generated by CGR to be distributed to nodes.  This may be
> >>>         based on the Contact Plan Update Protocol (CPUP) proposed in
> >>>
> >>>       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 registry for DTN Service Identifiers
> >>>
> >>>     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 such as LTP
> and
> >>>     the Saratoga protocol are among the candidates for work in this phase.
> >>>
> >>> Goals and Milestones:
> >>>   start+0mos - Accept 'Bundle Protocol Specification (RFC5050bis)' [2] as
> >>>                a working group work item intended for Proposed Standard.
> >>>   Start+0mos - Accept 'Streamlined Bundle Security Protocol (SBSP)' [3] as
> >>>                a working group work item intended for Proposed Standard.
> >>>   start+3mos - Accept 'Bundle In Bundle Encapsulation (BIBE)' [4] as a
> >>>                working work item intended for Proposed Standard.
> >>>   start+6mos - Working group getting concensus on changes to be
> implemented
> >>>                in RFC 5050(bis).
> >>>   start+9mos - Working group getting consensus on merging RFC5050bis,
> SBSP,
> >>>                BIBE etc. into a combined draft or keep as separate drafts.
> >>>   start+12mos - Accept 'CGR Functional Specification' as a working group
> >>>                 working group work item intended for Informational.
> >>>   start+12mos - Accept 'Delay Tolerant Networking Security Key
> Management'
> >>>                 as a working group work item intended for Proposed Standard.
> >>>   start+15mos - Accept 'Contact Plan Update Protocol' as working group
> work
> >>>                 item intended for Proposed Standard.
> >>>   start+18mos - Submit RFC5050bis, SBSP, BIBE and Key Mgmt to the IESG
> either
> >>>                 as a combined draft or as separate drafts.
> >>>   start+18mos - Submit Network Management [5], Registry [6] and
> Simple
> >>>                 Convergence Layer [7] as working group documents.
> >>>   start+20mos - Survey appropriate forums (e.g., DTNRG) for emerging
> >>>                 technologies (e.g., convergence layer protocols, dynamic
> >>>                 routing protocols, naming and addressing services, etc.)
> >>>                 ready for transition into IETF DTN Working Group. Publish
> >>>                 draft on survey results as independent submission related
> >>>                 to the WG.
> >>>   start+24mos - Submit Network Management, Registry and Simple
> Convergence
> >>>                 Layer to IESG
> >>>   start+24mos - Recharter to accommodate new work items or close
> >>> Working Group
> >>>
> >>>
> >>> [1] "BP/LTP deployment on EPOXI spacecraft" [2008],
> >>>     http://committees.comsoc.org/tccc/ccw/2010/slides/DINET_CCW.pdf
> >>> [2] "Proposed Revised Bundle Protocol" [2014],
> >>>     https://datatracker.ietf.org/doc/draft-burleigh-bpv7/
> >>> [3] "Streamlined Bundle Security Protocol Specification" [2014],
> >>>     https://datatracker.ietf.org/doc/draft-irtf-dtnrg-sbsp/
> >>> [4] "Bundle-in-Bundle Encapsulation" [2013],
> >>>     http://tools.ietf.org/id/draft-irtf-burleigh-bibe
> >>> [5] "Delay Tolerant Network Management Protocol" [2013],
> >>>     http://tools.ietf.org/id/draft-irtf-dtnrg-dtnmp
> >>> [6] "Delay-Tolerant Networking Bundle Protocol IANA Registries" [2011],
> >>>     https://datatracker.ietf.org/doc/rfc6255/
> >>> [7] "Datagram Convergence Layers ..." [2014],
> >>>     https://datatracker.ietf.org/doc/rfc7122/
> >>> [8] "Towards Flexibility and Accuracy in Space DTN Communications",
> >>>     Bezirgianndia et al, CHANTS 2012,
> >>>     http://dl.acm.org/citation.cfm?id=2505499 [2012]
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> dtn mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dtn
> >>>
> >
> > _______________________________________________
> > dtn mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dtn
> >
> >
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn