Re: [dtn] Draft Charter Discussion

"Templin, Fred L" <Fred.L.Templin@boeing.com> Tue, 17 June 2014 17:40 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37891A03BD for <dtn@ietfa.amsl.com>; Tue, 17 Jun 2014 10:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.841
X-Spam-Level:
X-Spam-Status: No, score=-4.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvvIu6V2lR4T for <dtn@ietfa.amsl.com>; Tue, 17 Jun 2014 10:40:54 -0700 (PDT)
Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3411A03B4 for <dtn@ietf.org>; Tue, 17 Jun 2014 10:40:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s5HHerAO008714; Tue, 17 Jun 2014 10:40:53 -0700
Received: from XCH-PHX-305.sw.nos.boeing.com (xch-phx-305.sw.nos.boeing.com [137.136.239.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s5HHeiVm008081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for <dtn@ietf.org>; Tue, 17 Jun 2014 10:40:44 -0700
Received: from XCH-BLV-410.nw.nos.boeing.com (137.136.239.131) by XCH-PHX-305.sw.nos.boeing.com (137.136.239.28) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 17 Jun 2014 10:40:43 -0700
Received: from XCH-BLV-512.nw.nos.boeing.com ([169.254.12.74]) by XCH-BLV-410.nw.nos.boeing.com ([169.254.10.180]) with mapi id 14.03.0181.006; Tue, 17 Jun 2014 10:40:43 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] Draft Charter Discussion
Thread-Index: Ac+GbO3wN7xIp4CqSFeVEjvJc65+vAAPLd8AAAy+SjAAJnyrgAC3CG0Q
Date: Tue, 17 Jun 2014 17:40:42 +0000
Message-ID: <2134F8430051B64F815C691A62D983183048DB80@XCH-BLV-512.nw.nos.boeing.com>
References: <2134F8430051B64F815C691A62D983183048B287@XCH-BLV-512.nw.nos.boeing.com> <394B12F3-CBD6-489A-99AD-82AEEC4AA51E@ibr.cs.tu-bs.de> <2134F8430051B64F815C691A62D983183048B3B6@XCH-BLV-512.nw.nos.boeing.com> <CFC0BA2C.1024A%Vinny.Ramachandran@jhuapl.edu>
In-Reply-To: <CFC0BA2C.1024A%Vinny.Ramachandran@jhuapl.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [137.136.248.6]
Content-Type: multipart/mixed; boundary="_002_2134F8430051B64F815C691A62D983183048DB80XCHBLV512nwnosb_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: http://mailarchive.ietf.org/arch/msg/dtn/V6xSdpCl2amj5rxvoj2DbmZEpxQ
Subject: Re: [dtn] Draft Charter Discussion
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jun 2014 17:40:58 -0000

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
fred.l.templin@boeing.com

---

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]