Received: from mail-gx0-f220.google.com (mail-gx0-f220.google.com [209.85.217.220]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBH7JNWW029715 for ; Wed, 16 Dec 2009 23:19:24 -0800 Received: by gxk20 with SMTP id 20so1833684gxk.14 for ; Wed, 16 Dec 2009 23:19:24 -0800 (PST) Received: by 10.101.135.15 with SMTP id m15mr3341971ann.13.1261034364029; Wed, 16 Dec 2009 23:19:24 -0800 (PST) Received: from galactica.ronin.pauledelman.net (cpe-24-167-15-148.hot.res.rr.com [24.167.15.148]) by mx.google.com with ESMTPS id 21sm1157014iwn.2.2009.12.16.23.19.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Dec 2009 23:19:23 -0800 (PST) From: Paul Edelman Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Dec 2009 01:19:20 -0600 Message-Id: <643FE708-0658-4A1C-921F-4168064ACC47@gmail.com> To: dtn-users@maillists.intel-research.net Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by maillists.intel-research.net id nBH7JNWW029715 Subject: [dtn-users] Wildcards and EIDs X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2009 07:19:24 -0000 I have looked around, but been unable to find a definitive answer on this. The documentation I have read indicates that DTN supports the use of wildcards in EIDs. I know the scheme has to support this; therefore, is there a scheme for this and how do I enable it? Any information is greatly appreciated. Cheers, Paul Received: from salvator.ibr.cs.tu-bs.de (salvator.ibr.cs.tu-bs.de [134.169.34.11]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBFDXXxQ008716 for ; Tue, 15 Dec 2009 05:33:34 -0800 Received: from [IPv6:2001:638:602:2200:218:8bff:fea1:cc80] (syrah.ibr.cs.tu-bs.de [IPv6:2001:638:602:2200:218:8bff:fea1:cc80]) (Authenticated sender: morgenro@salvator) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPA id 44E4514250 for ; Tue, 15 Dec 2009 14:33:29 +0100 (CET) Message-ID: <4B279029.2070407@ibr.cs.tu-bs.de> Date: Tue, 15 Dec 2009 14:33:29 +0100 From: Johannes Morgenroth User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dtn-users@maillists.intel-research.net References: <4B275390.6010403@ibr.cs.tu-bs.de> In-Reply-To: <4B275390.6010403@ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de Subject: Re: [dtn-users] message type codes in TCPCL X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 13:33:34 -0000 Hi again > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > | type | flags | > +-+-+-+-+-+-+-+-+ > Joerg told me the reason for this ordering. The numbers above are the bits on the wire, so we have to build an 8-bit array as depicted where the 1-bit of the type 0x01 is the bit 3. This was a little confusing to me, but now much clearer. Best regards Johannes Morgenroth -- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig Received: from salvator.ibr.cs.tu-bs.de (salvator.ibr.cs.tu-bs.de [134.169.34.11]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBF9ExsX028399 for ; Tue, 15 Dec 2009 01:15:00 -0800 Received: from [IPv6:2001:638:602:2200:218:8bff:fea1:cc80] (syrah.ibr.cs.tu-bs.de [IPv6:2001:638:602:2200:218:8bff:fea1:cc80]) (Authenticated sender: morgenro@salvator) by salvator.ibr.cs.tu-bs.de (Postfix) with ESMTPA id B1E9614294 for ; Tue, 15 Dec 2009 10:14:56 +0100 (CET) Message-ID: <4B275390.6010403@ibr.cs.tu-bs.de> Date: Tue, 15 Dec 2009 10:14:56 +0100 From: Johannes Morgenroth User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: dtn-users@maillists.intel-research.net Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at salvator X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on salvator.ibr.cs.tu-bs.de Subject: [dtn-users] message type codes in TCPCL X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 09:15:00 -0000 Hi All I'm working on an implementation of TCP convegence layer according to draft-irtf-dtnrg-tcp-clayer-02. During interoperability testing with the DTN2 reference implementation I stumbled over a potential inconsistency. The message type code in the draft is defined as two 4-bit fields, type and flags. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | type | flags | +-+-+-+-+-+-+-+-+ So I thought: we start with the type code (0x01, 0x02, 0x03, ...) and then use the upper 4 bits for the flags. But the the reference implementation seems to switch the fields and start with flags and then use the upper 4 bits for the type code. Could anyone explain why? Best regards Johannes Morgenroth -- Johannes Morgenroth Institut fuer Betriebssysteme und Rechnerverbund Tel.: +49-531-391-3249 Muehlenpfordtstrasse 23 Fax.: +49-531-391-5936 TU Braunschweig D-38106 Braunschweig Received: from mail-yx0-f186.google.com (mail-yx0-f186.google.com [209.85.210.186]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nBE5wkpD015590 for ; Sun, 13 Dec 2009 21:58:47 -0800 Received: by yxe16 with SMTP id 16so2776868yxe.27 for ; Sun, 13 Dec 2009 21:58:46 -0800 (PST) Received: by 10.150.37.36 with SMTP id k36mr6450514ybk.335.1260770326105; Sun, 13 Dec 2009 21:58:46 -0800 (PST) Received: from ?67.188.59.148? (c-67-188-59-148.hsd1.ca.comcast.net [67.188.59.148]) by mx.google.com with ESMTPS id 7sm1738631yxd.44.2009.12.13.21.58.16 (version=SSLv3 cipher=RC4-MD5); Sun, 13 Dec 2009 21:58:42 -0800 (PST) Sender: Alex McMahon From: Alex McMahon To: dtn-users Content-Type: multipart/mixed; boundary="=-dYbAUotzJ4SaTPDyYLDr" Organization: Trinity College Dublin Date: Sun, 13 Dec 2009 21:58:14 -0800 Message-Id: <1260770294.4731.2462.camel@sphere> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Subject: [dtn-users] DTN2 patch to update manual and tcl command line help X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: alex.mcmahon@cs.tcd.ie List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2009 05:58:48 -0000 --=-dYbAUotzJ4SaTPDyYLDr Content-Type: text/plain Content-Transfer-Encoding: 7bit I will apply the attached patch on Tuesday unless someone objects before then. The patch is to provide extensive additions and updates to the DTN2 documentation. Documentation and examples are provided for configuration file and command line options, arguments and syntax of routing protocols and algorithms, storage back ends, CLAs, link, interface, discovery, logging and debug parameters. It provides an extensive update to the tcl commands link, storage, bundle, route, discovery, and interface to provide detail on available options and arguments and syntax when help is requested. Also some general housekeeping including removal of dtnrg drafts from DTN2/doc/manual as many are outdated. Alex --=-dYbAUotzJ4SaTPDyYLDr Content-Disposition: attachment; filename="DTN2-patch" Content-Type: text/plain; name="DTN2-patch"; charset="UTF-8" Content-Transfer-Encoding: quoted-printable # HG changeset patch # User Alex McMahon # Date 1260769572 28800 # Node ID e62055127255c385bc59034df5fcb8254dcadc38 # Parent 8b0d483af1e21be3136e81118663b41ec4a0f89f Extensive additions and updates to the DTN2 documentation (Please see DTN2/doc/manual/index.html). Documentation and examples provided for configuration file and command line options, arguments and syntax for routing protocols and algorithms, storage back ends, CLAs, link, interface, discovery, logging and debug parameters. Extensive update to the tcl commands link, storage, bundle, route, discovery, and interface to provide detail on available options and arguments and syntax when help is requested. General housekeeping including removal of dtnrg drafts from DTN2/doc/manual as many are outdated. diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-arch-06.txt --- a/doc/draft-irtf-dtnrg-arch-06.txt Sat Dec 12 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1762 +0,0 @@ -DTN Research Group V. Cerf=20 -INTERNET-DRAFT Google/Jet Propulsion Laboratory=20 - S. Burleigh=20 -September 2006 A. Hooke=20 -Expires February 2007 L. Torgerson=20 - NASA/Jet Propulsion Laboratory=20 - R. Durst=20 - K. Scott=20 - The MITRE Corporation=20 - K. Fall=20 - Intel Corporation=20 - H. Weiss=20 - SPARTA, Inc.=20 -Delay-Tolerant Networking Architecture=20 -=20 -Status of this Memo=20 - =20 - By submitting this Internet-Draft, each author represents that any=20 - applicable patent or other IPR claims of which he or she is aware=20 - have been or will be disclosed, and any of which he or she becomes=20 - aware will be disclosed, in accordance with Section 6 of BCP 79.=20 - =20 - Internet-Drafts are working documents of the Internet Engineering=20 - Task Force (IETF), its areas, and its working groups. Note that=20 - other groups may also distribute working documents as Internet- - Drafts. =20 - =20 - Internet-Drafts are draft documents valid for a maximum of six months=20 - and may be updated, replaced, or obsoleted by other documents at any=20 - time. It is inappropriate to use Internet-Drafts as reference=20 - material or to cite them other than as "work in progress".=20 - =20 - The list of current Internet-Drafts can be accessed at =20 - http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- - Draft Shadow Directories can be accessed at =20 - http://www.ietf.org/shadow.html.=20 - =20 - This document represents the consensus of all the active contributors=20 - of the IRTF's Delay Tolerant Networking Research Group (DTNRG). =20 - Please see http://www.dtnrg.org. =20 - - - - - - - - - - - - - - - -=20 -Cerf, et al. Expires February 2007 [Page 1]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - =20 -Abstract=20 - =20 - This document describes an architecture for delay-tolerant and=20 - disruption-tolerant networks, and is an evolution of the architecture=20 - originally designed for the Interplanetary Internet, a communication=20 - system envisioned to provide Internet-like services across=20 - interplanetary distances in support of deep space exploration. This=20 - document describes an architecture that addresses a variety of=20 - problems with internetworks having operational and performance=20 - characteristics that make conventional (Internet-like) networking=20 - approaches either unworkable or impractical. We define a message- - oriented overlay that exists above the transport (or other) layers of=20 - the networks it interconnects. The document presents a motivation=20 - for the architecture, an architectural overview, review of state=20 - management required for its operation, and a discussion of=20 - application design issues.=20 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -=20 -Cerf, et al. Expires February 2007 [Page 2]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 -Table of Contents=20 - =20 - Status of this Memo................................................1=20 - Abstract...........................................................2=20 - Table of Contents..................................................3=20 - 1 Introduction.................................................5=20 - 2 Why an Architecture for Delay-Tolerant Networking?...........6=20 - 3 DTN Architectural Description................................7=20 - 3.1 Virtual Message Switching using Store-and-Forward=20 - Operation...............................................7=20 - 3.2 Nodes...................................................8=20 - 3.3 Endpoint Identifiers (EIDs) and Registrations...........8=20 - 3.4 Naming of Groups.......................................10=20 - 3.5 Priority Classes.......................................11=20 - 3.6 Postal-Style Delivery Options and Administrative Records12=20 - 3.7 Primary Bundle Fields..................................14=20 - 3.8 Routing and Forwarding.................................15=20 - 3.9 Fragmentation and Reassembly...........................17=20 - 3.10 Reliability and Custody Transfer.......................18=20 - 3.11 DTN Support for Proxies and Application Layer Gateways.20=20 - 3.12 Time Stamps and Time Synchronization...................20=20 - 3.13 Congestion and Flow Control at the Bundle Layer........21=20 - 3.14 Security...............................................22=20 - 4 State Management Considerations.............................23=20 - 4.1 Application Registration State.........................23=20 - 4.2 Custody Transfer State.................................24=20 - 4.3 Bundle Routing and Forwarding State....................24=20 - 4.4 Security-Related State.................................25=20 - 4.5 Policy and Configuration State.........................25=20 - 5 Application Structuring Issues..............................25=20 - 6 Convergence Layer Considerations for Use of Underlying=20 - Protocols...................................................26=20 - 7 Summary.....................................................27=20 - 8 Security Considerations.....................................27=20 - 9 IANA Considerations.........................................27=20 - 10 Normative References........................................27=20 - 11 Informative References......................................27=20 - =20 - - - - - - - - - - - - - - - -=20 -Cerf, et al. Expires February 2007 [Page 3]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 -Acknowledgments=20 - =20 - John Wroclawski, David Mills, Greg Miller, James P. G. Sterbenz, Joe=20 - Touch, Steven Low, Lloyd Wood, Robert Braden, Deborah Estrin, Stephen=20 - Farrell, Melissa Ho, Ting Liu, Mike Demmer, Jakob Ericsson, Susan=20 - Symington, Andrea Gurtov, Avri Doria and Craig Partridge all=20 - contributed useful thoughts and criticisms to previous versions of=20 - this document. We are grateful for their time and participation.=20 - =20 - This work was performed in part under DOD Contract DAA-B07-00-CC201,=20 - DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; and NASA=20 - Contract NAS7-1407.=20 - =20 -Release Notes=20 - =20 -draft-irtf-dtnrg-arch-00.txt, March 2003: =20 - -Revised model for delay tolerant network infrastructure security=20 - -Introduced fragmentation and reassembly to the architecture=20 - -Removed significant amounts of rationale and redundant text=20 - -Moved bundle transfer example(s) to separate draft(s).=20 - =20 -draft-irtf-dtnrg-arch-02.txt, July 2004:=20 - -Revised assumptions about reachability within DTN regions=20 - -Added management endpoint identifiers for nodes=20 - -Moved list of bundle header information to protocol spec document=20 - =20 -draft-irtf-dtnrg-arch-03.txt, July 2005:=20 - -Revised regions to become URI schemes=20 - -Added discussion of multicast and anycast=20 - -Revised motivation/introduction section (2)=20 - -Much of the security discussion has moved to the security draft=20 - -Updated terminology to match current bundle protocol specification=20 - =20 -draft-irtf-dtnrg-arch-04.txt, November 2005:=20 - -Included further terminology updates and minor editing=20 - =20 -draft-irtf-dtnrg-arch-05.txt, March 2006:=20 - -Added consensus wording for new IRTF document process proposal=20 -draft-irtf-dtnrg-arch-06.txt, May 2006:=20 - -Incorporated review comments / corrected typos=20 - -Clarified terminology with regard to bundles and messages=20 - -Changed terminology from "header" to "block"=20 - =20 - - - - - - - - - - -=20 -Cerf, et al. Expires February 2007 [Page 4]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 -1 Introduction=20 - =20 - This document describes an architecture for delay and disruption- - tolerant interoperable networking (DTN). The architecture embraces=20 - the concepts of occasionally-connected networks that may suffer from=20 - frequent partitions and that may be comprised of more than one=20 - divergent set of protocols or protocol families. The basis for this=20 - architecture lies with that of the Interplanetary Internet, which=20 - focused primarily on the issue of deep space communication in high- - delay environments. We expect the DTN architecture described here to=20 - be utilized in various operational environments, including those=20 - subject to disruption and disconnection and those with high-delay;=20 - the case of deep space is one specialized example of these, and is=20 - being pursued as a specialization of this architecture (See [IPN01]=20 - and [SB03] for more details).=20 - =20 - Other networks to which we believe this architecture applies include=20 - sensor-based networks using scheduled intermittent connectivity,=20 - terrestrial wireless networks that cannot ordinarily maintain end-to- - end connectivity, satellite networks with moderate delays and=20 - periodic connectivity, and underwater acoustic networks with moderate=20 - delays and frequent interruptions due to environmental factors. A=20 - DTN tutorial [FW03], aimed at introducing DTN and the types of=20 - networks for which it is designed, is available to introduce new=20 - readers to the fundamental concepts and motivation. More technical=20 - descriptions may be found in [KF03], [JFP04], [JDPF05] and [WJMF05].=20 - =20 - We define an end-to-end message-oriented overlay called the "bundle=20 - layer" that exists at a layer above the transport (or other) layers=20 - of the networks on which it is hosted and below applications. Devices=20 - implementing the bundle layer are called DTN nodes. The bundle layer=20 - forms an overlay that employs persistent storage to help combat=20 - network interruption. It includes a hop-by-hop transfer of reliable=20 - delivery responsibility and optional end-to-end acknowledgement. It=20 - also includes a number of diagnostic and management features. For=20 - interoperability, it uses a flexible naming scheme (based on Uniform=20 - Resource Identifiers [RFC3986]) capable of encapsulating different=20 - naming and addressing schemes in the same overall naming syntax. It=20 - also has a basic security model, optionally enabled, aimed at=20 - protecting infrastructure from unauthorized use.=20 - =20 - The bundle layer provides functionality similar to the internet layer=20 - of gateways described in the original ARPANET/Internet designs=20 - [CK74]. It differs from ARPANET gateways, however, because it is=20 - layer-agnostic and is focused on virtual message forwarding rather=20 - than packet switching. However, both generally provide=20 - interoperability between underlying protocols specific to one=20 - environment and those protocols specific to another, and both provide=20 - a store-and-forward forwarding service (with the bundle layer=20 - employing persistent storage for its store and forward function).=20 - =20 - In a sense, the DTN architecture provides a common method for=20 - interconnecting heterogeneous gateways or proxies that employ store- -=20 -Cerf, et al. Expires February 2007 [Page 5]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - and-forward message routing to overcome communication disruptions. =20 - It provides services similar to electronic mail, but with enhanced=20 - naming, routing, and security capabilities. Nodes unable to support=20 - the full capabilities required by this architecture may be supported=20 - by application layer proxies acting as DTN applications.=20 - =20 -2 Why an Architecture for Delay-Tolerant Networking?=20 - =20 - Our motivation for pursuing an architecture for delay tolerant=20 - networking stems from several factors. These factors are summarized=20 - below; much more detail on their rationale can be explored in [SB03],=20 - [KF03], and [DFS02].=20 - =20 - The existing Internet protocols do not work well for some=20 - environments, due to some fundamental assumptions built into the=20 - Internet architecture:=20 - =20 - - that an end-to-end path between source and destination exists for=20 - the duration of a communication session =20 - - (for reliable communication) that retransmissions based on timely=20 - and stable feedback from data receivers is an effective means for=20 - repairing errors=20 - - that end-to-end loss is relatively small=20 - - that all routers and end stations support the TCP/IP protocols=20 - - that applications need not worry about communication performance=20 - - that endpoint-based security mechanisms are sufficient for meeting=20 - most security concerns=20 - - that packet switching is the most appropriate abstraction for=20 - interoperability and performance=20 - - that selecting a single route between sender and receiver is=20 - sufficient for achieving acceptable communication performance=20 - =20 - The DTN architecture is conceived to relax most of these assumptions,=20 - based on a number of design principles that are summarized here (and=20 - further discussed in [KF03]):=20 - =20 - - Use variable-length (possibly long) messages (not streams or=20 - limited-sized packets) as the communication abstraction to help=20 - enhance the ability of the network to make good scheduling/path=20 - selection decisions when possible.=20 - - Use a naming syntax that supports a wide range of naming and=20 - addressing conventions to enhance interoperability.=20 - - Use storage within the network to support store-and-forward=20 - operation over multiple paths, and over potentially long=20 - timescales (i.e. to support operation in environments where many=20 - and/or no end-to-end paths may ever exist); do not require end-to- - end reliability.=20 - - Provide security mechanisms that protect the infrastructure from=20 - unauthorized use by discarding traffic as quickly as possible.=20 - - Provide coarse-grained classes of service, delivery options, time=20 - stamps and an expression of the useful life for data to further=20 - allow the network to better serve the needs of applications.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 6]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - In addition to the principles guiding the design of the bundle layer=20 - itself, its use is also guided by a few application design=20 - principles:=20 - =20 - - Applications should minimize the number of round-trip exchanges.=20 - - Applications should cope with restarts after failure while network=20 - transactions remain pending.=20 - =20 - These issues are discussed in further detail in Section 5.=20 - =20 -3 DTN Architectural Description =20 - =20 - The previous section summarized the design principles that guide the=20 - definition of the DTN architecture. This section presents a=20 - description of the major features of the architecture resulting from=20 - design decisions guided by the aforementioned design principles.=20 - =20 -3.1 Virtual Message Switching using Store-and-Forward Operation=20 - =20 - A DTN-enabled application sends messages, also called Application=20 - Data Units or ADUs [CT90] of arbitrary length, subject to any=20 - implementation limitations. The relative order of messages might not=20 - be preserved. ADUs are transformed into one or more protocol data=20 - units called "bundles" containing two or more "blocks" of data. Each=20 - block may contain ADU data or other information used to deliver=20 - bundles to their destination(s). Blocks serve the purpose of holding=20 - information typically found in the header or payload portion of=20 - protocol data units in other protocol architectures. ADUs are=20 - typically sent by and delivered to applications in complete units;=20 - bundles may be split up ("fragmented") into multiple constituent=20 - bundles (also called "fragments" or "bundle fragments") during=20 - transmission. =20 - =20 - Bundle sources and destinations are identified by (variable-length)=20 - Endpoint Identifiers (EIDs, described below), which identify the=20 - original sender and final destination(s) of bundles, respectively. =20 - Bundles also contain a "report-to" EID used when special operations=20 - are requested to direct diagnostic output to an arbitrary entity=20 - (e.g., other than the source).=20 - =20 - While IP networks are based on "store-and-forward" operation, there=20 - is an assumption that the "storing" will not persist for more than a=20 - modest amount of time, on the order of the queuing and transmission=20 - delay. In contrast, the DTN architecture does not expect that=20 - network links are always available or reliable, and instead expects=20 - that nodes may choose to store bundles for some time. We anticipate=20 - that most DTN nodes will use some form of persistent storage for this=20 - -- disk, flash memory, etc., and that stored bundles will survive=20 - system restarts. =20 - =20 - A message-oriented abstraction provides bundle layer routing with a- - priori knowledge of the size and performance requirements of=20 - requested data transfers. When there is a significant amount of=20 -=20 -Cerf, et al. Expires February 2007 [Page 7]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - queuing that can occur in the network (as is the case in the DTN=20 - version of store-and-forward), the advantage provided by knowing this=20 - information may be significant for making scheduling and path=20 - selection decisions [JFP04]. An alternative abstraction (i.e. of=20 - stream-based delivery) would make such scheduling much more=20 - difficult. Although packets provide some of the same benefits as=20 - bundles, larger aggregates provide a way for the network to apply=20 - scheduling and buffer management to entire units of data that are=20 - useful to applications.=20 - =20 - An essential element of the ADU-based style of operation for=20 - networking is that bundles have a place to wait in a queue until a=20 - communication opportunity ("contact") is available. This highlights=20 - the following assumptions:=20 - =20 - 1. that storage is available and well-distributed throughout the=20 - network, =20 - 2. that storage is sufficiently persistent and robust to store=20 - bundles until forwarding can occur, and=20 - 3. (implicitly) that this 'store-and-forward' model is a better=20 - choice than attempting to effect continuous connectivity or other=20 - alternatives.=20 - =20 - For a network to effectively support the DTN architecture, these=20 - assumptions must be considered and must be found to hold.=20 - =20 -=20 -3.2 Nodes=20 - =20 - A DTN node (or simply "node" in this document) is an engine for=20 - sending and receiving bundles-- an implementation of the bundle=20 - layer. Applications utilize DTN nodes to send or receive ADUs=20 - carried in bundles (or act as report-to destinations for diagnostic=20 - information carried in bundles). Nodes are identified by one or more=20 - Endpoint Identifiers (EIDs).=20 - =20 -3.3 Endpoint Identifiers (EIDs) and Registrations=20 - =20 - An Endpoint Identifier (EID) is a name, using the general syntax of=20 - URIs (see below), that refers to a set of DTN nodes. Such a set is=20 - called a "DTN endpoint". A node is able to determine from an EID the=20 - corresponding endpoint's "minimum reception group" (MRG). The MRG of=20 - an endpoint is the set of nodes "in" the endpoint to which a bundle=20 - must be delivered in order to complete a data transfer. In=20 - particular, the MRG of an endpoint may refer to one node (unicast),=20 - one of a group of nodes (anycast), or all of a group of nodes=20 - (multicast and broadcast). A single node may be in the MRG of=20 - multiple endpoints and an endpoint may have an MRG with cardinality=20 - greater than one (e.g., for anycast and multicast delivery, see=20 - below). Each node is also required to have at least one EID that=20 - uniquely identifies it.=20 - =20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 8]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - Applications send ADUs destined for an EID, and may arrange for=20 - bundles sent to a particular EID to be delivered to them. Depending=20 - on the construction of the EID being used (see below), there may be a=20 - provision for wildcarding some portion of an EID, which is often=20 - useful for diagnostic and routing purposes.=20 - =20 - An application's desire to receive traffic destined for a particular=20 - EID is called a "registration", and in general is maintained=20 - persistently by a DTN node. This allows application registration=20 - information to survive application and operating system restarts.=20 - =20 - An application's attempt to establish a registration is not=20 - guaranteed to succeed. For example, an application could request to=20 - register itself as a member of an endpoint by specifying an Endpoint=20 - ID that is uninterpretable or unavailable to the DTN node servicing=20 - the request. Such requests are likely to fail.=20 - =20 -3.3.1 URI Schemes=20 - =20 - Each Endpoint ID is expressed syntactically as a Uniform Resource=20 - Identifier (URI) [RFC3986]. The URI syntax has been designed as a=20 - way to express names or addresses for a wide range of purposes, and=20 - is therefore useful for constructing DTN names.=20 - =20 - In URI terminology, each URI begins with a scheme name. The scheme=20 - name is an element of the set of globally-managed scheme names=20 - maintained by IANA [ISCHEMES]. Lexically following the scheme name=20 - in a URI is a series of characters constrained by the syntax defined=20 - by the scheme. This portion of the URI is called the scheme-specific=20 - part (SSP), and can be quite general. (See, as one example, the URI=20 - scheme for SNMP [RFC4088]). Note that scheme-specific syntactical=20 - and semantic restrictions may be more constraining than the basic=20 - rules of RFC 3986. Section 3.1 of RFC 3986 provides guidance on the=20 - syntax of scheme names.=20 - =20 - URI schemes are a key concept in the DTN architecture, and evolved=20 - from an earlier concept called regions, which were tied more closely=20 - to assumptions of the network topology. Using URIs, significant=20 - flexibility is attained in the structuring of EIDs. They might, for=20 - example, be constructed based on DNS names, or might look like=20 - "expressions of interest" or forms of database-like queries as in a=20 - directed diffusion-routed network [IGE00] or in intentional naming=20 - [WSBL99]. As names, EIDs are not required to be related to routing=20 - or topological organization. Such a relationship is not prohibited,=20 - however, and in some environments using EIDs this way may be=20 - advantageous.=20 - =20 - A single EID may refer to more than one DTN node, as suggested above. =20 - It is the responsibility of a scheme designer to define how to=20 - interpret the SSP of an EID so as to determine whether it refers to a=20 - unicast, multicast or anycast set of nodes. See Section 3.4 for more=20 - details.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 9]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - URIs are constructed based on rules specified in RFC 3986, using the=20 - US-ASCII character set. However, note this excerpt from RFC 3986,=20 - section 1.2.1, on dealing with characters that cannot be represented=20 - by US-ASCII: "Percent-encoded octets (Section 2.1) may be used=20 - within a URI to represent characters outside the range of the US- - ASCII coded character set if this representation is allowed by the=20 - scheme or by the protocol element in which the URI is referenced.=20 - Such a definition should specify the character encoding used to map=20 - those characters to octets prior to being percent-encoded for the=20 - URI".=20 - =20 - =20 -3.3.2 Late Binding=20 - =20 - Binding means interpreting the SSP of an EID for the purpose of=20 - carrying an associated bundle to its destination(s) over some=20 - underlying protocols. For example, binding might require mapping an=20 - EID to a lower-layer address or an alternate EID in a fashion similar=20 - to DNS name-to-address mappings in the Internet. "Late binding" means=20 - that this interpretation may take place relatively late in the=20 - delivery process of a bundle. Late binding is in contrast with=20 - typical Internet communication sessions in which a DNS resolution=20 - takes place prior to data exchange at the IP layer. Such a=20 - circumstance would be considered "early binding" because the name-to- - address translation is performed prior to data being sent into the=20 - network.=20 - =20 - In a frequently-disconnected network, late binding may be=20 - advantageous because the transit time of a bundle may exceed the=20 - validity time of a binding. Furthermore, use of name-based (URI)=20 - routing with late binding may reduce the amount of administrative=20 - (mapping) information that must propagate through the network, and=20 - may also limit the scope of mapping synchronization requirements to a=20 - local topological neighborhood of its origin.=20 - =20 -3.4 Naming of Groups=20 - =20 - As mentioned above, an EID may refer to one node or a group of DTN=20 - nodes. When referring to a group of nodes, the delivery semantics=20 - may be of either the anycast or multicast variety (broadcast is=20 - considered to be of the multicast variety). For anycast group=20 - delivery, an ADU is delivered to one node among a group of=20 - potentially many nodes, and for multicast delivery it is intended to=20 - be delivered to all of them, subject to the normal DTN quality of=20 - service and maximum useful lifetime semantics. Group join operations=20 - are initiated at receivers.=20 - =20 - Multicast group delivery in a DTN presents an unfamiliar issue with=20 - respect to group membership. In relatively low-delay networks, such=20 - as the Internet, nodes may be considered to be part of the group if=20 - they have expressed interest to join it "recently". In a DTN,=20 - however, nodes may wish to receive data sent to a group during an=20 - interval of time earlier than when they are actually able to receive=20 -=20 -Cerf, et al. Expires February 2007 [Page 10]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - it [ZAZ05]. More precisely, an application expresses its desire to=20 - receive data sent to EID e at time t. Prior to this, during the=20 - interval [t0, t1], t > t1, data may have been generated for group e. =20 - For the application to receive any of this data, the data must be=20 - available a potentially long time after senders have ceased sending=20 - to the group. Thus, the data may need to be stored within the=20 - network in order to support temporal group semantics of this kind. =20 - How to design and implement this remains a research issue, as it is=20 - likely to be at least as hard as problems related to reliable=20 - multicast.=20 - =20 -3.5 Priority Classes=20 - =20 - The DTN architecture offers *relative* measures of priority (low,=20 - medium, high) for delivering traffic. These priorities differentiate=20 - traffic based upon an application's desire to affect the delivery=20 - urgency for ADUs. =20 - =20 - The (U.S. or similar) Postal Service provides a strong metaphor for=20 - the priority classes offered by the DTN architecture. Traffic is=20 - generally not interactive and is often one-way. There are generally=20 - no strong guarantees of timely delivery, yet there are some forms of=20 - class of service, reliability, and security.=20 -=20 - We have currently defined three relative priority classes. These=20 - priority classes typically imply some relative scheduling=20 - prioritization among bundles in queue at a sender:=20 - =20 - - Bulk - Bulk bundles are shipped on a "least effort" basis. No=20 - bundles of this class will be shipped until all bundles of other=20 - classes bound for the same destination and originating from the=20 - same source have been shipped. =20 - - Normal - Normal class bundles are shipped prior to any bulk class=20 - bundles and are otherwise the same as bulk bundles.=20 - - Expedited - Expedited bundles, in general, are shipped prior to=20 - bundles of other classes and are otherwise the same. =20 - =20 - Applications specify their requested priority class and data lifetime=20 - (see below) for each ADU they send. This information, coupled with=20 - policy applied at DTN nodes that forward messages and routing=20 - algorithms in use, affects the overall likelihood and timeliness of=20 - ADU delivery.=20 - =20 - The priority class of a bundle is only required to relate to other=20 - bundles from the same source. This means that a high priority bundle=20 - from one source may not be delivered faster (or with some other=20 - superior quality of service) than a medium priority bundle from a=20 - different source. It does mean that a high priority bundle from one=20 - source will be handled preferentially to a lower priority bundle sent=20 - from the same source.=20 - =20 - Depending on a particular DTN node's forwarding/scheduling policy,=20 - priority may or may not be enforced across different sources. That=20 -=20 -Cerf, et al. Expires February 2007 [Page 11]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - is, in some DTN nodes, expedited bundles might always be sent prior=20 - to any bulk bundles, irrespective of source. Many variations are=20 - possible.=20 - =20 -3.6 Postal-Style Delivery Options and Administrative Records=20 - =20 - Continuing with the postal analogy of message delivery, the DTN=20 - architecture supports several delivery options that may be selected=20 - by an application when it requests the transmission of an ADU. In=20 - addition, the architecture defines two types of administrative=20 - records: "status reports" and "signals". These records are bundles=20 - that provide information about the delivery of other bundles, and are=20 - used in conjunction with the delivery options.=20 - =20 -3.6.1 Delivery Options=20 - =20 - We have currently defined eight basic delivery options. Applications=20 - sending an ADU may request any combination of the following:=20 - =20 - - Custody Transfer Requested - requests a bundle be delivered with=20 - enhanced reliability using custody transfer procedures. A bundle=20 - will be transmitted by the bundle layer using reliable transfer=20 - protocols (if available), and the responsibility for reliable=20 - delivery of the bundle to its destination(s) may move among one or=20 - more "custodians" in the network. This capability is described in=20 - more detail in Section 3.10.=20 - =20 - - Source Node Custody Acceptance Required - requires the source DTN=20 - node to provide custody transfer for the bundle being sent. If=20 - custody transfer is not available at the source when this delivery=20 - option is requested, the requested transmission fails. This=20 - provides a means for applications to insist that the source DTN=20 - node take custody of the bundle.=20 - =20 - - Report When Bundle Received - requests a Bundle Reception Status=20 - Report be generated when the subject bundle arrives at a DTN node.=20 - =20 - - Report When Bundle Custody Accepted - requests a Custody=20 - Acceptance Status Report be generated when the subject bundle has=20 - been accepted using custody transfer.=20 - =20 - - Report When Bundle Forwarded - requests a Bundle Forwarding Status=20 - Report be generated when the subject bundle departs a DTN node=20 - that has forwarded it. =20 - =20 - - Report When Bundle Delivered - requests a Bundle Delivery Status=20 - Report be generated when the bundle reaches its intended=20 - recipient(s). This request is also known as "return-receipt".=20 - =20 - - Report When Bundle Deleted - requests a Bundle Deletion Status=20 - Report be generated when the subject bundle is deleted at a DTN=20 - node.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 12]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - - Report When Bundle Acknowledged by Application - requests an=20 - Acknowledgement Status Report be generated when the subject bundle=20 - is acknowledged by a receiving application. This only happens by=20 - action of the receiving application, and differs from the Bundle=20 - Delivery Status Report. It is intended for cases where the=20 - application may be acting as a form of application layer gateway=20 - and wishes to indicate the status of a protocol operation external=20 - to DTN back to the requesting source.=20 - =20 - If the security procedures defined in [DTNSEC] are also enabled, then=20 - three additional delivery options become available:=20 - =20 - - Confidentiality Required - requires a bundle's data be made secret=20 - from parties other than the source and the members of the=20 - destination EID.=20 - =20 - - Authentication Required - requires all non-mutable fields in the=20 - bundle blocks (i.e., those which do not change as the bundle is=20 - forwarded) be made strongly verifiable (i.e. cryptographically=20 - strong). This protects several fields, including the source and=20 - destination EIDs and the bundle's data.=20 - =20 - - Error Detection Required - requires modifications to a bundle's=20 - non-mutable fields be made detectable with high probability at=20 - each destination. =20 - =20 - =20 -3.6.2 Bundle Status Reports and Custody Signals=20 - =20 - Bundle Status Reports (BSRs) provide information and diagnostic=20 - responses in DTN and correspond (approximately) to the ICMP protocol=20 - in IP [RFC792]. In ICMP, however, messages are returned to the=20 - source. In DTN, they are instead directed to the report-to EID,=20 - which might differ from the source's EID. BSRs are sent as bundles=20 - with a source EID set to one of the EIDs associated with the DTN node=20 - generating the BSR. In some cases, arrival of a single bundle or=20 - bundle fragment may elicit multiple BSRs (e.g., in the case where a=20 - bundle is replicated for multicast forwarding). Many of the BSRs are=20 - used in forming responses to the delivery options discussed in the=20 - previous sub-section.=20 - =20 - The following BSRs are currently defined (also see [BSPEC] for more=20 - details):=20 - =20 - - Bundle Reception - sent when a bundle arrives at a DTN node=20 - =20 - - Custody Acceptance - sent when a node has accepted custody of a=20 - bundle with the Custody Transfer Requested option set=20 - =20 - - Bundle Forwarded - sent when a bundle containing a Report When=20 - Bundle Forwarded option departs from a DTN node after having been =20 - forwarded=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 13]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - - Bundle Delivery - sent from a final recipient's (destination) node=20 - when a bundle containing a Report When Bundle Delivered option is=20 - consumed by an application=20 - =20 - - Bundle Deletion - sent from a DTN node when a bundle containing a=20 - Report When Bundle Deleted option is discarded. This can happen=20 - for several reasons, such as expiration.=20 - =20 - - Acknowledged by application - sent from a DTN node when a bundle=20 - containing an Application Acknowledgment option has been processed=20 - by an application. This generally involves specific action on the=20 - receiving application's part.=20 - =20 - In addition to the status reports, a signal is currently defined to=20 - indicate the status of a custody transfer. These are sent to the=20 - current-custodian EID contained in an arriving bundle:=20 - =20 - - Custody Signal - indicates that custody has been successfully=20 - transferred. This signal appears as a Boolean indicator, and may=20 - therefore indicate either a successful or a failed custody=20 - transfer attempt.=20 - =20 - The BSRs must reference a received bundle. This is accomplished by a=20 - method for uniquely identifying bundles based on a transmission=20 - timestamp and sequence number discussed in Section 3.12.=20 - =20 -3.7 Primary Bundle Fields =20 - =20 - The bundles carried between and among DTN nodes obey a standard=20 - bundle protocol specified in [BSPEC]. Here we provide an overview of=20 - most of the fields carried with every bundle. The protocol is=20 - designed with a mandatory primary block, an optional payload block=20 - (which contains the ADU data itself), and a set of optional extension=20 - blocks. Blocks may be cascaded in a way similar to extension headers=20 - in IPv6. The following selected fields are all present in the=20 - primary block, and therefore are present for every bundle and=20 - fragment:=20 -=20 - - Creation Timestamp - a concatenation of the bundle's creation time=20 - and a monotonically increasing sequence number such that the=20 - creation timestamp is guaranteed to be unique for each ADU=20 - originating from the same source. The creation timestamp is based=20 - on the time-of-day an application requested an an ADU to be sent=20 - (not when the corresponding bundle(s) are sent into the network). =20 - DTN nodes are assumed to have a basic time synchronization=20 - capability (see Section 3.11).=20 - =20 - - Lifespan - the time-of-day at which the message is no longer=20 - useful. If a bundle is stored in the network (including the=20 - source's DTN node) when its lifespan is reached, it may be=20 - discarded. The lifespan of a bundle is expressed as an offset=20 - relative to its creation time.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 14]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - - Class of Service Flags - indicates the delivery options and=20 - priority class for the bundle. Priority classes may be one of=20 - bulk, normal, or expedited. See Section 3.6.1.=20 - =20 - - Source EID - EID of the source (the first sender)=20 -=20 - - Destination EID - EID of the destination (the final intended=20 - recipient(s))=20 -=20 - - Report-To Endpoint ID - an EID identifying where reports (return- - receipt, route-tracing functions) should be sent. This may or may=20 - not identify the same node as the Source EID.=20 - =20 - - Custodian EID - EID of the current custodian of a bundle (if any)=20 - =20 - The payload block indicates information about the contained payload=20 - (e.g. its length) and, somewhat unusually, includes the payload=20 - itself. In addition to the fields found in the primary and payload=20 - blocks, each bundle may have fields in additional blocks carried with=20 - each bundle. See [BSPEC] for additional details.=20 - =20 -3.8 Routing and Forwarding=20 -=20 - The DTN architecture provides a framework for routing and forwarding=20 - at the bundle layer for unicast, anycast, and multicast messages. =20 - Because nodes in a DTN network might be interconnected using more=20 - than one type of underlying network technology, a DTN network is best=20 - described abstractly using a *multigraph* (a graph where vertices may=20 - be interconnected with more than one edge). Edges in this graph are,=20 - in general, time-varying with respect to their delay and capacity and=20 - directional because of the possibility of one-way connectivity. When=20 - an edge has zero capacity, it is considered to not be connected.=20 - =20 - Because edges in a DTN graph may have significant delay, it is=20 - important to distinguish where time is measured when expressing an=20 - edge's capacity or delay. We adopt the convention of expressing=20 - capacity and delay as functions of time where time is measured at the=20 - point where data is inserted into a network edge. For example,=20 - consider an edge having capacity C(t) and delay D(t) at time t. If B=20 - bits are placed in this edge at time t, they completely arrive by=20 - time t + D(t) + (1/C(t))*B. We assume C(t) and B(t) does not change=20 - significantly during the interval [t, t+D(t)+(1/C(t))*B]. =20 - =20 - Because edges may vary between positive and zero capacity, it is=20 - possible to describe a period of time (interval) during which the=20 - capacity is strictly positive, and the delay and capacity can be=20 - considered to be constant [AF03]. This period of time is called a=20 - "contact". In addition, the product of the capacity and the interval=20 - is known as a contact's "volume". If contacts and their volumes are=20 - known ahead of time, intelligent routing and forwarding decisions can=20 - be made (optimally for small networks) [JFP04]. Optimally using a=20 - contact's volume, however, requires the ability to divide large ADUs=20 - -=20 -Cerf, et al. Expires February 2007 [Page 15]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - and bundles into smaller routable units. This is provided by DTN=20 - fragmentation (see Section 3.9).=20 - =20 - When delivery paths through a DTN graph are lossy or contact=20 - intervals and volumes are not known precisely ahead of time, routing=20 - computations become especially challenging. How to handle these=20 - situations is an active area of work in the (emerging) research area=20 - of delay tolerant networking.=20 - =20 -3.8.1 Types of Contacts=20 - =20 - Contacts typically fall into one of several categories, based largely=20 - on the predictability of their performance characteristics and=20 - whether some action is required to bring them into existence. To=20 - date, the following major types of contacts have been defined:=20 - =20 - Persistent Contacts=20 - =20 - Persistent contacts are always available (i.e., no connection- - initiation action is required to instantiate a persistent contact). =20 - An 'always-on' Internet connection such as a DSL or Cable Modem=20 - connection would be representatives of this class.=20 - =20 - On-Demand Contacts=20 - =20 - On-Demand contacts require some action in order to instantiate, but=20 - then function as persistent contacts until terminated. A dial-up=20 - connection is an example of an On-Demand contact (at least, from the=20 - viewpoint of the dialer; it may be viewed as an Opportunistic Contact=20 - - below - from the viewpoint of the dial-up service provider).=20 - =20 - Intermittent - Scheduled Contacts=20 - =20 - A scheduled contact is an agreement to establish a contact at a=20 - particular time, for a particular duration. An example of a=20 - scheduled contact is a link with a low-earth orbiting satellite. A=20 - node's list of contacts with the satellite can be constructed from=20 - the satellite's schedule of view times, capacities and latencies. =20 - Note that for networks with substantial delays, the notion of the=20 - "particular time" is delay-dependent. For example, a single=20 - scheduled contact between Earth and Mars would not be at the same=20 - instant in each location, but would instead be offset by the (non- - negligible) propagation delay.=20 - =20 - Intermittent - Opportunistic Contacts=20 - =20 - Opportunistic contacts are not scheduled, but rather present=20 - themselves unexpectedly. For example, an unscheduled aircraft flying=20 - overhead and beaconing, advertising its availability for=20 - communication, would present an opportunistic contact. Another type=20 - of opportunistic contact might be via an infrared or Bluetooth=20 - communication link between a personal digital assistant (PDA) and a=20 - kiosk in an airport concourse. The opportunistic contact begins as=20 -=20 -Cerf, et al. Expires February 2007 [Page 16]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - the PDA is brought near the kiosk, lasting an undetermined amount of=20 - time (i.e., until the link is lost or terminated).=20 - =20 - Intermittent - Predicted Contacts=20 - =20 - Predicted contacts are based on no fixed schedule, but rather are=20 - predictions of likely contact times and durations based on a history=20 - of previously observed contacts or some other information. Given a=20 - great enough confidence in a predicted contact, routes may be chosen=20 - based on this information. This is an active research area, and a=20 - few approaches having been proposed [LFC05].=20 - =20 -3.9 Fragmentation and Reassembly=20 - =20 - DTN fragmentation and reassembly is designed to improve the=20 - efficiency of bundle transfers by ensuring that contact volumes are=20 - fully utilized and by avoiding re-transmission of partially-forwarded=20 - bundles. There are two forms of DTN fragmentation/reassembly:=20 - =20 - Proactive Fragmentation =20 - =20 - A DTN node may divide a block of application data into multiple=20 - smaller blocks and transmit each such block as an independent=20 - bundle. In this case the *final destination(s)* are responsible=20 - for extracting the smaller blocks from incoming bundles and=20 - reassembling them into the original larger bundle. This approach=20 - is called proactive fragmentation because it is used primarily when=20 - contact volumes are known (or predicted) in advance.=20 - =20 - Reactive Fragmentation=20 - =20 - DTN nodes sharing an edge in the DTN graph may fragment a bundle=20 - cooperatively when a bundle is only partially transferred. In this=20 - case, the receiving bundle layer modifies the incoming bundle to=20 - indicate it is a fragment, and forwards it normally. The previous- - hop sender may learn that only a portion of the bundle was=20 - delivered to the next hop, and send the remaining portion(s) when=20 - subsequent contacts become available (possibly to different next- - hops if routing changes). This is called reactive fragmentation=20 - because the fragmentation process occurs after an attempted=20 - transmission has taken place.=20 - =20 - The reactive fragmentation capability is not required to be available=20 - in every DTN implementation. It presents significant challenges with=20 - respect to handling digital signatures and authentication codes on=20 - messages because a signed message may be only partially received,=20 - thereby causing most message authentication codes to fail. When DTN=20 - security is present and enabled, it may therefore be necessary to=20 - proactively fragment large bundles into smaller units that are more=20 - convenient for digital signatures.=20 - =20 - Even if reactive fragmentation is not present in an implementation,=20 - the ability to re-assemble fragments at a destination is required in=20 -=20 -Cerf, et al. Expires February 2007 [Page 17]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - order to support DTN fragmentation. Furthermore, for contacts with=20 - volumes that are small compared to typical bundle sizes, some=20 - incremental delivery approach must be used (e.g. checkpoint/restart)=20 - to prevent data delivery livelock. Reactive fragmentation is one=20 - such approach, but other protocol layers could potentially handle=20 - this issue as well.=20 -=20 -3.10 Reliability and Custody Transfer=20 - =20 - The most basic service provided by the bundle layer is=20 - unacknowledged, prioritized (but not guaranteed) unicast message=20 - delivery. It also provides two options for enhancing delivery=20 - reliability: end-to-end acknowledgments and custody transfer. =20 - Applications wishing to implement their own end-to-end message=20 - reliability mechanisms are free to utilize the acknowledgment. The=20 - custody transfer feature of the DTN architecture only specifies a=20 - coarse-grained retransmission capability, described next.=20 - =20 - Transmission of bundles with the Custody Transfer Requested option=20 - specified generally involves moving the responsibility for reliable=20 - delivery of an ADU's bundles among different DTN nodes in the=20 - network. For unicast delivery, this will typically involve moving=20 - bundles "closer" (in terms of some routing metric) to their ultimate=20 - destination(s), and re-transmitting when necessary. The nodes=20 - receiving these bundles along the way (and agreeing to accept the=20 - reliable delivery responsibility) are called "custodians". The=20 - movement of a bundle (and its delivery responsibility) from one node=20 - to another is called a "custody transfer". It is analogous to a=20 - database commit transaction [FHM03]. The exact meaning and design of=20 - custody transfer for multicast and anycast delivery remains to be=20 - fully explored.=20 - =20 - Custody transfer allows the source to delegate retransmission=20 - responsibility and recover its retransmission-related resources=20 - relatively soon after sending a bundle (on the order of the minimum=20 - round-trip time to the first bundle hop(s)). Not all nodes in a DTN=20 - are required by the DTN architecture to accept custody transfers, so=20 - it is not a true 'hop-by-hop' mechanism. For example, some nodes may=20 - have sufficient storage resources to sometimes act as custodians, but=20 - may elect to not offer such services when congested or running low on=20 - power.=20 - =20 - The existence of custodians can alter the way DTN routing is=20 - performed. In some circumstances, it may be beneficial to move a=20 - bundle to a custodian as quickly as possible even if the custodian is=20 - further away (in terms of distance, time or some routing metric) from=20 - the bundle's final destination(s) than some other reachable node. =20 - Designing a system with this capability involves constructing more=20 - than one routing graph, and is an area of continued research.=20 - =20 - Custody transfer in DTN not only provides a method for tracking=20 - bundles that require special handling and identifying DTN nodes that=20 - participate in custody transfer, it also provides a (weak) mechanism=20 -=20 -Cerf, et al. Expires February 2007 [Page 18]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - for enhancing the reliability of message delivery. Generally=20 - speaking, custody transfer relies on underlying reliable delivery=20 - protocols of the networks that it operates over to provide the=20 - primary means of reliable transfer from one bundle node to the next=20 - (set). However, when custody transfer is requested, the bundle layer=20 - provides an additional coarse-grained timeout and retransmission=20 - mechanism and an accompanying (bundle-layer) custodian-to-custodian=20 - acknowledgment signaling mechanism. When an application does *not*=20 - request custody transfer, this bundle layer timeout and=20 - retransmission mechanism is typically not employed, and successful=20 - bundle layer delivery depends solely on the reliability mechanisms of=20 - the underlying protocols. =20 - =20 - When a node accepts custody for a bundle that contains the Custody=20 - Transfer Requested option, a Custody Transfer Accepted Signal is sent=20 - by the bundle layer to the Current Custodian EID contained in the=20 - primary bundle block. In addition, the Current Custodian EID is=20 - updated to contain one of the forwarding node's (unicast) EIDs before=20 - the bundle is forwarded.=20 - =20 - When an application requests an ADU to be delivered with custody=20 - transfer, the request is advisory. In some circumstances, a source=20 - of a bundle for which custody transfer has been requested may not be=20 - able to provide this service. In such circumstances, the subject=20 - bundle may traverse multiple DTN nodes before it obtains a custodian. =20 - Bundles in this condition are specially marked with their Current=20 - Custodian EID field set to a null endpoint. In cases where=20 - applications wish to require the source to take custody of the bundle=20 - they may supply the Source Node Custody Acceptance Required delivery=20 - option. This may be useful to applications that desire a continuous=20 - "chain" of custody or that wish to exit after being ensured their=20 - data is safely held in a custodian.=20 - =20 - In a DTN network where one or more custodian-to-custodian hops are=20 - strictly one directional (and cannot be reversed), the DTN custody=20 - transfer mechanism will be affected over such hops due to the lack of=20 - any way to receive a custody signal (or any other information) back=20 - across the path, resulting in the expiration of the bundle at the=20 - ingress to the one-way hop. This situation does not necessarily mean=20 - the bundle has been lost; nodes on the other side of the hop may=20 - continue to transfer custody, and the bundle may be delivered=20 - successfully to its destination(s). However, in this circumstance a=20 - source that has requested to receive expiration BSRs for this bundle=20 - will receive an expiration report for the bundle, and possibly=20 - conclude (incorrectly) the bundle has been discarded and not=20 - delivered. Although this problem cannot be fully solved in this=20 - situation, a mechanism is provided to help ameliorate the seemingly=20 - incorrect information that may be reported when the bundle expires=20 - after having been transferred over a one-way hop. This is=20 - accomplished by the node at the ingress to the one-way hop reporting=20 - the existence of a known one-way path using a variant of a bundle=20 - status report. These types of reports are provided if the subject=20 - -=20 -Cerf, et al. Expires February 2007 [Page 19]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - bundle requests the report using the 'Report When Bundle Forwarded'=20 - delivery option.=20 - =20 -3.11 DTN Support for Proxies and Application Layer Gateways=20 - =20 - One of the aims of DTN is to provide a common method for=20 - interconnecting application layer gateways and proxies. In cases=20 - where existing Internet applications can be made to tolerate delays,=20 - local proxies can be constructed to benefit from the existing=20 - communication capabilities provided by DTN [S05, T02]. Making such=20 - proxies compatible with DTN reduces the burden on the proxy author=20 - from being concerned with how to implement routing and reliability=20 - management and allows existing TCP/IP-based applications to operate=20 - unmodified over a DTN-based network.=20 - =20 - When DTN is used to provide a form of tunnel encapsulation for other=20 - protocols, it can be used in constructing overlay networks comprised=20 - of application layer gateways. The application acknowledgment=20 - capability is designed for such circumstances. This provides a=20 - common way for remote application layer gateways to signal the=20 - success or failure of non-DTN protocol operations initiated as a=20 - result of receiving DTN ADUs. Without this capability, such=20 - indicators would have to implemented by applications themselves in=20 - non-standard ways.=20 - =20 -3.12 Time Stamps and Time Synchronization=20 - =20 - The DTN architecture depends on time synchronization among DTN nodes=20 - (supported by external, non-DTN protocols) for four primary purposes:=20 - bundle and fragment identification, routing with scheduled or=20 - predicted contacts, bundle expiration time computations, and=20 - application registration expiration.=20 - =20 - Bundle identification and expiration are supported by placing a=20 - creation timestamp and an explicit expiration field (expressed in=20 - seconds after the source time stamp) in each bundle . The=20 - origination time stamp on arriving bundles are made available to=20 - consuming applications by some system interface function. Each set=20 - of bundles corresponding to an ADU is required to contain a=20 - timestamp unique to the sender's EID. The concatenation of the=20 - Source EID and the creation timestamp serves as a unique identifier=20 - for a particular ADU, and is used for a number of purposes, including=20 - custody transfer and reassembly of bundle fragments.=20 - =20 - Time is also used in conjunction with application registrations. =20 - When an application expresses its desire to receive data for a=20 - particular EID, this registration is only maintained for a finite=20 - period of time, and may be specified by the application. For=20 - multicast registrations, an application may also specify a time range=20 - or "interest interval" for its registration. In this case, traffic=20 - sent to the specified EID any time during the specified interval will=20 - eventually be delivered to the application (unless such traffic has=20 - -=20 -Cerf, et al. Expires February 2007 [Page 20]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - expired due to the expiration time provided by the application at the=20 - source or some other reason prevents such delivery).=20 - =20 -3.13 Congestion and Flow Control at the Bundle Layer=20 - =20 - The subject of congestion control and flow control at the bundle=20 - layer is one on which the authors of this document have not yet=20 - reached complete consensus. We have unresolved concerns about the=20 - efficiency and efficacy of congestion and flow control schemes=20 - implemented across long and/or highly variable delay environments,=20 - especially with the custody transfer mechanism that may require nodes=20 - to retain bundles for long periods of time. =20 - =20 - For the purposes of this document, we define "flow control" as a=20 - means of assuring that the average rate at which a sending node=20 - transmits data to a receiving node does not exceed the average rate=20 - at which the receiving node is prepared to receive data from that=20 - sender. (Note that this is a generalized notion of flow control,=20 - rather than one that applies only to end-to-end communication.) We=20 - define "congestion control" as a means of assuring that the aggregate=20 - rate at which all traffic sources inject data into a network does not=20 - exceed the maximum aggregate rate at which the network can deliver=20 - data to destination nodes over time. If flow control is propagated=20 - backward from congested nodes toward traffic sources, then the flow=20 - control mechanism can be used as at least a partial solution to the=20 - problem of congestion as well.=20 - =20 - DTN flow control decisions must be made within the bundle layer=20 - itself based on information about resources (in this case, primarily=20 - persistent storage) available within the bundle node. When storage=20 - resources become scarce, a DTN node has only a certain degree of=20 - freedom in handling the situation. It can always discard bundles=20 - which have expired-- an activity DTN nodes should perform regularly=20 - in any case. If it ordinarily is willing to accept custody for=20 - bundles, it can cease doing so. It can also discard bundles which=20 - have not expired but for which it has not accepted custody. A node=20 - must avoid discarding bundles for which it has accepted custody. =20 - Determining when a node should engage in or cease to engage in=20 - custody transfers is a resource allocation and scheduling problem of=20 - current research interest.=20 - =20 - In addition to the bundle layer mechanisms described above, a DTN=20 - node may be able to avail itself of support from lower layer=20 - protocols in affecting its own resource utilization. For example, a=20 - DTN node receiving a bundle using TCP/IP might intentionally slow=20 - down its receiving rate by performing read operations less frequently=20 - in order to reduce its offered load. This is possible because TCP=20 - provides its own flow control, so reducing the application data=20 - consumption rate could effectively implement a form of hop-by-hop=20 - flow control. Unfortunately, it may also lead to head-of-line=20 - blocking issues, depending on the nature of bundle multiplexing=20 - within a TCP connection. A protocol with more relaxed ordering=20 - -=20 -Cerf, et al. Expires February 2007 [Page 21]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - constraints (e.g. SCTP [RFC2960]) might be preferable in such=20 - circumstances.=20 - =20 - Congestion control is an ongoing research topic. =20 - =20 -3.14 Security=20 - =20 - The possibility of severe resource scarcity in some delay-tolerant=20 - networks dictates that some form of authentication and access control=20 - to the network itself is required in many circumstances. It is not=20 - acceptable for an unauthorized user to flood the network with traffic=20 - easily, possibly denying service to authorized users. In many cases=20 - it is also not acceptable for unauthorized traffic to be forwarded=20 - over certain network links at all. This is especially true for=20 - exotic, mission-critical links. In light of these considerations,=20 - several goals are established for the security component of the DTN=20 - architecture:=20 - =20 - - Promptly prevent unauthorized applications from having their data=20 - carried through the DTN=20 - - Prevent unauthorized applications from asserting control over the=20 - DTN infrastructure=20 - - Prevent otherwise authorized applications from sending bundles at a=20 - rate or class of service for which they lack permission=20 - - Promptly discard bundles that are damaged or improperly modified in=20 - transit=20 - - Promptly detect and de-authorize compromised entities=20 - =20 - Many existing authentication and access control protocols designed=20 - for operation in low-delay, connected environments may not perform=20 - well in DTNs. In particular, updating access control lists and=20 - revoking ("blacklisting") credentials may be especially difficult. =20 - Also, approaches that require frequent access to centralized servers=20 - to complete an authentication or authorization transaction are not=20 - attractive. The consequences of these difficulties include delays in=20 - the onset of communication, delays in detecting and recovering from=20 - system compromise, and delays in completing transactions due to=20 - inappropriate access control or authentication settings. =20 - =20 - To help satisfy these security requirements in light of the=20 - challenges, the DTN architecture adopts a standard but optionally=20 - deployed security architecture [DTNSEC] that utilizes hop-by-hop and=20 - end-to-end authentication and integrity mechanisms. The purpose of=20 - using both approaches is to be able to handle access control for data=20 - forwarding separately from application-layer data integrity. While=20 - the end-to-end mechanism provides authentication for a principal such=20 - as a user (of which there may be many), the hop-by-hop mechanism is=20 - intended to authenticate DTN nodes as legitimate transceivers of=20 - bundles to each-other. Note that it is conceivable to construct a=20 - DTN in which only a subset of the nodes participate in the security=20 - mechanisms, resulting in a secure DTN overlay existing atop an=20 - insecure DTN overlay. This idea is relatively new and is still being=20 - explored. =20 -=20 -Cerf, et al. Expires February 2007 [Page 22]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - =20 - In accordance with the goals listed above, DTN nodes discard traffic=20 - as early as possible if authentication or access control checks fail. =20 - This approach meets the goals of removing unwanted traffic from being=20 - forwarded over specific high-value links, but also has the associated=20 - benefit of making denial-of-service attacks considerably harder to=20 - mount more generally, as compared with conventional Internet routers. =20 - However, the obvious cost for this capability is potentially larger=20 - computation and storage overhead required at DTN nodes.=20 - =20 - For more detailed information on DTN security provisions, refer to=20 - [DTNSEC] and [DTNSOV]. =20 - =20 -4 State Management Considerations=20 - =20 - An important aspect of any networking architecture is its management=20 - of state. This section describes the state managed at the bundle=20 - layer and discusses how it is established and removed.=20 - =20 -4.1 Application Registration State=20 - =20 - In long/variable delay environments, an asynchronous application=20 - interface seems most appropriate. Such interfaces typically include=20 - methods for applications to register callback actions when certain=20 - triggering events occur (e.g. when ADUs arrive). These registrations=20 - create state information called application registration state.=20 - =20 - Application registration state is typically created by explicit=20 - request of the application, and is removed by a separate explicit=20 - request, but may also be removed by an application-specified timer=20 - (it is thus "firm" state). In most cases, there must be a provision=20 - for retaining this state across application and operating system=20 - termination/restart conditions because a client/server bundle round- - trip time may exceed the requesting application's execution time (or=20 - hosting system's uptime). In cases where applications are not=20 - automatically restarted but application registration state remains=20 - persistent, a method must be provided to indicate to the system what=20 - action to perform when the triggering event occurs (e.g. restarting=20 - some application, ignoring the event, etc.). =20 - =20 - To initiate a registration and thereby establish application=20 - registration state, an application specifies an Endpoint ID for which=20 - it wishes to receive ADUs, along with an optional time value=20 - indicating how long the registration should remain active. This=20 - operation is somewhat analogous to the bind() operation in the common=20 - sockets API.=20 - =20 - For registrations to groups (i.e., joins), a time interval may also=20 - be specified. The time interval refers to the range of origination=20 - times of ADUs sent to the specified EID. See Section 3.4 above for=20 - more details.=20 - =20 - -=20 -Cerf, et al. Expires February 2007 [Page 23]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 -4.2 Custody Transfer State=20 - =20 - Custody transfer state includes information required to keep account=20 - of bundles for which a node has taken custody, as well as the=20 - protocol state related to transferring custody for one or more of=20 - them. The accounting-related state is created when a bundle is=20 - received. Custody transfer retransmission state is created when a=20 - transfer of custody is initiated by forwarding a bundle with the=20 - custody transfer requested delivery option specified. Retransmission=20 - state and accounting state may be released upon receipt of one or=20 - more Custody Transfer Succeeded signals, indicating custody has been=20 - moved. In addition, the bundle's expiration time (possibly mitigated=20 - by local policy) provides an upper bound on the time when this state=20 - is purged from the system in the event that it is not purged=20 - explicitly due to receipt of a signal.=20 -=20 -4.3 Bundle Routing and Forwarding State=20 - =20 - As with the Internet architecture, we distinguish between routing and=20 - forwarding. Routing refers to the execution of a (possibly=20 - distributed) algorithm for computing routing paths according to some=20 - objective function (see [JFP04], for example). Forwarding refers to=20 - the act of moving a bundle from one DTN node to another. Routing=20 - makes use of routing state (the RIB, or routing information base),=20 - while forwarding makes use of state derived from routing, and is=20 - maintained as forwarding state (the FIB, or forwarding information=20 - base). The structure of the FIB and the rules for maintaining it are=20 - implementation choices. In some DTNs exchange of information used to=20 - update state in the RIB may take place on network paths distinct from=20 - those where exchange of application data takes place.=20 - =20 - The maintenance of state in the RIB is dependent on the type of=20 - routing algorithm being used. A routing algorithm may consider=20 - requested class of service and the location of potential custodians=20 - (for custody transfer, see section 3.10), and this information will=20 - tend to increase the size of the RIB. The separation between FIB and=20 - RIB is not required by this document, as these are implementation=20 - details to be decided by system implementers. The choice of routing=20 - algorithms is still under study.=20 - =20 - Bundles may occupy queues in nodes for a considerable amount of time. =20 - For unicast or anycast delivery, the amount of time is likely to be=20 - the interval between when a bundle arrives at a node and when it can=20 - be forwarded to its next hop. For multicast delivery of bundles,=20 - this could be significantly longer, up to a bundle's expiration time. =20 - This situation occurs when multicast delivery is utilized in such a=20 - way that nodes joining a group can obtain information previously sent=20 - to the group. In such cases, some nodes may act as "archivers" that=20 - provide copies of bundles to new participants that have already been=20 - delivered to other participants.=20 - =20 - - -=20 -Cerf, et al. Expires February 2007 [Page 24]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 -4.4 Security-Related State=20 -=20 - The DTN security approach described in [DTNSEC], when used, requires=20 - maintenance of state in all DTN nodes that use it. All such nodes=20 - are required to store their own private information (including their=20 - own policy and authentication material) and a block of information=20 - used to verify credentials. Furthermore, in most cases, DTN nodes=20 - will cache some public information (and possibly the credentials) of=20 - their next-hop (bundle) neighbors. All cached information has=20 - expiration times, and nodes are responsible for acquiring and=20 - distributing updates of public information and credentials prior to=20 - the expiration of the old set (in order to avoid a disruption in=20 - network service). =20 - =20 - In addition to basic end-to-end and hop-by-hop authentication, access=20 - control may be used in a DTN by one or more mechanisms such as=20 - capabilities or access control lists (ACLs). ACLs would represent=20 - another block of state present in any node that wishes to enforce=20 - security policy. ACLs are typically initialized at node=20 - configuration time and may be updated dynamically by DTN bundles or=20 - by some out of band technique. Capabilities or credentials may be=20 - revoked, requiring the maintenance of a revocation list ("black=20 - list", another form of state) to check for invalid authentication=20 - material that has already been distributed.=20 - =20 - Some DTNs may implement security boundaries enforced by selected=20 - nodes in the network, where end-to-end credentials may be checked in=20 - addition to checking the hop-by-hop credentials. (Doing so may=20 - require routing to be adjusted to ensure complete bundles pass=20 - through these points). Public information used to verify end-to-end=20 - authentication will typically be cached at these points.=20 - =20 -4.5 Policy and Configuration State=20 - =20 - DTN nodes will contain some amount of configuration and policy=20 - information. Such information may alter the behavior of bundle=20 - forwarding. Examples of policy state include the types of=20 - cryptographic algorithms and access control procedures to use if DTN=20 - security is employed, whether nodes may become custodians, what types=20 - of convergence layer and routing protocols are in use, how bundles of=20 - differing priorities should be scheduled, where and for how long=20 - bundles and other data is stored, etc.=20 - =20 -5 Application Structuring Issues=20 - =20 - DTN bundle delivery is intended to operate in a delay-tolerant=20 - fashion over a broad range of network types. This does not mean=20 - there *must* be large delays in the network; it means there *may* be=20 - very significant delays (including extended periods of disconnection=20 - between sender and intended recipient). The DTN protocols are delay=20 - tolerant, so applications using them must also be delay tolerant in=20 - order to operate effectively in environments subject to significant=20 - delay or disruption.=20 -=20 -Cerf, et al. Expires February 2007 [Page 25]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - =20 - The communication primitives provided by the DTN architecture are=20 - based on asynchronous, message-oriented communication which differs=20 - from conversational request/response communication. In general,=20 - applications should attempt to include enough information in an ADU=20 - so that it may be treated as an independent unit of work by the=20 - receiving entity. The goal is to minimize synchronous interchanges=20 - between applications that are separated by a network characterized by=20 - long and possibly highly variable delays. A single file transfer=20 - request message, for example, might include authentication=20 - information, file location information, and requested file operation=20 - (thus "bundling" this information together). Comparing this style of=20 - operation to a classic FTP transfer, one sees that the bundled model=20 - can complete in one round trip, whereas an FTP file "put" operation=20 - can take as many as eight round trips to get to a point where file=20 - data can flow [DFS02]. =20 - =20 - Delay-tolerant applications must consider additional factors beyond=20 - the conversational implications of long delay paths. For example, an=20 - application may terminate (voluntarily or not) between the time it=20 - sends a message and the time it expects a response. If this=20 - possibility has been anticipated, the application can be "re- - instantiated" with state information saved in persistent storage. =20 - This is an implementation issue, but also an application design=20 - consideration. =20 - =20 - Some consideration of delay-tolerant application design can result in=20 - applications that work reasonably well in low-delay environments, and=20 - that do not suffer extraordinarily in high or highly-variable delay=20 - environments.=20 - =20 -6 Convergence Layer Considerations for Use of Underlying Protocols=20 -=20 - Implementation experience with the DTN architecture has revealed an=20 - important architectural construct and interface for DTN nodes=20 - [DBFJHP04]. Not all underlying protocols in different protocol=20 - families provide the same exact functionality, so some additional=20 - adaptation or augmentation on a per-protocol or per-protocol-family=20 - basis may be required. This adaptation is accomplished by a set of=20 - convergence layers placed between the bundle layer and underlying=20 - protocols. The convergence layers manage the protocol-specific=20 - details of interfacing with particular underlying protocols and=20 - present a consistent interface to the bundle layer.=20 - =20 - The complexity of one convergence layer may vary substantially from=20 - another, depending on the type of underlying protocol it adapts. For=20 - example, a TCP/IP convergence layer for use in the Internet might=20 - only have to add message boundaries to TCP streams, whereas a=20 - convergence layer for some network where no reliable transport=20 - protocol exists might be considerably more complex (e.g. it might=20 - have to implement reliability, fragmentation, flow-control, etc.) if=20 - reliable delivery is to be offered to the bundle layer.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 26]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - As convergence layers implement protocols above and beyond the basic=20 - bundle protocol specified in [BSPEC], they will be defined in their=20 - own documents (in a fashion similar to the way encapsulations for IP=20 - datagrams are specified on a per-underlying-protocol basis, such as=20 - in RFC 894 [RFC894]).=20 -=20 -7 Summary =20 -=20 - The DTN architecture addresses many of the problems of heterogeneous=20 - networks that must operate in environments subject to long delays and=20 - discontinuous end-to-end connectivity. It is based on asynchronous=20 - messaging and uses postal mail as a model of service classes and=20 - delivery semantics. It accommodates many different forms of=20 - connectivity, including scheduled, predicted, and opportunistically=20 - connected links. It introduces a novel approach to end-to-end=20 - reliability across frequently partitioned and unreliable networks. =20 - It also proposes a model for securing the network infrastructure=20 - against unauthorized access. =20 - =20 - It is our belief that this architecture is applicable to many=20 - different types of challenged environments.=20 - =20 -8 Security Considerations=20 - =20 - Security is an integral concern for the design of the Delay Tolerant=20 - Network Architecture, but its use is optional. Sections 3.6.1, 3.14,=20 - and 4.4 of this document present some factors to consider for=20 - securing the DTN architecture, but separate documents [DTNSOV]and=20 - [DTNSEC] define the security architecture in much more detail.=20 -=20 -9 IANA Considerations=20 - =20 - This document specifies the architecture for Delay Tolerant=20 - Networking which uses Internet-standard URIs for its Endpoint=20 - Identifiers. URIs intended for use with DTN should be compliant with=20 - the guidelines given in [RFC3986].=20 - =20 -10 Normative References=20 - =20 - [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC=20 - 3978, March 2005.=20 - =20 - [RFC3979] Bradner, S., "Intellectual Property Rights in IETF=20 - Technology", BCP 79, RFC 3979, March 2005.=20 - =20 - [RFC3986] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource=20 - Identifier (URI): Generic Syntax", STD 66, RFC 3986, Jan 2005.=20 -=20 - =20 -11 Informative References=20 - =20 - [IPN01] http://www.ipnsig.org=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 27]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - [SB03] S. Burleigh et al, "Delay-Tolerant Networking - An Approach to=20 - Interplanetary Internet", IEEE Communications Magazine, July 2003.=20 - =20 - [FW03] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial=20 - v1.1", Wartham Associates, 2003. Available from=20 - http://www.dtnrg.org.=20 - =20 - [KF03] K. Fall, "A Delay-Tolerant Network Architecture for Challenged=20 - Internets", Proceedings SIGCOMM, Aug 2003. =20 - =20 - [JFP04] S. Jain, K. Fall, R. Patra, "Routing in a Delay Tolerant=20 - Network", Proceedings SIGCOMM, Aug/Sep 2004.=20 -=20 - [DFS02] R. Durst, P. Feighery, K. Scott, "Why not use the Standard=20 - Internet Suite for the Interplanetary Internet?", MITRE White Paper,=20 - 2002. Available from http://www.ipnsig.org/reports/TCP_IP.pdf =20 - =20 - [CK74] V. Cerf, R. Kahn, "A Protocol for Packet Network=20 - Intercommunication",IEEE Trans.on Comm.,COM-22(5),May 1974.=20 - =20 - [IGE00] C. Intanagonwiwat, R. Govindan, D. Estrin, "Directed=20 - Diffusion: A scalable and robust communication paradigm for sensor=20 - networks", Proceedings MobiCOM, Aug 2000.=20 - =20 - [WSBL99] W. Adjie-Winoto, E. Schwartz, H. Balakrishnan, J. Lilley,=20 - "The design and implementation of an intentional naming system",=20 - Proc. 17th ACM SOSP, Kiawah Island, SC, Dec. 1999.=20 - =20 - [CT90] D. Clark, D. Tennenhouse, "Architectural Considerations for a=20 - new generation of protocols", Proceedings SIGCOMM, 1990.=20 - =20 - [ISCHEMES] http://www.iana.org/assignments/uri-schemes=20 - =20 - [JDPF05] S. Jain, M. Demmer, R. Patra, K. Fall, "Using Redundancy to=20 - Cope with Failures in a Delay Tolerant Network", Proceedings SIGCOMM,=20 - 2005.=20 - =20 - [WJMF05] Y. Wang, S. Jain, M. Martonosi, K. Fall, "Erasure coding=20 - based routing in opportunistic Networks", Proceedings SIGCOMM=20 - Workshop on Delay Tolerant Networks, 2005.=20 - =20 - [ZAZ05] W. Zhao, M. Ammar, E. Zegura, "Multicast in Delay Tolerant=20 - Networks", Proceedings SIGCOMM Workshop on Delay Tolerant Networks,=20 - 2005.=20 - =20 - [LFC05] J. Leguay, T. Friedman, V. Conan, "DTN Routing in a Mobility=20 - Pattern Space", Proceedings SIGCOMM Workshop on Delay Tolerant=20 - Networks, 2005.=20 - =20 - [AF03] J. Alonso, K. Fall, "A Linear Programming Formulation of Flows=20 - over Time with Piecewise Constant Capacity and Transit Times", Intel=20 - Research Technical Report IRB-TR-03-007, June 2003.=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 28]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - [FHM03] K. Fall, W. Hong, S. Madden, "Custody Transfer for Reliable=20 - Delivery in Delay Tolerant Networks", Intel Research Technical Report=20 - IRB-TR-03-030, July 2003.=20 - =20 - [RFC2960] R. Stewart et. al., "Stream Control Transmission Protocol",=20 - RFC 2960, Oct. 2000.=20 - =20 - [BSPEC] K. Scott, S. Burleigh, "Bundle Protocol Specification",=20 - draft-irtf-dtnrg-bundle-spec-05.txt, Work in Progress, March 2006.=20 - =20 - [DTNSEC] S. Symington, S. Farrell, H. Weiss, "Bundle Security=20 - Protocol Specification", draft-irtf-dtnrg-bundle-security-01.txt,=20 - Work in Progress, March 2006.=20 - =20 - [DTNSOV] S. Farrell, S. Symington, H. Weiss, "Delay-Tolerant=20 - Networking Security Overview", draft-irtf-dtnrg-sec-overview-01.txt,=20 - Work in Progress, March 2006.=20 - =20 - [DBFJHP04] M. Demmer, E. Brewer, K. Fall, S. Jain, M. Ho, R. Patra,=20 - "Implementing Delay Tolerant Networking", Intel Research Technical=20 - Report IRB-TR-04-020, Dec. 2004.=20 - =20 - [RFC894] C. Hornig, "Standard for the Transmission of IP Datagrams=20 - over Ethernet Networks", RFC 894, Apr. 1984.=20 - =20 - =20 - =20 -=20 -Authors' Addresses=20 - =20 - Dr. Vinton G. Cerf=20 - Google Corporation=20 - Suite 384=20 - 13800 Coppermine Rd.=20 - Herndon, VA 20171=20 - Telephone +1 (703) 234-1823=20 - FAX +1 (703) 848-0727=20 - Email vint@google.com=20 - =20 - Scott C. Burleigh=20 - Jet Propulsion Laboratory=20 - 4800 Oak Grove Drive=20 - M/S: 179-206=20 - Pasadena, CA 91109-8099=20 - Telephone +1 (818) 393-3353=20 - FAX +1 (818) 354-1075=20 - Email Scott.Burleigh@jpl.nasa.gov=20 -=20 -Cerf, et al. Expires February 2007 [Page 29]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - =20 - Robert C. Durst=20 - The MITRE Corporation=20 - 7515 Colshire Blvd.=20 - M/S H300=20 - McLean, VA 22102=20 - Telephone +1 (703) 883-7535=20 - FAX +1 (703) 883-7142=20 - Email durst@mitre.org=20 - =20 - Dr. Kevin Fall=20 - Intel Research, Berkeley=20 - 2150 Shattuck Ave., #1300=20 - Berkeley, CA 94704=20 - Telephone +1 (510) 495-3014=20 - FAX +1 (510) 495-3049=20 - Email kfall@intel.com=20 - =20 - Adrian J. Hooke=20 - Jet Propulsion Laboratory=20 - 4800 Oak Grove Drive=20 - M/S: 303-400=20 - Pasadena, CA 91109-8099=20 - Telephone +1 (818) 354-3063=20 - FAX +1 (818) 393-3575=20 - Email Adrian.Hooke@jpl.nasa.gov=20 - =20 - Dr. Keith L. Scott=20 - The MITRE Corporation=20 - 7515 Colshire Blvd.=20 - M/S H300=20 - McLean, VA 22102=20 - Telephone +1 (703) 883-6547=20 - FAX +1 (703) 883-7142=20 - Email kscott@mitre.org=20 - =20 - Leigh Torgerson=20 - Jet Propulsion Laboratory=20 - 4800 Oak Grove Drive=20 - M/S: 238-420=20 - Pasadena, CA 91109-8099=20 - Telephone +1 (818) 393-0695=20 - FAX +1 (818) 354-6825=20 - Email ltorgerson@jpl.nasa.gov=20 - =20 - Howard S. Weiss=20 - SPARTA, Inc.=20 - 9861 Broken Land Parkway=20 - Columbia, MD 21046=20 - Telephone +1 (410) 381-9400 x201=20 - FAX +1 (410) 381-5559=20 - Email hsw@sparta.com=20 - =20 -=20 -Cerf, et al. Expires February 2007 [Page 30]=20 -=0CInternet Draft draft-irtf-dtnrg-arch-06.txt September 2006=20 -=20 - Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay=20 - Tolerant Networking Research Group (DTNRG) web site is located at=20 - http://www.dtnrg.org.=20 -=20 -Copyright Notice=20 - =20 - Copyright (C) The Internet Society (2006). This document is subject=20 - to the rights, licenses and restrictions contained in BCP 78, and=20 - except as set forth therein, the authors retain all their rights.=20 - =20 -Disclaimer of Validity=20 - =20 - This document and the information contained herein are provided on an=20 - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=20 - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET=20 - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,=20 - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE=20 - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20 - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=20 - =20 -Intellectual Property=20 - =20 - The IETF takes no position regarding the validity or scope of any=20 - Intellectual Property Rights or other rights that might be claimed to=20 - pertain to the implementation or use of the technology described in=20 - this document or the extent to which any license under such rights=20 - might or might not be available; nor does it represent that it has=20 - made any independent effort to identify any such rights. Information=20 - on the procedures with respect to rights in RFC documents can be=20 - found in BCP 78 and BCP 79.=20 - =20 - Copies of IPR disclosures made to the IETF Secretariat and any=20 - assurances of licenses to be made available, or the result of an=20 - attempt made to obtain a general license or permission for the use of=20 - such proprietary rights by implementers or users of this=20 - specification can be obtained from the IETF on-line IPR repository at=20 - http://www.ietf.org/ipr.=20 - =20 - The IETF invites any interested party to bring to its attention any=20 - copyrights, patents or patent applications, or other proprietary=20 - rights that may cover technology that may be required to implement=20 - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org.=20 - =20 - =20 - - - - - - - - -=20 -Cerf, et al. Expires February 2007 [Page 31]=20 -=0C \ No newline at end of file diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-bundle-encapsulat= ion-01.txt --- a/doc/draft-irtf-dtnrg-bundle-encapsulation-01.txt Sat Dec 12 17:10:03 = 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,728 +0,0 @@ - - - -DTN Research Group S. Symington -Internet-Draft R. Durst -Expires: November 12, 2007 K. Scott - The MITRE Corporation - May 11, 2007 - - - Delay-Tolerant Networking Bundle-in-Bundle Encapsulation - draft-irtf-dtnrg-bundle-encapsulation-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 12, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 1] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -Abstract - - This document defines an additional administrative record type to be - used with the Bundle Protocol [2] within the context of a Delay- - Tolerant Network architecture [5]. This new administrative record - type, called a Bundle-in-Bundle Encapsulation Administrative Record, - is designed to be used to encapsulate one or more bundles inside of - another bundle. When an administrative record of the bundle-in- - bundle encapsulation type is carried as the payload of a bundle, it - provides a mechanism for transmitting one or more bundles as part of - the payload of another bundle. This administrative record type is - expected to be of general use in DTN. It may be used, for example, - to encapsulate a multicast bundle inside of a unicast bundle, or to - encapsulate a bundle with one type of security protection inside of a - bundle with a different type of security protection. This document - defines the format and processing of this new bundle-in-bundle - encapsulation administrative record type. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 2] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Bundle-in-Bundle Encapsulation Administrative Record Format . 5 - 3. Bundle-in-Bundle Encapsulation Administrative Record - Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. Generation and Transmission of an Encapsulated Bundle - or Bundles . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.2. Local Delivery of an Encapsulating Bundle . . . . . . . . 7 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 3] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -1. Introduction - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - The DTN bundle protocol [2] defines the bundle as its protocol data - unit and also defines two types of administrative records that may be - carried as the payload of bundles. This document defines an - additional administrative record type. This new administrative - record type, called a Bundle-in-Bundle Encapsulation Administrative - Record, is designed to be used to encapsulate one or more bundles - inside of another bundle. When an administrative record of the - bundle-in-bundle encapsulation type is carried as the payload of a - bundle, it provides a mechanism for transmitting one or more bundles - as part of another bundle. This administrative record type is - expected to be of general use in DTN. It may be used, for example, - to encapsulate a multicast bundle inside of a unicast bundle, or to - encapsulate a bundle with one type of security protection inside of a - bundle with a different type of security protection. This document - defines the format and processing of this new bundle-in-bundle - encapsulation administrative record type. - - The capabilities described in this document are OPTIONAL for - deployment with the Bundle Protocol. Bundle Protocol implementations - claiming to support bundle-in-bundle encapsulation MUST be capable of - both: - - -generating and sending bundles containing Bundle-in-Bundle - Encapsulation administrative records, and - - -receiving and processing bundles containing Bundle-in-Bundle - Encapsulation administrative records - - as defined in this document. - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 4] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -2. Bundle-in-Bundle Encapsulation Administrative Record Format - - The basic format of every administrative record is defined in the - Bundle Protocol. The bundle-in-bundle encapsulation administrative - record also has this basic format. That is, it is comprised of the - following elements: - - -Record type code (four bits) - as in all administrative records. - The administrative record type code value for the bundle-in-bundle - encapsulation administrative record is 0x03. - - -Administrative record flags - (four bits) - as in all - administrative records. - - -Administrative record type-specific record content as follows: - - -Encapsulated Bundles field - contains a sequence of one or - more bundles that are to be extracted from this administrative - record for further processing (e.g., delivery and/or - forwarding). - - The format of the a bundle-in-bundle encapsulation administrative - record is as follows: - - Bundle-in-Bundle Encapsulation Administrative Record Type Format - +---------------+---------------+--------------+ - | Admin. Record | Admin. Record | Encapsulated | - | Type Code | flags | Bundles | - +---------------+---------------+--------------+ - - - Figure 1 - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 5] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -3. Bundle-in-Bundle Encapsulation Administrative Record Processing - - For the most part, the processing of a bundle that contains a bundle- - in-bundle encapsulation administrative record type is the same as the - processing of any other bundle. The main difference between a bundle - that contains a bundle-in-bundle encapsulation administrative record - type and a bundle with a generic payload is what happens before - generation and after delivery of the bundle. The generation and - initial transmission of all bundles is in response to bundle - transmission requests posed by a node's application agent. For most - bundles, the transmission request comes from an application, via the - node's application agent, to the node's bundle protocol agent. For - bundles that contain administrative records, the bundle protocol - agent itself is responsible for causing the new bundle to be - generated and transmitted because it directs the administrative - element of the node's application agent to construct the - administrative record and request its transmission. For bundles that - contain bundle-in-bundle encapsulation administrative records, in - particular, the receipt by a node of a bundle that is to be - encapsulated in the bundle-in-bundle encapsulation administrative - record is what causes the bundle protocol agent to direct the - administrative element of the node's application agent to construct - the bundle-in-bundle encapsulation administrative record and request - its transmission. - - Similarly, upon delivery of a bundle containing a bundle-in-bundle - encapsulation administrative record, processing of the bundle does - not end with this delivery. The administrative element of the node's - application agent to which the bundle-in-bundle encapsulation - administrative record was delivered is expected to extract the - encapsulated bundle or bundles from the bundle-in-bundle - encapsulation administrative record and then pass them down to its - bundle protocol agent for further processing, followed by forwarding - and/or delivery, as appropriate. This section describes the steps - that are particular to the processing of bundles containing bundle- - in-bundle encapsulation administrative records. In particular, it - focuses on the processing that occurs prior to and during generation - of these bundles, and during and after delivery of these bundles, - because these periods of processing are what distinguish the - processing of bundles containing bundle-in-bundle encapsulation - administrative records from the processing of other bundles. - -3.1. Generation and Transmission of an Encapsulated Bundle or Bundles - - To take a received bundle (or bundles) and forward this bundle as - part of a bundle-in-bundle encapsulation administrative record that - is carried as the payload of another bundle, a node must perform the - following steps: - - - -Symington, et al. Expires November 12, 2007 [Page 6] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - - The node SHALL process the received bundle for forwarding as if it - were going to simply forward the bundle. Some of the processing - steps include, for example: - - -Processing the security extension blocks [4] (if any) - contained in the bundle, as appropriate (e.g., verifying the - security result in the Bundle Authentication Block and deleting - this block, verifying the security result in the Payload - Security Block if the node is the security destination, etc.). - - -Deleting all Previous Hop Insertion Blocks from the bundle (if - any). - - -If the bundle should (according to local policy) be given one - or more Previous Hop Insertion Blocks [3], these blocks SHALL - be inserted into the bundle. - - -If the bundle should be given one or more security extension - blocks such as a Bundle Authentication, Payload Security, or - Confidentiality Block, the appropriate security blocks SHALL be - inserted into the bundle. - - Next, the node's bundle protocol agent MUST direct the - administrative element of the node's application agent to - construct an encapsulating bundle. This encapsulating bundle will - have as its payload a bundle-in-bundle encapsulation - administrative record of type 0x03, as described in the previous - section. The bundle or bundle's to be encapsulated MUST be placed - in the "Encapsulated Bundles" field of this administrative record. - -3.2. Local Delivery of an Encapsulating Bundle - - Upon delivery of a bundle with a payload that is a Bundle-in-Bundle - Encapsulation administrative record, the administrative element of - the application agent of the node at which the bundle was delivered - SHALL perform the following processing steps: - - Extract the encapsulated bundle(s) from the bundle-in-bundle - encapsulation administrative record. - - Pass each of these de-encapsulated bundles in their entirety to - the node's bundle protocol agent. - - Upon receipt of each of these de-encapsulated bundles, the bundle - protocol agent SHALL process each bundle as if it had just been - received from another node. Some of these processing steps include, - for example: - - - - -Symington, et al. Expires November 12, 2007 [Page 7] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - - -Processing the security extension blocks [4] (if any) contained - in the bundle, as appropriate (e.g., verifying the security result - in the Bundle Authentication Block and deleting this block, - verifying the security result in the Payload Security Block if the - node is the security destination, etc.). - - -Deleting all Previous Hop Insertion Blocks from the bundle (if - any). - - -If the bundle should (according to local policy) be given one or - more Previous Hop Insertion Blocks [3], these blocks SHALL be - inserted into the bundle. - - -The bundle protocol agent SHALL deliver the bundle, if - appropriate. - - -The bundle protocol agent SHALL perform custody transfer and/or - status reporting procedures on the bundle as directed by the - bundle's custody transfer and status report request flags. - - -If the bundle should be given one or more security extension - blocks such as a Bundle Authentication, Payload Security, or - Confidentiality Block, the appropriate security blocks SHALL be - inserted into the bundle. - - -The bundle protocol agent SHALL forward the bundle to all - appropriate endpoints. - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 8] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -4. Security Considerations - - There are two documents that pertain to providing security within DTN - [4] [6]. The security blocks and other protection mechanisms defined - and described in those documents apply completely to the protection - of bundle-in-bundle encapsulation administrative records, in the - sense that administrative records are simply carried in bundles as - the content of the payload field in the Bundle Payload block. All - security protection mechanisms that apply to the Bundle Payload - block, therefore, also apply to protection of bundle-in-bundle - encapsulation administrative records. In particular, all three - mandatory ciphersuites defined in the Bundle Security Protocol - provide protection for the bundle-in-bundle encapsulation - administrative record. - - It should be noted that when a bundle is encapsulated, the - encapsulated bundle itself may be protected by one or more security - blocks. In particular, it may contain a Bundle Authentication block - (BAB), which is designed to be processed by a next-hop neighboring - node. If a bundle with a BAB is encapsulated by one node and it is - received and de-encapsulated by a non-neighboring node, the de- - encapsulating node must be capable of validating the security result - in that BAB if its security policy requires such validation. - Therefore, encapsulation of bundles protected by BABs may require - that keys that are normally only shared between neighbors be - distributed further in the DTN so that they are shared by the - encapsulating and de-encapsulating nodes. - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 9] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -5. IANA Considerations - - None at this time. If the bundle protocol becomes a standards track - protocol, then we may want to consider having IANA establish a - register of administrative record types, of which the Bundle-in- - Bundle Encapsulation would be one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 10] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -6. References - -6.1. Normative References - - [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to - Indicate Requirement Levels", RFC 2119, October 1997. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-09.txt, work-in-progress, - April 2007. - - [3] Symington, S., "Delay-Tolerant Networking Previous Hop Insertion - Block", draft-irtf-dtnrg-bundle-previous-hop-block-02.txt, work- - in-progress, April 2007. - - [4] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle - Security Protocol Specification", - draft-irtf-dtnrg-bundle-security-03.txt, work-in-progress, - April 2007. - -6.2. Informative References - - [5] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., - Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network - Architecture", RFC 4838, April 2007. - - [6] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- - Tolerant Network Security Overview", - draft-irtf-dtnrg-sec-overview-03.txt, work-in-progress, - April 2007. - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 11] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -Authors' Addresses - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - Robert C. Durst - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7535 - Email: durst@mitre.org - URI: http://mitre.org/ - - - Keith L. Scott - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-6547 - Email: kscott@mitre.org - URI: http://mitre.org/ - - - - - - - - - - - - - - - - - - -Symington, et al. Expires November 12, 2007 [Page 12] -=0C -Internet-Draft DTN Bundle-in-Bundle Encapsulation May 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Symington, et al. Expires November 12, 2007 [Page 13] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-bundle-previous-h= op-block-01.txt --- a/doc/draft-irtf-dtnrg-bundle-previous-hop-block-01.txt Sat Dec 12 17:1= 0:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,728 +0,0 @@ - - - -DTN Research Group S. Symington -Internet-Draft The MITRE Corporation -Intended status: Experimental February 1, 2007 -Expires: August 5, 2007 - - - Delay-Tolerant Networking Previous Hop Insertion Block - draft-irtf-dtnrg-bundle-previous-hop-block-01 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on August 5, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 1] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -Abstract - - This document defines an extension block that may be used with the - Bundle Protocol [2] within the context of a Delay-Tolerant Network - architecture [4]. This Previous Hop Insertion Block is designed to - be inserted by a forwarding node to provide information to its next- - hop receiving node. This block is always removed from the bundle by - the receiving node so that it's duration within the bundle lasts for - exactly one hop. It provides a general insertion capability to - enable any node that forwards a bundle to insert an arbitrary record - (or records) of information into the bundle. While this block is - defined to provide an arbitrary insertion capability, this - specification also defines two specific, mandatory, information - record formats for the information that may be carried in the - Previous Hop Insertion block. Using these mandatory information - record formats, an insertion block may be used to carry the - inserting/forwarding node's endpoint ID (EID), which may be required - in some circumstances to support certain routing protocols (e.g., - flood routing). This document defines the format and processing of - this Previous Hop Insertion Block. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 2] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Previous Hop Insertion Block Format . . . . . . . . . . . . . 6 - 3. Previous Hop Insertion Block Processing . . . . . . . . . . . 7 - 3.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 7 - 3.2. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 7 - 3.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 7 - 4. Mandatory Information Record Formats . . . . . . . . . . . . . 8 - 4.1. EID-only . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.2. EID-with-Timestamp . . . . . . . . . . . . . . . . . . . . 8 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 - Intellectual Property and Copyright Statements . . . . . . . . . . 13 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 3] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -1. Introduction - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - The DTN bundle protocol [2] defines the bundle as its protocol data - unit. A bundle consists of a primary bundle block, which is defined - in the Bundle Protocol, followed by at least one other type of bundle - block. The Bundle Protocol defines a single other type of bundle - block, called a Bundle Payload block. This document defines an - additional, optional, bundle block called a Previous Hop Insertion - Block. This block is designed to be used by a forwarding node to - insert information into a bundle before forwarding that bundle. The - intent of this Previous Hop Insertion Block is to provide a general - insertion mechanism such that an arbitrary record of information may - be inserted into the bundle by a forwarding node for consumption by - the next-hop receiving node. The lifetime of the Previous Hop - Insertion Block is always exactly one hop in the DTN, so if a bundle - containing a Previous Hop Insertion Block is received, the receiving - node is assured that the information in this block was inserted by - the previous node; likewise, the information in this block is not - retained with the bundle when the bundle is forwarded. - - The information record(s) to be inserted into the block may have any - content and format, providing the content and format have been - defined and documented in order to enable the information to be - understood. In this specification we define two specific information - record formats for use in the insertion block that MUST be supported. - Each of these formats includes a field for the endpoint ID - information of the inserting node. Insertion of a node's EID into a - bundle's Previous Hop Insertion Block enables the inserting/ - forwarding node to provide its EID to its next-hop receiving node. - This previous-hop EID information may be required in some - circumstances to support various routing protocols (e.g., flood - routing). Although there may be some situations in which a node that - receives a bundle may be able to infer the EID of the node that - forwarded the bundle to it, there are other situations in which the - EID of the forwarding node will not be able to be inferred by the - receiving node. In these situations, if there is a requirement that - the receiving node be able to determine the EID of the forwarding - node, the forwarding node must provide this information in the - bundle. This specification defines the mechanism, i.e. the Previous - Hop Insertion Block, used in conjunction with either an EID-only or - an EID-with-timestamp information record format, whereby a node can - insert its EID (and possibly other information) into a bundle before - forwarding it. - - - - -Symington Expires August 5, 2007 [Page 4] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - - Using the information record formats that are defined in this - document, the information that is provided in the insertion blocks at - each node may include not only the EID of the inserting/forwarding - node, but also a time stamp. This information may be further - expanded or altered through the future definition of additional - information record formats to provide an arbitrary information record - insertion capability. This document defines the format and - processing of the Previous Hop Insertion Block. It also defines two - mandatory information record formats. - - The capabilities described in this document are OPTIONAL for - deployment with the Bundle Protocol. Bundle Protocol implementations - claiming to support Previous Hop Insertion Blocks MUST be capable of: - - -Generating a Previous Hop Insertion Block and inserting it into a - bundle, - - -Receiving bundles containing a Previous Hop Insertion Block and - making the information contained in this Previous Hop Insertion - Block's information record field available for use, e.g., in - forwarding decisions. - - -Deleting a Previous Hop Insertion Block from a bundle - - as defined in this document. - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 5] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -2. Previous Hop Insertion Block Format - - The Previous Hop Insertion Block uses the Canonical Bundle Block - Format as defined in the bundle protocol [2]. That is, it is - comprised of the following elements: - - -Block-type code (8-bit unsigned binary integer) - defined as in - all bundle protocol blocks except the primary bundle block (as - described in the Bundle Protocol). The block type code for the - Previous Hop Insertion Block is 0x05 - - -Block processing control flags (SDNV) - defined as in all bundle - protocol blocks except the primary bundle block. (SDNV encoding - is described in the Bundle Protocol.) The following block - processing control flag MUST be set: - - -Discard block if it can't be processed. - - -Block data length (SDNV) - defined as in all bundle protocol - blocks except the primary bundle block. SDNV encoding is - described in the bundle protocol. - - -Block-type-specific data fields as follows: - - -Information Record Format ID (SDNV) - Its value identifies the - format of the information record that comes later in the block. - Some mandatory information record formats are specified in - Section 4. Additional information record formats MAY be - defined in separate specifications. - - -Information Record - Contains the data being inserted by the - forwarding node, formatted as identified by the value of the - Information Record Format ID field. - - The Structure of a Previous Hop Insertion Block is as follows: - - Previous Hop Insertion Block Format: - +-----+------+-------+-------------+-------------+ - |Type |Flags |Length |Info. Record |Info. Record | - | | | | Format ID | | - +-----+------+-------+-------------+-------------+ - - Figure 1 - - - - - - - - -Symington Expires August 5, 2007 [Page 6] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -3. Previous Hop Insertion Block Processing - - The following are the processing steps that a bundle node must take - relative to generation, reception, and processing of Previous Hop - Insertion Blocks. - -3.1. Bundle Transmission - - When an outbound bundle is created per the parameters of the bundle - transmission request, this bundle MAY (as influenced by local policy) - include one or more Previous Hop Insertion Blocks (as defined in this - specification). - -3.2. Bundle Forwarding - - Before forwarding a bundle, the node SHALL delete all of the Previous - Hop Insertion Blocks that were in the bundle when it was received. - The node SHALL delete all strings (scheme names and scheme-specific - parts--SSPs) in the bundle's dictionary to which no endpoint ID - references in the bundle currently refer (if any). - - The node MAY insert one or more Previous Hop Insertion Blocks into - the bundle before forwarding it, as dictated by local policy. - -3.3. Bundle Reception - - If the bundle includes one or more Previous Hop Insertion Blocks, the - information records in these blocks SHALL be made available for use - at this node (e.g., in forwarding decisions). - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 7] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -4. Mandatory Information Record Formats - - This section defines the mandatory information record formats for - this specification. Additional formats may be defined elsewhere. - -4.1. EID-only - - The EID-only record format has record-format ID 0x00000001. - - The EID-only record format consists of two fields: - - The EID Scheme Offset (SDNV) - its value is the offset within the - dictionary byte array of the first character of the scheme name of - the EID of the inserting/forwarding node. - - The EID SSP Offset (SDNV) - its value is the offset within the - dictionary byte array of the first character of the scheme- - specific part of the EID of the inserting/forwarding node. - -4.2. EID-with-Timestamp - - The EID-with-Timestamp record format has record-format ID 0x00000002. - - The EID-with-Timestamp record format consists of three fields, the - first two of which are the same as the fields in the EID-only record - format: - - The EID Scheme Offset (SDNV) - its value is the offset within the - dictionary byte array of the first character of the scheme name of - the EID of the inserting/forwarding node. - - The EID SSP Offset (SDNV) - its value is the offset within the - dictionary byte array of the first character of the scheme- - specific part of the EID of the inserting/forwarding node. - - The Elapsed Time field (SDNV) - indicates the time at which the - bundle is being processed by the forwarding node, encoded as a - number of seconds past the bundle's creation time. - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 8] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -5. Security Considerations - - There are two documents that pertain to providing security within - DTN: the DTN Security Overview [5] and the Bundle Security Protocol - [3]. These documents define three security-related blocks to provide - hop-by-hop authentication, end-to-end authentication, and end-to-end - confidentiality of bundles or parts of bundles, as well as a set of - mandatory ciphersuites that may be used to calculate security results - carried in these security blocks. All ciphersuites that use the - strict canonicalisation algorithm [3] to calculate and verify - security results (e.g., many hop-by-hop authentication ciphersuites) - apply to all blocks in the bundle, and so would apply to bundles that - include an optional Previous Hop Insertion Block and would include - that block in the calculation of their security result. In - particular, bundles including the optional Previous Hop Insertion - Block would be protected in their entirety for the duration of a - single hop, from a forwarding node to an adjacent receiving node (but - not from source to destination), using the mandatory BAH-HMAC - ciphersuite defined in the Bundle Security Protocol. Ciphersuites - that use the mutable canonicalisation algorithm to calculate and - verify security results (e.g., the mandatory PSH-RSA-SHA256 - ciphersuite and most end-to-end authentication ciphersuites) will - (correctly) omit the Previous Hop Insertion Block from their - calculation. The fact that several different instantiations of this - block may be present in the bundle as the bundle transits the network - will not interfere with end-to-end security protection when using - ciphersuites that use mutable canonicalisation. Lastly, the Previous - Hop Insertion Block will not be encrypted by the mandatory CH-RSA- - AES-PAYLOAD-PSH end-to-end confidentiality ciphersuite, which only - allows for payload and PSH encryption. - - The Bundle Authentication Block (BAB) currently includes a mandatory - security source field over which an authenticator is calculated. - This security source field contains the EID of the node forwarding - the bundle. If a bundle's dictionary already contains both strings - (the scheme and the SSP) that comprise the EID of the forwarding - node, however, e.g., as a result of the inclusion of an EID-only or - an EID-with-Timestamp-formatted information record in a Previous Hop - Insertion Block that is in the bundle, then it would be redundant to - include the forwarding node's EID in the BAB as well. In this case, - it would make sense to omit the security source field from the BAB. - However, as currently defined, the security source field is mandatory - in the BAB. The BAB should be redefined to make the security source - field optional to enable the elimination of such potential - redundancy. - - - - - - -Symington Expires August 5, 2007 [Page 9] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -6. IANA Considerations - - None at this time. If the bundle protocol becomes a standards track - protocol, then we may want to consider having IANA establish a - register of header types, and in particular for this specification a - separate register of information record formats. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 10] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -7. References - -7.1. Normative References - - [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to - Indicate Requirement Levels", RFC 2119, October 1997. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-08.txt, work-in-progress, - December 2006. - - [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security - Protocol Specification", - draft-irtf-dtnrg-bundle-security-02.txt, work-in-progress, - October 2006. - -7.2. Informative References - - [4] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., - Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network - Architecture", draft-irtf-dtnrg-arch-08.txt, work-in-progress, - December 2006. - - [5] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant - Network Security Overview", - draft-irtf-dtnrg-sec-overview-02.txt, work-in-progress, - October 2006. - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 11] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -Author's Address - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires August 5, 2007 [Page 12] -=0C -Internet-Draft DTN Previous Hop Insertion Block February 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Symington Expires August 5, 2007 [Page 13] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-bundle-retrans-bl= ock-00.txt --- a/doc/draft-irtf-dtnrg-bundle-retrans-block-00.txt Sat Dec 12 17:10:03 = 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1176 +0,0 @@ - - - -DTN Research Group S. Symington -Internet-Draft The MITRE Corporation -Expires: October 27, 2007 April 25, 2007 - - - Delay-Tolerant Networking Retransmission Block - draft-irtf-dtnrg-bundle-retrans-block-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 27, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 1] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -Abstract - - This document defines an optional extension block, called a - Retransmission Block, that may be used with the Bundle Protocol [2] - within the context of a Delay-Tolerant Network architecture [4]. The - Retransmission Block (RB) is designed to be inserted by a custodian - when re-forwarding a bundle, so as to mark the bundle as a legitimate - custody-based retransmission rather than an unauthorized bundle - duplicate. By providing a way for nodes that receive the re- - forwarded bundle to distinguish it from an unauthorized duplicate, - the RB enables those nodes whose local security policies do not - permit them to forward unauthorized duplicate bundles to detect and - delete unauthorized bundle duplicates but forward legitimate custody- - based bundle retransmissions. This document defines the format and - processing of this new Retransmission Block. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Background and Motivation . . . . . . . . . . . . . . . . . . 5 - 2.1. Replay Detection as Currently Provided in the Bundle - Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. The Denial-of-Service Threat . . . . . . . . . . . . . . . 5 - 2.3. Detecting Duplicates is Largely a Matter of Local - Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.4. Not All Duplicates are Bad . . . . . . . . . . . . . . . . 6 - 2.5. A Mechanism for Distinguishing Legitimate - Retransmissions from Replays is Required . . . . . . . . . 7 - 3. The Treatment of Replays Must Be a Defined Aspect of - Security Policy . . . . . . . . . . . . . . . . . . . . . . . 8 - 4. Replays versus Loops . . . . . . . . . . . . . . . . . . . . . 9 - 5. Ramifications of Allowing Support for the Retransmission - Block to be Optional . . . . . . . . . . . . . . . . . . . . . 11 - 6. Retransmission Block Format . . . . . . . . . . . . . . . . . 13 - 7. Retransmission Block Processing . . . . . . . . . . . . . . . 15 - 7.1. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 15 - 7.2. Replay Detection and Suppression . . . . . . . . . . . . . 15 - 7.3. Keeping Track of Bundles Received . . . . . . . . . . . . 15 - 7.4. Purging stored bundle information . . . . . . . . . . . . 16 - 7.5. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 16 - 7.6. Custodial Retransmission . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 - - - -Symington Expires October 27, 2007 [Page 2] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - Intellectual Property and Copyright Statements . . . . . . . . . . 21 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 3] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -1. Introduction - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - - The DTN bundle protocol [2] defines the bundle as its protocol data - unit. A bundle consists of a primary bundle block, which is defined - in the Bundle Protocol, followed by at least one other type of bundle - block. The Bundle Protocol defines a single other type of bundle - block, called a Bundle Payload block. This document defines an - additional, optional, bundle block called a Retransmission Block. - This block is designed to be inserted by a custodian node into a - bundle that the custodian is re-forwarding in response to a custody - transfer failure. The intent of this Retransmission Block is to mark - a re-forwarded bundle as such, so that when the bundle is received at - downstream nodes that detect it to be a duplicate of a previously- - received bundle, those nodes can understand it to be a legitimate - retransmission that should be preserved rather than an unauthorized - duplicate (aka a replay) that may (according to local policy) be - deleted. - - The capabilities described in this document are OPTIONAL for - deployment with the Bundle Protocol. Bundle Protocol implementations - claiming to support Retransmission Blocks MUST be capable of: - - -Generating a Retransmission Block and inserting it into a bundle, - - -Logging the relevant fields of all bundles received until those - bundles expire, - - -Receiving bundles containing a Retransmission Block and using the - information contained in this Retransmission Block (in conjunction - with the information from logged bundles) to make duplicate - deletion (aka replay suppression) decisions, - - -Deleting a Retransmission Block from a bundle - - as defined in this document. - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 4] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -2. Background and Motivation - -2.1. Replay Detection as Currently Provided in the Bundle Protocol - - The Bundle Security Protocol defines an "at-most-once-delivery" - registration option that, when used by a node that is registering in - a particular endpoint, indicates that at most one copy of each bundle - destined for that endpoint that is received at that node shall be - delivered at that node. If the at-most-once-delivery option is used - with a given endpoint ID registration, the registering node is - required to check all bundles that it receives with that destination - endpoint ID to determine if the bundle has already been delivered at - that node. If it has, the bundle must be discarded. This is a - limited form of replay detection because it requires a node to keep - track of only the bundles that have been delivered at that node; it - does not apply to bundles that the node receives for forwarding. It - is designed to protect applications from receiving duplicate bundles, - but it is not intended to protect the network from denial of service - attacks that can result from replayed bundles. - -2.2. The Denial-of-Service Threat - - As discussed in the DTN Security Overview [5], due to the resource- - scarcity that characterizes DTNs, unauthorized access and use of DTNs - is a serious concern. DTNs, by definition, may suffer from network - disconnections, limited bandwidth, limited battery power, and other - challenges, and the transmission of unauthorized bundles wastes - precious network resources. The DTN security protocol already - includes some mechanisms to protect against unauthorized use of the - DTN. For example, an attacker wanting to launch a denial of service - attack on a DTN by injecting a bogus bundle into the network or by - copying a legitimate bundle from the network, modifying it, and - injecting this modified copy into the network can be thwarted by the - use of the Bundle Authentication Block (BAB). Use of the BAB enables - each node that receives a bundle to check the validity of the - security result in the BAB to determine whether the bundle is - legitimate or not. Bogus or modified bundles will be detected at the - very first node at which they are received, and thus will be deleted - from the network at the earliest possible opportunity. Replayed - bundles, on the other hand, can not be detected by checking the - validity of the bundle's BAB because the value of the BAB will be - correct. Replayed bundles will only be deleted from the network when - they expire. Given the high latency typical in some DTNs, bundles - may be valid for days or weeks. For those networks in which waiting - for replayed bundles to expire is not an adequate form of protection - against the unauthorized use of the network posed by replayed - bundles, additional measures will be required to actively detect and - delete replayed bundles. - - - -Symington Expires October 27, 2007 [Page 5] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -2.3. Detecting Duplicates is Largely a Matter of Local Policy - - Detecting duplicate bundles at any given node is largely a matter of - local security policy and enforcement. A node could be configured to - maintain a record of every bundle it receives, check every new bundle - received against the list of bundles that have already been received, - and delete any duplicates. A concern with this approach is the - potentially large amount of state that could accumulate and use up - storage at any given node. This state can be minimized by only - storing those parts of the bundle needed to identify it uniquely - (source EID, creation timestamp, and fragment offset and length - if - present), and keeping this information only until the time that the - bundle expires (creation timestamp added to lifetime). The lifetime - of the bundle would also need to be stored in order to be able to - determine whether or not it has expired. Because bundles may be - valid for long periods in a DTN, however, the amount of storage that - may be required could still be substantial enough to pose a burden on - the node. If the amount of information that needs to be stored - exceeds the available storage and bundles are purged before they - expire, however, some duplicates could go undetected. - -2.4. Not All Duplicates are Bad - - Although detecting duplicates is a fairly straightforward local - matter (assuming sufficient storage is available), detecting which of - these duplicates are unauthorized and should therefore be deleted is - more involved, and has protocol implications. Simply being able to - detect and delete duplicate bundles is not sufficient in a DTN, - because not all duplicate bundles are unwanted replays. As discussed - in the security overview, there are instances within DTNs in which - replayed messages are desirable and in fact necessary. As a first - example, in some instances, the optimal path to a destination will - involve routing loops, such that the nodes on this loop will receive - the same bundle for forwarding more than once. As a second example, - the DTN protocol includes a custody-based retransmission mechanism - that may result in a custodian re-forwarding a bundle when the - bundle's retransmission timer expires or when the custodian receives - a "failed" custody signal for the bundle. These re-forwarded bundles - are legitimate retransmissions that are required in order to enable - custody transfer to operate correctly. - - On the other hand, there are also illegitimate retransmissions, also - known as replays. Some replays are introduced unintentionally by the - routing protocols; these replays are not needed in order to deliver - the bundle, but rather are the result of routing or forwarding - mistakes. Other replays are more pernicious, being introduced - intentionally by malicious intruders. Ideally, a node would be able - to distinguish replays from legitimate retransmissions so that it can - - - -Symington Expires October 27, 2007 [Page 6] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - know which duplicate bundles to delete and which to forward. - -2.5. A Mechanism for Distinguishing Legitimate Retransmissions from - Replays is Required - - When routing loops or custody transfer is being used in a DTN, replay - detection cannot be handled merely as a matter of locally detecting - and deleting duplicate bundles because there is no way for a local - node to independently distinguish legitimate retransmissions from - illegitimate replays. Instead, a protocol mechanism is required to - assist the local duplicate suppression mechanism in making this - distinction. - - As discussed in the DTN Security Overview, to accommodate intentional - retransmissions that are part of the routing protocol but suppress - replays that are the result of routing protocol errors, replay - detection schemes may need to be specified and enforced as part of - the bundle routing algorithm used. - - If the security requirements of a network are such that replays must - not be allowed, then that network must either not use routing or - transport protocols that allow routing loops or, if it does use a - routing or transport protocol that allows loops, this protocol must - also include a mechanism for detecting and suppressing unintentional - loops. The details of such a mechanism would most likely be specific - to the routing or transport protocol and as such they are not - addressed in this document. - - In addition, if the security requirements of a network are such that - replays must not be allowed, then that network must either not use - custody transfer of bundles or, if it does use custody transfer of - bundles, it must also include a mechanism for detecting and - suppressing duplicate bundles that are not the result of custodial - retransmissions. This paper defines the DTN Retransmission Block as - an optional Bundle Protocol block that can be used to mark bundles - that are the result of custodial retransmission, thereby enabling - these bundles to be distinguished from both unintentional replays and - replays that are the result of intentional, malicious attacks. - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 7] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -3. The Treatment of Replays Must Be a Defined Aspect of Security Policy - - An additional component of a DTN node's security policy should be - whether or not replays are allowed to be forwarded by that node. If - replay forwarding is not allowed, the node must implement mechanisms - to detect and delete replays. In the context of a node that does not - implement the optional Retransmission Block protocol extensions - defined in this document but at which replay forwarding is not - allowed, all duplicate bundles must be deleted, where duplicate - bundles are defined as bundles that have the same source EID, time - stamp, and fragment offset and length (if present). In the context - of a node that does implement the optional Retransmission Block - protocol extensions defined in this document, unauthorized replays - can be distinguished from legitimate retransmissions such that only - unauthorized replays must be deleted. The processing steps with - regard to replay protection at an arbitrary node are defined as - follows: - - If replays are allowed, then no additional requirements are levied - on that node. - - If replays are not allowed and if the node supports the optional - Retransmission Block defined in this document, then the node MUST - delete all duplicate bundles that it receives that are not - legitimate custodial retransmissions; when such a duplicate bundle - is deleted, the node MAY indicate this by generating a bundle - deletion status report (see [2]), as determined by local policy. - A received duplicate bundle is not a legitimate custodial - retransmission if it: - - -Has the same custodian EID as the previously-received - duplicate, but it does not also have a Retransmission Block - that was inserted by that custodian, or - - -Has the same custodian EID as the previously-received - duplicate, and also has a Retransmission Block with the same - EID reference and retransmission sequence number values as the - Retransmission Block in the previously-received duplicate. - - If replays are not allowed and if the node does not support the - optional Retransmission Block defined in this document, then the - node MUST delete all duplicate bundles that it receives (at the - risk of also deleting all legitimate custodial retransmissions - that it receives). - - - - - - - -Symington Expires October 27, 2007 [Page 8] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -4. Replays versus Loops - - The procedures for deleting all duplicate bundles that are not - legitimate custodial retransmissions above will result in the - deletion of not only replays, but also of bundles that loop through - the network multiple times. If the looping is unintentional, due to - routing or forwarding errors, deletion of these bundles is desirable. - If the looping is intentional, however, then the deletion of a bundle - in such a loop is not desirable. For example, if a custodial node, - C, needs to free up disk space by temporarily transferring custody - and storage of a bundle to some sort of "auxiliary storage" node that - is not on the path to the bundle's destination until the path to the - destination becomes connected, then the path from the custodian C to - the auxiliary storage node and back would constitute an intentional - routing loop. In order to free up its storage space when sending the - bundle to auxiliary storage, custody of the bundle would be - transferred from node C to the auxiliary storage node. When the - bundle is sent back to node C from auxiliary storage, the auxiliary - storage node would be listed as the bundle's custodian. According to - the procedures for deleting duplicate bundles that are not legitimate - custodial retransmissions as described in Section 3, this bundle - would not be deleted by node C because it does not have the same - custodian as it had when it was initially received by node C. If for - some reason this storing of the bundle at the auxiliary storage node - has to be performed a second time, however, then the procedures above - will not suffice to spare this bundle from deletion. - - If node C receives the bundle from auxiliary storage and forwards it - back to auxiliary storage without taking custody of it, auxiliary - storage will delete this copy of the bundle, but it will still be - custodian of the bundle and will still have it in storage. This case - is not a problem. If, on the other hand, node C receives the bundle - from auxiliary storage and takes custody of the bundle before - forwarding it back to auxiliary storage, the auxiliary storage node - will delete this bundle (but the auxiliary storage node will not - still be custodian of the bundle and will not still have the bundle - in storage) because the auxiliary storage node has already received - this bundle with node C listed as its custodian and this bundle does - not contain a retransmission block because node C did not forward it - as a custodial retransmission. - - There are several possible approaches that may be taken to address - this problem by attempting to process bundles that are in "desirable" - loops and discard bundles that are in "undesirable" loops, while - staying within the procedures defined above for deleting duplicate - bundles that are not legitimate custodial retransmissions. For - example, custodial nodes that make use of auxiliary storage nodes - might be configured to accept duplicate bundles received from - - - -Symington Expires October 27, 2007 [Page 9] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - auxiliary storage nodes, and vice versa. Alternatively, a special - block might be defined to mark a bundle that a custodial node is - sending to an auxiliary storage node for storage and custody - transfer. As long as a bundle is marked such that it is intended for - auxiliary storage, it could be accepted and stored at the auxiliary - storage node, even if it is a duplicate of a previously-received - bundle. If the auxiliary storage node treats all subsequent - forwardings of a bundle after the first forwarding as though the - forwarding were the result of a custodial retransmission by inserting - a Retransmission Block into the bundle, bundles could be circulated - between custodians and their auxiliary storage nodes multiple times - without being summarily deleted. Using these solution approaches, - there would be no limit to the number of times a bundle could be - offloaded to auxiliary storage, if needed. A risk of implementing - these approaches, however, is that bundles that unintentionally loop - between a custodian and its auxiliary storage node may not be - discarded. Furthermore, these approaches assume that all intentional - loops can be known a priori, so that nodes can be configured to - accept duplicate bundles looping through them or that at least one - node in the loop can be configured to insert Retransmission Blocks - into the looping bundles to protect them from being discarded. These - approaches do not necessarily work for loops that arise - opportunistically, being unplanned but useful, unless there is a - mechanism within the loop for retransmission blocks to be inserted - into the looping bundle as appropriate. - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 10] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -5. Ramifications of Allowing Support for the Retransmission Block to be - Optional - - The objective of the DTN Retransmission Block is to make custodially- - retransmitted bundles distinguishable from unintentional and - malicious replays. Because support for the Retransmission Block is - optional, it may not be supported by all nodes in the DTN. Failure - to support the Retransmission Block at one or more nodes in the DTN - may result in the erroneous deletion of bundles that are legitimate - retransmissions because: - - A node that does not support the Retransmission Block but that is - configured to suppress replays will delete all duplicate bundles, - whether or not they include Retransmission Blocks that mark them - as being legitimate retransmissions. - - A custodial node that does not support the Retransmission Block - but that legitimately retransmits a bundle will not include a - Retransmission Block to mark the bundle as a legitimate - retransmission, so that when the bundle is received at a - downstream node that is configured to suppress replays, the bundle - will be deleted by that downstream node (even if that downstream - node supports the Retransmission Block). - - A DTN cannot completely support both replay suppression and custodial - retransmission if some of its nodes do not support the Retransmission - Block. If replays must be suppressed and custodial retransmission - must be supported, all nodes in the network must support the - Retransmission Block. If one or more nodes do not support the - Retransmission Block, then if those nodes are configured to suppress - replays, they will delete custodial retransmissions that they receive - and issue custodial retransmissions that are vulnerable to being - deleted downstream; if they are configured to forward replays, then - they will forward all replays, both intentional and malicious ones. - - Nodes that do not support the Retransmission Block cannot create, - recognize, or process a Retransmission Block. If the Retransmission - Block Processing Flags indicate that a bundle must be deleted if the - Retransmission Block cannot be processed, then all nodes that do not - support the Retransmission Block will delete all custodial - retransmissions, even if these nodes are not configured to suppress - replays. If the Retransmission Block Processing Flags indicate that - the Retransmission Block must be deleted if it cannot be processed, - then all nodes that do not support the Retransmission Block will - strip the Retransmission Block out of every custodial retransmission - that they forward, leaving these custodial retransmissions vulnerable - to downstream deletion by nodes that suppress replays (even if those - downstream nodes support the Retransmission Block). - - - -Symington Expires October 27, 2007 [Page 11] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - If not all nodes in the DTN support the Retransmission Block, then to - preserve support for custodial retransmission while maximizing replay - suppression, the security policies of the nodes and the Block - Processing Flags in the Retransmission Block should be configured as - follows: - - -The "Discard bundle if block can't be processed" Block Processing - Flag SHOULD NOT be set, - - -The "Discard block if it can't be processed" Block Processing - Flag SHOULD NOT be set, - - -Nodes that support the Retransmission Block should be configured - to delete all replays that are not legitimate custodial - retransmissions, - - -Nodes that do not support the Retransmission Block should be - configured to forward duplicates (so that they don't inadvertently - delete custodial retransmissions), and - - -Nodes that do not support the Retransmission Block should be - configured not to take custody of bundles (to ensure that - custodial retransmissions will always include Retransmission - Blocks). - - The above configuration ensures that custodial retransmissions will - not be erroneously deleted, and that all replays that are received at - nodes that support the Retransmission Block will be deleted. Only - replays that are received at nodes that do not support the - Retransmission Block will be forwarded and allowed to remain in the - network. If these are forwarded to a node that supports the - Retransmission Block, however, they will be deleted at that node. - Therefore, a network configured in this way is vulnerable to a - denial-of-service attack only from replayed bundles that circulate - exclusively among nodes that do not support the Retransmission Block. - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 12] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -6. Retransmission Block Format - - The Retransmission Block (RB) is a new block that MAY be included in - a bundle. A RB uses the Canonical Bundle Block Format as defined in - the Bundle Protocol [2]. That is, it is comprised of the following - elements: - - -Block-type code (one byte) - defined as in all bundle protocol - blocks except the primary bundle block (as described in the Bundle - Protocol). The block type code for the Retransmission Block is - 0x07. - - -Block processing control flags (SDNV) - defined as in all bundle - protocol blocks except the primary bundle block (as described in - the Bundle Protocol). The following block processing control flag - MUST NOT be set: - - -Block must be replicated in every fragment - - The following block processing control flag MUST be set: - - -Block contains an EID-reference field - - - Block EID reference count and EID reference - composite field - defined in [2] containing a count of EID references with a value - of 1 (expressed as an SDNV) followed by a single EID reference - (expressed as a pair of SDNVs). Presence of this field is - indicated by the setting of the "block contains an EID reference - field" flag in the block processing control flags to 1. The EID - referenced MUST be that of the retransmitting custodian that - inserted this block. - - -Block data length (SDNV) - defined as in all bundle protocol - blocks except the primary bundle block. SDNV encoding is - described in the Bundle Protocol. - - -Block-type-specific data field as follows: - - - Retransmission sequence number (SDNV) - An unsigned integer - indicating the number of times this bundle has been - retransmitted by this custodian. - - The structure of a Retransmission Block is as follows: - - - - - - - - -Symington Expires October 27, 2007 [Page 13] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - Retransmission Block Format: - +------+--------------+------------------------------+--------------+ - |type |flags (SDNV) |EID ref count and list (comp) |length (SDNV) | - +------+--------------+------------------------------+--------------+ - | Retransmission Sequence Number (SDNV) | - +-------------------------------------------------------------------+ - - Figure 1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 14] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -7. Retransmission Block Processing - - The following are the processing steps that a bundle node must take - relative to generation, reception, and processing of Retransmission - Blocks. - -7.1. Bundle Reception - - According to the Bundle Protocol, if a node receives a bundle that it - currently has in custody as custodian, that node will send a "Failed" - custody signal for this bundle to the bundle's listed current - custodian, but receipt of this duplicate bundle will not cause the - bundle to be either delivered at that node or forwarded to another - node. - - Upon receipt of a bundle that the node does not currently have in - custody, the node SHALL delete the bundle's Retransmission Block if - the endpoint ID referred to by the EID reference field in the - Retransmission Block is not the same as the endpoint ID referred to - by the Custodian scheme and Custodian SSP offsets in the Primary - Bundle Block. The node MAY also delete all strings (scheme names and - scheme-specific parts-SSPs) in the bundle's dictionary to which no - endpoint ID references in the bundle currently refer (if any). - -7.2. Replay Detection and Suppression - - If a node's security policy indicates that replays are not allowed - and if a bundle is received such that the bundle's source EID, - timestamp, and fragment offset and length (if it has one) are - identical to those in a bundle that the node had previously received, - then - - -If the received bundle does not include a Retransmission Block - and the Custodian scheme and Custodian SSP offsets in its Primary - Bundle Block are the same as they were in the previously-received - duplicate bundle and the previously-received duplicate bundle also - did not include an RB, the bundle MUST be deleted. - - -If the received bundle does include a Retransmission Block and - its EID reference and retransmission sequence number values are - the same as those in the Retransmission Block (if any) of the - previously-received, duplicate bundle, the bundle MUST be deleted. - -7.3. Keeping Track of Bundles Received - - If replays are not allowed at this node, and if a bundle will not be - deleted as a replay, the node must store at least the following - information from the bundle: source EID, creation timestamp, - - - -Symington Expires October 27, 2007 [Page 15] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - - lifetime, fragment offset and length (if any), custodian EID (if the - bundle does not include a Retransmission Block) and Retransmission - Block (if any) EID reference and retransmission sequence number for - comparison with future received bundles. - -7.4. Purging stored bundle information - - The stored information for all bundles whose creation timestamp + - lifetime is less than the current time MAY be deleted. - -7.5. Bundle Forwarding - - As part of the custody acceptance procedures, the accepting node MUST - delete the bundle's Retransmission Block (if it has one). - -7.6. Custodial Retransmission - - Upon deciding to re-forward a bundle as a result of custody transfer - failure, the re-forwarding custodian MUST: - - - insert a Retransmission Block with a retransmission sequence - number value of 0 into the bundle if the bundle does not already - include an RB, or - - - increment the retransmission sequence number value in the - Retransmission Block if the bundle does already include an RB. - - In either case, the EID reference in the Retransmission Block MUST - refer to the EID of the re-forwarding custodian as referenced by the - bundle's primary bundle block. - - If a custodian decides to re-forward only a fragment of a bundle that - it had previously forwarded, the re-forwarded fragment will not be a - duplicate of any bundle that had previously been transmitted by this - custodian. Therefore, the re-forwarded fragment SHALL NOT include a - Retransmission Block. - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 16] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -8. Security Considerations - - Each node's local security policy will determine whether replays will - be detected and suppressed at that node or whether replays will be - forwarded indiscriminately. When deciding upon a node's security - policy, it is worth noting that in most networks, the Bundle - Authentication Block (BAB) must be used in conjunction with replay - detection and suppression. It does not make sense to detect and - suppress replayed bundles without first authenticating that those - bundles have not been modified. Without use of the BAB to - authenticate that a bundle has been forwarded in tact, a network is - vulnerable to denial of service attacks launched merely by the - injection of any spurious bundles into the network or the - modification of any authentic bundles. There seems little value in - protecting against denial-of-service attacks resulting from replayed - bundles if denial-of-service attacks resulting from such modified or - spurious bundles will be permitted. Therefore, in determining the - security policy of a node, it will usually be the case that nodes - that do not allow replays must also require received bundles to - include BABs. - - Because the RB may be inserted at any custodian in the network and - deleted at any subsequent custodian, its integrity can't be protected - by an end-to-end Payload Security Block (PSB) [3]. Its integrity - must be protected by the BAB. If the integrity of the RB is not - protected by the BAB, then a malicious intruder could modify the RB - to inject many illegitimately replayed bundles, yet give the RB - values such that these bundles appear to be legitimate - retransmissions. As currently defined, protection for the RB will be - included when using the mandatory BAH-HMAC ciphersuite defined in the - Bundle Security Protocol, given that this ciphersuite uses the strict - canonicalisation algorithm. - - If a node is compromised, this BAB doesn't help to protect against - replays, but then the network has a lot more vulnerabilities than - just a vulnerability to replays. If a node is compromised, any - bundle could be created and injected into the network. The RB - mechanism is no more vulnerable to misuse by a compromised node than - are any of the other security mechanisms. - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 17] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -9. IANA Considerations - - If the bundle protocol becomes a standards track protocol, then we - may want to consider having IANA establish a register of block types, - of which the Retransmission Block would be one. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 18] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -10. References - -10.1. Normative References - - [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to - Indicate Requirement Levels", RFC 2119, October 1997. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-09.txt, work-in-progress, - April 2007. - - [3] Symington, S., Farrell, S., Weiss, H., and P. Lovell, "Bundle - Security Protocol Specification", - draft-irtf-dtnrg-bundle-security-03.txt, work-in-progress, - April 2007. - -10.2. Informative References - - [4] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., - Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network - Architecture", RFC 4838, April 2007. - - [5] Farrell, S., Symington, S., Weiss, H., and P. Lovell, "Delay- - Tolerant Network Security Overview", - draft-irtf-dtnrg-sec-overview-03.txt, work-in-progress, - April 2007. - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 19] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -Author's Address - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington Expires October 27, 2007 [Page 20] -=0C -Internet-Draft DTN Retransmission Block April 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Symington Expires October 27, 2007 [Page 21] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-bundle-security-0= 3.txt --- a/doc/draft-irtf-dtnrg-bundle-security-03.txt Sat Dec 12 17:10:03 2009 = +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2184 +0,0 @@ - - - -DTN Research Group S. Symington -Internet-Draft The MITRE Corporation -Expires: October 26, 2007 S. Farrell - Trinity College Dublin - H. Weiss - P. Lovell - SPARTA, Inc. - April 24, 2007 - - - Bundle Security Protocol Specification - draft-irtf-dtnrg-bundle-security-03 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on October 26, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 1] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -Abstract - - This document defines the bundle security protocol, which provides - data integrity and confidentiality services. We also describe - various bundle security considerations including policy options. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Security Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 - 2.1. Abstract Security Block . . . . . . . . . . . . . . . . . 7 - 2.2. Bundle Authentication Block . . . . . . . . . . . . . . . 10 - 2.3. Payload Security Block . . . . . . . . . . . . . . . . . . 11 - 2.4. Confidentiality Block . . . . . . . . . . . . . . . . . . 12 - 2.5. PSB and CB combinations . . . . . . . . . . . . . . . . . 14 - 3. Security Processing . . . . . . . . . . . . . . . . . . . . . 16 - 3.1. Nodes as policy enforcement points . . . . . . . . . . . . 16 - 3.2. Canonicalisation of bundles . . . . . . . . . . . . . . . 16 - 3.3. Endpoint ID confidentiality . . . . . . . . . . . . . . . 22 - 3.4. Bundles received from other nodes . . . . . . . . . . . . 22 - 3.5. The At-Most-Once-Delivery Option . . . . . . . . . . . . . 24 - 3.6. Bundle Fragmentation and Reassembly . . . . . . . . . . . 24 - 3.7. Reactive fragmentation . . . . . . . . . . . . . . . . . . 25 - 4. Mandatory Ciphersuites . . . . . . . . . . . . . . . . . . . . 27 - 4.1. BAB-HMAC . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 4.2. PSB-RSA-SHA256 . . . . . . . . . . . . . . . . . . . . . . 28 - 4.3. CB-RSA-AES128-PAYLOAD-PSB . . . . . . . . . . . . . . . . 28 - 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 30 - 6. Default Security Policy . . . . . . . . . . . . . . . . . . . 31 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 35 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 35 - Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 - Intellectual Property and Copyright Statements . . . . . . . . . . 39 - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 2] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -1. Introduction - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [1]. - - This document defines security features for the bundle protocol [2] - intended for use in delay tolerant networks, in order to provide the - DTN security services as described in the DTN Security Overview and - Motivations document [8]. - - The bundle protocol is used in DTNs which overlay multiple networks, - some of which may be challenged by limitations such as intermittent - and possibly unpredictable loss of connectivity, long or variable - delay, asymmetric data rates, and high error rates. The purpose of - the bundle protocol is to support interoperability across such - stressed networks. The bundle protocol is layered on top of - underlay-network-specific convergence layers, on top of network- - specific lower layers, to enable an application in one network to - communicate with an application in another network, both of which are - spanned by the DTN. - - Security will be important for the bundle protocol. The stressed - environment of the underlying networks over which the bundle protocol - will operate makes it important that the DTN be protected from - unauthorized use, and this stressed environment poses unique - challenges on the mechanisms needed to secure the bundle protocol. - Furthermore, DTNs may very likely be deployed in environments where a - portion of the network might become compromised, posing the usual - security challenges related to confidentiality, integrity and - availability. - -1.1. Related Documents - - This document is best read and understood within the context of the - following other DTN documents: - - The Delay-Tolerant Network Architecture [9] defines the - architecture for delay-tolerant networks, but does not discuss - security at any length. - - The DTN Bundle Protocol [2] defines the format and processing of - the blocks used to implement the bundle protocol, excluding the - security-specific blocks defined here. - - The Delay-Tolerant Networking Security Overview [8] provides an - informative overview and high-level description of DTN security. - - - - -Symington, et al. Expires October 26, 2007 [Page 3] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -1.2. Terminology - - We introduce the following terminology for purposes of clarity: - - source - the bundle node from which a bundle originates - - destination - the bundle node to which a bundle is ultimately - destined - - forwarder - the bundle node that forwarded the bundle on its most - recent hop - - intermediate receiver or "next hop" - the neighboring bundle node - to which a forwarder forwards a bundle. - - In the figure below, which is adapted from figure 1 in the Bundle - Protocol Specification, four bundle nodes (denoted BN1, BN2, BN3, and - BN4) reside above some transport layer(s). Three distinct transport - and network protocols (denoted T1/N1, T2/N2, and T3/N3) are also - shown. - - - - - +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ - |BN1 v | | ^ BN2 v | | ^ BN3 v | | ^ BN4 | - +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ - |Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | - +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ - |Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | - +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ - | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | - +-----------+ +------------+ +-------------+ +-----------+ - | | | | - |<-- An Internet --->| |<--- An Internet --->| - | | | | - - BN =3D "Bundle Node" (as defined in the Bundle Protocol Specification - - Bundle Nodes Sit at the Application layer of the Internet Model. - - Figure 1 - - Bundle node BN1 originates a bundle that it forwards to BN2. BN2 - forwards the bundle to BN3, and BN3 forwards the bundle to BN4. BN1 - is the source of the bundle and BN4 is the destination of the bundle. - BN1 is the first forwarder, and BN2 is the first intermediate - receiver; BN2 then becomes the forwarder, and BN3 the intermediate - - - -Symington, et al. Expires October 26, 2007 [Page 4] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - receiver; BN3 then becomes the last forwarder, and BN4 the last - intermediate receiver, as well as the destination. - - If node BN2 originates a bundle (for example, a bundle status report - or a custodial signal), which is then forwarded on to BN3, and then - to BN4, then BN2 is the source of the bundle (as well as being the - first forwarder of the bundle) and BN4 is the destination of the - bundle (as well as being the final intermediate receiver). - - We introduce the following security-specific DTN terminology: - - security-source - a bundle node that adds a security block to a - bundle - - security-destination - a bundle node that processes a security - block of a bundle - - Referring to figure 1 again: - - If the bundle that originates at BN1 as source is given a security - block by BN1, then BN1 is the security-source of this bundle with - respect to that security block, as well as being the source of the - bundle. - - If the bundle that originates at BN1 as source is given a security - block by BN2, then BN2 is the security-source of this bundle with - respect to that security block, even though BN1 is the source. - - If the bundle that originates at BN1 as source is given a security - block by BN1 that is intended to be processed by BN3, then BN1 is the - security-source and BN3 is the security destination with respect to - this security block. - - A bundle may have multiple security blocks. The security-source of a - bundle with respect to a given security block in the bundle may be - the same as or different from the security-source of the bundle with - respect to a different security block in the bundle. Similarly, the - security-destination of a bundle with respect to each of that - bundle's security blocks may be the same or different. - - Forwarding nodes MUST transmit blocks in the same order as they were - received. This requirement applies to all dtn nodes, not just ones - which implement security processing. Blocks in a bundle may be added - or deleted according to the applicable specification, but blocks - which are received and then transmitted MUST remain in the same - relative order. - - - - - -Symington, et al. Expires October 26, 2007 [Page 5] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -2. Security Blocks - - There are three types of security blocks that MAY be included in a - bundle. These are the Bundle Authentication Block (BAB), the Payload - Security Block (PSB), and the Confidentiality Block (CB). - - The BAB is used to assure the authenticity of the bundle along a - single hop from forwarder to intermediate receiver. - - The PSB is used to assure the authenticity of the bundle from the - PSB security-source, which creates the PSB, to the PSB security- - destination, which verifies the PSB authenticator. The - authentication information in the PSB may (if the ciphersuite - allows) be verified by any node in between the PSB security-source - and the PSB security-destination that has access to the - cryptographic keys and revocation status information required to - do so. - - Since a BAB protects on a "hop-by-hop" basis and a PSB protects on - a (sort of) "end-to-end" basis, whenever both are present the BAB - MUST form the "outer" layer of protection - that is, the BAB MUST - always be calculated and added to the bundle after the PSB has - been calculated and added to the bundle. - - The CB indicates that some parts of the bundle have been encrypted - while en route between the CB security-source and the CB security- - destination. - - Each of the security blocks uses the Canonical Bundle Block Format as - defined in the Bundle Protocol Specification. That is, each security - block is comprised of the following elements: - - - Block type code - - - Block processing control flags - - - Block EID reference list (optional) - - - Block data length - - - Block-type-specific data fields - - Since the three security blocks have most fields in common, we can - shorten the description of the Block-type-specific data fields of - each security block if we first define an abstract security block - (ASB) and then specify each of the real blocks in terms of the fields - which are present/absent in an ASB. Note that no bundle ever - contains an ASB, which is simply a specification artifact. - - - -Symington, et al. Expires October 26, 2007 [Page 6] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -2.1. Abstract Security Block - - An ASB consists of the following mandatory and optional fields: - - - Block-type code (one byte) - as in all bundle protocol blocks - except the primary bundle block. The block types codes for the - security blocks are: - - BAB: 0x02 - - PSB: 0x03 - - CB: 0x04 - - - Block processing control flags (SDNV) - defined as in all bundle - protocol blocks except the primary bundle block (as described in - the Bundle Protocol [2]). SDNV encoding is described in the - bundle protocol. There are no constraints on the use of the block - processing flags.[Comment.1] - - - EID references - composite field defined in [2] containing - references to one or two EIDs. Presence of EIDs is indicated by - by the setting of bit 6 ("block contains an EID-reference field") - of the block processing control flags. If one or more is present, - flags in the ciphersuite ID field, described below, specify which. - The possible EIDs are, in order:- - - - (optional) Security-source - specifies the security source for - the service. If this is omitted, then the source of the bundle is - assumed to be the security-source. - - - (optional) Security-destination - specifies the security - destination for the service. If this is omitted, then the - destination of the bundle is assumed to be the security- - destination. - - Both EID fields may be omitted, in which case the composite field - itself is empty, as defined in [2]. In this case neither count - nor references appear, and bit 6 is not set. - - - Block data length (SDNV) - as in all bundle protocol blocks - except the primary bundle block. SDNV encoding is described in - the bundle protocol. - - - Block-type-specific data fields as follows: - - - Ciphersuite ID - identifies the ciphersuite in use. This is - two bytes long, though the top five bits are used to indicate - - - -Symington, et al. Expires October 26, 2007 [Page 7] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - the presence or absence of the optional fields below. - - - (optional) Correlator - when more than one related block is - inserted then this field must have the same value in each - related block instance. This is encoded as an SDNV. See note - in Section 3.6 with regard to correlator values in bundle - fragments. - - - (optional) Ciphersuite parameters - compound field of next - two items - - - Ciphersuite parameters length - specifies the length of - the following Ciphersuite parameters data field and is - encoded as an SDNV. - - - Ciphersuite parameters data - parameters to be used with - the ciphersuite in use, e.g. a key identifier or - initialization vector (IV). The encoding rules for this - field are defined as part of the ciphersuite specification. - - - (optional) Security result - compound field of next two items - - - Security result length - contains the length of the next - field and is encoded as an SDNV. - - - Security result data - contains the results of the - appropriate ciphersuite-specific calculation (e.g. a - signature, MAC or ciphertext block key). - - - +----------------+----------------+----------------+----------------+ - | type | flags (SDNV) | EID ref list(comp) | - +----------------+----------------+----------------+----------------+ - | length (SDNV) | - +----------------+----------------+----------------+----------------+ - | ciphersuite | correlator (SDNV) | - +----------------+----------------+----------------+----------------+ - |params len(SDNV)| ciphersuite params data | - +----------------+----------------+----------------+----------------+ - |res-len (SDNV) | security result data | - +----------------+----------------+----------------+----------------+ - - The structure of an abstract security block - - Figure 2 - - The ciphersuite ID is a 16-bit value with the top five bits - indicating which of the optional fields are present (value =3D "1") or - - - -Symington, et al. Expires October 26, 2007 [Page 8] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - absent (value=3D"0"). The remaining 11 bits indicate the ciphersuite. - - Some ciphersuites are specified in Section 4, which also specifies - the rules which MUST be satisfied by ciphersuite specifications. - Additional ciphersuites MAY be defined in separate specifications. - - The structure of the ciphersuite ID bytes is shown in Figure 3. In - each case the presence of an optional field is indicated by setting - the value of the corresponding flag to one. A value of zero - indicates the corresponding optional field is missing. - - src - the most significant bit (bit 0) indicates whether the ASB - contains the optional security-source-length and security-source - fields. - - dest - bit 1 indicates whether the security-destination-length and - security-destination fields are present or not. - - parm - bit 2 indicates whether the ciphersuite-parameters-length - and ciphersuite parameters data fields are present or not. - - corr - bit 3 indicates whether or not the ASB contains an optional - correlator. - - res - bit 4 indicates whether or not the ASB contains the security - result length and security result data fields. - - bits 5-15 represent the ciphersuite number, giving a maximum of - 2048 different ciphersuites. - - - - Ciphersuite ID - Bit Bit Bit Bit Bit Bit Bit Bit - 0 1 2 3 4 5 ... 15 - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - |src |dest |parm |corr |res | ciphersuite ID | - +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ - - Figure 3 - - A little bit more terminology: when the block is a PSB then we refer - to the PSB-source when we mean the security source field in the PSB. - Similarly we may refer to the CB-dest, meaning the security- - destination field of the CB. For example, referring to Figure 1 - again, if the bundle that originates at BN1 as source is given a - Confidentiality Block (CB) by BN1 that is protected using a key held - by BN3 and it is given a Payload Security Block (PSB) by BN1, then - - - -Symington, et al. Expires October 26, 2007 [Page 9] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - BN1 is both the CB-source and the PSB-source of the bundle, and BN3 - is the CB-dest of the bundle. - - The correlator field is used to associate several related instances - of a security block. This can be used to place a BAB that contains - the ciphersuite information at the "front" of a (probably large) - bundle , and another correlated BAB that contains the security result - at the "end" of the bundle. This allows even very memory-constrained - nodes to be able to process the bundle and verify the BAB. There are - similar use cases for multiple related instances of PSB and CB as - will be seen below. - - The ciphersuite specification MUST make it clear whether or not - multiple block instances are allowed, and if so, under what - conditions. Some ciphersuites can of course leave flexibility to the - implementation, whereas others might mandate a fixed number of - instances. - -2.2. Bundle Authentication Block - - In this section we describe typical BAB field values for two - scenarios - where a single instance of the BAB contains all the - information and where two related instances are used, one "up front" - which contains the ciphersuite and another following the payload - which contains the security result (e.g. a MAC). - - For the case where a single BAB is used: - - The block-type code field value MUST be 0x02. - - The block processing control flags value can be set to whatever - values are required by local policy. - - The ciphersuite ID MUST be documented as a hop-by-hop - authentication-ciphersuite which requires one instance of the BAB. - - The correlator field MUST NOT be present. - - The ciphersuite parameters field MAY be present, if so specified - in the ciphersuite specification. - - The security-source field SHOULD be present and, if it is present, - it MUST identify the forwarder of the bundle. (If the forwarding - node is identified in another block of the bundle that the next - hop supports, e.g., the Previous Hop Insertion Block, the - forwarding node need not be identified in the BAB.) - - - - - -Symington, et al. Expires October 26, 2007 [Page 10] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - The security-destination field SHOULD NOT be present unless the - ciphersuite requires this information (since the first node - receiving the bundle ought be the one to validate the BAB). - - The security result MUST be present as it is effectively the - "output" from the ciphersuite calculation (e.g. the MAC or - signature) applied to the (relevant parts of) the bundle (as - specified in the ciphersuite definition). - - For the case using two related BAB instances, the first instance is - as defined above, except the ciphersuite ID MUST be documented as a - hop-by-hop authentication ciphersuite that requires two instances of - the BAB. In addition, the correlator MUST be present and the - security result length and security result fields MUST be absent. - The second instance of the BAB MUST have the same correlator value - present and MUST contain security result length and a security result - fields. The other optional fields MUST NOT be present. Typically, - this second instance of a BAB will be the last block of the bundle. - -2.3. Payload Security Block - - A PSB is an ASB with the following additional restrictions: - - The block type code value MUST be 0x03. - - The block processing control flags value can be set to whatever - values are required by local policy. - - The ciphersuite ID MUST be documented as an end-to-end - authentication-ciphersuite or as an end-to-end error-detection- - ciphersuite. - - The correlator MUST be present if the ciphersuite requires more - than one related instance of a PSB be present in the bundle. The - correlator MUST NOT be present if the ciphersuite only requires - one instance of the PSB in the bundle. - - The ciphersuite parameters field MAY be present. - - The security-source field MAY be present. - - The security-destination field MAY be present. - - The security result is effectively the "output" from the - ciphersuite calculation (e.g. the MAC or signature) applied to the - (relevant parts of) the bundle. As in the case of the BAB, this - field MUST be present if the correlator is absent. If more than - one related instance of the PSB is required then this is handled - - - -Symington, et al. Expires October 26, 2007 [Page 11] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - in the same way as described for the BAB above. - - For some ciphersuites, (e.g. those using asymmetric keying to produce - signatures or those using symmetric keying with a group key), the - security information can be checked at any hop on the way to the - destination that has access to the required keying information. - - Most asymmetric PSB-ciphersuites will use the PSB-source to indicate - the signer and will not require the PSB-dest field because the key - needed to verify the PSB authenticator will be a public key - associated with the PSB-source. - -2.4. Confidentiality Block - - A typical confidentiality ciphersuite will encrypt the payload using - a randomly generated bundle encrypting key (BEK) and will use a CB - security result to carry the BEK encrypted with some long term key - encryption key (KEK). or well-known public key. If neither the - destination or security-destination resolves the key to use for - decryption, the ciphersuite parameters field can be used to indicate - the decryption key with which the BEK can be recovered. Subsequent - CB security results will contain blocks encrypted using the BEK if - non-payload blocks are to be encrypted. - - The payload is encrypted "in-place", that is, following encryption, - the payload block payload field contains ciphertext, not plaintext. - The payload block processing flags are unmodified.[Comment.2] - - Payload super-encryption is allowed. If a CB ciphersuite supports - such super-encryption, then the ciphersuite MUST provide an - unambiguous way to do the decryption operations in the correct order - (e.g. by encoding the "layer" information as a ciphersuite - parameter). This "in-place" encryption of payload bytes is so as to - allow bundle payload fragmentation and re-assembly to operate without - knowledge of whether encryption has occurred. A side-effect of this - "in-place" encryption is that the payload will typically be expanded - by up-to a ciphertext blocksize if the bulk cipher is a block cipher. - Another is that the 2nd application of confidentiality does not - generally protect the parameters of the first which represent a - vulnerability in some circumstances. - - A CB is an ASB with the following additional restrictions: - - The block type code value MUST be 0x04. - - The block processing control flags value can be set to whatever - values are required by local policy. - - - - -Symington, et al. Expires October 26, 2007 [Page 12] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - The ciphersuite ID MUST be documented as a confidentiality- - ciphersuite. - - The correlator MUST be present if more than one related CB - instance is required. More than one CB instance might be required - if the payload is to be encrypted for more than one security- - destination so as to be robust in the face of routing - uncertainties. These multiple CB instances, however, would not be - related and would therefore not require correlators. On the other - hand, multiple related CB instances would be required if both the - payload and the PSB blocks in the bundle were to be encrypted. - These multiple CB instances would require correlators to associate - them with each other. The correlator MUST NOT be present if there - are no related CB instances. - - The ciphersuite parameters field MAY be present - - The security-source field MAY be present. - - The security-destination field MAY be present (and typically will - be). - - The security result MAY be present and normally represents an - encrypted bundle encryption key or encrypted versions of bundle - blocks other than the payload block. - - As was the case for the BAB and PSB, if the ciphersuite requires more - than one instance of the CB, then the first occurrence MUST contain - any optional fields (e.g. security destination etc.) that apply to - all instances with this correlator. These MUST be contained in the - first instance and MUST NOT be repeated in other correlated blocks. - Fields that are specific to a particular instance of the CB MAY - appear in that CB. For example, the security result field MAY (and - probably will) be included in multiple related CB instances. - Similarly, subsequent CBs might each contain a ciphersuite parameters - field with an IV specific to that CB instance. - - Put another way: when a node is encrypting some (non-payload) blocks, - it MUST first create a CB with the required ciphersuite ID, - parameters etc. as specified above. Typically, this CB will appear - "early" in the bundle. If this "first" CB doesn't contain all of the - ciphertext, then it may be followed by other (correlated) CB, which - MUST NOT repeat the ciphersuite parameters, security-source, or - security-destination fields from the first CB. - - A CB ciphersuite may, or may not, specify which blocks are to be - encrypted. If the ciphersuite doesn't specify this, then the node is - free to encrypt whichever blocks it wishes. If a CB ciphersuite does - - - -Symington, et al. Expires October 26, 2007 [Page 13] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - specify which blocks are to be encrypted, then doing otherwise is an - error. - - Since a single CB security result can contain the ciphertext for - multiple (non-payload) plaintext blocks, the node simply catenates - these plaintext blocks prior to encryption. After decryption the - recovered plaintext should then replace the CB in the bundle for - further processing (e.g. PSB verification). This recovered - plaintext MUST contain all the appropriate block type, processing - flags and length information. In other words delete the CB in - question and place the recovered plaintext, which consists of - additional (non-payload) blocks, in the bundle at the location from - which the CB was deleted. - - Even if a to-be-encrypted block has the "discard" flag set, whether - or not the CB's "discard" flag is set is an implementation/policy - decision for the encrypting node. (The "discard" flag is more - properly called the "discard if block cannot be processed" flag.) - -2.5. PSB and CB combinations - - Given the above definitions, nodes are free to combine applications - of PSB and CB in any way they wish - the correlator value allows for - multiple applications of security services to be handled separately. - - However, there are some clear security problems that could arise when - applying multiple services, for example, if we encrypted a payload - but left a PSB security result containing a signature in clear, this - would allow payload guesses to be confirmed. - - We cannot, in general, prevent all such problems since we cannot - assume that every ciphersuite definition takes account of every other - ciphersuite definition. However, we can limit the potential for such - problems by requiring that any ciphersuite which applies to one - instance of a PSB or CB, must be applied to all instances with the - same correlator. - - We now list the PSB and CB combinations which we envisage as being - useful to support: - - Encrypted tunnels - a single bundle may be encrypted many times - en-route to its destination. Clearly it must be decrypted an - equal number of times, but we can imagine each encryption as - representing the entry into yet another layer of tunnel. This is - supported by using multiple instances of CB, but with the payload - encrypted multiple times, "in-place". - - - - - -Symington, et al. Expires October 26, 2007 [Page 14] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - Multiple parallel authenticators - a single security source might - wish to integrity protect a bundle in multiple ways, in the hope - that one of them will be useful. This could be required if the - path the bundle will take is unpredictable, and if various nodes - might be involved as security destinations. Similarly, if the - security source cannot determine in advance which algorithms to - use, then using all might be reasonable. This would result in - uses of PSB which presumably all protect the payload, and which - cannot in general protect one another. Note that this logic can - also apply to a BAB, if the unpredictable routing happens in the - convergence layer, so we also envisage support for multiple - parallel uses of BAB. - - Multiple sequential authenticators - if some security destination - requires assurance about the route that bundles have taken, then - it might insist on each forwarding node adding its own PSB. More - likely however would be that outbound "bastion" nodes would be - configured to sign bundles as a way of allowing the sending - "domain" to take accountability for the bundle. In this case, the - various PSBs will likely be layered, so that each protects the - earlier applications of PSB. - - Authenticated and encrypted bundles - a single bundle may require - both authenticity and confidentiality. In this case, most - specifications first apply the authenticator and follow this by - encrypting the payload and authenticator. As noted previously in - the case where the authenticator is a signature, there are - security reasons for this ordering. (See the CB-RSA-AES128- - PAYLOAD-PSB ciphersuite defined later in Section 4.3.) - - There are no doubt other valid ways to combine PSB and CB instances, - but these are the "core" set we wish to support. Having said that, - as will be seen, the mandatory ciphersuites defined here are quite - specific and restrictive in terms of limiting the flexibility offered - by the correlator mechanism. This is primarily in order to keep this - specification as simple as possible, while at the same time - supporting the above scenarios. - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 15] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -3. Security Processing - - This section describes the security aspects of bundle processing. - -3.1. Nodes as policy enforcement points - - All nodes are REQUIRED to have and enforce their own configurable - security policies, whether these policies be explicit or default, as - defined in Section 6. - - All nodes serve as Policy Enforcement Points (PEP) insofar as they - enforce polices that may restrict the permissions of bundle nodes to - inject traffic into the network. If a particular transmission - request satisfies the node's policy and is therefore accepted, then - an outbound bundle can be created and dispatched. If not, then in - its role as a PEP, the node will not create or forward a bundle. - Error handling for such cases is currently considered out of scope of - this document.[Comment.3] - - Policy enforcing code MAY override all other processing steps - described here and elsewhere in this document. For example, it is - valid to implement a node which always attempts to attach a PSB. - Similarly it is also valid to implement a node which always rejects - all requests which imply the use of a PSB. - - Nodes MUST consult their security policy to determine the criteria - that a received bundle ought to meet before it will be forwarded. - These criteria MUST include a determination of whether or not the - received bundle must include valid BAB, PSB or CB. If the bundle - does not meet the node's policy criteria, then the bundle MUST be - discarded and processed no further; in this case, a bundle status - report indicating the failure MAY be generated, destined for the - forwarding node's own endpoint.[Comment.4] - - The node's policy MAY call for the node to add or subtract some - security blocks, for example, requiring the node attempt to encrypt - (parts of) the bundle for some security-destination, or requiring - that the node add a PSB. If the node's policy requires a BAB to be - added to the bundle, it MUST be added last so that the calculation of - its security result may take into consideration the values of all - other blocks in the bundle. - -3.2. Canonicalisation of bundles - - In order to verify a signature or MAC on a bundle the exact same - bits, in the exact same order, must be input to the calculation upon - verification as were input upon initial computation of the original - signature or MAC value. Consequently, a node SHOULD NOT change the - - - -Symington, et al. Expires October 26, 2007 [Page 16] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - encoding of any URI in the dictionary field, e.g., changing the DNS - part of some HTTP URL from lower case to upper case. Because bundles - may be modified while in transit (either correctly or due to - implementation errors), a canonical form of any given bundle (that - contains a BAB or PSB) must be defined. - - This section defines two bundle canonicalisation algorithms which can - be used by various ciphersuites. - -3.2.1. Strict canonicalisation - - The first algorithm which can be used basically permits no changes at - all to the bundle between when it is forwarded at the security-source - and when it is received at the security-destination and is mainly - intended for use in BAB ciphersuites. This algorithm simply involves - catenating all blocks in the order presented, but omits all security - result fields which are present in blocks of the ciphersuite type in - question - that is, when a BAB ciphersuite specifies this algorithm - then we omit all BAB security results, when a PSB ciphersuite - specifies this algorithm then we omit all PSB security results. (All - security result length fields are included, even though their - corresponding security result length fields may be omitted.) - - Notes: - - - In the above we call for security results to be omitted. This - means that no bytes at all of the security result are input. We - do not set the security result length to zero. Rather, we are - assuming that the security result length will be known to the - module that implements the ciphersuite before the security result - is calculated, and that this value will be in the security result - length field even though the security result itself will be - omitted. - - - The 'res' bit of the ciphersuite ID, which indicates whether or - not the security result length and security result data field are - present, is part of the canonical form. - - -The value of the block data length field, which indicates the - length of the block, is also part of the canonical form. Its - value indicates the length of the entire bundle when the bundle - includes the security result field. - - -BABs are always added to bundles after PSBs, so when a PSB - ciphersuite specifies this strict canonicalisation algorithm and - the PSB is received with a bundle that also includes one or more - BABs, application of strict canonicalisation as part of the PSB - security result verification process requires that all BABs in the - - - -Symington, et al. Expires October 26, 2007 [Page 17] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - bundle be ignored entirely. - -3.2.2. Mutable canonicalisation - - This algorithm is mainly intended to protect parts of the bundle - which should not be changed in-transit, and hence it omits the - mutable parts of the bundle. - - The basic approach is to define a canonical form for the primary - block, and catenate that with the security and payload blocks in the - order that they will be transmitted. This algorithm ignores all - other blocks on the basis that we cannot tell whether or not they are - liable to change as the bundle transits the network. - - Endpoint ID references in security blocks are canonicalized using the - de-referenced text form in place of the reference pair. The - reference count is not included. - - The canoncial form of the primary block is shown below. Essentially, - it de-references the dictionary block, adjusts lengths where - necessary and ignores flags that may change in transit. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 18] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - +----------------+----------------+----------------+----------------+ - | Version | Proc. Flags | COS Flags | SRR Flags | - +----------------+----------------+---------------------------------+ - | Canonical primary block length | - +----------------+----------------+---------------------------------+ - | Destination endpoint ID length | - +----------------+----------------+---------------------------------+ - | | - | Destination endpoint ID | - | | - +----------------+----------------+---------------------------------+ - | Source endpoint ID length | - +----------------+----------------+----------------+----------------+ - | | - | Source endpoint ID | - | | - +----------------+----------------+---------------------------------+ - | Report-to endpoint ID length | - +----------------+----------------+----------------+----------------+ - | | - | Report-to endpoint ID | - | | - +----------------+----------------+----------------+----------------+ - | | - + Creation Timestamp (2 x SDNV) + - | | - +---------------------------------+---------------------------------+ - | Lifetime | - +----------------+----------------+----------------+----------------+ - | Fragment offset (optional) | - +----------------+----------------+---------------------------------+ - | Total application data unit length (optional) | - +----------------+----------------+---------------------------------+ - - The canonical form of the primary bundle block. - - Figure 4 - - The fields shown are: - - Version, Processing Flags, COS, SRR - are all copied from the - first four bytes of the primary block and will contain the version - and the immutable flag values from the primary block. Formed by - copying the processing, COS and SRR flag fields from the primary - block and then subsequently setting all of the mutable bits to - zero. This requires ANDing with the (four byte) value 0xFF3E031F - so that the mutable and reserved bits are set to zero. The only - currently mutable bit masked out here is the "bundle is a - - - -Symington, et al. Expires October 26, 2007 [Page 19] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - fragment" bit - all others are reserved bits. Note also that, - since the flags fields are packed into an SDNV, adding a bit might - change its length and thereby invalidate the signature even though - the extra bit is not included in the canonicalization. To prevent - this error, canonicalization uses the non-SDNV form of the flags - field, along with the appropriate mask. As described in [2], the - maximum size supported for SDNV encoding is 64 bits. - Canonicalization therefore uses the 64-bit decoded value, masked - as described above. - - There is an issue here which PSB ciphersuites MUST tackle. If a - bundle is fragmented before the PSB is applied then the PSB - applies to a fragment and not the entire bundle. However, the - protected fragment could be subsequently further fragmented, which - would leave the verifier unable to know which bytes were protected - by the PSB. For this reason, PSB ciphersuites which support - applying a PSB to fragments MUST specify which bytes of the bundle - payload are protected as part of the ciphersuite parameters. When - verifying such a fragment only the bytes from the fragment are - input to the PSB verification. Of course, if is also valid for a - ciphersuite to be specified so as to only apply to entire bundles - and not to fragments. - - Length - a four-byte value containing the length (in bytes) of - this structure.[Comment.5] - - Destination endpoint ID length and value - are the length (as a - four byte value) and value of the destination endpoint ID from the - primary bundle block. The URI is simply copied from the relevant - part(s) of the dictionary block and is not itself canonicalised. - - Source endpoint ID length and value are handled similarly to the - destination. - - Report-to endpoint ID length and value are handled similarly to - the destination. - - Creation time and Lifetime are simply copied from the primary - block. - - Fragment offset and Total application data unit length are copied - from the primary block if they are present there (which is - controlled by one of the flags). - - Payload blocks are generally copied as-is, with the exception that - the processing flags value in the canonical version MUST be ANDed - with 0x37 to ensure that currently "reserved" flags are clear and - that the "last block" flag is ignored. The reason to ignore the - - - -Symington, et al. Expires October 26, 2007 [Page 20] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - "last block" flag is that if a bundle is created with both PSB and - BAB, then the next hop will remove the BAB instances, and if one of - those was the last block, it may set the "last block" flag of, e.g., - a PSB instance. The "last block" flag is therefore a mutable bit and - should be omitted from the canonical form. Note that the "Block was - forwarded without being processed" flag is included in the canonical - form of the Payload Block because this flag is never expected to be - set by any node; all nodes are required to be able to process the - Payload Block. The SDNV considerations described above for the - primary block flags field apply also to the flags field of the - payload and other non-primary blocks. - - Another exception occurs in cases where only a fragment of the - payload was protected, when only those bytes of the payload block - payload field are considered part of the canonical form. - - Security blocks are handled likewise, with two exceptions: - - - the "Block was forwarded without being processed" flag MUST be - omitted from the canonical form of the PSB and the CB because this - flag may be set by a node located between the security-source and - the security-destination. Therefore, the processing flags value - of the PSB and the CB in the canonical version MUST be ANDed with - 0x17 to ensure that the mutable "Block was forwarded without being - processed" flag is ignored during canonicalization of these - blocks. - - - the ciphersuite will likely specify that the "current" security - block security result field not be considered part of the - canonical form. This differs from the case in strict - canonicalisation since we might use the mutable canonicalisation - algorithm to handle sequential signatures, where later signatures - should cover earlier ones. - - Notes: - - - The canonical form of the bundle is not what is transmitted. It - is simply an artifact that is used as input to digesting. - - - We omit the reserved flags on the basis that we cannot determine - whether or not they will change in transit. This means that this - algorithm may have to be revised if those flags are given a - definition and if we want to protect them. - - - Our URI encoding does not preserve the "null-termination" - convention from the dictionary field, nor do we separate the - scheme and ssp as is done there. - - - - -Symington, et al. Expires October 26, 2007 [Page 21] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - - Note that the URI encoding above will be a cause for errors if - any node rewrites the dictionary for example changing the DNS part - of some HTTP URL from lower-case to upper case. This could happen - transparently, for example, when a bundle is synched to disk using - one set of software and then read from disk and forwarded by a - second set of software. Because there are no exact general rules - for canonicalising URIs (or even worse IRIs), this problem may be - an unavoidable source of integrity failures. - - - All length fields here are four byte values in network byte - order. We do not need to optimize the encoding since the values - are never sent over the network. - -3.3. Endpoint ID confidentiality - - Since every bundle MUST contain a primary block that cannot be - encrypted, and which contains the source endpoint ID (and others), if - we want to provide endpoint ID confidentiality, then we have to - invent a fake primary block with false values for these fields and - then a new block type to contain the actual values. - - Similarly, there may be confidentiality requirements applying to - other parts of the primary block (e.g. the current-custodian) and we - support these in the same way. - - Since we don't know if we'll do this...details are TBD:-)[Comment.6] - - 3.4. Bundles received from other nodes - - Nodes implementing this specification SHALL consult their security - policy to determine whether or not a received bundle is required by - policy to include a BAB. If the bundle is not required to have a - BAB, then BAB processing on the received bundle is complete and the - bundle is ready to be further processed for CB/PSB handling or - delivery or forwarding. - - If the bundle is required to have a BAB but it does not, then the - bundle MUST be discarded and processed no further. If the bundle is - required to have a BAB but all of its BABs identify a different node - other than the receiving node as the BAB security destination, then - the bundle MUST be discarded and processed no further. - - Otherwise, if the bundle does have a BAB that either does not have a - security destination field or that identifies the receiving node as - the BAB security destination, then the value in the security result - field of the BAB MUST be verified according to the ciphersuite - specification. If for all such BABs in the bundle either the BAB - security source cannot be determined or the security result value - - - -Symington, et al. Expires October 26, 2007 [Page 22] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - check fails, the bundle has failed to authenticate and the bundle - SHALL be discarded and processed no further. Otherwise, if any of - the BABs present verify, the bundle is ready to have its CB processed - (if it includes one). - - When forwarding a bundle that included some BABs when it was - received, these BABs MUST be stripped from the bundle. New BABs MAY - be added as required by policy. This might require correcting the - "last block" field of the to-be-forwarded bundle. - - If the bundle has a CB and the receiving node is the CB destination - for the bundle (either because the node is listed in the bundle's CB- - dest field or because the node is listed as the bundle's destination - and there is no CB-dest field), the node MUST decrypt the relevant - parts of the bundle according to the ciphersuite specification and - delete the CB in question. If the relevant parts of the bundle - cannot be decrypted (i.e., the decryption key cannot be deduced or - decryption fails), then the bundle MUST be discarded and processed no - further; in this case a bundle deletion status report (see the Bundle - Protocol [2]) indicating the decryption failure MAY be generated, - destined for the receiving node's own endpoint. If the CB security - result included the ciphertext of anything other than an encrypted - BEK that was used to encrypt the bundle payload, the recovered - plaintext blocks MUST be placed in the bundle at the location from - which the CB was deleted. - - If the bundle has a PSB and the receiving node is the PSB destination - for the bundle (either because the node is listed in the bundle's - PSB-dest field or because the node is listed as the bundle's - destination and there is no PSB-dest field), the node MUST verify the - value in the security result field of the PSB according to the - ciphersuite specification. If the check fails, the bundle has failed - to authenticate and the bundle SHALL be discarded and processed no - further; a bundle status report indicating the failure MAY be - generated, destined for the receiving node's own endpoint. - Otherwise, if the PSB verifies, the bundle is ready to be processed - for either delivery or forwarding. Before forwarding the bundle, the - node SHOULD remove the PSB from the bundle, unless there is the - likelihood that some downstream node will also be able to verify the - PSB. - - If the bundle has a PSB and the receiving node is not the PSB-dest - for the bundle but the ciphersuite allows, the receiving node MAY, if - it is able, verify the value in the security result field. If the - check fails, the node SHALL discard the bundle and it MAY send a - bundle status report indicating the failure to the receiving node's - own endpoint. - - - - -Symington, et al. Expires October 26, 2007 [Page 23] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -3.5. The At-Most-Once-Delivery Option - - An application may request (in some implementation specific manner) - that a node be registered as a member of an endpoint and that - received bundles destined for that endpoint be delivered to that - application. - - We define a new option for use in such cases, known as "at-most-once- - delivery". If this option is chosen, then the application is - indicating that it wants the node to check for duplicate bundles, - discard duplicates, and deliver at most one copy of each received - bundle to the application. If this option is not chosen, the - application is indicating that it wants the node to deliver all - received bundle copies to the application. If this option is chosen, - the node SHALL deliver at most one copy of each received bundle to - the application. If the option is not chosen, the node SHOULD - (subject to policy) deliver all bundles. - - To enforce this the node MUST look at the (source, timestamp) pair - value of each complete (reassembled, if necessary) bundle received - and determine if this pair, which should uniquely identify a bundle, - has been received before. If it has, then the bundle is a duplicate. - If it has not, then the bundle is not a duplicate. The (source, - timestamp) pair SHALL be added to the list of pair values already - received by that node. - - The duration for which a node maintains entries on such a list is an - implementation matter. - - If any application has indicated that it wants a node to use the "at - most once" delivery option for a particular destination endpoint ID - that is in a bundle, then the node MUST compare the (source, - timestamp, fragment offset, fragment length) values of the bundle - with the local list of such values of already-received bundles. - - Additional discussion relevant to at-most-delivery is in the DTN - Retransmission Block specification [10]. - -3.6. Bundle Fragmentation and Reassembly - - If it is necessary for a node to fragment a bundle and security is - being used on that bundle, the following security-specific processing - is REQUIRED: - - Firstly, a BAB, PSB or CB MUST NOT be fragmented. At this time, only - the payload field of the payload block MAY be fragmented. - - If the bundle is required by the security policy to have a BAB before - - - -Symington, et al. Expires October 26, 2007 [Page 24] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - being forwarded, all fragments resulting from that bundle MUST - contain individual BAB values. - - If the original bundle had a PSB, then each of the PSB instances MUST - be included in some fragment. A single PSB instance MUST NOT be sent - more than once. - - If the original bundle had a CB, then the each of the CB instances - MUST be included in some fragment. A single CB instance MUST NOT be - sent more than once. - - Note: various fragments may have additional security blocks added at - this or later stages and it is possible that correlators may collide. - In order to facilitate uniqueness, ciphersuites SHOULD include the - fragment-offset of the fragment as a high-order component of the - correlator. - -3.7. Reactive fragmentation - - When original bundle transmission is terminated before the entire - bundle has been transmitted, the receiving node SHALL consult its - security policy to determine whether it is permitted to transform the - received portion of the bundle into a bundle fragment for further - forwarding. Whether or not such reactive fragmentation is permitted - SHALL be dependent on the security policy in combination with the - ciphersuite used to calculate the BAB authentication information if - required. (Some BAB ciphersuites, i.e., the mandatory BAB-HMAC - ciphersuite defined in Section 4.1, do not accommodate reactive - fragmentation because the security result in the BAB requires that - the entire bundle be signed. It is conceivable, however, that a BAB - ciphersuite could be defined such that multiple security results are - calculated, each on a different segment of a bundle, and that these - security results could be interspersed between bundle payload - segments such that reactive fragmentation could be accommodated.) - - If the original bundle is fragmented by the intermediate receiver - (reactively), and the BAB-ciphersuite is of an appropriate type (e.g. - with multiple security results embedded in the payload), the bundle - MUST be fragmented immediately after the last security result value - in the partial payload that is received. Any data received after the - last security result value MUST be dropped. - - If an original bundle transmission is terminated before the entire - bundle has been transmitted, if the truncated bundle arriving at the - intermediate receiver is reactively fragmented and forwarded, only - the part of the bundle that was not received MUST be retransmitted, - though more of the bundle MAY be retransmitted. Before - retransmitting a portion of the bundle, it SHALL be changed into a - - - -Symington, et al. Expires October 26, 2007 [Page 25] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - fragment and, if the original bundle included a BAB, the fragmented - bundle MUST also, and its BAB SHALL be recalculated. - - This specification does not currently define any ciphersuite which - can handle this reactive fragmentation case well. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 26] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -4. Mandatory Ciphersuites - - This section defines the mandatory ciphersuites for this - specification. There is currently one mandatory ciphersuite for each - of BAB, PSB and CB. The BAB ciphersuite is based on shared secrets - using HMAC. The PSB ciphersuite is based on digital signatures using - RSA with SHA256. The CB ciphersuite is based on using RSA for key - transport and AES for bulk encryption. - -4.1. BAB-HMAC - - The BAB-HMAC ciphersuite has ciphersuite ID value 0x001. - - Security parameters are optional with this scheme, but if used then - the value of the ciphersuite parameter MUST be used as a key - identifier. The exact type of key identifier to be used is an - implementation issue. In the absence of a key identifier the - intermediate receiver is expected to be able to find the correct key - based on the sending identity (from the security-source and/or - convergence layer). - - BAB-HMAC uses the strict canonicalisation algorithm in Section 3.2.1. - - The variant of HMAC to be used is HMAC-SHA1 as defined in RFC 2104 - [3].[Comment.7] - - This ciphersuite requires the use of two related instances of the - BAB. It involves placing the first BAB instance (as defined in - Section 2.2) just after the primary block. The second (correlated) - instance of the BAB MUST be placed after all other blocks (except - possibly other BAB blocks) in the bundle. - - This means that normally, the BAB will be the second and last blocks - of the bundle. If a forwarder wishes to apply more than one - correlated BAB pair, then this can be done. There is no requirement - that each application "wrap" the others, but the forwarder MUST - insert all the "up front" BABs, and their "at back" "partners" - (without any security result), before canonicalising. - - Inserting more than one correlated BAB pair would be useful if the - bundle could be routed to more than one potential "next-hop" or if - both an old or a new key were valid at sending time, with no - certainty about the situation that will obtain at reception time. - - The security result is the output of the HMAC-SHA1 calculation with - input being the result of running the entire bundle through the - strict canonicalisation algorithm. Both required BAB instances MUST - be included in the bundle before canonicalisation. - - - -Symington, et al. Expires October 26, 2007 [Page 27] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -4.2. PSB-RSA-SHA256 - - The PSB-RSA-SHA256 ciphersuite has ciphersuite ID value 0x002. - - If the bundle being signed has been fragmented before signing, then - we have to specify which bytes were signed, in case the signed bundle - is subsequently fragmented for a second time. So, if the bundle is a - fragment, then the ciphersuite parameters MUST include two SDNV - encoded numbers, representing the offset and length of the signed - fragment. If the entire bundle is signed then these numbers MUST be - omitted. - - The ciphersuite parameters field MAY also contain a key identifier. - The exact type of key identifier to be used is an implementation - issue. In the absence of a key identifier the verifier of the PSB is - expected to be able to use the security source (if supplied) or else - the bundle source (if no security source is present) in order to - determine the correct public key to use for PSB verification. - - PSB-RSA-SHA256 uses the mutable canonicalisation algorithm - Section 3.2.2. The resulting canonical form of the bundle is the - input to the signing process. This ciphersuite requires the use of a - single instance of the PSB. - - RSA is used with SHA256 as specified for the sha256WithRSAEncryption - PKCSv1.5 signature scheme in RFC 4055 [4]. The output of the signing - process is the security result for the PSB. - - "Commensurate strength" cryptography is generally held to be a good - idea. A combination of RSA with SHA256 is reckoned to require a 3076 - bit RSA key according to this logic. Few implementations will choose - this length by default (and probably some just won't support such - long keys). Since this is an experimental protocol, we expect that - 1024 or 2048 bit RSA keys will be used in many cases, and that that - will be fine since we also expect that the hash function "issues" - will be resolved before any standard would be derived from this - protocol.[Comment.8] - - 4.3. CB-RSA-AES128-PAYLOAD-PSB - [Comment.9] - - The CB-RSA-AES128-PAYLOAD-PSB ciphersuite has ciphersuite ID value - 0x003. - - This scheme only allows for payload and PSB encryption and involves - encrypting every instance of a PSB as well as the payload. - - This ciphersuite requires the use of a single CB instance if the - - - -Symington, et al. Expires October 26, 2007 [Page 28] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - bundle does not contain a PSB, and multiple CB instances if the - bundle includes one or more PSBs. A first CB is created which - contains the encrypted bundle encryption key (BEK). The key size for - this ciphersuite is 128 bits. - - For the first CB, there MUST be a ciphersuite parameter which - contains a 16 byte IV, optionally followed by a key identifier (whose - format is again out of scope here). (If the ciphersuite parameters - length field has a value equal to 16, then the parameters data field - consists of only a 16-bye IV. If the ciphersuite parameters length - field has a value greater than 16, then the ciphersuite parameters - data field consists of a 16-byte IV followed by a key identifier, and - the length of that key identifier is the value in the ciphersuite - parameters length field minus 16.) The security result contains the - BEK encrypted using PKCSv1.5 rsaEncryption as specified in RFC 3370 - [5]. - - For each subsequent PSB, the entire block is replaced by a CB that is - correlated with the first CB and whose security result is the - ciphertext form of the PSB, including the block type, etc. The - parameters field contains a 16-byte IV specific to this block. - - For the payload, only the bytes of the bundle payload field are - affected, being replaced by ciphertext. - - We separately encrypt the payload and each of the PSB blocks, using - the BEK and a different IV. The IV for the payload is contained in - the first CB, the IV for each of the PSBs is in the parameter field - of the replacement C block. - - The BEK uses the AES algorithm in CBC mode as specified by the id- - aes-cbc object identifier in RFC 3565 [6] - [Comment.10][Comment.11][Comment.12] - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 29] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - 5. Key Management - - Since key management in delay tolerant networks is still a research - topic we cannot provide much in the way of useful key management - here. However, solely in order to support implementation and - testing, implementations SHOULD support: - - - Long-term pre-shared-symmetric keys for the BAB-HMAC - ciphersuite. - - - The use of well-known RSA public keys for PSB-RSA-SHA256 and CB- - RSA-AES128-PAYLOAD-PSB ciphersuites. - - Since endpoint IDs are URIs and URIs can be placed in X.509 [7] - public key certificates (in the subjectAltName extension) - implementations SHOULD support this way of distributing public keys. - Implementations SHOULD NOT be very strict in how they process X.509 - though, for example, it would probably not be correct to insist on - Certificate Revocation List (CRL) checking in many DTN contexts. - - Other than that, key management is for future study. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 30] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -6. Default Security Policy - - Every node serves as a Policy Enforcement Point (PEP) insofar as it - enforces some policy that controls the forwarding and delivery of - bundles via one or more convergence layer protocol implementation. - Consequently, every node SHALL have and operate according to its own - configurable security policy, whether the policy be explicit or - default. The policy SHALL specify: - - Under what conditions received bundles SHALL be forwarded. - - Under what conditions received bundles SHALL be required to - include valid BABs. - - Under what conditions the authentication information provided in a - bundle's BAB SHALL be deemed adequate to authenticate the bundle. - - Under what conditions received bundles SHALL be required to have - valid PSBs and/or CBs. - - Under what conditions the authentication information provided in a - bundle's PSB SHALL be deemed adequate to authenticate the bundle. - - Under what conditions a BAB SHALL be added to a received bundle - before that bundle is forwarded. - - Under what conditions a PSB SHALL be added to a received bundle - before that bundle is forwarded. - - Under what conditions a CB SHALL be added to a received bundle - before that bundle is forwarded. - - The actions that SHALL be taken in the event that a received - bundle does not meet the receiving node's security policy - criteria. - - This specification does not address how security policies get - distributed to nodes. It only REQUIRES that nodes have and enforce - security policies. [Comment.13] - - If no security policy is specified at a given node, or if a security - policy is only partially specified, that node's default policy - regarding unspecified criteria SHALL consist of the following: - - Bundles that are not well-formed do not meet the security policy - criteria. - - - - - -Symington, et al. Expires October 26, 2007 [Page 31] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - The mandatory ciphersuites MUST be used. - - All bundles received MUST have a BAB which MUST be verified to - contain a valid security result. If the bundle does not have a - BAB, then the bundle MUST be discarded and processed no further; a - bundle status report indicating the authentication failure MAY be - generated, destined for the receiving node's own endpoint. - - No received bundles SHALL be required to have a PSB; if a received - bundle does have a PSB, however, the PSB can be ignored unless the - receiving node is the PSB-dest, in which case the PSB MUST be - verified. - - No received bundles SHALL be required to have a CB; if a received - bundle does have a CB, however, the CB can be ignored unless the - receiving node is the CB-dest, in which case the CB MUST be - processed. If processing of a CB yields a PSB, that PSB SHALL be - processed by the node according to the node's security policy. - - A PSB SHALL NOT be added to a bundle before sourcing or forwarding - it. - - A CB SHALL NOT be added to a bundle before sourcing or forwarding - it. - - A BAB MUST always be added to a bundle before that bundle is - forwarded. - - If a destination node receives a bundle that has a PSB-destination - field but the value in that PSB-destination field is not the EID - of the destination node, the bundle SHALL be delivered at that - destination node. - - If a received bundle does not satisfy the node's security policy - for any reason, then the bundle MUST be discarded and processed no - further; in this case, a bundle deletion status report (see the - Bundle Protocol [2]) indicating the failure SHOULD be generated, - destined for the receiving node's own endpoint. - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 32] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -7. Security Considerations - [Comment.14] - - If a BAB ciphersuite uses digital signatures but doesn't include the - security destination (which for a BAB is the next host), then this - allows the bundle to be sent to some node other than the intended - adjacent node. Because the BAB will still authenticate, the - receiving node may erroneously accept and forward the bundle. When - asymmetric BAB ciphersuites are used, the security destination field - SHOULD therefore be included in the BAB. - - If a bundle's PSB-dest is not the same as its destination, then some - node other than the destination (the node identified as the PSB-dest) - is expected to validate the PSB security result while the bundle is - en route. However, if for some reason the PSB is not validated, - there is no way for the destination to become aware of this. - Typically, a PSB-dest will remove the PSB from the bundle after - verifying the PSB and before forwarding it. However, if there is a - possibility that the PSB will also be verified at a downstream node, - the PSB-dest will leave the PSB in the bundle. Therefore, if a - destination receives a bundle with a PSB that has a PSB-dest (which - isn't the destination), this may, but does not necessarily, indicate - a possible problem. - - If a bundle is fragmented after being forwarded by its PSB-source but - before being received by its PSB-dest, the payload in the bundle MUST - be reassembled before validating the PSB security result in order for - the security result to validate correctly. Therefore, if the PSB- - dest is not capable of performing payload reassembly, its utility as - a PSB-dest will be limited to validating only those bundles that have - not been fragmented since being forwarded from the PSB-source. - Similarly, if a bundle is fragmented after being forwarded by its - PSB-source but before being received by its PSB-dest, all fragments - MUST be received at that PSB-dest in order for the bundle payload to - be able to be reassembled. If not all fragments are received at the - PSB-dest node, the bundle will not be able to be authenticated, and - will therefore never be forwarded by this PSB-dest node. - - Specification of a security-destination other than the bundle - destination creates a routing requirement that the bundle somehow be - directed to the security-destination node on its way to the final - destination. This requirement is presently private to the - ciphersuite, since routing nodes are not required to implement - security processing. - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 33] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -8. IANA Considerations - - None at this time. If the bundle protocol becomes a standards track - protocol, then we may want to consider having IANA establish a - register of block types, and in particular for this specification a - separate register of ciphersuite specifications. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 34] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -9. References - -9.1. Normative References - - [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to - Indicate Requirement Levels", RFC 2119, October 1997. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-09.txt, work-in-progress, - April 2007. - - [3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing - for Message Authentication", RFC 2104, February 1997. - - [4] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms - and Identifiers for RSA Cryptography for use in the Internet - X.509 Public Key Infrastructure Certificate and Certificate - Revocation List (CRL) Profile", RFC 4055, June 2005. - - [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", - RFC 3370, August 2002. - - [6] Schaad, J., "Use of the Advanced Encryption Standard (AES) - Encryption Algorithm in Cryptographic Message Syntax (CMS)", - RFC 3565, July 2003. - - [7] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 - Public Key Infrastructure Certificate and Certificate - Revocation List (CRL) Profile", RFC 3280, April 2002. - -9.2. Informative References - - [8] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant - Network Security Overview", - draft-irtf-dtnrg-sec-overview-03.txt, work-in-progress, - April 2007. - - [9] Cerf, V., Burleigh, S., Durst, R., Fall, K., Hooke, A., Scott, - K., Torgerson, L., and H. Weiss, "Delay-Tolerant Network - Architecture", RFC 4838, April 2007. - - [10] Symington, S., "Delay-Tolerant Network Retransmission Block", - draft-irtf-dtnrg-bundle-retrans-00.txt, work-in-progress, - April 2007. - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 35] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -Editorial Comments - - [Comment.1] Stephen: I guess there could be some weird corner case - where a CB ciphersuite using counter-mode would allow - fragments to be individually decrypted, and in that - case, we might want to set replication for each - fragment. So we can't fully rule out setting that flag - for all PSB/CB. - - [Comment.2] Stephen: This to be revisited! - - [Comment.3] Stephen: Do we need to specify error handling for the - case where a node drops a bundle for policy reasons? - Does/can it signal back to the source that its done so? - - [Comment.4] Howie: The security policy database will need to be - discussed somewhere. Does it belong in this document, - the bundle protocol spec., both, some other document? - - [Comment.5] Editors: Check that mask value at the very last moment - (incl. during auth-48) to be sure its (still) correct. - - [Comment.6] Stephen: Should we support source confidentiality? - Might complicate PSB which is the downside IMO. - - [Comment.7] Editors: At the moment there appears to be no security - reason to move away from HMAC-SHA1 since the HMAC - construct is not as far as we know affected by - collisions in the underlying digest algorithm (which - are nearly practically computable for SHA-1). - Nevertheless, since we use SHA-256 in the signature - ciphersuite (since collisions do matter there), it may - be desirable to move to HMAC-SHA-256 as specified in - RFC 4321. So if you're writing code based on this...be - warned! - - [Comment.8] Editors: There are currently unresolved "issues" with - digest algorithms which might cause a change here prior - to, but more likely, after, an RFC has issued. So - expect change! - - [Comment.9] Editors: This entire section is to be treated as a - strawman for the present. - - [Comment.10] Speculation: There would be an interesting possibility - opened up were we to use a stream cipher with the REK. - That is that we could then encrypt and decrypt - independently - Alice could encrypt for Bob, then - - - -Symington, et al. Expires October 26, 2007 [Page 36] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - - Charlie could encrypt for Dessie, then Bob could - decrypt, then Dessie. Better in terms of not adding - padding but worse in that it trivially allows known - plaintext manipulation if there's no PSB. - - [Comment.11] Editors: Another option might also be to switch to - using counter mode rather than CBC which would have the - benefit of allowing some fragments to be decrypted even - if not all fragments arrive. While that seems nice - enough to do, it would of course require us to think - more about fragments and so is for the next version if - at all. - - [Comment.12] Peter: there does not seem to be a suitable CTR mode - implementation for AES but perhaps CFB (also stream - mode) would be suitable. It also avoids padding. - - [Comment.13] Howie: Eventually we will need to state where the - security policy information/DB does get discussed/ - specified. - - [Comment.14] Editors: Much more text is needed here no doubt. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 37] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -Authors' Addresses - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - Stephen Farrell - Trinity College Dublin - Distributed Systems Group - Department of Computer Science - Trinity College - Dublin 2 - Ireland - - Phone: +353-1-608-1539 - Email: stephen.farrell@cs.tcd.ie - - - Howard Weiss - SPARTA, Inc. - 7110 Samuel Morse Drive - Columbia, MD 21046 - US - - Phone: +1-443-430-8089 - Email: hsw@sparta.com - - - Peter Lovell - SPARTA, Inc. - 7110 Samuel Morse Drive - Columbia, MD 21046 - US - - Phone: +1-443-430-8052 - Email: peter.lovell@sparta.com - - - - - - - - -Symington, et al. Expires October 26, 2007 [Page 38] -=0C -Internet-Draft Bundle Security Protocol April 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Symington, et al. Expires October 26, 2007 [Page 39] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-bundle-spec-10.tx= t --- a/doc/draft-irtf-dtnrg-bundle-spec-10.txt Sat Dec 12 17:10:03 2009 +000= 0 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,3192 +0,0 @@ - - - -IRTF Delay Tolerant Networking K. Scott -Research Group The MITRE Corporation -Internet-Draft S. Burleigh -Intended status: Experimental NASA Jet Propulsion Laboratory -Expires: January 4, 2008 July 3, 2007 - - - Bundle Protocol Specification - draft-irtf-dtnrg-bundle-spec-10.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 4, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 1] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -Abstract - - This document describes the end-to-end protocol, block formats, and - abstract service description for the exchange of messages (bundles) - in Delay Tolerant Networking (DTN). - - This document was produced within the IRTF's Delay Tolerant - Networking Research Group (DTNRG) and represents the consensus of all - of the active contributors to this Group. See http://www.dtnrg.org - for more information. - - -Table of Contents - - 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Service Description . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2. Implementation architectures . . . . . . . . . . . . . . . 11 - 3.3. Services offered by bundle protocol agents . . . . . . . . 13 - 4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 14 - 4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 14 - 4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 16 - 4.3. Block Processing Control Flags . . . . . . . . . . . . . . 17 - 4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 18 - 4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 19 - 4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 21 - 4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 24 - 4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 25 - 4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 26 - 4.7. Dictionary revision . . . . . . . . . . . . . . . . . . . 26 - 5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 27 - 5.1. Generation of administrative records . . . . . . . . . . . 27 - 5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 28 - 5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 29 - 5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 29 - 5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 31 - 5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 31 - 5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 32 - 5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 32 - 5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 33 - 5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 34 - 5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 35 - 5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 36 - 5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 36 - 5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 37 - 5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 37 - 5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 37 - - - -Scott & Burleigh Expires January 4, 2008 [Page 2] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - 5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 38 - 5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 38 - 5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 38 - 5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 6. Administrative Record Processing . . . . . . . . . . . . . . . 40 - 6.1. Administrative Records . . . . . . . . . . . . . . . . . . 40 - 6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 41 - 6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 44 - 6.2. Generation of Administrative Records . . . . . . . . . . . 47 - 6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 47 - 7. Services Required of the Convergence Layer . . . . . . . . . . 48 - 7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 48 - 7.2. Summary of Convergence Layer Services . . . . . . . . . . 48 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 49 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 52 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 52 - Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 54 - Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 55 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 - Intellectual Property and Copyright Statements . . . . . . . . . . 57 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 3] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -1. Requirements notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 4] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -2. Introduction - - This document describes version 6 of the Delay Tolerant Networking - (DTN) "bundle" protocol (BP). Delay Tolerant Networking is an end- - to-end architecture providing communications in and/or through highly - stressed environments. Stressed networking environments include - those with intermittent connectivity, large and/or variable delays, - and high bit error rates. To provide its services, BP sits at the - application layer of some number of constituent internets, forming a - store-and-forward overlay network. Key capabilities of BP include: - - o Custody-based retransmission - - o Ability to cope with intermittent connectivity - - o Ability to take advantage of scheduled, predicted, and - opportunistic connectivity (in addition to continuous - connectivity) - - o Late binding of overlay network endpoint identifiers to - constituent internet addresses - - For descriptions of these capabilities and the rationale for the DTN - architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial-level - overview of DTN concepts. - - This is an experimental protocol, produced within the IRTF's Delay - Tolerant Networking Research Group (DTNRG) and represents the - consensus of all of the active contributors to this Group. If this - protocol is used on the Internet, IETF standard protocols for - security and congestion control should be used. - - BP's location within the standard protocol stack is as shown in - Figure 1. BP uses the "native" internet protocols for communications - within a given internet. Note that "internet" in the preceding is - used in a general sense and does not necessarily refer to TCP/IP. - The interface between the common bundle protocol and a specific - internetwork protocol suite is termed a "convergence layer adapter". - Figure 1 shows three distinct transport and network protocols - (denoted T1/N1, T2,N2, and T3/N3). - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 5] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - +-----------+ +-----------+ - | BP app | | BP app | - +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ - | BP v | | ^ BP v | | ^ BP v | | ^ BP | - +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ - | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | - +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ - | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | - +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ - | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | - +-----------+ +-------------+ +-------------+ +-----------+ - | | | | - |<--- An internet --->| |<--- An internet --->| - | | | | - - Figure 1: The bundle protocol sits at the application layer of the - Internet model. - - This document describes the format of the protocol data units (called - bundles) passed between entities participating in BP communications. - The entities are referred to as "bundle nodes". This document does - not address: - - o Operations in the convergence layer adapters that bundle nodes use - to transport data through specific types of internet. (However, - the document does discuss the services that must be provided by - each adapter at the convergence layer.) - - o The bundle routing algorithm. - - o Mechanisms for populating the routing or forwarding information - bases of bundle nodes. - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 6] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -3. Service Description - -3.1. Definitions - - Bundle - A bundle is a protocol data unit of the DTN bundle - protocol. Each bundle comprises a sequence of two or more - "blocks" of protocol data, which serve various purposes. Multiple - instances of the same bundle (the same unit of DTN protocol data) - might exist concurrently in different parts of a network - - possibly in different representations - in the memory local to one - or more bundle nodes and/or in transit between nodes. In the - context of the operation of a bundle node, a bundle is an instance - of some bundle in the network that is in that node's local memory. - - Bundle payload - A bundle payload (or simply "payload") is the - application data whose conveyance to the bundle's destination is - the purpose for the transmission of a given bundle. The terms - "bundle content", "bundle payload", and "payload" are used - interchangeably in this document. The "nominal" payload for a - bundle forwarded in response to a bundle transmission request is - the application data unit whose location is provided as a - parameter to that request. The nominal payload for a bundle - forwarded in response to reception of that bundle is the payload - of the received bundle. - - Fragment - A fragment is a bundle whose payload block contains a - fragmentary payload. A fragmentary payload is either the first N - bytes or the last N bytes of some other payload - either a nominal - payload or a fragmentary payload - of length M, such that 0 < N < - M. - - Bundle node - A bundle node (or, in the context of this document, - simply a "node") is any entity that can send and/or receive - bundles. In the most familiar case a bundle node is instantiated - as a single process running on a general-purpose computer, but in - general the definition is meant to be broader: a bundle node might - alternatively be a thread, an object in an object-oriented - operating system, a special-purpose hardware device, etc. Each - bundle node has three conceptual components, defined below: a - "bundle protocol agent", a set of zero or more "convergence layer - adapters", and an "application agent". - - Bundle protocol agent - The bundle protocol agent (BPA) of a node is - the node component that offers the BP services and executes the - procedures of the Bundle Protocol. The manner in which it does so - is wholly an implementation matter. For example, BPA - functionality might be coded into each node individually; it might - be implemented as a shared library that is used in common by any - - - -Scott & Burleigh Expires January 4, 2008 [Page 7] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - number of bundle nodes on a single computer; it might be - implemented as a daemon whose services are invoked via inter- - process or network communication by any number of bundle nodes on - one or more computers; it might be implemented in hardware. - - Convergence layer adapters - A convergence layer adapter (CLA) sends - and receives bundles on behalf of the BPA, utilizing the services - of some 'native' internet protocol that is supported in one of the - internets within which the node is functionally located. The - manner in which a CLA sends and receives bundles is wholly an - implementation matter, exactly as described for the BPA. - - Application agent - The application agent (AA) of a node is the node - component that utilizes the BP services to effect communication - for some purpose. The application agent in turn has two elements, - an administrative element and an application-specific element. - The application-specific element of an AA constructs, requests - transmission of, accepts delivery of, and processes application- - specific application data units; the only interface between the - BPA and the application-specific element of the AA is the BP - service interface. The administrative element of an AA constructs - and requests transmission of administrative records (status - reports and custody signals), and it accepts delivery of and - processes any custody signals that the node receives. In addition - to the BP service interface, there is a (conceptual) private - control interface between the BPA and the administrative element - of the AA that enables each to direct the other to take action - under specific circumstances. In the case of a node that serves - simply as a "router" in the overlay network, the AA may have no - application-specific element at all. The application-specific - elements of other nodes' AAs may perform arbitrarily complex - application functions, perhaps even offering multiplexed DTN - communication services to a number of other applications. As with - the BPA, the manner in which the AA performs its functions is - wholly an implementation matter; in particular, the administrative - element of an AA might be built into the library or daemon or - hardware that implements the BPA, and the application-specific - element of an AA might be implemented either in software or in - hardware. - - Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set - of zero or more bundle nodes that all identify themselves for BP - purposes by some single text string, called a "bundle endpoint ID" - (or, in this document, simply "endpoint ID"; endpoint IDs are - described in detail in 3.4 below). The special case of an - endpoint that never contains more than one node is termed a - "singleton" endpoint; every bundle node must be a member of at - least one singleton endpoint. Singletons are the most familiar - - - -Scott & Burleigh Expires January 4, 2008 [Page 8] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - sort of endpoint, but in general the endpoint notion is meant to - be broader. For example, the nodes in a sensor network might - constitute a set of bundle nodes that identify themselves by a - single common endpoint ID and thus form a single bundle endpoint. - **Note** too that a given bundle node might identify itself by - multiple endpoint IDs and thus be a member of multiple bundle - endpoints. - - Forwarding - When the bundle protocol agent of a node determines - that a bundle must be "forwarded" to an endpoint, it causes the - bundle to be sent to all of the nodes that the bundle protocol - agent currently believes are in the "minimum reception group" of - that endpoint. The minimum reception group of an endpoint may be - any one of the following: (a) ALL of the nodes registered in an - endpoint that is permitted to contain multiple nodes (in which - case forwarding to the endpoint is functionally similar to - "multicast" operations in the Internet, though possibly very - different in implementation); (b) ANY N of the nodes registered in - an endpoint that is permitted to contain multiple nodes, where N - is in the range from zero to the cardinality of the endpoint (in - which case forwarding to the endpoint is functionally similar to - "anycast" operations in the Internet); (c) THE SOLE NODE - registered in a singleton endpoint (in which case forwarding to - the endpoint is functionally similar to "unicast" operations in - the Internet). The nature of the minimum reception group for a - given endpoint can be determined from the endpoint's ID (again, - see 3.4 below): for some endpoint ID "schemes", the nature of the - minimum reception group is fixed - in a manner that is defined by - the scheme - for all endpoints identified under the scheme; for - other schemes, the nature of the minimum reception group is - indicated by some lexical feature of the "scheme-specific part" of - the endpoint ID, in a manner that is defined by the scheme. - - Registration - A registration is the state machine characterizing a - given node's membership in a given endpoint. Any number of - registrations may be concurrently associated with a given - endpoint, and any number of registrations may be concurrently - associated with a given node. Any single registration must at any - time be in one of two states: Active, Passive. A registration - always has an associated "delivery failure action", the action - that is to be taken when a bundle that is "deliverable" (see - below) subject to that registration is received at a time when the - registration is in the Passive state. Delivery failure action - must be one of the following: - - * defer "delivery" (see below) of the bundle subject to this - registration until (a) this bundle is the least recently - received of all bundles currently deliverable subject to this - - - -Scott & Burleigh Expires January 4, 2008 [Page 9] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - registration and (b) either the registration is polled or else - the registration is in Active state; - - * "abandon" (see below) delivery of the bundle subject to this - registration. - - An additional implementation-specific delivery deferral procedure - may optionally be associated with the registration. While the - state of a registration is Active, reception of a bundle that is - deliverable subject to this registration must cause the bundle to - be delivered automatically as soon as it is the least recently - received bundle that is currently deliverable subject to the - registration. While the state of a registration is Passive, - reception of a bundle that is deliverable subject to this - registration must cause delivery of the bundle to be abandoned or - deferred as mandated by the registration's current delivery - failure action; in the latter case, any additional delivery - deferral procedure associated with the registration must also be - performed. - - Delivery - Upon reception, the processing of a bundle that has been - sent to a given node depends on whether or not the receiving node - is registered in the bundle's destination endpoint; if it is, and - if the payload of the bundle is non-fragmentary (possibly as a - result of successful payload reassembly from fragmentary payloads, - including the original payload of the received bundle), then the - bundle is normally "delivered" to the node's application agent - subject to the registration characterizing the node's membership - in the destination endpoint. A bundle is considered to have been - delivered at a node subject to a registration as soon as the - application data unit that is the payload of the bundle, together - with the value of the bundle's "Acknowledgement by application is - requested" flag and any other relevant metadata (an implementation - matter), has been presented to the node's application agent in a - manner consistent with the state of that registration and, as - applicable, the registration's delivery failure action. - - Deliverability, Abandonment - A bundle is considered "deliverable" - subject to a registration if and only if (a) the bundle's - destination endpoint is the endpoint with which the registration - is associated, (b) the bundle has not yet been delivered subject - to this registration, and (c) delivery of the bundle subject to - this registration has not been abandoned. To "abandon" delivery - of a bundle subject to a registration is simply to declare it no - longer deliverable subject to that registration; normally only - registrations' registered delivery failure actions cause - deliveries to be abandoned. - - - - -Scott & Burleigh Expires January 4, 2008 [Page 10] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Deletion, Discarding - A bundle protocol agent "discards" a bundle - by simply ceasing all operations on the bundle and functionally - erasing all references to it; the specific procedures by which - this is accomplished are an implementation matter. Bundles are - discarded silently, i.e., the discarding of a bundle does not - result in generation of an administrative record. "Retention - constraints" are elements of bundle state that prevent a bundle - from being discarded; a bundle cannot be discarded while it has - any retention constraints. A bundle protocol agent "deletes" a - bundle in response to some anomalous condition by notifying the - bundle's report-to endpoint of the deletion (provided such - notification is warranted; see 4.13 for details) and then - arbitrarily removing all of the bundle's retention constraints, - enabling the bundle to be discarded. - - Transmission - A transmission is a sustained effort by a node's - bundle protocol agent to cause a bundle to be sent to all nodes in - the minimum reception group of some endpoint (which may be the - bundle's destination or may be some intermediate forwarding - endpoint) in response to a transmission request issued by the - node's application agent. Any number of transmissions may be - concurrently undertaken by the bundle protocol agent of a given - node. - - Custody - To "accept custody" upon forwarding a bundle is to commit - to retaining a copy of the bundle - possibly re-forwarding the - bundle when the necessity to do so is determined - until custody - of that bundle is "released". Custody of a bundle whose - destination is a singleton endpoint is released when either (a) - notification is received that some other node has accepted custody - of the same bundle, (b) notification is received that the bundle - has been delivered at the (sole) node registered in the bundle's - destination endpoint, or (c) the bundle is explicitly deleted for - some reason, such as lifetime expiration. The condition(s) under - which custody of a bundle whose destination is not a singleton - endpoint may be released are not defined in this specification. - To "refuse custody" of a bundle is to decide not to accept custody - of the bundle. A "custodial node" of a bundle is a node that has - accepted custody of the bundle and has not yet released that - custody. A "custodian" of a bundle is a singleton endpoint whose - sole member is one of the bundle's custodial nodes. - -3.2. Implementation architectures - - The above definitions are intended to enable the bundle protocol's - operations to be specified in a manner that minimizes bias toward any - particular implementation architecture. To illustrate the range of - interoperable implementation models that might conform to this - - - -Scott & Burleigh Expires January 4, 2008 [Page 11] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - specification, four example architectures are briefly described - below. - - 1. Bundle protocol application server - - A single bundle protocol application server, constituting a - single bundle node, runs as a daemon process on each computer. - The daemon's functionality includes all functions of the bundle - protocol agent, all convergence layer adapters, and both the - administrative and application-specific elements of the - application agent. The application-specific element of the - application agent functions as a server, offering bundle protocol - service over a local area network: it responds to remote - procedure calls from application processes (on the same computer - and/or remote computers) that need to communicate via the bundle - protocol. The server supports its clients by creating a new - (conceptual) node for each one and registering each such node in - a client-specified endpoint; the conceptual nodes managed by the - server function as clients' Bundle Protocol service access - points. - - 2. Peer application nodes - - Any number of bundle protocol application processes, each one - constituting a single bundle node, run in ad-hoc fashion on each - computer. The functionality of the bundle protocol agent, all - convergence layer adapters, and the administrative element of the - application agent is provided by a library to which each node - process is dynamically linked at run time; the application- - specific element of each node's application agent is node- - specific application code. - - 3. Sensor network nodes - - Each node of the sensor network is the self-contained - implementation of a single bundle node. All functions of the - bundle protocol agent, all convergence layer adapters, and the - administrative element of the application agent are implemented - in simplified form in ASICs, while the application-specific - element of each node's application agent is implemented in a - programmable microcontroller. Forwarding is rudimentary: all - bundles are forwarded on a hard-coded default route. - - 4. Dedicated bundle router - - Each computer constitutes a single bundle node that functions - solely as a high-performance bundle forwarder. Many standard - functions of the bundle protocol agent, the convergence layer - - - -Scott & Burleigh Expires January 4, 2008 [Page 12] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - adapters, and the administrative element of the application agent - are implemented in ASICs, but some functions are implemented in a - high-speed processor to enable reprogramming as necessary. The - node's application agent has no application-specific element. - Substantial non-volatile storage resources are provided, and - arbitrarily complex forwarding algorithms are supported. - -3.3. Services offered by bundle protocol agents - - The bundle protocol agent of each node is expected to provide the - following services to the node's application agent: - - o commencing a registration (registering a node in an endpoint); - - o terminating a registration; - - o switching a registration between Active and Passive state; - - o transmitting a bundle to an identified bundle endpoint; - - o canceling a transmission; - - o polling a registration that is in passive state; - - o delivering a received bundle. - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 13] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -4. Bundle Format - - Each bundle shall be a concatenated sequence of at least two block - structures. The first block in the sequence must be a primary bundle - block, and no bundle may have more than one primary bundle block. - Additional bundle protocol blocks of other types may follow the - primary block to support extensions to the Bundle Protocol, such as - the Bundle Security Protocol [BSP]. At most one of the blocks in the - sequence may be a payload block. The last block in the sequence must - have the "last block" flag (in its block processing control flags) - set to 1; for every other block in the bundle after the primary - block, this flag must be set to zero. - -4.1. Self-Delimiting Numeric Values (SDNVs) - - The design of the bundle protocol attempts to reconcile minimal - consumption of transmission bandwidth with: - - o extensibility to address requirements not yet identified, and - - o scalability across a wide range of network scales and payload - sizes. - - A key strategic element in the design is the use of self-delimiting - numeric values (SDNVs). The SDNV encoding scheme is closely adapted - from the Abstract Syntax Notation One Basic Encoding Rules for - subidentifiers within an object identifier value [ASN1]. An SDNV is - a numeric value encoded in N octets, the last of which has its most - significant bit (MSB) set to zero; the MSB of every other octet in - the SDNV must be set to 1. The value encoded in an SDNV is the - unsigned binary number obtained by concatenating into a single bit - string the 7 least significant bits of each octet of the SDNV. - - The following examples illustrate the encoding scheme for various - hexadecimal values. - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 14] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - 0xABC : 1010 1011 1100 - is encoded as - {1 00 10101} {0 0111100} - =3D 10010101 00111100 - - 0x1234 : 0001 0010 0011 0100 - =3D 1 0010 0011 0100 - is encoded as - {1 0 100100} {0 0110100} - =3D 10100100 00110100 - - 0x4234 : 0100 0010 0011 0100 - =3D 100 0010 0011 0100 - is encoded as - {1 000000 1} {1 0000100} {0 0110100} - =3D 10000001 10000100 00110100 - - 0x7F : 0111 1111 - =3D 111 1111 - is encoded as - {0 1111111} - =3D 01111111 - - Figure 2: SDNV Example - - Note: Care must be taken to make sure that the value to be encoded is - (in concept) padded with high-order zero bits to make its bitwise - length a multiple of 7 before encoding. Also note that, while there - is no theoretical limit on the size of an SDNV field, the overhead of - the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of - actual data to be encoded. Thus a 7-octet value (a 56-bit quantity - with no leading zeroes) would be encoded in an 8-octet SDNV; an - 8-octet value (a 64-bit quantity with no leading zeroes) would be - encoded in a 10-octet SDNV (one octet containing the high-order bit - of the value padded with six leading zero bits, followed by nine - octets containing the remaining 63 bits of the value). 148 bits of - overhead would be consumed in encoding a 1024-bit RSA encryption key - directly in an SDNV. In general, an N-bit quantity with no leading - zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil - is the integer ceiling function. - - Implementations of the Bundle Protocol may handle as an invalid - numeric value any SDNV that encodes an integer that is larger than - (2^64 - 1). - - An SDNV can be used to represent both very large and very small - integer values. However, SDNV is clearly not the best way to - represent every numeric value. For example, an SDNV is a poor way to - - - -Scott & Burleigh Expires January 4, 2008 [Page 15] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - represent an integer whose value typically falls in the range 128 to - 255. In general, though, we believe that SDNV representation of - numeric values in bundle blocks yields the smallest block sizes - without sacrificing scalability. - -4.2. Bundle Processing Control Flags - - The bundle processing control flags field in the primary bundle block - of each bundle is an SDNV; the value encoded in this SDNV is a string - of bits used to invoke selected bundle processing control features. - The significance of the value in each currently defined position of - this bit string is described here. Note that in the figure and - descriptions, the bit label numbers denote position (from least - significant ('0') to most significant) within the decoded bit string, - and not within the representation of the bits on the wire. This is - why the descriptions in this section and the next do not follow - standard RFC conventions with bit 0 on the left; if fields are added - in the future, the SDNV will grow to the left, and using this - representation allows the references here to remain valid. - - 2 1 0 - 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Status Report|Class of Svc.| General | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 3: Bundle processing control flags bit layout - - The bits in positions 0 through 6 are flags that characterize the - bundle as follows: - - 0 -- Bundle is a fragment. - - 1 -- Application data unit is an administrative record. - - 2 -- Bundle must not be fragmented. - - 3 -- Custody transfer is requested. - - 4 -- Destination endpoint is a singleton. - - 5 -- Acknowledgement by application is requested. - - 6 -- Reserved for future use. - - The bits in positions 7 through 13 are used to indicate the bundle's - class of service. The bits in positions 8 and 7 constitute a two-bit - priority field indicating the bundle's priority, with higher values - - - -Scott & Burleigh Expires January 4, 2008 [Page 16] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - being of higher priority: 00 =3D bulk, 01 =3D normal, 10 =3D expedited,= 11 - is reserved for future use. Within this field, bit 8 is the most - significant bit. The bits in positions 9 through 13 are reserved for - future use. - - The bits in positions 14 through 20 are status report request flags. - These flags are used to request status reports as follows: - - 14 -- Request reporting of bundle reception. - - 15 -- Request reporting of custody acceptance. - - 16 -- Request reporting of bundle forwarding. - - 17 -- Request reporting of bundle delivery. - - 18 -- Request reporting of bundle deletion. - - 19 -- Reserved for future use. - - 20 -- Reserved for future use. - - If the bundle processing control flags indicate that the bundle's - application data unit is an administrative record, then the custody - transfer requested flag must be zero and all status report request - flags must be zero. If the custody transfer requested flag is 1 then - the sending node requests that the receiving node accept custody of - the bundle. If the bundle's source endpoint ID is "dtn:none" (see - below), then the bundle is not uniquely identifiable and all bundle - protocol features that rely on bundle identity must therefore be - disabled: the bundle's custody transfer requested flag must be zero, - the "bundle must not be fragmented" flag must be 1, and all status - report request flags must be zero. - -4.3. Block Processing Control Flags - - The block processing control flags field in every block other than - the primary bundle block is an SDNV; the value encoded in this SDNV - is a string of bits used to invoke selected block processing control - features. The significance of the values in all currently defined - positions of this bit string, in order from least-significant - position in the decoded bit string (labeled '0') to most-significant - (labeled '6'), are described here. - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 17] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - 0 - 6 5 4 3 2 1 0 - +-+-+-+-+-+-+-+ - | Flags | - +-+-+-+-+-+-+-+ - - Figure 4: Block processing control flags bit layout - - 0 - Block must be replicated in every fragment. - - 1 - Transmit status report if block can't be processed. - - 2 - Delete bundle if block can't be processed. - - 3 - Last block. - - 4 - Discard block if it can't be processed. - - 5 - Block was forwarded without being processed. - - 6 - Block contains an EID-reference field. - - For each bundle whose primary block's bundle processing control flags - (see above) indicate that the bundle's application data unit is an - administrative record, the "Transmit status report if block can't be - processed" flag in the block processing flags field of every other - block in the bundle must be zero. - - The 'Block must be replicated in every fragment' bit in the block - processing flags must be set to zero on all blocks that follow the - payload block. - -4.4. Endpoint IDs - - The destinations of bundles are bundle endpoints, identified by text - strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID - conveyed in any bundle block takes the form of a Uniform Resource - Identifier (URI; [URI]). As such, each endpoint ID can be - characterized as having this general structure: - - < scheme name > : < scheme-specific part, or "SSP" > - - As used for the purposes of the bundle protocol, neither the length - of a scheme name nor the length of an SSP may exceed 1023 bytes. - - Bundle blocks cite a number of endpoint IDs for various purposes of - the bundle protocol. Many, though not necessarily all, of the - endpoint IDs referred to in the blocks of a given bundle are conveyed - - - -Scott & Burleigh Expires January 4, 2008 [Page 18] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - in the "dictionary" byte array in the bundle's primary block. This - array is simply the concatenation of any number of null-terminated - scheme names and SSPs. - - "Endpoint ID references" are used to cite endpoint IDs that are - contained in the dictionary; all endpoint ID citations in the primary - bundle block are endpoint ID references, and other bundle blocks may - contain endpoint ID references as well. Each endpoint ID reference - is an ordered pair of SDNVs: - - o The first SDNV contains the offset within the dictionary of the - first character of the referenced endpoint ID's scheme name. - - o The second SDNV contains the offset within the dictionary of the - first character of the referenced endpoint ID's SSP. - - This encoding enables a degree of block compression: when the source - and report-to of a bundle are the same endpoint, for example, the - text of that endpoint's ID may be cited twice yet appear only once in - the dictionary. - - The scheme identified by the < scheme name > in an endpoint ID is a - set of syntactic and semantic rules that fully explain how to parse - and interpret the SSP. The set of allowable schemes is effectively - unlimited. Any scheme conforming to [URIREG] may be used in a bundle - protocol endpoint ID. In addition, a single additional scheme is - defined by the present document: - - o The "dtn" scheme, which is used at minimum in the representation - of the null endpoint ID "dtn:none". The forwarding of a bundle to - the null endpoint is never contraindicated, and the minimum - reception group for the null endpoint is the empty set. - - Note that, although the endpoint IDs conveyed in bundle blocks are - expressed as URIs, implementations of the BP service interface may - support expression of endpoint IDs in some internationalized manner - (e.g., IRIs; see RFC 3987). - -4.5. Formats of Bundle Blocks - - This section describes the formats of the primary block and payload - block. Rules for processing these blocks appear in Section 5 of this - document. - - Note that supplementary DTN protocol specifications (including, but - not restricted to, the Bundle Security Protocol [BSP]) may require - that BP implementations conforming to those protocols construct and - process additional blocks. - - - -Scott & Burleigh Expires January 4, 2008 [Page 19] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - The format of the two basic BP blocks is shown in Figure 5 below. - - Primary Bundle Block - +----------------+----------------+----------------+----------------+ - | Version | Proc. Flags (*) | - +----------------+----------------+----------------+----------------+ - | Block length (*) | - +----------------+----------------+---------------------------------+ - | Destination scheme offset (*) | Destination SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Source scheme offset (*) | Source SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Report-to scheme offset (*) | Report-to SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Custodian scheme offset (*) | Custodian SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Creation Timestamp time (*) | - +---------------------------------+---------------------------------+ - | Creation Timestamp sequence number (*) | - +---------------------------------+---------------------------------+ - | Lifetime (*) | - +----------------+----------------+----------------+----------------+ - | Dictionary length (*) | - +----------------+----------------+----------------+----------------+ - | Dictionary byte array (variable) | - +----------------+----------------+---------------------------------+ - | [Fragment offset (*)] | - +----------------+----------------+---------------------------------+ - | [Total application data unit length (*)] | - +----------------+----------------+---------------------------------+ - - - Bundle Payload Block - +----------------+----------------+----------------+----------------+ - | Block type | Proc. Flags (*)| Block length(*) | - +----------------+----------------+----------------+----------------+ - / Bundle Payload (variable) / - +-------------------------------------------------------------------+ - - Figure 5: Bundle Block Formats - - (*) Notes: - - The bundle processing control ("Proc.") flags field in the Primary - Bundle Block is an SDNV and is therefore variable-length. A three- - octet SDNV is shown here for convenience in representation. - - The block length field of the Primary Bundle Block is an SDNV and is - - - -Scott & Burleigh Expires January 4, 2008 [Page 20] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - therefore variable-length. A four-octet SDNV is shown here for - convenience in representation. - - Each of the eight offset fields in the Primary Bundle Block is an - SDNV and is therefore variable-length. Two-octet SDNVs are shown - here for convenience in representation. - - The Creation Timestamp time field in the Primary Bundle Block is an - SDNV and is therefore variable-length. A four-octet SDNV is shown - here for convenience in representation. - - The Creation Timestamp sequence number field in the Primary Bundle - Block is an SDNV and is therefore variable-length. A four-octet SDNV - is shown here for convenience in representation. - - The Lifetime field in the Primary Bundle Block is an SDNV and is - therefore variable-length. A four-octet SDNV is shown here for - convenience in representation. - - The dictionary length field of the Primary Bundle Block is an SDNV - and is therefore variable-length. A four-octet SDNV is shown here - for convenience in representation. - - The fragment offset field of the Primary Bundle Block is present only - if the Fragment flag in the block's processing flags byte is set to - 1. It is an SDNV and is therefore variable-length; a four-octet SDNV - is shown here for convenience in representation. - - The total application data unit length field of the Primary Bundle - Block is present only if the Fragment flag in the block's processing - flags byte is set to 1. It is an SDNV and is therefore variable- - length; a four-octet SDNV is shown here for convenience in - representation. - - The block processing control ("Proc.") flags field of the Payload - Block is an SDNV and is therefore variable-length. A one-octet SDNV - is shown here for convenience in representation. - - The block length field of the Payload Block is an SDNV and is - therefore variable-length. A two-octet SDNV is shown here for - convenience in representation. - -4.5.1. Primary Bundle Block - - The primary bundle block contains the basic information needed to - route bundles to their destinations. The fields of the primary - bundle block are: - - - - -Scott & Burleigh Expires January 4, 2008 [Page 21] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Version: A 1-byte field indicating the version of the bundle - protocol that constructed this block. The present document - describes version 0x05 of the bundle protocol. - - Bundle Processing Control Flags: The Bundle Processing Control - Flags field is an SDNV that contains the bundle processing control - flags discussed in Section 4.2 above. - - Block Length: The Block Length field is an SDNV that contains the - aggregate length of all remaining fields of the block. - - Destination Scheme Offset: The Destination Scheme Offset field - contains the offset within the dictionary byte array of the scheme - name of the endpoint ID of the bundle's destination, i.e., the - endpoint containing the node(s) at which the bundle is to be - delivered. - - Destination SSP Offset: The Destination SSP Offset field contains - the offset within the dictionary byte array of the scheme-specific - part of the endpoint ID of the bundle's destination. - - Source Scheme Offset: The Source Scheme Offset field contains the - offset within the dictionary byte array of the scheme name of the - endpoint ID of the bundle's nominal source, i.e., the endpoint - nominally containing the node from which the bundle was initially - transmitted. - - Source SSP Offset: The Source SSP Offset field contains the offset - within the dictionary byte array of the scheme-specific part of - the endpoint ID of the bundle's nominal source. - - Report-to Scheme Offset: The Report-to Scheme Offset field contains - the offset within the dictionary byte array of the scheme name of - the ID of the endpoint to which status reports pertaining to the - forwarding and delivery of this bundle are to be transmitted. - - Report-to SSP Offset: The Report-to SSP Offset field contains the - offset within the dictionary byte array of the scheme-specific - part of the ID of the endpoint to which status reports pertaining - to the forwarding and delivery of this bundle are to be - transmitted. - - Custodian Scheme Offset: The "current custodian endpoint ID" of a - primary bundle block identifies an endpoint whose membership - includes the node that most recently accepted custody of the - bundle upon forwarding this bundle. The Custodian Scheme Offset - field contains the offset within the dictionary byte array of the - scheme name of the current custodian endpoint ID. - - - -Scott & Burleigh Expires January 4, 2008 [Page 22] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Custodian SSP Offset: The Destination SSP Offset field contains the - offset within the dictionary byte array of the scheme-specific - part of the current custodian endpoint ID. - - Creation Timestamp: The creation timestamp is a pair of SDNVs that, - together with the source endpoint ID and (if the bundle is a - fragment) the fragment offset and payload length, serve to - identify the bundle. The first SDNV of the timestamp is the - bundle's creation time while the second is the bundle's creation - timestamp sequence number. Bundle creation time is the time - - expressed in seconds since the start of the year 2000, on the - Coordinated Universal Time (UTC) scale [UTC] - at which the - transmission request was received that resulted in the creation of - the bundle. Sequence count is the latest value (as of the time at - which that transmission request was received) of a monotonically - increasing positive integer counter managed by the source node's - bundle protocol agent that may be reset to zero whenever the - current time advances by one second. A source Bundle Protocol - Agent must never create two distinct bundles with the same source - endpoint ID and bundle creation timestamp. The combination of - source endpoint ID and bundle creation timestamp therefore serves - to identify a single transmission request, enabling it to be - acknowledged by the receiving application (provided the source - endpoint ID is not "dtn:none"). - - Lifetime: The lifetime field is an SDNV that indicates the time at - which the bundle's payload will no longer be useful, encoded as a - number of seconds past the creation time. When the current time - is greater than the creation time plus the lifetime, bundle nodes - need no longer retain or forward the bundle; the bundle may be - deleted from the network. - - Dictionary Length: The Dictionary Length field is an SDNV that - contains the length of the dictionary byte array. - - Dictionary: The Dictionary field is an array of bytes formed by - concatenating the null-terminated scheme names and SSPs of all - endpoint IDs referenced by any fields in this Primary Block - together with, potentially, other endpoint IDs referenced by - fields in other TBD DTN protocol blocks. Its length is given by - the value of the Dictionary Length field. - - Fragment Offset: If the Bundle Processing Control Flags of this - Primary block indicate that the bundle is a fragment, then the - Fragment Offset field is an SDNV indicating the offset from the - start of the original application data unit at which the bytes - comprising the payload of this bundle were located. If not, then - the Fragment Offset field is omitted from the block. - - - -Scott & Burleigh Expires January 4, 2008 [Page 23] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Total Application Data Unit Length: If the Bundle Processing - Control Flags of this Primary block indicate that the bundle is a - fragment, then the Total Application Data Unit Length field is an - SDNV indicating the total length of the original application data - unit of which this bundle's payload is a part. If not, then the - Total Application Data Unit Length field is omitted from the - block. - -4.5.2. Canonical Bundle Block Format - - Every bundle block of every type other than the primary bundle block - comprises the following fields, in this order: - - o Block type code, expressed as an 8-bit unsigned binary integer. - Bundle block type code 1 indicates that the block is a bundle - payload block. Block type codes 192 through 255 are not defined - in this specification and are available for private and/or - experimental use. All other values of the block type code are - reserved for future use. - - o Block processing control flags, an unsigned integer expressed as - an SDNV. The individual bits of this integer are used to invoke - selected block processing control features. - - o Block EID reference count and EID references (optional). If and - only if the block references EID elements in the primary block's - dictionary, the 'block contains an EID-reference field' flag in - the block processing control flags is set to 1 and the block - includes an EID reference field consisting of a count of EID - references expressed as an SDNV followed by the EID references - themselves. Each EID reference is a pair of SDNVs. The first - SDNV of each EID reference contains the offset of a scheme name in - the primary block's dictionary, and the second SDNV of each - reference contains the offset of a scheme-specific part in the - dictionary. - - o Block data length, an unsigned integer expressed as an SDNV. The - Block data length field contains the aggregate length of all - remaining fields of the block, i.e., the block-type-specific data - fields. - - o Block-type-specific data fields, whose format and order are type- - specific and whose aggregate length in octets is the value of the - block data length field. All multi-byte block-type-specific data - fields are represented in network byte order. - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 24] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - +-----------+-----------+-----------+-----------+ - |Block type | Block processing ctrl flags (SDNV)| - +-----------+-----------+-----------+-----------+ - | Block length (SDNV) | - +-----------+-----------+-----------+-----------+ - / Block body data (variable) / - +-----------+-----------+-----------+-----------+ - - Figure 6: Block layout without EID reference list. - - - +-----------+-----------+-----------+-----------+ - |Block Type | Block processing ctrl flags (SDNV)| - +-----------+-----------+-----------+-----------+ - | EID Reference Count (SDNV) | - +-----------+-----------+-----------+-----------+ - | Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) | - +-----------+-----------+-----------+-----------+ - | Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) | - +-----------+-----------+-----------+-----------+ - | Block length (SDNV) | - +-----------+-----------+-----------+-----------+ - / Block body data (variable) / - +-----------+-----------+-----------+-----------+ - - Figure 7: Block layout showing two EID references. - -4.5.3. Bundle Payload Block - - The fields of the bundle payload block are: - - Block Type: The Block Type field is a 1-byte field that indicates - the type of the block. For the bundle payload block this field - contains the value 1. - - Block Processing Control Flags: The Block Processing Control Flags - field is an SDNV that contains the block processing control flags - discussed in Section 4.3 above. - - Block Length: The Block Length field is an SDNV that contains the - aggregate length of all remaining fields of the block - which is - to say, the length of the bundle's payload. - - Payload: The application data carried by this bundle. - - That is, bundle payload blocks follow the canonical format of the - previous section with the restriction that the 'block contains an - EID-reference field' bit of the block processing control flags is - - - -Scott & Burleigh Expires January 4, 2008 [Page 25] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - never set. The block body data for payload blocks is the application - data carried by the bundle. - -4.6. Extension Blocks - - "Extension blocks" are all blocks other than the primary and payload - blocks. Because extension blocks are not defined in the Bundle - Protocol specification (the present document), not all nodes - conforming to this specification will necessarily instantiate Bundle - Protocol implementations that include procedures for processing (that - is, recognizing, parsing, acting on, and/or producing) all extension - blocks. It is therefore possible for a node to receive a bundle that - includes extension blocks which the node cannot process. - - Whenever a bundle is forwarded that contains one or more extension - blocks that could not be processed, the "Block was forwarded without - being processed" flag must be set to 1 within the block processing - flags of each such block. For each block flagged in this way, the - flag may optionally be cleared (i.e., set to zero) by another node - that subsequently receives the bundle and is able to process that - block; the specifications defining the various extension blocks are - expected to define the circumstances under which this flag may be - cleared, if any. - -4.7. Dictionary revision - - Any strings (scheme names and SSPs) in a bundle's dictionary that are - not referenced from the bundle's primary block nor from the block EID - reference field of any extension block may be removed from the - dictionary at the time the bundle is forwarded. - - Whenever removal of a string from the dictionary causes the offsets - (within the dictionary byte array) of any other strings to change, - all endpoint ID references that refer to those strings must be - adjusted at the same time. Note that these references may be in the - primary block and/or in the block EID reference fields of extension - blocks. - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 26] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -5. Bundle Processing - - The bundle processing procedures mandated in this section and in - Section 6 govern the operation of the Bundle Protocol Agent and the - Application Agent administrative element of each bundle node. They - are neither exhaustive nor exclusive. That is, supplementary DTN - protocol specifications (including, but not restricted to, the Bundle - Security Protocol [BSP]) may require that additional measures be - taken at specified junctures in these procedures. Such additional - measures shall not override or supersede the mandated bundle protocol - procedures, except that they may in some cases make these procedures - moot by requiring, for example, that implementations conforming to - the supplementary protocol terminate the processing of a given - incoming or outgoing bundle due to a fault condition recognized by - that protocol. - -5.1. Generation of administrative records - - All initial transmission of bundles is in response to bundle - transmission requests presented by nodes' application agents. When - required to "generate" an administrative record (a bundle status - report or a custody signal), the bundle protocol agent itself is - responsible for causing a new bundle to be transmitted, conveying - that record. In concept, the bundle protocol agent discharges this - responsibility by directing the administrative element of the node's - application agent to construct the record and request its - transmission as detailed in Section 6 below; in practice, the manner - in which administrative record generation is accomplished is an - implementation matter, provided the constraints noted in Section 6 - are observed. - - Under some circumstances the requesting of status reports could - result in an unacceptable increase in the bundle traffic in the - network. For this reason, the generation of status reports is - mandatory only in one case, the deletion of a bundle for which - custody transfer is requested. In all other cases the decision on - whether or not to generate a requested status report is left to the - discretion of the bundle protocol agent. Mechanisms that could - assist in making such decisions, such as pre-placed agreements - authorizing the generation of status reports under specified - circumstances, are beyond the scope of this specification. - - Notes on administrative record terminology: - - o A "bundle reception status report" is a bundle status report with - the "reporting node received bundle" flag set to 1. - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 27] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - o A "custody acceptance status report" is a bundle status report - with the "reporting node accepted custody of bundle" flag set to - 1. - - o A "bundle forwarding status report" is a bundle status report with - the "reporting node forwarded the bundle" flag set to 1. - - o A "bundle delivery status report" is a bundle status report with - the "reporting node delivered the bundle" flag set to 1. - - o A "bundle deletion status report" is a bundle status report with - the "reporting node deleted the bundle" flag set to 1. - - o A "Succeeded" custody signal is a custody signal with the "custody - transfer succeeded" flag set to 1. - - o A "Failed" custody signal is a custody signal with the "custody - transfer succeeded" flag set to zero. - - o The "current custodian" of a bundle is the endpoint identified by - the current custodian endpoint ID in the bundle's primary block. - -5.2. Bundle Transmission - - The steps in processing a bundle transmission request are: - - Step 1: If custody transfer is requested for this bundle - transmission and, moreover, custody acceptance by the source node - is required, then either the bundle protocol agent must commit to - accepting custody of the bundle - in which case processing - proceeds from Step 2 - or else the request cannot be honored and - all remaining steps of this procedure must be skipped. The bundle - protocol agent must not commit to accepting custody of a bundle if - the conditions under which custody of the bundle may be accepted - are not satisfied. The conditions under which a node may accept - custody of a bundle whose destination is not a singleton endpoint - are not defined in this specification. - - Step 2: Transmission of the bundle is initiated. An outbound - bundle must be created per the parameters of the bundle - transmission request, with current custodian endpoint ID set to - the null endpoint ID "dtn:none" and with the retention constraint - "Dispatch pending". The source endpoint ID of the bundle must be - either the ID of an endpoint of which the node is a member or else - the null endpoint ID "dtn:none". - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 28] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Step 3: Processing proceeds from Step 1 of Section 5.4. - -5.3. Bundle Dispatching - - The steps in dispatching a bundle are: - - Step 1: If the bundle's destination endpoint is an endpoint of - which the node is a member, the bundle delivery procedure defined - in Section 5.7 must be followed. - - Step 2: Processing proceeds from Step 1 of Section 5.4. - -5.4. Bundle Forwarding - - The steps in forwarding a bundle are: - - Step 1: The retention constraint "Forward pending" must be added to - the bundle, and the bundle's "Dispatch pending" retention - constraint must be removed. - - Step 2: The bundle protocol agent must determine whether or not - forwarding is contraindicated for any of the reasons listed in - Figure 12. In particular: - - * The bundle protocol agent must determine which endpoint(s) to - forward the bundle to. The bundle protocol agent may choose - either to forward the bundle directly to its destination - endpoint (if possible) or else to forward the bundle to some - other endpoint(s) for further forwarding. The manner in which - this decision is made may depend on the scheme name in the - destination endpoint ID but in any case is beyond the scope of - this document. If the agent finds it impossible to select any - endpoint(s) to forward the bundle to, then forwarding is - contraindicated. - - * Provided the bundle protocol agent succeeded in selecting the - endpoint(s) to forward the bundle to, the bundle protocol agent - must select the convergence layer adapter(s) whose services - will enable the node to send the bundle to the nodes of the - minimum reception group of each selected endpoint. The manner - in which the appropriate convergence layer adapters are - selected may depend on the scheme name in the destination - endpoint ID but in any case is beyond the scope of this - document. If the agent finds it impossible to select - convergence layer adapters to use in forwarding this bundle, - then forwarding is contraindicated. - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 29] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Step 3: If forwarding of the bundle is determined to be - contraindicated for any of the reasons listed in Figure 12, then - the Forwarding Contraindicated procedure defined in Section 5.4.1 - must be followed; the remaining steps of Section 5 are skipped at - this time. - - Step 4: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1 then the custody - transfer procedure defined in Section 5.10.2 must be followed. - - Step 5: For each endpoint selected for forwarding, the bundle - protocol agent must invoke the services of the selected - convergence layer adapter(s) in order to effect the sending of the - bundle to the nodes constituting the minimum reception group of - that endpoint. Determining the time at which the bundle is to be - sent by each convergence layer adapter is an implementation - matter. - - To keep from possibly invalidating bundle security, the sequencing - of the blocks in a forwarded bundle must not be changed as it - transits a node; received blocks must be transmitted in the same - relative order as that in which they were received. While blocks - may be added to bundles as they transit intermediate nodes, - removal of blocks that do not have their 'Discard block if it - can't be processed' flag in the block processing control flags set - to 1 may cause security to fail. - - Step 6: When all selected convergence layer adapters have informed - the bundle protocol agent that they have concluded their data - sending procedures with regard to this bundle: - - * If the "request reporting of bundle forwarding" flag in the - bundle's status report request field is set to 1, then a bundle - forwarding status report should be generated, destined for the - bundle's report-to endpoint ID. If the bundle has the - retention constraint "custody accepted" and all of the nodes in - the minimum reception group of the endpoint selected for - forwarding are known to be unable to send bundles back to this - node, then the reason code on this bundle forwarding status - report must be "forwarded over unidirectional link"; otherwise - the reason code must be "no additional information". - - * The bundle's "Forward pending" retention constraint must be - removed. - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 30] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -5.4.1. Forwarding Contraindicated - - The steps in responding to contraindication of forwarding for some - reason are: - - Step 1: The bundle protocol agent must determine whether or not to - declare failure in forwarding the bundle for this reason. Note: - this decision is likely to be influenced by the reason for which - forwarding is contraindicated. - - Step 2: If forwarding failure is declared, then the Forwarding - Failed procedure defined in 4.4.2 must be followed. Otherwise, - (a) if the bundle's custody transfer requested flag (in the bundle - processing flags field) is set to 1 then the custody transfer - procedure defined in Section 5.10 must be followed; (b) when - at - some future time - the forwarding of this bundle ceases to be - contraindicated, processing proceeds from Step 5 of Section 5.4. - -5.4.2. Forwarding Failed - - The steps in responding to a declaration of forwarding failure for - some reason are: - - Step 1: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1, custody transfer - failure must be handled. Procedures for handling failure of - custody transfer for a bundle whose destination is not a singleton - endpoint are not defined in this specification. For a bundle - whose destination is a singleton endpoint, the bundle protocol - agent must handle the custody transfer failure by generating a - "Failed" custody signal for the bundle, destined for the bundle's - current custodian; the custody signal must contain a reason code - corresponding to the reason for which forwarding was determined to - be contraindicated. (Note that discarding the bundle will not - delete it from the network, since the current custodian still has - a copy.) - - Step 2: If the bundle's destination endpoint is an endpoint of - which the node is a member, then the bundle's "Forward pending" - retention constraint must be removed. Otherwise the bundle must - be deleted: the bundle deletion procedure defined in 4.13 must be - followed, citing the reason for which forwarding was determined to - be contraindicated. - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 31] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -5.5. Bundle Expiration - - A bundle expires when the current time is greater than the bundle's - creation time plus its lifetime as specified in the primary bundle - block. Bundle expiration may occur at any point in the processing of - a bundle. When a bundle expires, the bundle protocol agent must - delete the bundle for the reason "lifetime expired": the bundle - deletion procedure defined in Section 5.13 must be followed. - -5.6. Bundle Reception - - The steps in processing a bundle received from another node are: - - Step 1: The retention constraint "Dispatch pending" must be added - to the bundle. - - Step 2: If the "request reporting of bundle reception" flag in the - bundle's status report request field is set to 1, then a bundle - reception status report with reason code "No additional - information" should be generated, destined for the bundle's - report-to endpoint ID. - - Step 3: For each block in the bundle that is an extension block - that the bundle protocol agent cannot process: - - * If the block processing flags in that block indicate that a - status report is requested in this event, then a bundle - reception status report with reason code "Block unintelligible" - should be generated, destined for the bundle's report-to - endpoint ID. - - * If the block processing flags in that block indicate that the - bundle must be deleted in this event, then the bundle protocol - agent must delete the bundle for the reason "Block - unintelligible"; the bundle deletion procedure defined in 4.13 - must be followed and all remaining steps of the bundle - reception procedure must be skipped. - - * If the block processing flags in that block do NOT indicate - that the bundle must be deleted in this event but do indicate - that the block must be discarded, then the bundle protocol - agent must remove this block from the bundle. - - * If the block processing flags in that block indicate NEITHER - that the bundle must be deleted NOR that the block must be - discarded, then the bundle protocol agent must set to 1 the - "Block was forwarded without being processed" flag in the block - processing flags of the block. - - - -Scott & Burleigh Expires January 4, 2008 [Page 32] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Step 4: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1 and the bundle has the - same source endpoint ID, creation timestamp, and (if the bundle is - a fragment) fragment offset and payload length as another bundle - that (a) has not been discarded and (b) currently has the - retention constraint "Custody accepted", custody transfer - redundancy must be handled; otherwise, processing proceeds from - Step 5. Procedures for handling redundancy in custody transfer - for a bundle whose destination is not a singleton endpoint are not - defined in this specification. For a bundle whose destination is - a singleton endpoint, the bundle protocol agent must handle - custody transfer redundancy by generating a "Failed" custody - signal for this bundle with reason code "Redundant reception", - destined for this bundle's current custodian, and removing this - bundle's "Dispatch pending" retention constraint. - - Step 5: Processing proceeds from Step 1 of Section 5.3. - -5.7. Local Bundle Delivery - - The steps in processing a bundle that is destined for an endpoint of - which this node is a member are: - - Step 1: If the received bundle is a fragment, the application data - unit reassembly procedure described in Section 5.9 must be - followed. If this procedure results in reassembly of the entire - original application data unit, processing of this bundle (whose - fragmentary payload has been replaced by the reassembled - application data unit) proceeds from Step 2; otherwise the - retention constraint "Reassembly pending" must be added to the - bundle and all remaining steps of this procedure are skipped. - - Step 2: Delivery depends on the state of the registration whose - endpoint ID matches that of the destination of the bundle: - - * If the registration is in the Active state, then the bundle - must be delivered subject to this registration (see Section 3.1 - above) as soon as all previously received bundles that are - deliverable subject to this registration have been delivered. - - * If the registration is in the Passive state, then the - registration's delivery failure action must be taken (see - Section 3.1 above). - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 33] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Step 3: As soon as the bundle has been delivered: - - - - * If the "request reporting of bundle delivery" flag in the - bundle's status report request field is set to 1, then a bundle - delivery status report should be generated, destined for the - bundle's report-to endpoint ID. Note that this status report - only states that the payload has been delivered to the - application agent, not that the application agent has processed - that payload. - - * If the bundle's custody transfer requested flag (in the bundle - processing flags field) is set to 1, custodial delivery must be - reported. Procedures for reporting custodial delivery for a - bundle whose destination is not a singleton endpoint are not - defined in this specification. For a bundle whose destination - is a singleton endpoint, the bundle protocol agent must report - custodial delivery by generating a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - -5.8. Bundle Fragmentation - - It may at times be necessary for bundle protocol agents to reduce the - sizes of bundles in order to forward them. This might be the case, - for example, if the endpoint to which a bundle is to be forwarded is - accessible only via intermittent contacts and no upcoming contact is - long enough to enable the forwarding of the entire bundle. - - The size of a bundle can be reduced by "fragmenting" the bundle. To - fragment a bundle whose payload is of size M is to replace it with - two "fragments" - new bundles with the same source endpoint ID and - creation timestamp as the original bundle - whose payloads are the - first N and the last (M - N) bytes of the original bundle's payload, - where 0 < N < M. Note that fragments may themselves be fragmented, so - fragmentation may in effect replace the original bundle with more - than two fragments. (However, there is only one 'level' of - fragmentation, as in IP fragmentation.) - - Any bundle whose primary block's bundle processing flags do NOT - indicate that it must not be fragmented may be fragmented at any - time, for any purpose, at the discretion of the bundle protocol - agent. - - Fragmentation shall be constrained as follows: - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 34] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - o The concatenation of the payloads of all fragments produced by - fragmentation must always be identical to the payload of the - bundle that was fragmented. Note that the payloads of fragments - resulting from different fragmentation episodes, in different - parts of the network, may be overlapping subsets of the original - bundle's payload. - - o The bundle processing flags in the primary block of each fragment - must be modified to indicate that the bundle is a fragment, and - both fragment offset and total application data unit length must - be provided at the end of each fragment's primary bundle block. - - o The primary blocks of the fragments will differ from that of the - fragmented bundle as noted above. - - o The payload blocks of fragments will differ from that of the - fragmented bundle as noted above. - - o All blocks that precede the payload block at the time of - fragmentation must be replicated in the fragment with the lowest - offset. - - o All blocks that follow the payload block at the time of - fragmentation must be replicated in the fragment with the highest - offset. - - o If the 'Block must be replicated in every fragment' bit is set to - one then the block must be replicated in every fragment. - - o If the 'Block must be replicated in every fragment' bit is set to - zero, the block should be replicated in only one fragment. - - o The relative order of all blocks that are present in a fragment - must be the same as in the bundle prior to fragmentation. - -5.9. Application Data Unit Reassembly - - If the concatenation - as informed by fragment offsets and payload - lengths - of the payloads of all previously received fragments with - the same source endpoint ID and creation timestamp as this fragment, - together with the payload of this fragment, forms a byte array whose - length is equal to the total application data unit length in the - fragment's primary block, then: - - o This byte array - the reassembled application data unit - must - replace the payload of this fragment. - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 35] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - o The "Reassembly pending" retention constraint must be removed from - every other fragment whose payload is a subset of the reassembled - application data unit. - - Note: reassembly of application data units from fragments occurs at - destination endpoints as necessary; an application data unit may also - be reassembled at some other endpoint on the route to the - destination. - -5.10. Custody Transfer - - The conditions under which a node may accept custody of a bundle - whose destination is not a singleton endpoint are not defined in this - specification. - - The decision as to whether or not to accept custody of a bundle whose - destination is a singleton endpoint is an implementation matter which - may involve both resource and policy considerations; however, if the - bundle protocol agent has committed to accepting custody of the - bundle (as described in Step 1 of Section 5.2) then custody must be - accepted. - - If the bundle protocol agent elects to accept custody of the bundle, - then it must follow the custody acceptance procedure defined in - Section 5.10.1. - -5.10.1. Custody Acceptance - - Procedures for acceptance of custody of a bundle whose destination is - not a singleton endpoint are not defined in this specification. - - Procedures for acceptance of custody of a bundle whose destination is - a singleton endpoint are defined as follows. - - The retention constraint "Custody accepted" must be added to the - bundle. - - If the "request custody acceptance reporting" flag in the bundle's - status report request field is set to 1, a custody acceptance status - report should be generated, destined for the report-to endpoint ID of - the bundle. However, if a bundle reception status report was - generated for this bundle (step 1 of Section 5.6) then this report - should be generated by simply turning on the "Reporting node accepted - custody of bundle" flag in that earlier report's status flags byte. - - The bundle protocol agent must generate a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - - - - -Scott & Burleigh Expires January 4, 2008 [Page 36] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - The bundle protocol agent must assert the new current custodian for - the bundle. It does so by changing the current custodian endpoint ID - in the bundle's primary block to the endpoint ID of one of the - singleton endpoints in which the node is registered. This may entail - appending that endpoint ID's null-terminated scheme name and SSP to - the dictionary byte array in the bundle's primary block, and in some - case it may also enable the (optional) removal of the current - custodian endpoint ID's scheme name and/or SSP from the dictionary. - - The bundle protocol agent may set a custody transfer countdown timer - for this bundle; upon expiration of this timer prior to expiration of - the bundle itself and prior to custody transfer success for this - bundle, the custody transfer failure procedure detailed in section - Section 5.12 must be followed. The manner in which the countdown - interval for such a timer is determined is an implementation matter. - - The bundle should be retained in persistent storage if possible. - -5.10.2. Custody Release - - Procedures for release of custody of a bundle whose destination is - not a singleton endpoint are not defined in this specification. - - When custody of a bundle is released, where the destination of the - bundle is a singleton endpoint, the "Custody accepted" retention - constraint must be removed from the bundle and any custody transfer - timer that has been established for this bundle must be destroyed. - -5.11. Custody Transfer Success - - Procedures for determining custody transfer success for a bundle - whose destination is not a singleton endpoint are not defined in this - specification. - - Upon receipt of a "Succeeded" custody signal at a node that is a - custodial node of the bundle identified in the custody signal, where - the destination of the bundle is a singleton endpoint, custody of the - bundle must be released as described in Section 5.10.2. - -5.12. Custody Transfer Failure - - Procedures for determining custody transfer failure for a bundle - whose destination is not a singleton endpoint are not defined in this - specification. Custody transfer for a bundle whose destination is a - singleton endpoint is determined to have failed at a custodial node - for that bundle when either (a) that node's custody transfer timer - for that bundle (if any) expires or (b) a "Failed" custody signal for - that bundle is received at that node. - - - -Scott & Burleigh Expires January 4, 2008 [Page 37] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Upon determination of custody transfer failure, the action taken by - the bundle protocol agent is implementation-specific and may depend - on the nature of the failure. For example, if custody transfer - failure was inferred from expiration of a custody transfer timer or - was asserted by a "Failed" custody signal with the "Depleted storage" - reason code, the bundle protocol agent might choose to re-forward the - bundle, possibly on a different route (Section 5.4). Receipt of a - "Failed" custody signal with the "Redundant reception" reason code, - on the other hand, might cause the bundle protocol agent to release - custody of the bundle and to revise its algorithm for computing - countdown intervals for custody transfer timers. - -5.13. Bundle Deletion - - The steps in deleting a bundle are: - - Step 1: If the retention constraint "Custody accepted" currently - prevents this bundle from being discarded, and the destination of - the bundle is a singleton endpoint, then: - - * Custody of the node is released as described in Section 5.10.2. - - * A bundle deletion status report citing the reason for deletion - must be generated, destined for the bundle's report-to endpoint - ID. - - Otherwise, if the "request reporting of bundle deletion" flag in - the bundle's status report request field is set to 1, then a - bundle deletion status report citing the reason for deletion - should be generated, destined for the bundle's report-to endpoint - ID. - - Step 2: All of the bundle's retention constraints must be removed. - -5.14. Discarding a Bundle - - As soon as a bundle has no remaining retention constraints it may be - discarded. - -5.15. Canceling a Transmission - - When requested to cancel a specified transmission, where the bundle - created upon initiation of the indicated transmission has not yet - been discarded, the bundle protocol agent must delete that bundle for - the reason "transmission canceled". For this purpose, the procedure - defined in Section 5.13 must be followed. - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 38] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -5.16. Polling - - When requested to poll a specified registration that is in Passive - state, the bundle protocol agent must immediately deliver the least - recently received bundle that is deliverable subject to the indicated - registration, if any. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 39] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -6. Administrative Record Processing - -6.1. Administrative Records - - Administrative records are standard application data units that are - used in providing some of the features of the Bundle Protocol. Two - types of administrative records have been defined to date: bundle - status reports and custody signals. - - Every administrative record consists of a four-bit record type code - followed by four bits of administrative record flags, followed by - record content in type-specific format. Record type codes are - defined as follows: - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0001 | Bundle status report. | - +---------+--------------------------------------------+ - | 0010 | Custody signal. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 8: Administrative Record Type Codes. - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0001 | Record is for a fragment; fragment | - | | offset and length fields are present. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 9: Administrative Record Flags. - - All time values in administrative records are UTC times expressed in - "DTN time" representation. A DTN time consists of an SDNV indicating - the number of seconds since the start of the year 2000, followed by - an SDNV indicating the number of nanoseconds since the start of the - indicated second. - - The contents of the various types of administrative records are - described below. - - - - -Scott & Burleigh Expires January 4, 2008 [Page 40] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -6.1.1. Bundle Status Reports - - The transmission of 'bundle status reports' under specified - conditions is an option that can be invoked when transmission of a - bundle is requested. These reports are intended to provide - information about how bundles are progressing through the system, - including notices of receipt, custody transfer, forwarding, final - delivery, and deletion. They are transmitted to the Report-to - endpoints of bundles. - - - +----------------+----------------+----------------+----------------+ - | Status Flags | Reason code | Fragment offset (*) (if - +----------------+----------------+----------------+----------------+ - present) | Fragment length (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Time of receipt of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of custody acceptance of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of forwarding of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of delivery of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of deletion of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp time (*) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp sequence number (*) | - +----------------+----------------+----------------+----------------+ - | Length of X's source endpoint ID (*) | Source - +----------------+---------------------------------+ + - endpoint ID of bundle X (variable) | - +----------------+----------------+----------------+----------------+ - - Figure 10: Bundle status report format - - (*) Notes: - - The Fragment Offset field, if present, is an SDNV and is therefore - variable-length. A three-octet SDNV is shown here for convenience in - representation. - - The Fragment Length field, if present, is an SDNV and is therefore - variable-length. A three-octet SDNV is shown here for convenience in - representation. - - The Creation Timestamp fields replicate the Creation Timestamp fields - - - -Scott & Burleigh Expires January 4, 2008 [Page 41] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - in the primary block of the subject bundle. As such they are SDNVs - (see 3.5.1 above) and are therefore variable-length. Four-octet - SDNVs are shown here for convenience in representation. - - The source endpoint ID length field is an SDNV and is therefore - variable-length. A three-octet SDNV is shown here for convenience in - representation. - - The fields in a bundle status report are: - - Status Flags: A 1-byte field containing the following flags: - - +----------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | 00000001 | Reporting node received bundle. | - +----------+--------------------------------------------+ - | 00000010 | Reporting node accepted custody of bundle.| - +----------+--------------------------------------------+ - | 00000100 | Reporting node forwarded the bundle. | - +----------+--------------------------------------------+ - | 00001000 | Reporting node delivered the bundle. | - +----------+--------------------------------------------+ - | 00010000 | Reporting node deleted the bundle. | - +----------+--------------------------------------------+ - | 00100000 | Unused. | - +----------+--------------------------------------------+ - | 01000000 | Unused. | - +----------+--------------------------------------------+ - | 10000000 | Unused. | - +----------+--------------------------------------------+ - - Figure 11: Status Flags for Bundle Status Reports - - Reason Code: A 1-byte field explaining the value of the flags in - the status flags byte. The list of status report reason codes - provided here is neither exhaustive nor exclusive; supplementary - DTN protocol specifications (including, but not restricted to, the - Bundle Security Protocol [BSP]) may define additional reason - codes. Status report reason codes are defined as follows: - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 42] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0x00 | No additional information. | - +---------+--------------------------------------------+ - | 0x01 | Lifetime expired. | - +---------+--------------------------------------------+ - | 0x02 | Forwarded over unidirectional link. | - +---------+--------------------------------------------+ - | 0x03 | Transmission canceled. | - +---------+--------------------------------------------+ - | 0x04 | Depleted storage. | - +---------+--------------------------------------------+ - | 0x05 | Destination endpoint ID unintelligible. | - +---------+--------------------------------------------+ - | 0x06 | No known route to destination from here. | - +---------+--------------------------------------------+ - | 0x07 | No timely contact with next node on route.| - +---------+--------------------------------------------+ - | 0x08 | Block unintelligible. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 12: Status Report Reason Codes - - Fragment Offset: If the bundle fragment bit is set in the status - flags, then the offset (within the original application data unit) - of the payload of the bundle that caused the status report to be - generated is included here. - - Fragment length: If the bundle fragment bit is set in the status - flags, then the length of the payload of the subject bundle is - included here. - - Time of Receipt (if present): If the bundle-received bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was received at the reporting node is included here. - - Time of Custody Acceptance (if present): If the custody-accepted - bit is set in the status flags, then a DTN time indicating the - time at which custody was accepted at the reporting node is - included here. - - Time of Forward (if present): If the bundle-forwarded bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was first forwarded at the reporting node is included here. - - - - -Scott & Burleigh Expires January 4, 2008 [Page 43] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Time of Delivery (if present): If the bundle-delivered bit is set - in the status flags, then a DTN time indicating the time at which - the bundle was delivered at the reporting node is included here. - - Time of Deletion (if present): If the bundle-deleted bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was deleted at the reporting node is included here. - - Creation Timestamp of Subject Bundle: A copy of the creation - timestamp of the bundle that caused the status report to be - generated. - - Length of Source Endpoint ID: The length in bytes of the source - endpoint ID of the bundle that caused the status report to be - generated. - - Source Endpoint ID text: The text of the source endpoint ID of the - bundle that caused the status report to be generated. - -6.1.2. Custody Signals - - Custody signals are administrative records that effect custody - transfer operations. They are transmitted to the endpoints that are - the current custodians of bundles. - - Custody signals have the following format. - - Custody Signal regarding bundle 'X': - - +----------------+----------------+----------------+----------------+ - | Status | Fragment offset (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Fragment length (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Time of signal (a DTN time) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp time (*) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp sequence number (*) | - +----------------+----------------+----------------+----------------+ - | Length of X's source endpoint ID (*) | Source - +----------------+---------------------------------+ + - endpoint ID of bundle X (variable) | - +----------------+----------------+----------------+----------------+ - - Figure 13: Custody signal format. - - (*) Notes: - - - -Scott & Burleigh Expires January 4, 2008 [Page 44] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - The Fragment Offset field, if present, is an SDNV and is therefore - variable-length. A three-octet SDNV is shown here for convenience in - representation. - - The Fragment Length field, if present, is an SDNV and is therefore - variable-length. A four-octet SDNV is shown here for convenience in - representation. - - The Creation Timestamp fields replicate the Creation Timestamp fields - in the primary block of the subject bundle. As such they are SDNVs - (see Section 4.5.1 above) and are therefore variable-length. Four- - octet SDNVs are shown here for convenience in representation. - - The source endpoint ID length field is an SDNV and is therefore - variable-length. A three-octet SDNV is shown here for convenience in - representation. - - The fields in a custody signal are: - - Status: A 1-byte field containing a 1-bit "custody transfer - succeeded" flag followed by a 7-bit reason code explaining the - value of that flag. Custody signal reason codes are defined as - follows: - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 45] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0x00 | No additional information. | - +---------+--------------------------------------------+ - | 0x01 | Reserved for future use. | - +---------+--------------------------------------------+ - | 0x02 | Reserved for future use. | - +---------+--------------------------------------------+ - | 0x03 | Redundant reception (reception by a node | - | | that is a custodial node for this bundle).| - +---------+--------------------------------------------+ - | 0x04 | Depleted storage. | - +---------+--------------------------------------------+ - | 0x05 | Destination endpoint ID unintelligible. | - +---------+--------------------------------------------+ - | 0x06 | No known route to destination from here. | - +---------+--------------------------------------------+ - | 0x07 | No timely contact with next node on route.| - +---------+--------------------------------------------+ - | 0x08 | Block unintelligible. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 14: Custody Signal Reason Codes - - Fragment offset: If the bundle fragment bit is set in the status - flags, then the offset (within the original application data unit) - of the payload of the bundle that caused the status report to be - generated is included here. - - Fragment length: If the bundle fragment bit is set in the status - flags, then the length of the payload of the subject bundle is - included here. - - Time of Signal: A DTN time indicating the time at which the signal - was generated. - - Creation Timestamp of Subject Bundle: A copy of the creation - timestamp of the bundle to which the signal applies. - - Length of Source Endpoint ID: The length in bytes of the source - endpoint ID of the bundle to which the signal applied. - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 46] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Source Endpoint ID text: The text of the source endpoint ID of the - bundle to which the signal applies. - -6.2. Generation of Administrative Records - - Whenever the application agent's administrative element is directed - by the bundle protocol agent to generate an administrative record - with reference to some bundle, the following procedure must be - followed: - - Step 1: The administrative record must be constructed. If the - referenced bundle is a fragment, the administrative record must - have the Fragment flag set and must contain the fragment offset - and fragment length fields; the value of the fragment offset field - must be the value of the referenced bundle's fragment offset, and - the value of the fragment length field must be the length of the - referenced bundle's payload. - - Step 2: A request for transmission of a bundle whose payload is - this administrative record must be presented to the bundle - protocol agent. - -6.3. Reception of Custody Signals - - For each received custody signal that has the Custody Transfer - Succeeded flag set to 1, the administrative element of the - application agent must direct the bundle protocol agent to follow the - custody transfer success procedure in Section 5.11. - - For each received custody signal that has the Custody Transfer - Succeeded flag set to 0, the administrative element of the - application agent must direct the bundle protocol agent to follow the - custody transfer failure procedure in Section 5.12. - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 47] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -7. Services Required of the Convergence Layer - -7.1. The Convergence Layer - - The successful operation of the end-to-end bundle protocol depends on - the operation of underlying protocols at what is termed the - "convergence layer"; these protocols accomplish communication between - nodes. A wide variety of protocols may serve this purpose, so long - as each convergence layer protocol adapter provides a defined minimal - set of services to the bundle protocol agent. This convergence layer - service specification enumerates those services. - -7.2. Summary of Convergence Layer Services - - Each convergence layer protocol adapter is expected to provide the - following services to the bundle protocol agent: - - o sending a bundle to all bundle nodes in the minimum reception - group of the endpoint identified by a specified endpoint ID that - are reachable via the convergence layer protocol; - - o delivering to the bundle protocol agent a bundle that was sent by - a remote bundle node via the convergence layer protocol. - - The convergence layer service interface specified here is neither - exhaustive nor exclusive. That is, supplementary DTN protocol - specifications (including, but not restricted to, the Bundle Security - Protocol [BSP]) may expect convergence layer adapters which serve BP - implementations conforming to those protocols to provide additional - services. - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 48] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -8. Security Considerations - - The bundle protocol has taken security into concern from the outset - of its design. It was always assumed that security services would be - needed in the use of the bundle protocol. As a result, the bundle - protocol security architecture and the available security services - are specified in an accompanying document, the Bundle Security - Protocol specification [BSP]; an informative overview of this - architecture is provided in [SECO]. - - The bundle protocol has been designed with the notion that it will be - run over networks with scarce resources. For example, the networks - might have limited bandwidth, limited connectivity, constrained - storage in relay nodes, etc. Therefore, the bundle protocol must - ensure that only those entities authorized to send bundles over such - constrained environments are actually allowed to do so. All - unauthorized entities should be prevented from consuming valuable - resources. - - Likewise, because of the potentially long latencies and delays - involved in the networks that make use of the bundle protocol, data - sources should be concerned with the integrity of the data received - at the intended destination(s) and may also be concerned with - ensuring confidentiality of the data as it traverses the network. - Without integrity, the bundle payload data might be corrupted while - in transit without the destination able to detect it. Similarly, the - data source can be concerned with ensuring that the data can only be - used by those authorized; hence the need for confidentiality. - - Internal to the bundle-aware overlay network, the bundle nodes should - be concerned with the authenticity of other bundle nodes as well as - the preservation of bundle payload data integrity as it is forwarded - between bundle nodes. - - As a result, bundle security is concerned with the authenticity, - integrity, and confidentiality of bundles conveyed among bundle - nodes. This is accomplished via the use of three, independent - security specific bundle blocks which may be used together to provide - multiple bundle security services or independently of one another, - depending on perceived security threats, mandated security - requirements, and security policies that must be enforced. - - The Bundle Authentication Block (BAB) ensures the authenticity and - integrity of bundles on a hop-by-hop basis between bundle nodes. The - BAB allows each bundle node to verify a bundle's authenticity before - processing or forwarding the bundle. In this way, entities that are - not authorized to send bundles will have unauthorized transmissions - blocked by security-aware bundle nodes. - - - -Scott & Burleigh Expires January 4, 2008 [Page 49] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Additionally, to provide "security-source" to "security-destination" - bundle authenticity and integrity, the Payload Security Block (PSB) - is used. A "security-source" may not actually be the origination - point of the bundle but instead may be the first point along the path - that is security-aware and is able to apply security services. For - example, an enclave of networked systems may generate bundles but - only their gateway may be required and/or able to apply security - services. The PSB allows any security-enabled entity along the - delivery path, in addition to the "security-destination" (the - recipient counterpart to the "security-source"), to ensure the - bundle's authenticity. - - Finally, to provide payload confidentiality, the use of the - Confidentiality Block (CB) is available. The bundle payload may be - encrypted to provide "security-source" to "security-destination" - payload confidentiality/privacy. The CB indicates the cryptographic - algorithm and key IDs that were used to encrypt the payload. - - Note that removal of strings from the dictionary at a given point in - a bundle's end-to-end path, and attendant adjustment of endpoint ID - references in the blocks of that bundle, may make it necessary to re- - compute values in one or more of the bundle's security blocks. - - Bundle security must not be invalidated by forwarding nodes even - though they themselves might not use the Bundle Security Protocol. - In particular, the sequencing of the blocks in a forwarded bundle - must not be changed as it transits a node; received blocks must be - transmitted in the same relative order as that in which they were - received. While blocks may be added to bundles as they transit - intermediate nodes, removal of blocks that do not have their 'Discard - block if it can't be processed' flag in the block processing control - flags set to 1 may cause security to fail. - - Inclusion of the Bundle Security Protocol in any Bundle Protocol - implementation is RECOMMENDED. Use of the Bundle Security Protocol - in Bundle Protocol operations is OPTIONAL. - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 50] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -9. IANA Considerations - - The "dtn:" URI scheme has been provisionally registered by IANA. See - http://www.iana.org/assignments/uri-schemes.html for the latest - details. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 51] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -10. References - -10.1. Normative References - - [IPR] Bradner, S., "Intellectual Property Rights in IETF - Technology", RFC 3979, BCP 79, March 2005. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RGTS] Bradner, S., "IETF Rights in Contributions", RFC 3978, - BCP 78, March 2005. - - [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", RFC 3986, - STD 66, January 2005. - - [URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and - Registration Procedures for New URI Schemes", RFC 4395, - BCP 115, February 2006. - -10.2. Informative References - - [ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", - RFC 4838, April 2007. - - [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding - Rules: Specification of Basic Encoding Rules (BER), - Canonical Encoding Rules (CER) and Distinguished Encoding - Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- - 1:2002", 2003. - - [BSP] Symington, S., "Bundle Security Protocol Specification, - work in progress", Work in - progress, draft-irtf-dtnrg-bundle-security-03, - October 2007. - - [NTP] Mills, D., "Network Time Protocol (Version 3) - Specification", RFC 1305, March 1992. - - [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, - "Delay-Tolerant Networking Security Overview", Work in - progress, draft-irtf-dtnrg-sec-overview-03, July 2007. - - [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for - Challenged Internets", SIGCOMM 2003 . - - [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A - - - -Scott & Burleigh Expires January 4, 2008 [Page 52] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - - Tutorial", . - - [UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC: - historical background and perspectives" in Journees - systemes de reference spatio-temporels", 2004. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 53] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -Appendix A. Contributors - - This was an effort of the delay tolerant networking research group. - The following dtnrg participants contributed significant technical - material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, - Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, - Michael Demmer of the University of California at Berkeley, Robert - Durst, Keith Scott, and Susan Symington of The MITRE Corporation, - Kevin Fall of Intel Research, Stephen Farrell of Trinity College - Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio - University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. - (text of Section 8) . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 54] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -Appendix B. Comments - - Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay - Tolerant Networking Research Group (DTNRG) web site is located at - http://www.dtnrg.org. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 55] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -Authors' Addresses - - Keith L. Scott - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 21102 - US - - Phone: +1 703 983 6547 - Fax: +1 703 983 7142 - Email: kscott@mitre.org - - - Scott Burleigh - NASA Jet Propulsion Laboratory - 4800 Oak Grove Dr. - Pasadena, CA 91109-8099 - US - - Phone: +1 818 393 3353 - Fax: +1 818 354 1075 - Email: Scott.Burleigh@jpl.nasa.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 56] -=0C -Internet-Draft Bundle Protocol Specification July 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Scott & Burleigh Expires January 4, 2008 [Page 57] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-sec-overview-02.t= xt --- a/doc/draft-irtf-dtnrg-sec-overview-02.txt Sat Dec 12 17:10:03 2009 +00= 00 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1457 +0,0 @@ - - - -DTN Research Group S. Farrell -Internet-Draft Trinity College Dublin -Intended status: Informational S. Symington -Expires: April 7, 2007 The MITRE Corporation - H. Weiss - SPARTA, Inc. - October 4, 2006 - - - Delay-Tolerant Networking Security Overview - draft-irtf-dtnrg-sec-overview-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on April 7, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 1] -=0C -Internet-Draft DTN Security Overview October 2006 - - -Abstract - - This document provides an overview of the security requirements and - mechanisms considered for delay tolerant networking security. It - discusses the options for protecting such networks and describes - reasons why specific security mechanisms were (or were not) chosen - for the relevant protocols. The entire document is informative, - given it's purpose is mainly to document design decisions. - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. This document . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.1. Non DTN node threats . . . . . . . . . . . . . . . . . . . 5 - 2.2. Resource consumption . . . . . . . . . . . . . . . . . . . 5 - 2.3. Denial of service . . . . . . . . . . . . . . . . . . . . 6 - 2.4. Confidentiality and integrity . . . . . . . . . . . . . . 6 - 2.5. Traffic storms . . . . . . . . . . . . . . . . . . . . . . 7 - 2.6. Partial protection is just that. . . . . . . . . . . . . . 8 - 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 9 - 3.1. End-to-end-ish-ness . . . . . . . . . . . . . . . . . . . 9 - 3.2. Confidentiality and integrity . . . . . . . . . . . . . . 10 - 3.3. Policy based routing . . . . . . . . . . . . . . . . . . . 11 - 4. Security Design considerations . . . . . . . . . . . . . . . . 14 - 4.1. Only DTN-friendly schemes need apply . . . . . . . . . . . 14 - 4.2. TLS is a good model . . . . . . . . . . . . . . . . . . . 14 - 4.3. Naming and identities . . . . . . . . . . . . . . . . . . 15 - 4.4. Placement of checksums . . . . . . . . . . . . . . . . . . 16 - 4.5. Hop-by-hop-ish-ness . . . . . . . . . . . . . . . . . . . 16 - 5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 5.1. Key management . . . . . . . . . . . . . . . . . . . . . . 18 - 5.2. Handling replays . . . . . . . . . . . . . . . . . . . . . 18 - 5.3. Traffic analysis . . . . . . . . . . . . . . . . . . . . . 20 - 5.4. Routing protocol security . . . . . . . . . . . . . . . . 20 - 5.5. Multicast security . . . . . . . . . . . . . . . . . . . . 20 - 5.6. Performance Issues . . . . . . . . . . . . . . . . . . . . 21 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 - 8. Informative References . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 - Intellectual Property and Copyright Statements . . . . . . . . . . 26 - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 2] -=0C -Internet-Draft DTN Security Overview October 2006 - - -1. Introduction - - This section places this document in its current context as one of a - series of DTN documents. - -1.1. This document - - This document is a product of the IRTF (http://www.irtf.org/) Delay - Tolerant Networking Research Group (DTRNG) and is being discussed on - the dtn-security mailing list. See the DRNRG site - (http://www.dtnrg.org/) for details of the various DTN mailing lists. - - The intent is for this document to present a snapshot of the security - analysis which has been carried out in the DTNRG. The document is - not normative in any sense but is intended to be a companion document - which explains further the reasons for the design choices which are - documented elsewhere. - - The structure of the document is as follows: - - We first present a selection of threats which were considered - during the analysis carried out so far. - - We then present some security requirements derived from that - analysis or elsewhere. - - We next present some of the design considerations which were - applied during the design of the security mechanisms. - - And we finally discuss some of the remaining open issues in DTN - security. - - Given that this is simply an informative snapshot document, none of - the above are intended to be exhaustive, nor should other documents - be criticized because something is mentioned here, but not countered - there. - - While this document is being prepared in parallel with the various - protocol and security specifications, we will generally try not to - refer to the specific fields used in those documents since the - details may change and maintaining consistency at that level is not a - goal here. Where we do refer to such details, of course, the - specification documents are normative. - -1.2. Background - - The overall delay tolerant networking (DTN) architecture is described - in [1]. A DTN is an overlay network on top of multiple lower layer - - - -Farrell, et al. Expires April 7, 2007 [Page 3] -=0C -Internet-Draft DTN Security Overview October 2006 - - - networks, some of which may be challenged by limitations such as - intermittent loss of connectivity, long or variable delay, asymmetric - data rates, or high error rates. The purpose of a DTN protocol is to - support interoperability across such potentially stressed lower layer - networks. The DTN overlay network specifies a bundle protocol which - is layered on top of a so-called convergence layer, (probably on top - of even lower layers). The DTN Bundle Protocol [2] describes the - format of the messages (called bundles) passed between DTN bundle - agents that participate in bundle communications to form the DTN - store-and-forward overlay network. - - The Bundle Security Protocol Specification [3] defines the integrity - and confidentiality mechanisms for use with the Bundle protocol - together with associated policy options. - - Two other documents exists which are now somewhat outdated but remain - worthwhile reading: A tutorial [4] about DTNs generally and an early - DTN security model document [5]. - - There is also a related lower layer protocol specifically designed - for very long delay environments, called the Licklider Transmission - Protocol (LTP), [6] and which is also being developed by the same - group. Even though the LTP protocol shares some security features - [7] with the bundle protocol, we will mainly reference the bundle - protocol here since its environment is much more complex and there is - also a separate LTP motivation document [8]. - - In this document we may refer to messages to mean either a bundle - from the bundle protocol, or else a segment from the LTP protocol. - The context should make the meaning clear in each case. - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 4] -=0C -Internet-Draft DTN Security Overview October 2006 - - -2. Threats - - This section describes some of the threats which were considered - during the process of designing the DTN security mechanisms. In this - discussion (and throughout the document), we will try to highlight - DTN-specific aspects and generally assume the reader is familiar with - basic networking security concepts. - -2.1. Non DTN node threats - - The first set of threats to consider are those coming from network - elements which aren't directly part of the DTN. As an overlay - network, bundles may traverse multiple underlying network elements on - each DTN "hop". Of course, any vulnerability in the bundle protocol - can be exploited at any of those network elements. - - DTN security must take into account the usual range of such potential - exploits (masquerading, bit flips etc.) but in contrast to most - network protocols, as an overlay protocol, the bundle protocol is - possibly an easier target. In particular if it is possible to insert - new bundles at such lower-layer "hops" then many DTN nodes will have - to be capable of countering such insertions by where possible, - detecting and quickly deleting such spurious bundles. - - Conversely, it is equally possible to take advantage of lower layer - security services, but this won't be visible from the DTN layer, and - requires coordinated administration in order to be really effective. - -2.2. Resource consumption - - Due to the resource-scarcity that characterizes DTNs, unauthorized - access and use of DTN resources is a serious concern. Specifically, - the following consume DTN resources and can be considered as threats - against the DTN as an infrastructure: - - 1. access by unauthorized entities, - - 2. unauthorized applications controlling the DTN infrastructure, - - 3. authorized applications sending bundles at a rate or class of - service for which they lack permission, - - 4. modifying bundle content, - - 5. compromised network elements, be they DTN nodes or not. - - In addition to these threats, DTN nodes can act to assist or amplify - such resource consuming behavior as follows: - - - -Farrell, et al. Expires April 7, 2007 [Page 5] -=0C -Internet-Draft DTN Security Overview October 2006 - - - 1. forwarding bundles that were not sent by authorized DTN nodes - - 2. generating reports which weren't originally requested (say if a - bundle has been modified). - - 3. not detecting unplanned replays or other mis-behaviors - -2.3. Denial of service - - In addition to the basic resource consumption threats mentioned above - there are also a range of denial of service (DoS) attacks which must - be considered in the DTN context. DTNs are in this respect, in more- - or-less the same position as other MANETs, so all the problems with - secure routing in ad-hoc networks [9] exist for many DTNs too! - - While DoS attacks can be mounted at any layer, from physical to - application, generally when developing a new protocol we should be - attempting to do two things:- - - Make it hard to launch an "off-path" DoS attacks by making it hard - to "guess" valid values for messages, e.g. through using random - values instead of counters for identifying messages. - - Make it easier to withstand "on-path" DoS attacks, by providing a - way to choke-off DoS traffic, e.g. by changing to a mode of - operation where only fresh, authenticated messages are accepted - and all others are dropped. - - In a DTN environment, the generally longer latencies involved will - probably act to make DoS attempts more effective, so protocol - developers and deployments should explicitly consider DoS at all - times. - - As with all networks, security mechanisms will themselves create new - DoS opportunities so whatever services and mechanisms are defined for - DTN security should also explicitly consider DoS, e.g. mechanisms - which involve certificate status checking (via some protocol to a key - server) based on received messages create new DoS opportunities since - such lookups consume resources on both the receiving node and the key - server. - -2.4. Confidentiality and integrity - - In addition to the resource consuming threats, DTN applications can - also be vulnerable to the usual threats against confidentiality and - integrity, in particular the following: - - - - - -Farrell, et al. Expires April 7, 2007 [Page 6] -=0C -Internet-Draft DTN Security Overview October 2006 - - - 1. falsifying a bundle's source, - - 2. changing the intended destination, - - 3. changing the bundle's control fields, - - 4. changing other header or payload fields, - - 5. replay of bundles - - 6. copying or disclosing bundle data as it passes - -2.5. Traffic storms - - So long as DTN protocols include traffic generated as an artifact of - other traffic, then the possibility exists that manipulation of - (genuine, forged or modified) bundle content can be used to create - unwanted traffic. Given a DTN operating sufficiently "close to the - wire", such traffic could have serious affects. - - In particular, the current bundle protocol includes various messages - containing administrative records (bundle status reports and custody - signals) that are produced in response to original traffic. The - Bundle Protocol, however, includes a constraint that the status - report request flags on all bundles containing administrative records - must be zero. So, although a bundle that is not a custody signal or - status report may cause the generation of custody signals and/or - status reports, bundles that are themselves custody signals or status - reports are not permitted to cause the generation of custody signals - or status reports. This constraint is designed to prevent bundle - storms, and it does so in the case in which bundles can not be - modified. If a DTN node (or other network element) could modify a - single "forwarding report" by both resetting its "Application Data - Unit is an Administrative Record" bundle processing flag and setting - its "forwarding report" status report request flag, then the - forwarding of a bundle status report could cause the forwarding of an - additional status report, and so on. Traffic could continue to be - generated in this manner for as long as the values of the bundle - processing flags and the status report request flags can be modified. - So, while the constraint that bundles containing administrative - records are not permitted to generate other bundles containing - administrative records goes a long way toward preventing traffic - storms, it may be best to entirely remove some of status reporting - capabilities from the Bundle Protocol.) - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 7] -=0C -Internet-Draft DTN Security Overview October 2006 - - -2.6. Partial protection is just that. - - Some DTN nodes won't need to protect all parts of all bundles. Some - DTN nodes won't be able to properly protect the integrity of the - entire bundle including its payload. Potential reasons range from - lack of computing power to application (or lower) layer protection - applying integrity, with the result that there's no benefit in - repeating this work in the bundle layer. Alternatively, some DTN - nodes may choose not to protect all parts of all bundles in return - for being able to perform reactive fragmentation. - - There are also cases where bundle headers should be modified in - transit (e.g. the dictionary header in some versions of the bundle - protocol), or a "via" header which captures the route a bundle has - followed, so that integrity checking on anything more than a hop-by- - hop basis becomes unwieldy since the to-be-protected bytes are a - moving target. - - The result is that it is possible that some fields of a bundle are - strongly protected whilst others are effectively unprotected. - Whenever such a situation occurs then it will be possible for network - elements to at least use the bundle protocol as a communications - channel, perhaps covert or perhaps overt. Where such misuse is a - concern, then the DTN should either use different security options - which do cover the fields of concern, or else administrators (if they - exist!) must ensure that the bundles only traverse lower layers where - the probability of such misuse is sufficiently small. - - - - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 8] -=0C -Internet-Draft DTN Security Overview October 2006 - - -3. Security Requirements - - This section lists some of the security requirements which were - agreed as priorities during the development of the DTN security - mechanisms. - -3.1. End-to-end-ish-ness - - Traditionally, protocols tend to provide security services which are - used either (or both) on a hop-by-hop or end-to-end basis. For DTN - security though, we require that these services be usable also - between nodes which are not endpoints, but which can be in the middle - of a route. - - For example, if a sensor network uses some satisfactory lower layer - security, and has some gateway sensor node, which is more capable and - also say periodically connected to the Internet, then we may wish to - use DTN security services to protect messages between that gateway - node and the other DTN sources and destinations on the Internet-side - of the gateway. In the case of a confidentiality service, this is - clearly useful since bundles which leave the sensor network could be - encrypted (by the gateway node) for the final destination. In the - case of say a software download, new code might be integrity - protected from the origin to the gateway which is able to check some - relevant white or black lists or use some other software - authorisation scheme which cannot practically be used from a sensor - node. - - In order to define services which can be used in these ways we - distinguish between the sender of a bundle and the security-sender - for an application of one of these services. Similarly, we can - distinguish between the bundle recipient and the security-recipient - (or security-destination) for a given application of a security - service. Basically, the security-sender is the DTN node that applied - the security service, and the security-recipient (or security- - destination) is the DTN node which is the target for the security - service - say the node expected to decrypt or do integrity checking. - - The extent to which the various services can be combined for the - same, or different security senders and destinations is something - which has to be made clear in the relevant protocol definition. - However, we can state a requirement that this should be kept as - simple as possible since unwanted complexity in this respect is - highly likely to make a DTN harder to manage, and thus less secure. - - Having said that, there may still be good reason to distinguish (at - the protocol field level) between uses of these services which are - intended to be hop-by-hop (i.e. between this and the next DTN node), - - - -Farrell, et al. Expires April 7, 2007 [Page 9] -=0C -Internet-Draft DTN Security Overview October 2006 - - - as opposed to uses of these services which are intended to be applied - across multiple nodes. Equally, a protocol might not need to make - this distinction and might only define e.g. one confidentiality - service which can be applied multiple times for a single bundle with - different combinations of security-sender and security-recipient. - - There is one more example of the ways in which DTN security services - seem to differ from more "normal" network security services, that is - worth mentioning here. (Indeed this mode of operation might be - useful in non-DTNs too!). When a message is authenticated using a - digital signature, then in principle any network element on the path - can do some checking of that signature. If the message contains - sufficient information (the supposed signer's public key or a - resolvable reference thereto) then any node can at least check the - cryptographic correctness of the signature. - - However, this is typically insufficient to decide how to process the - message, since in many environments basically anyone could insert a - public key and a signature thus producing a message which passes this - test. So in most real cases, there is some additional check that the - signer is authorised, either explicitly by checking the signer's name - or key is authorised for the purpose, or else implicitly by for - example using a PKI for this purpose (say via an extended key usage - extension). It turns out that all practical ways to perform this - authorisation check are problematic in at least some DTN cases, - either due to the lack of availability of an authorisation server - (say due to simple latency back from the verifier to the relevant - authorisation server) or due to restricted node capabilities (say in - the case of a sensor node). - - In such cases, it may be sensible for some "bastion" node along the - route to do the authorisation check and then to (again explicitly or - implicitly) attest that the authorisation test has passed. - Subsequent nodes, may however, for either data integrity or - accountability reasons wish to also validate the cryptographic - correctness of the signature. The end result might be a mechanism - whereby the message has a signature plus some meta-data which are - fully processed by the "bastion" node, whereas the signature is only - partly processed by all subsequent nodes. (Note: The role of the - "security-destination" concept in such cases is not yet clear.) - -3.2. Confidentiality and integrity - - Since most protocol designs use common elements to deal with all - cryptographic based security services and mechanisms, we will deal - with all of these in this section. - - DTN protocols should provide a way to encrypt protocol elements so - - - -Farrell, et al. Expires April 7, 2007 [Page 10] -=0C -Internet-Draft DTN Security Overview October 2006 - - - that messages in transit cannot practically be read. The extent to - which a confidentiality service should be able to be applied to any - or all protocol elements is a somewhat open issue. In particular, - whether or not source confidentiality should be provided is still - under discussion. Clearly, calling for a confidentiality service - implies a need for key management. However, a proper DTN key - management scheme is still an open issue, so we would expect DTN - protocols, to support pre-shared-keys (and/or known irrevocable - certificates) in the meantime. - - Similarly, DTN protocols should provide a way to apply an integrity - check to a message so that the identity of the security-sender can be - established and so that changes in sensitive parts of the message can - be detected. Again, this implies a need for key management which is - not, so far, really met. - - Clearly a protocol should allow for fairly flexible combinations of - applications of the confidentiality and integrity services, though - hopefully disallowing insecure combinations e.g. a plaintext - signature which is out of scope of a confidentiality service allows - plaintext guesses to be verified. - - However these services are provided they should allow for sensible - combinations of a range of standard cryptographic algorithms to be - used and should also allow for changes to the set of acceptable - algorithms to be made over time. - -3.3. Policy based routing - - Since the DTN, as a piece of infrastructure, may be quite fragile, we - require protocols to be cautious in how they consume network - resources. While the intent of this is fairly clear, it is of course - not testable so we need to be a little more prescriptive in order to - state a testable requirement. - - We require that DTN protocols and implementations support mechanisms - for policy-based routing, in other words each DTN protocol - specification should state the security-relevant policy variables - based upon which it is reasonable to expect an implementation should - be able to make routing and forwarding decisions. While this is - still a little vague, the expectation is that each DTN specification - should, in its security considerations text, say which security - issues may exist which require a routing or forwarding policy - decision to be made. - - In particular, since forwarding even a single bundle will consume - some network resources, every single DTN node must implicitly - incorporate some element of policy-based routing. Of course, we do - - - -Farrell, et al. Expires April 7, 2007 [Page 11] -=0C -Internet-Draft DTN Security Overview October 2006 - - - not expect that every single DTN node will be able to handle complex - policy decisions. In fact, a DTN node can be programmed to forward - all bundles received in a deterministic manner, say flooding the - bundle to all peers other than then one from which it was received. - Even such a simple minded node is however, implicitly implementing a - policy - in this case a simple flooding policy. So, though we - require all nodes to implement some policy, that policy can be very - simple. - - Regardless of how simple, or complex, a node's support for policy - based routing/forwarding might be, DTN implementers should document - the relevant aspects of the implementation. In the absence of such - documentation a node might be deployed in an inappropriate context, - potentially damaging an entire network. - - Some DTN nodes will however be on boundaries of various sorts, - whether they be network topology related, administrative, networking - technology related or simply a case where this node is the first - which is capable of handling complex policy decisions. At one stage - these nodes were termed security policy routers, and were considered - to be "special" nodes. Our current view though, is that all nodes - are in fact policy routers with some implementing policies which are - more complex than others. - - We do not, at this stage, require that there be an interoperable way - to transfer policy settings between DTN nodes. Such a system could - perhaps be developed (though it is an extremely complex task), but - pragmatically, for now we consider the development of a DTN specific - policy language and distribution framework out of scope. - - DTNs themselves do not appear to generate many new types of policy - based controls - the usual ingress, egress and forwarding types of - control can all be applied in DTNs. For example, some "bastion" node - might insist on all inbound bundles being authenticated, and might - add an authentication element to all outbound elements. So all the - usual forms of control can and should be available for use in DTN - nodes. - - The DTN specific policy controls identified thus far, and for which - we would recommend support include: - - TTL type controls where we consider the amount of time for which a - bundle has been "in-flight" - - controls to do with "strange" routes, such as those that loop - - controls handling local or global information about resource - constraints in the DTN (e.g. knowledge of a peer's storage - - - -Farrell, et al. Expires April 7, 2007 [Page 12] -=0C -Internet-Draft DTN Security Overview October 2006 - - - capacity) - - controls related to special types of fragmentation (e.g. reactive - fragmentation) which are defined in a DTN - - No doubt more will be identified as DTN deployment experience is - gained. - - DTN node implementations will also be required to control access to - whatever DTN interface they provide so that only authorized entities - can act as the source (or destination) of bundles. Clearly this - aspect of access control is an implementation, rather than a protocol - issue. - - It must be noted that policy based routing, if not deployed - appropriately, may inadvertently create bundle sinkholes. Consider - the case in which a bundle is fragmented, and if one fragment of the - bundle reaches a router who's policy requires it to see the entire - bundle, then all fragments of that bundle must also pass through that - same router. If they do not, then eventually the fragment at our - paranoid router will expire and ultimately the entire bundle never - arrives at the intended destination. This is clearly a case to avoid - - doing so, may however be difficult to arrange without good control - over routes. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 13] -=0C -Internet-Draft DTN Security Overview October 2006 - - -4. Security Design considerations - - This section lists some of the security design considerations which - were used during the development of the DTN security mechanisms - -4.1. Only DTN-friendly schemes need apply - - The high round-trip times and frequent and unpredictable - disconnections that are characteristic of DTNs mean that security - solutions which depend on ubiquitous online security services cannot - generally be applied. So solutions requiring ubiquitous access to - such servers (e.g. Kerberos, XKMS) are problematic. This is more- - or-less analogous to the way that TCP doesn't work in DTNs. However, - such solutions might be usable from a range of DTN nodes within some - security domain, though in that case what happens when a route spans - more than one such domain is an interesting question. - - The long delays that may be inherent in DTNs mean that data may be - valid (even in-transit) for days or weeks, so depending on message - expiration alone to rid the network of unwanted messages will also - not work in general. - - The impact of this design consideration most obviously applies to key - management, but it will also apply to other aspects of security, for - example, distribution of new policy settings. - -4.2. TLS is a good model - - The Transport Layer Security (TLS) specification [10] provides us - with some useful design ideas, especially in its use of what it calls - "ciphersuites". In TLS a ciphersuite is a single number that defines - how all of the various cryptographic algorithms are to be used. The - ciphersuite number is used in TLS during negotiation. One of the - more common ciphersuites is usually called - "TLS_RSA_WITH_3DES_EDE_CBC_SHA" indicating that the TLS protocol - (rather than an earlier SSL version) is being used with RSA based key - transport and with a variant of triple-DES as its bulk encryption - algorithm and SHA-1 for various digesting tasks. - - So we can obviously use a ciphersuite value in the same way - to - indicate which cryptographic algorithms are in use for what purpose. - This is how we can support both symmetric and asymmetric mechanisms - for our cryptographic security services, and also allows us to extend - DTN security in the future, e.g. if identity based cryptography - schemes become usable. - - In DTNs of course we won't be doing negotiations of the sort done in - TLS but we can still use the ciphersuite idea, and in fact, we extend - - - -Farrell, et al. Expires April 7, 2007 [Page 14] -=0C -Internet-Draft DTN Security Overview October 2006 - - - it a little more to use the ciphersuite to also indicate which - services are being applied (integrity or confidentiality) and also - the set of input bits for the service. In this way we can - distinguish between say an integrity service which only protects the - headers, from one which also protects the payload. - - This allows us to address one of the trickier problems which was - considered for DTN security - combining integrity checking with - fragmentation. So-called reactive fragmentation is where we try to - optimize retransmission on the basis that we're fairly sure that some - bytes were sent before a link dropped out unexpectedly. What we do - is basically start from where we left off (or from where we are - confident that the recipient had received) in order to reduce the - number of bytes re-transmitted. Clearly though the recipient of such - a fragment has a problem checking integrity - say if I've gotten the - first 1MB of a 2MB bundle and then the link goes down. I (the - recipient) now have to decide whether to forward this fragment, but - if I do forward it - it cannot be integrity checked in an end-to- - end(-ish) fashion, since not all bytes are present, which clearly is - a breach of integrity. - - One of the ways we've discussed for handling this is to associated a - number of checksums with the bundle - say one for every 100k in this - case, so that the entire bundle would use 20 checksums to provide - end-to-end integrity. The trick is that if the reactively forwarded - fragment has the first 10 of those, then its integrity can be - checked. Of course this comes at the expense of complexity and - additional bytes of overhead (in this case perhaps 400 or more - bytes), so it won't be desirable in most cases. Since each checksum - protects a part of the payload, this scheme has been referred to as - the "toilet paper" scheme - each forwardable fragment consisting of a - number of sheets of payload-paper with its associated checksum. In - order to support this type of fragmentation, we therefore have to - define the relevant toilet paper ciphersuites, which is done in the - security protocol specification. (At the time of writing anyway - - hopefully, these schemes can be deprecated since they are clumsy and - overly-complex for the benefit accruing.) - - In summary the DTN concept of ciphersuite is borrowed from TLS and - slightly extended to also encompass the idea of having different - parts of the bundle being protected by the relevant security service. - However, in general DTNs cannot support the use of the TLS handshake - protocol as used in the terrestrial Internet. - -4.3. Naming and identities - - Most security mechanisms work well, or at least work obviously well, - with only some kinds of identity. For example, Kerberos style - - - -Farrell, et al. Expires April 7, 2007 [Page 15] -=0C -Internet-Draft DTN Security Overview October 2006 - - - security tends to go with domain-specific login names, PKI tends to - work best with X.500 or ldap style names (and well-ish with RFC822 - addresses). In bundles the current scheme for endpoint identifiers - is to represent them as URIs. However, there is currently no well- - defined URI scheme which is specifically required to be supported. - This means that there is work to be done to map from these URIs to - the types of identity which are easily supported by whatever - mechanisms we're considering. - - In LTP, identities are flat octet strings, so again there is work to - be done to map from these to e.g. user identities in your favorite - security mechanism. - -4.4. Placement of checksums - - As currently specified, the bundle protocol requires that the last - header in the bundle be identified as such by setting its "Last - header" header processing flag. This bit enables security headers to - be placed either before or after the bundle payload header. The - ability to place a signature after the bundle payload header, at the - end of the bundle, is important for integrity-protecting some bundles - at nodes that have limited buffer space. For example, if a node - wishes to sign a 10Mb bundle, but it only has 1Mb of usable buffer, - then creating a digital signature over the 10Mb and sending that out - before the end of the payload is simply impossible. - - However, due to the properties of most hash functions, were the - signature to be placed at the end of the bundle, then such a - constrained node could in fact send out the signed bundle. This is - due to the fact that hash functions have a continuation property - which allows the to-be-hashed data to be fed through the function in - blocks with only a small amount of state information required to be - stored. - - For this reason, DTN security protocols have the option of placing - either a single header in the message or placing correlated headers - in the message, for example one at the start of the message which - specifies the signature/hashing to be used (the ciphersuite in our - case), and one (that contains the actual signature or MAC) at the end - of the entire bundle. The ability to place such correlated security - headers in the message allows even very memory-constrained nodes to - be able to process the bundle and verify its security result. - -4.5. Hop-by-hop-ish-ness - - In the above we discussed how security services can be applied which - are not "truly" end-to-end. In the limit of course, we can use such - a scheme to apply security just between this DTN node and the next - - - -Farrell, et al. Expires April 7, 2007 [Page 16] -=0C -Internet-Draft DTN Security Overview October 2006 - - - hop. In particular there is clearly benefit in many cases from - applying integrity checks on such a hop-by-hop basis. - - There are two things worth noting about this particular case: - - Even though the protocol data units involved in end-to-end-ish and - hop-by-hop-ish applications of security services may be almost - identical, there may be benefit in artificially distinguishing - between them since one could imagine many nodes which would only - ever require (and thus properly support) hop-by-hop security - and - in fact one could reasonably define ciphersuites which are only - useful in such a hop-by-hop fashion. - - There doesn't seem to be much interest in making such an - artificial distinction for confidentiality services, perhaps since - the ability to use lower layer security is presumed to be much - more common when the DTN nodes are "close" like this. - - In any case, the current version of the bundle security protocol does - use a different header for this sort of hop-by-hop integrity. - Whether this remains, or changes in future drafts, is an open issue. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 17] -=0C -Internet-Draft DTN Security Overview October 2006 - - -5. Open Issues - - This section discusses some of the issues which are still very open, - either due to a current lack of consensus in the DTNRG, or else due - to their being areas (like DTN key management) where much basic - research remains to be done. - - Where an issue has been discussed previously (e.g. source - confidentiality), we will not include it here again. - -5.1. Key management - - The main open issue in DTN security is the lack of a delay-tolerant - method for key management. It seems that we are at the stage where - we only really know how to use existing schemes, which ultimately - require an on-line status checking service or key distribution - service which is not practical in a high delay or highly disrupted - environment. - - Note that even though some identity based cryptography (IBC) schemes - superficially appear to solve this problem (once we assume that the - originator has a name for the destination endpoint), this is in fact - not the case. The problem is that current IBC schemes effectively - act only as a kind of "group certificate" where all of the nodes - using a given private key generator can use a single "certificate", - but the problem of validity for that "certificate" (which will - contain the generator's parameters) is the same problem as verifying - a CA certificate in a standard PKI. - - So, the only generally applicable schemes we currently have are - basically equivalent to shared secrets or else irrevocable public key - (or certificate based) schemes. Clearly, this is an area where more - research work could produce interesting results. - -5.2. Handling replays - - In most networking scenarios, we either wish to eliminate or else - dramatically reduce the probability of messages being replayed. In - some DTN contexts this will also be the case - particularly as - replaying a (say authenticated, authorized) message can be a fairly - straightforward way to consume scarce network resources. - - However, there are also DTN scenarios where we wish to deliberately - replay messages, even to the extent of routing messages around a - loop. For example, if Bob is willing to act as a data mule for - Alice, who has limited storage, then Bob might pick up a bundle as he - passes Alice on his outbound journey from his Internet-connected home - location. As he goes on however, Bob also runs into storage - - - -Farrell, et al. Expires April 7, 2007 [Page 18] -=0C -Internet-Draft DTN Security Overview October 2006 - - - problems, and so he temporarily deposits the bundle with Charlie, who - he's passing now, and who he'll also pass on his way back home, in - say, a week's time. After a week, Bob indeed passes Charlie again - and picks up that bundle for the second time, after which he goes on - to successfully deliver the bundle via the Internet-connected node at - home. Now in this scenario, the same bundle is received by Bob - twice, and so would likely trigger any replay detection algorithm - that Bob is running, but of course, the behavior as described, is the - nominal behavior for the circumstances presented. - - In addition to the example above, there are some routing schemes - which involve duplicating messages, for example, a node might flood - all its peers with a copy of a message to increase the probability - that the message will arrive at the destination before it (the - message) expires. Clearly such routing schemes are likely to result - in nodes seeing the same message more than once, but it's not clear - whether any such node would be correct to delete such apparent - "duplicates". - - The element of delay in DTNs also complicates handling replays. - Replay detection schemes generally depend on noting some unique - aspect of messages (via digesting of some message fields) and then - keeping a list of (the digests of) recently seen messages. The - problem in the DTN context is however, the "recently seen" part of - such replay detection algorithms, since maintaining such a list for - say 30 days would be fairly resource intensive, but might be required - if latencies are of that size. So the most obvious ways to protect - against replays are problematic. - - The result is that the extent to which we can or should define a - generic DTN replay detection scheme is hard to determine, and at this - point this remains an open issue in DTN security. It may well be - that this means that replay detection schemes really need to be - specified as part of a bundle routing algorithm. - - There is one aspect of replay handling where we can however enforce - some security - the bundle node which is the final destination can be - set to only deliver each bundle once to its application. In this - way, even though replays can consume network resources, they are less - likely cause application layer damage. (An example of such damage - would be a protocol which used a bundle to represent "Move the - telescope 10 degrees left" - repeated replays of this message could - result in damage if the telescope is pointed at the Sun. Of course, - the application layer in this case ought also be detecting replays, - e.g. by including a command number, but the example does demonstrate - the point.) - - - - - -Farrell, et al. Expires April 7, 2007 [Page 19] -=0C -Internet-Draft DTN Security Overview October 2006 - - -5.3. Traffic analysis - - We do not currently define any security services for protecting - against traffic analysis. A general traffic analysis protection - scheme is probably not in any case a realistic goal for DTNs, given - their tendency to be resource-scarce and in addition there have been - no calls for a generic approach to this problem. However, for some - disruption tolerant networks, hiding traffic (e.g. the existence of a - signal from a sensor net) may be a very important security - requirement. - - So, the first open issue here is the extent to which there is a real - need for a generic scheme for protection against traffic analysis. - If there were, then the second open issue is how to define such a - scheme to be delay and disruption tolerant and which also doesn't - consume too many resources. - - Finally, traffic analysis protection may be left as a local matter - for the underlying network layers, e.g. if a particular radio link - were of concern, then total obscuration of that link may be required, - and may in fact be the only way to hide such radio traffic. - -5.4. Routing protocol security - - Clearly whenever DTN routing protocols are defined they will - introduce new security requirements, or at least change the emphasis - to be properly placed on meeting the various requirements posited - above. For example, one could expect that a robust and scalable - origin-authentication scheme would become more important. - - At the time of writing there are no well-documented DTN routing - protocols, so DTN routing protocol security must clearly be in our - list of open issues. However, if a putative DTN routing protocol - were to use either the Bundle protocol or LTP, it could clearly make - use of their existing security features. - -5.5. Multicast security - - Work on what it means to use modes of operation like multicast, - nearcast, anycast etc. in a DTN is really only beginning. However, - it is clear that there are some new aspects to this work, since most - work to date has implicitly assumed that the signalling traffic (e.g. - joining a group) can occur in more-or-less "real" time. In a DTN, - joining a multicast group may be more akin to signing up to a mailing - list, so that messages originated before the join may be received - afterwards - in principle such a DTN "joiner" might get sent the - entire mailing list archive either by design or in error. - - - - -Farrell, et al. Expires April 7, 2007 [Page 20] -=0C -Internet-Draft DTN Security Overview October 2006 - - - So, given that there are differences between "traditional" multicast - and DTN "multicast", then we clearly have no real idea about the - threats or security requirements which may apply. Just to give an - example of the type of issue to be considered: when joining if I - authenticate with some credential which has a notBefore time of Jan 1 - 2005, (as an X.509 public key certificate might have), and some - message created before that time is still to be delivered, should the - notBefore time of the credential be part of the decision as to - whether to route the message to the "joiner"? In this case, probably - the answer is "no", but in some contexts that could be the wrong - answer, allowing new (cheap) identities access to old (expensively - accrued) materials. - -5.6. Performance Issues - - Provision of security within a DTN imposes both bandwidth utilization - costs on the DTN links and computational costs on the DTN nodes. - - The provision of DTN security consumes additional bandwidth which - will depend on the way optional parameters are encoded (or not) and - also on the cryptographic algorithms being used. In addition, if - more than one security service is used for the same bundle (say a MAC - to be removed by the next hop and a signature for the final - destination) then we are again chewing into the possibly limited - amount of bandwidth available for security purposes. - - The use of DTN security also imposes computational costs on DTN - nodes. Again there may be limits as to how much CPU is worth - devoting to security and the amount of computation will depend on the - algorithms used and their parameters. - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 21] -=0C -Internet-Draft DTN Security Overview October 2006 - - -6. Security Considerations - - Since this entire document is an informative description of how the - DTNRG are approaching security, there is little to say in this - section. - - However, implementers of DTN protocols must not take text here to be - normative, in the case of conflict the relevant protocol - specification takes precedence. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 22] -=0C -Internet-Draft DTN Security Overview October 2006 - - -7. IANA Considerations - - None. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 23] -=0C -Internet-Draft DTN Security Overview October 2006 - - -8. Informative References - - [1] Cerf, V., "Delay-Tolerant Network Architecture", - draft-irtf-dtnrg-arch-06.txt, work-in-progress, September 2006. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-06.txt, work-in-progress, - August 2006. - - [3] Symington, S., Farrell, S., and H. Weiss, "Bundle Security - Protocol Specification", - draft-irtf-dtnrg-bundle-security-02.txt, work-in-progress, - October 2006. - - [4] Warthman, F., "Delay-Tolerant Networks (DTNs) A Tutorial", - http://www.dtnrg.org/ , March 2003. - - [5] Durst, R., "An Infrastructure Security Model for Delay Tolerant - Networks", http://www.dtnrg.org/ , July 2002. - - [6] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider - Transmission Protocol", - draft-irtf-dtnrg-ltp-05.txt, work-in-progress, September 2006. - - [7] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider - Transmission Protocol - Extensions", - draft-irtf-dtnrg-ltp-extensions-04.txt, work-in-progress, - September 2006. - - [8] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider - Transmission Protocol - Motivation", - draft-irtf-dtnrg-ltp-motivation-03.txt, work-in-progress, - September 2006. - - [9] Zhou, L. and Z. Haas, "Securing Ad-Hoc Networks", IEEE - network vol 13, no. 6, Nov-Dec 1999, pp 24-30. - - [10] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC - 2246 , January 1999. - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 24] -=0C -Internet-Draft DTN Security Overview October 2006 - - -Authors' Addresses - - Stephen Farrell - Trinity College Dublin - Distributed Systems Group - Department of Computer Science - Trinity College - Dublin - Ireland - - Phone: +353-1-608-1539 - Email: stephen.farrell@cs.tcd.ie - - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: 703 983 7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - Howard Weiss - SPARTA, Inc. - 7075 Samuel Morse Drive - Columbia, MD 21046 - US - - Phone: +1-410-872-1515 x201 - Email: hsw@sparta.com - - - - - - - - - - - - - - - - - - -Farrell, et al. Expires April 7, 2007 [Page 25] -=0C -Internet-Draft DTN Security Overview October 2006 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2006). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Farrell, et al. Expires April 7, 2007 [Page 26] -=0C - diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-tcp-clayer-00.txt --- a/doc/draft-irtf-dtnrg-tcp-clayer-00.txt Sat Dec 12 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1176 +0,0 @@ - - - -Delay Tolerant Networking Research M. Demmer -Group UC Berkeley -Internet-Draft J. Ott -Intended status: Experimental Helsinki University of Technology -Expires: December 29, 2007 June 27, 2007 - - - Delay Tolerant Networking TCP Convergence Layer Protocol - draft-irtf-dtnrg-tcp-clayer-00.txt - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on December 29, 2007. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - This document describes the protocol for the TCP-based Convergence - Layer for Delay Tolerant Networking (DTN). - - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 1] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Definitions Relating to the Bundle Protocol . . . . . . . 4 - 2.2. Definitions specific to the TCPCL Protocol . . . . . . . . 5 - 3. General Protocol Description . . . . . . . . . . . . . . . . . 6 - 3.1. Example message exchange . . . . . . . . . . . . . . . . . 7 - 4. Connection Establishment . . . . . . . . . . . . . . . . . . . 8 - 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2. Validation and parameter negotiation . . . . . . . . . . . 11 - 5. Established Connection Operation . . . . . . . . . . . . . . . 12 - 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . . 12 - 5.2. Bundle Data Transmission . . . . . . . . . . . . . . . . . 14 - 5.3. Bundle Acknowledgments . . . . . . . . . . . . . . . . . . 15 - 5.4. Bundle Refusal . . . . . . . . . . . . . . . . . . . . . . 15 - 5.5. Keepalive Messages . . . . . . . . . . . . . . . . . . . . 16 - 6. Connection Termination . . . . . . . . . . . . . . . . . . . . 17 - 6.1. Shutdown Message . . . . . . . . . . . . . . . . . . . . . 17 - 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . . 18 - 7. Requirements notation . . . . . . . . . . . . . . . . . . . . 19 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 - Intellectual Property and Copyright Statements . . . . . . . . . . 21 - - - - - - - - - - - - - - - - - - - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 2] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -1. Introduction - - This document describes the TCP-based convergence layer protocol for - Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an - end-to-end architecture providing communications in and/or through - highly stressed environments, including those with intermittent - connectivity, long and/or variable delays, and high bit error rates. - More detailed descriptions of the rationale and capabilities of these - networks can be found in the Delay-Tolerant Network Architecture [2] - Internet Draft. - - An important goal of the DTN architecture is to accommodate a wide - range of networking technologies and environments. The protocol used - for DTN communications is the Bundling Protocol (BP) [3], an - application-layer protocol that is used to construct a store-and- - forward overlay network. As described in the bundle protocol - specification, BP requires the services of a "convergence layer - adapter" (CLA) to send and receive bundles using an underlying - internet protocol. This document describes one such convergence - layer adapter that uses the well-known Transmission Control Protocol - (TCP). - - The locations of the TCPCL and BP in the Internet model protocol - stack are shown in Figure 1. In particular, both the BP and the - TCPCL reside above the transport layer, i.e., at the application - layer. - - +-------------------------+ - | DTN Application | -\ - +-------------------------| | - | Bundle Protocol (BP) | -> Application Layer - +-------------------------+ | - | TCP Conv. Layer (TCPCL) | -/ - +-------------------------+ - | TCP | ---> Transport Layer - +-------------------------+ - | IP | ---> Network Layer - +-------------------------+ - | Link-Layer Protocol | ---> Link Layer - +-------------------------+ - | Physical Medium | ---> Physical Layer - +-------------------------+ - - Figure 1: The locations of the bundle protocol and the TCP - convergence layer protocol in the Internet protocol stack - - This document describes the format of the protocol data units passed - between entities participating in TCPCL communications. This - - - -Demmer & Ott Expires December 29, 2007 [Page 3] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - document does not address: - - The format of protocol data units of the bundling protocol, as - those are defined elsewhere [3]. - - Mechanisms for locating or identifying other bundle nodes within - an internet. - - Operational logic or procedures used to implement this protocol. - - - Note that this document describes version 3 of the protocol. - Versions 0, 1, and 2 were never specified in any Internet Draft, RFC, - or any other public document. These prior versions of the protocol - were, however, implemented in the DTN reference implementation [5], - in prior releases, hence the current version number reflects the - existence of those prior versions. - - -2. Definitions - -2.1. Definitions Relating to the Bundle Protocol - - The following set of definitions are abbreviated versions of those - which appear in the Bundle Protocol Specification [3]. To the extent - in which terms appear in both documents, they are intended to have - the same meaning. - - Bundle -- A bundle is a protocol data unit of the DTN bundle - protocol. - - Bundle payload -- A bundle payload (or simply "payload") is the - application data whose conveyance to the bundle's destination is - the purpose for the transmission of a given bundle. - - Fragment -- A fragment is a bundle whose payload contains a range of - bytes from another bundle's payload. - - Bundle node -- A bundle node (or simply a "node") is any entity that - can send and/or receive bundles. The particular instantiation - of this entity is deliberately unconstrained, allowing for - implementations in software libraries, long-running processes, - or even hardware. One component of the bundle node is the - implementation of a convergence layer adapter. - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 4] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - - Convergence layer adapter -- A convergence layer adapter (CLA) sends - and receives bundles utilizing the services of some 'native' - internet protocol. This document describes the manner in which - a CLA sends and receives bundles when using the TCP protocol for - inter-node communication. - - Self Describing Numeric Value -- A self describing numeric value - (SDNV) is a variable length encoding for integer values, defined - in the bundle protocol specification. - - -2.2. Definitions specific to the TCPCL Protocol - - This section contains definitions that are interpreted to be specific - to the operation of the TCPCL protocol, as described below. - - TCP Connection -- A TCP connection refers to a transport connection - using TCP as the transport protocol. - - TCPCL Connection -- A TCPCL connection (as opposed to a TCP - connection) is a TCPCL communication relationship between two - bundle nodes. The lifetime of a TCPCL connection is one-to-one - with the lifetime of an underlying TCP connection. Therefore a - TCPCL connection is initiated when a bundle node initiates a TCP - connection to be established for the purposes of bundle - communication. A TCPCL connection is terminated when the TCP - connection ends, due either to one or both nodes actively - terminating the TCP connection or due to network errors causing - a failure of the TCP connection. For the remainder of this - document, the term "connection" without the prefix "TCPCL" shall - refer to a TCPCL connection. - - Connection parameters -- The connection parameters are a set of - values used to affect the operation of the TCPCL for a given - connection. The manner in which these parameters are conveyed - to the bundle node and thereby to the TCPCL is implementation- - dependent. However, the mechanism by which two bundle nodes - exchange and negotiate the values to be used for a given session - is described in Section Section 4.2. - - Connection initiator -- The connection initiator is the bundle node - that causes the establishment of a new connection by creating a - new TCP connection (for example, by using the connect() call in - the BSD sockets API) and then following the procedures described - in Section 4. - - - - - -Demmer & Ott Expires December 29, 2007 [Page 5] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - - Connection acceptor -- The connection acceptor is the bundle node - that establishes a connection in response to an active - connection attempt by another bundle node (for example, by using - the listen() and accept() calls of the BSD sockets API) and then - following the procedures described in Section 4. - - Transmission -- Transmission refers to the procedures and mechanisms - (described below) for conveyance of a bundle from one node to - another. - - - - -3. General Protocol Description - - This protocol provides bundle conveyance over a TCP connection and - specifies the encapsulation of bundles as well as procedures for TCP - connection setup and teardown. The general operation of the protocol - is as follows: - - First one node establishes a TCPCL connection to the other by - initiating a TCP connection. After setup of the TCP connection is - complete, an initial contact header is exchanged in both directions - to set parameters of the TCPCL connection and exchange a singleton - endpoint identifier for each node (not the singleton EID of any - application running on the node), to denote the bundle-layer identity - of each DTN node. This is used to assist in routing and forwarding - messages, e.g., to prevent loops. - - Once the TCPCL connection is established and configured in this way, - bundles can be transmitted in either direction. Each bundle is - transmitted in one or more logical segments of formatted bundle data. - Each logical data segment consists of a DATA_SEGMENT message header, - an SDNV containing the length of the segment, and finally the byte - range of the bundle data. The choice of the length to use for - segments is an implementation matter. The first segment for a bundle - must set the 'start' flag and the last one must set the 'end' flag in - the DATA_SEGMENT message header. - - An optional feature of the protocol is for the receiving node to send - acknowledgments as bundle data segments arrive (ACK_SEGMENT). The - rationale behind these acknowledgments is to enable the sender node - to determine how much of the bundle has been received, so that in - case the connection is interrupted, it can perform reactive - fragmentation to avoid re-sending the already transmitted part of the - bundle. - - - - -Demmer & Ott Expires December 29, 2007 [Page 6] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - When acknowledgments are enabled, then for each data segment that is - received, the receiving node sends an ACK_SEGMENT code followed by an - SDNV containing the cumulative length of the bundle that has been - received. Note that in the case of concurrent bidirectional - transmission, then ack segments may be interleaved with data - segments. - - Another optional feature is that a receiver may interrupt the - transmission of a bundle at any point in time by replying with a - negative acknowledgment (REFUSE_BUNDLE) which causes the sender to - stop transmission of the current bundle, after completing - transmission of a partially sent data segment. Note: This allows a - receiver that detects it already has received a certain bundle to - interrupt transmission as early as possible and thus save - transmission capacity for other bundles. - - For connections that are idle, a KEEPALIVE message may optionally be - sent at a negotiated interval. This is used to convey liveness - information. - - Finally, before connections close, a SHUTDOWN message is sent on the - channel. After sending a SHUTDOWN message, the sender of this - message may send further acknowledgments (ACK_SEGMENT or - REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A - SHUTDOWN message may also be used to refuse a connection setup by a - peer. - -3.1. Example message exchange - - The following figure visually depicts the protocol exchange for a - simple session, showing the connection establishment, and the - transmission of a single bundle split into three data segments (of - lengths L1, L2, and L3) from Node A to Node B. - - Note that the sending node may transmit multiple DATA_SEGMENT - messages without necessarily waiting for the corresponding - ACK_SEGMENT responses. This enables pipelining of messages on a - channel. Although this example only demonstrates a single bundle - transmission, it is also possible to pipeline multiple DATA_SEGMENT - messages for different bundles without necessarily waiting for - ACK_SEGMENT messages to be returned for each one. However, - interleaving data segments from different bundles is not allowed. - - No errors or rejections are shown in this example. - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 7] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - Node A Node B - =3D=3D=3D=3D=3D=3D =3D=3D=3D= =3D=3D=3D - - +-------------------------+ +-------------------------+ - | Contact Header | -> <- | Contact Header | - +-------------------------+ +-------------------------+ - - +-------------------------+ - | DATA_SEGMENT (start) | -> - | SDNV length [L1] | -> - | Bundle Data 0..L1 | -> - +-------------------------+ - +-------------------------+ +-------------------------+ - | DATA_SEGMENT | -> <- | ACK_SEGMENT | - | SDNV length [L2] | -> <- | SDNV length [L1] | - | Bundle Data L1..L2 | -> +-------------------------+ - +-------------------------+ - +-------------------------+ +-------------------------+ - | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | - | SDNV length [L3] | -> <- | SDNV length [L1+L2] | - | Bundle Data L2..L3 | -> +-------------------------+ - +-------------------------+ - +-------------------------+ - <- | ACK_SEGMENT | - <- | SDNV length [L1+L2+L3] | - +-------------------------+ - - +-------------------------+ +-------------------------+ - | SHUTDOWN | -> <- | SHUTDOWN | - +-------------------------+ +-------------------------+ - - Figure 2: A simple visual example of the flow of protocol messages on - a single TCP session between two nodes (A and B) - - -4. Connection Establishment - - For bundle transmissions to occur using the TCPCL, a TCPCL connection - must first be established between communicating nodes. The manner in - which a bundle node makes the decision to establish such a connection - is implementation-dependent. For example, some connections may be - opened proactively and maintained for as long as is possible given - the network conditions, while other connections may be opened only - when there is a bundle that is queued for transmission and the - routing algorithm selects a certain next hop node. - - To establish a TCPCL connection, a node must first establish a TCP - connection with the intended peer node, typically by using the - - - -Demmer & Ott Expires December 29, 2007 [Page 8] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - services provided by the operating system. Port number 4556 has been - assigned by IANA as the well-known port number for the TCP - convergence layer. Other port numbers MAY be used per local - configuration. Determining a peer's port number (if different from - the well-known TCPCL port) is up to the implementation. - - If the node is unable to establish a TCP connection for any reason, - then it is an implementation matter to determine how to handle the - connection failure. A node MAY decide to re-attempt to establish the - connection, perhaps. If it does so, it MUST NOT overwhelm its target - with repeated connection attempts. Therefore, the node MUST retry - the connection setup only after some delay and it SHOULD use a - (binary) exponential backoff mechanism to increase this delay in case - of repeated failures. - - The node MAY declare failure after one or more connection attempts - and MAY attempt to find an alternate route for bundle data. - - Once a TCP connection is established, the connection initiator MUST - immediately transmit a contact header over the TCP connection. The - connection acceptor MUST also immediately transmit a contact header - over the TCP connection. The format of the contact header is - described in Section 4.1). - - Upon receipt of the contact header, both nodes perform the validation - and negotiation procedures defined in Section 4.2 - - After receiving the contact header from the other node, either node - MAY also refuse the connection by sending a SHUTDOWN message. If - connection setup is refused a reason MUST be included in the SHUTDOWN - message. - -4.1. Contact Header - - Once a TCP connection is established, both parties exchange a contact - header. This section describes the format of the contact header and - the meaning of its fields. - - - - - - - - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 9] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - The format for the Contact Header is as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +---------------+---------------+---------------+---------------+ - | magic=3D'dtn!' | - +---------------+---------------+---------------+---------------+ - | version | flags | keepalive_interval | - +---------------+---------------+---------------+---------------+ - | local EID length (SDNV) | - +---------------+---------------+---------------+---------------+ - | | - + local EID (variable) + - | | - +---------------+---------------+---------------+---------------+ - - Figure 3: Contact Header Format - - The fields of the contact header are: - - magic: A four byte field that always contains the byte sequence 0x64 - 0x76 0x6e 0x21, i.e. the text string "dtn!". - - version: A one byte field value containing the current version of - the protocol. - - flags: A one byte field containing optional connection flags. The - first five bits are unused and MUST be set to zero upon - transmission and MUST be ignored upon reception. The last three - bits are interpreted as shown in table Table 1 below. - - keepalive_interval: A two byte integer field containing the number - of seconds between exchanges of keepalive messages on the - connection (see Section 5.5). This value is in network byte - order, as are all other multi-byte fields described in this - protocol. - - local eid length: A variable length SDNV field containing the length - of the endpoint identifier (EID) for some singleton endpoint in - which the sending node is a member. A four byte SDNV is - depicted for clarity of the figure. - - local EID: An octet string containing the EID of some singleton - endpoint in which the sending node is a member, in the canonical - format of :. A four byte EID - is shown the clarity of the figure. - - - - - -Demmer & Ott Expires December 29, 2007 [Page 10] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - - - +----------+--------------------------------------------------------+ - | Value | Meaning | - +----------+--------------------------------------------------------+ - | 00000001 | Request acknowledgment of bundle segments. | - | 00000010 | Request enabling of reactive fragmentation. | - | 00000100 | Indicate support for negative acknowledgments. This | - | | flag MUST NOT be set to '1' unless support for | - | | acknowledgments is also indicated. | - +----------+--------------------------------------------------------+ - - Table 1: Contact Header Flags - - The manner in which values are configured and chosen for the various - flags and parameters in the contact header is implementation - dependent. - -4.2. Validation and parameter negotiation - - Upon reception of the contact header, both the TCPCL connection - initiator and the TCPCL connection acceptor follow the following - procedures for ensuring the validity of the TCPCL connection and to - negotiate values for the connection parameters. - - If the magic string is not present or is not valid, the connection - MUST be terminated. The intent of the magic string is to provide a - some protection against an inadvertent TCP connection by a different - protocol than the one described in this document. To prevent a flood - of repeated connections from a misconfigured application, a node MAY - elect to hold an invalid connection open and idle for some time - before closing it. - - If a node receives a contact header containing a version that is - greater than the current version of the protocol that the node - implements, then the node SHOULD interpret all fields and messages as - it would normally. If a node receives a contact header with a - version that is lower than the version of the protocol that the node - implements, the node may either terminate the connection due to the - version mismatch, or may adapt its operation to conform to the older - version of the protocol. This decision is an implementation matter. - - A node calculates the parameters for a TCPCL connection by - negotiating the values from its own preferences (conveyed by the - contact header it sent) with the preferences of the peer node - (expressed in the contact header that it received). This negotiation - should proceed in the following manner: - - - - -Demmer & Ott Expires December 29, 2007 [Page 11] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - - The segment acknowledgments enabled parameter is set to true iff - the corresponding flag is set in both contact headers. - - The reactive fragmentation enabled parameter is set to true iff - the corresponding flag is set in both contact headers. - - Negative acknowledgments to interrupt transmission (actually: - refuse reception) of a bundle may only be used iff both peers - indicate support for negative acknowledgments in their contact - header. - - The keealive_interval parameter should be set to the minimum - value from both contact headers. If one or both contact headers - contains the value zero, then the keepalive feature (described - in Section 5.5) is disabled. - - - Once this process of parameter negotiation is completed, the protocol - defines no additional mechanism to change the parameters of an - established connection; to effect such a change, the connection MUST - be terminated and a new connection established. - - -5. Established Connection Operation - - This section describes the protocol operation for the duration of an - established connection, including the mechanisms for transmitting - bundles over the connection. - -5.1. Message Type Codes - - After the initial exchange of a contact header, all messages - transmitted over the connection are denoted by a one octet header - with the following structure: - - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+ - | type | flags | - +-+-+-+-+-+-+-+-+ - - type: Indicates the type of the message as per Table 2 below - - flags: Optional flags defined on a per message type basis. - - The types and values for the message type code are as follows. - - - - - -Demmer & Ott Expires December 29, 2007 [Page 12] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - +----------------+------+-------------------------------------------+ - | Type | Code | Comment | - +----------------+------+-------------------------------------------+ - | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | - | | | of bundle data, described in Section 5.2. | - | | | | - | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | - | | | described in Section 5.3 | - | | | | - | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | - | | | current bundle shall be stopped, | - | | | described in Section 5.4. | - | | | | - | KEEPALIVE | 0x4 | Keepalive message for the connection, | - | | | described in Section 5.5. | - | | | | - | SHUTDOWN | 0x5 | Indicates that one of the nodes | - | | | participating in the connection wishes to | - | | | cleanly terminate the connection, | - | | | described in Section 6. | - | | | | - +----------------+------+-------------------------------------------+ - - Table 2: TCPCL Header Types - - Open Issue: Currently, the message code implicitly identifies the - expected message length, possibly in combination with some flags. - This may limit backwards compatible extensibility: an "old" endpoint - may not know about a "new" message code or extension flag and hence - may not be able to skip the unknown (part of the) message, even - though it would otherwise be perfectly capable of interoperating (at - reduced functionality). Therefore, we may want to consider providing - an explicit length indication if the message length is more than a - single octet. Options include: (a) always including a length field, - (b) using one bit of the flags to indicate whether or not length - field is present (which then would be the case for all messages of - more than one byte length), and (c) relying on a new version number - for all extensions. - - - - - - - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 13] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -5.2. Bundle Data Transmission - - Each bundle is transmitted in one or more data segments. The format - of a data segment message follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x1 |0|0|S|E| length ... | contents.... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: Format of bundle data segment messages - - The type portion of the message header contains the value 0x1. - - The flags portion of the message header octet contains two optional - values in the two low-order bits, denoted 'S' and 'E' above. The 'S' - bit MUST be set to one iff it precedes the transmission of the first - segment of a new bundle. The 'E' bit MUST be set to one when - transmitting the last segment of a bundle. - - Determining the size of the segment is an implementation matter. In - particular, a node may, based on local policy or configuration, only - ever transmit bundle data in a single segment, in which case both the - 'S' and 'E' bits MUST be set to one. However, a node MUST be able to - receive a bundle that has been transmitted in any segment size. - - In the bundle protocol specification, a single bundle comprises a - primary bundle block, a payload block, and zero or more additional - bundle blocks. The relationship between the protocol blocks and the - convergence layer segments is an implementation-specific decision. - In particular, a segment MAY contain more than one protocol block; - alternatively, a single protocol block (such as the payload) MAY be - split into multiple segments. - - However, a single segment MUST NOT contain data of more than a single - bundle. - - Once a transmission of a bundle has commenced, the node MUST only - send segments containing sequential portions of that bundle until it - sends a segment with the 'E' bit set. - - Following the message header, the length field is an SDNV containing - the number of bytes of bundle data that are transmitted in this - segment. Following this length is the actual data contents. - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 14] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -5.3. Bundle Acknowledgments - - Although the TCP transport provides reliable transfer of data between - transport peers, the typical BSD sockets interface provides no means - to inform a sending application of when the receiving application has - processed some amount of transmitted data. Thus after transmitting - some data, a bundle protocol agent needs an additional mechanism to - determine whether the receiving agent has successfully received the - segment. - - To this end, the TCPCL protocol offers an optional feature whereby a - receiving node transmits acknowledgments of reception of data - segments. This feature is enabled if and only if during the exchange - of contact headers, both parties set the flag to indicate that - segment acknowledgments are enabled (see Section 4.1). If so, then - the receiver MUST transmit a bundle acknowledgment header when it - successfully receives each data segment. - - The format of a bundle acknowledgment is as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x2 |0|0|0|0| acknowledged length ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 5: Format of bundle acknowledgement messages - - To transmit an acknowledgment, a node first transmits a message - header with the ACK_SEGMENT type code and all flags set to zero, then - transmits an SDNV containing the cumulative length of the received - segment(s) of the current bundle. - - For example, suppose the sending node transmits four segments of - bundle data with lengths 100, 200, 500, and 1000 respectively. After - receiving the first segment, the node sends an acknowledgment of - length 100. After the second segment is received, the node sends an - acknowledgment of length 300. The third and fourth acknowledgments - are of length 800 and 1800 respectively. - -5.4. Bundle Refusal - - As bundles may be large, the TCPCL supports an optional mechanisms by - which a receiving node may indicate to the sender that it does not - want to receive the corresponding bundle. - - To do so, upon receiving a DATA_SEGMENT message, the node MAY - transmit a REFUSE_BUNDLE message. As data segments and - - - -Demmer & Ott Expires December 29, 2007 [Page 15] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - acknowledgments may cross on the wire, the data segment (and thus the - bundle) that is being refused is implicitly identified by the - sequence in which positive and negative acknowledgments are received. - - The receiver MUST have acknowledged (positively or negatively) all - other received DATA_SEGMENTs before the one to be refused so that the - sender can identify the bundles accepted and refused by means of a - simple FIFO list of segments and acknowledgments. - - The bundle refusal MAY be sent before the entire data segment is - received. If a sender receives a REFUSE_BUNDLE message, the sender - MUST complete the transmission of any partially-sent DATA_SEGMENT - message (so that the receiver stays in sync). The sender MUST NOT - commence transmission of any further segments of the rejected bundle - subsequently. Note, however, that this requirement does not ensure - that a node will not receive another DATA_SEGMENT for the same bundle - after transmitting a REFUSE_BUNDLE message since messages may cross - on the wire; if this happens, subsequent segments of the bundle - SHOULD be refused with a REFUSE_BUNDLE message, too. - - Note: If a bundle transmission if aborted in this way, the receiver - may not receive a segment with the 'E' flag set to '1' for the - aborted bundle. The beginning of the next bundle is identified by - the 'S' bit set to '1', indicating the start of a new bundle. - -5.5. Keepalive Messages - - The protocol includes a provision for transmission of keepalive - messages over the TCP connection to help determine if the connection - has been disrupted. - - As described in Section 4.1, one of the parameters in the contact - header is the keepalive_interval. Both sides populate this field - with their requested intervals (in seconds) between keepalive - messages. - - The format of a keepalive message is a one byte message type code of - KEEPALIVE (as described in Table 2, with no additional data. Both - sides SHOULD send a keepalive message whenever the negotiated - interval has elapsed with no transmission of any message (keepalive - or other). - - If no message (keepalive or other) has been received for at least - twice the keepalive interval, then either party may terminate the - session by transmitting a one byte message type code of SHUTDOWN (as - described in Table 2) and closing the TCP connection. - - Note: The keepalive interval should not be chosen too short as TCP - - - -Demmer & Ott Expires December 29, 2007 [Page 16] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - retransmissions may occur in case of packet loss. Those will have to - be triggered by a timeout (TCP RTO) which is dependent on the - measured RTT for the TCP connection so that keepalive message may - experience noticeable latency. - - -6. Connection Termination - - This section describes the procedures for ending a TCPCL connection. - -6.1. Shutdown Message - - To cleanly shut down a connection, a SHUTDOWN message MUST be - transmitted by either the initiator or the acceptor at any point - following complete transmission of any other message. In case - acknowledgments have been negotiated, it is advisable to acknowledge - all received data segments first and then shut down the connection. - - The format of the shutdown message is as follows: - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x3 |0|0|R|D| reason (opt) | reconnection delay (opt) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 6: Format of bundle shutdown messages - - It is possible for a node to convey additional information regarding - the reason for connection termination. To do so, the node MUST set - the 'R' bit in the message header flags, and transmit a one-byte - reason code immediately following the message header. The specified - values of the reason code are: - - +------+-------------------+----------------------------------------+ - | Code | Meaning | Comment | - +------+-------------------+----------------------------------------+ - | 0x00 | Idle timeout | The connection is being closed due to | - | | | idleness. | - | | | | - | 0x01 | Version mismatch | The node cannot conform to the | - | | | specified TCPCL protocol version. | - | | | | - | 0x02 | Busy | The node is too busy to handle the | - | | | current connection. | - +------+-------------------+----------------------------------------+ - - Table 3: Shutdown Reason Codes - - - -Demmer & Ott Expires December 29, 2007 [Page 17] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - It is also possible to convey a requested reconnection delay to - indicate how long the other node must wait before attempting - connection re-establishment. To do so, the node sets the 'D' bit in - the message header flags, then transmits an SDNV specifying the - requested delay, in seconds, following the message header (and - optionally the shutdown reason code). The value 0 SHALL be - interpreted as an infinite delay, i.e. that the connecting node MUST - NOT re-establish the connection. In contrast, if the node does not - wish to request a delay, it SHOULD omit the delay field (and set the - 'D' bit to zero). Note that in the figure above, a two octet SDNV is - shown for convenience of the presentation. - - A connection shutdown MAY occur immediately after TCP connection - establishment or reception of a contact header (and prior to any - further data exchange). This may, for example, be used to notify a - the initiator that the node is currently not capable of or willing to - communicate. However, a node MUST always send the contact header to - its peer first. - - If either node terminates a connection prematurely in this manner, it - SHOULD send a SHUTDOWN message and MUST indicate a reason code unless - the incoming connection did not include the magic string. If a node - does not want its peer to re-open the connection immediately, it - SHOULD set the 'D' bit in the flags and include a reconnection delay - to indicate when the peer is allowed to attempt another connection - setup. - - If a connection is to be terminated before another protocol message - has completed, then the node MUST NOT transmit the SHUTDOWN message - but still SHOULD close the TCP connection. In particular, if the - connection is to be closed (for whatever reason) while a node is in - the process of transmitting a bundle data segment, receiving node is - still expecting segment data and might erroneously interpret the - SHUTDOWN message to be part of the data segment. - -6.2. Idle Connection Shutdown - - The protocol includes a provision for clean shutdown of idle TCP - connections. Determining the length of time to wait before closing - idle connections, if they are to be closed at all, is an - implementation and configuration matter. - - If there is a configured time to close idle links, then if no bundle - data (other than keepalive messages) has been received for at least - that amount of time, then either node MAY terminate the connection by - transmitting a SHUTDOWN message indicating the reason code of 'idle - timeout' (as described above). After receiving a SHUTDOWN message in - response, both sides may close the TCP connection. - - - -Demmer & Ott Expires December 29, 2007 [Page 18] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -7. Requirements notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [1]. - - -8. Security Considerations - - One security consideration for this protocol relates to the fact that - nodes present their endpoint identifier as part of the connection - header exchange. It would be possible for a node to fake this value - and present the identity of a singleton endpoint in which the node is - not a member, essentially masquerading as another DTN node. If this - identifier is used without further verification as a means to - determine which bundles are transmitted over the connection, then the - node that has falsified its identity may be able to obtain bundles - that it should not have. - - These concerns may be mitigated through the use of the Bundle - Security Protocols [4]. In particular, the Bundle Authentication - Header defines mechanism for secure exchange of bundles between DTN - nodes. Thus an implementation could delay trusting the presented - endpoint identifier until the node can securely validate that its - peer is in fact the only member of the given singleton endpoint. - - Another consideration for this protocol relates to denial of service - attacks. A node may send a large amount of data over a TCP - connection, requiring the receiving node to either handle the data, - attempt to stop the flood of data by sending a REFUSE_BUNDLE message, - or forcibly terminate the connection. This burden could cause denial - of service on other, well-behaving connections. There is also - nothing to prevent a malicious node from continually establishing - connections and repeatedly trying to send copious amounts of bundle - data. - - -9. IANA Considerations - - Port number 4556 has been assigned as the default port for the TCP - convergence layer. - - -10. References - - [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", RFC 2119, March 1997. - - - - -Demmer & Ott Expires December 29, 2007 [Page 19] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - - [2] Cerf et al, V., "Delay-Tolerant Network Architecture", RFC 4838, - April 2007. - - [3] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - Internet Draft, work in progress, Internet Draft - draft-irtf-dtnrg-bundle-spec-09.txt, April 2007. - - [4] Symington, S., Farrell, S., and H. Weiss, "Bundle Security - Protocol Specification", Internet Draft, work in - progress draft-irtf-dtnrg-bundle-security-03.txt, April 2007. - - [5] DTNRG, "Delay Tolerant Networking Reference Implementation", - . - - -Authors' Addresses - - Michael J. Demmer - University of California, Berkeley - Computer Science Division - 445 Soda Hall - Berkeley, CA 94720-1776 - US - - Email: demmer@cs.berkeley.edu - - - Joerg Ott - Helsinki University of Technology - Networking Laboratory - PO Box 3000 - TKK 02015 - Finland - - Email: jo@netlab.tkk.fi - - - - - - - - - - - - - - - - -Demmer & Ott Expires December 29, 2007 [Page 20] -=0C -Internet-Draft DTN TCP Convergence Layer June 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Demmer & Ott Expires December 29, 2007 [Page 21] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-irtf-dtnrg-tcp-clayer-00.xml --- a/doc/draft-irtf-dtnrg-tcp-clayer-00.xml Sat Dec 12 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,1277 +0,0 @@ - - -]> - - -=20 - - - - - - - - - - Delay Tolerant Networking TCP Convergence Layer Protocol - - - Delay Tolerant Networking Research Group - - - - University of California, Berkeley - - -
- - Computer Science Division - 445 Soda Hall - Berkeley - CA - 94720-1776 - US - - - demmer@cs.berkeley.edu -
- - - - - Helsinki University of Technology - - -
- - Networking Laboratory - PO Box 3000 - TKK - 02015 - Finland - - - jo@netlab.tkk.fi -
- - - - - - - This document describes the protocol for the TCP-based - Convergence Layer for Delay Tolerant Networking (DTN). - - - - - - - -
- - This document describes the TCP-based convergence layer protocol for - Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an - end-to-end architecture providing communications in and/or through - highly stressed environments, including those with intermittent - connectivity, long and/or variable delays, and high bit error - rates. More detailed descriptions of the rationale and capabilities - of these networks can be found in the - Delay-Tolerant Network Architecture Internet Draft. - - - - An important goal of the DTN architecture is to accommodate a wide - range of networking technologies and environments. The protocol - used for DTN communications is the - Bundling Protocol (BP), an application-layer protocol that - is used to construct a store-and-forward overlay network. As - described in the bundle protocol specification, BP requires the - services of a "convergence layer adapter" (CLA) to send and receive - bundles using an underlying internet protocol. This document - describes one such convergence layer adapter that uses the - well-known Transmission Control Protocol (TCP). - - - - The locations of the TCPCL and BP in the Internet model protocol - stack are shown in . In - particular, both the BP and the TCPCL reside above the transport - layer, i.e., at the application layer. - - -
- - - +-------------------------+=20 - | DTN Application | -\ - +-------------------------| | - | Bundle Protocol (BP) | -> Application Layer - +-------------------------+ | - | TCP Conv. Layer (TCPCL) | -/ - +-------------------------+=20 - | TCP | ---> Transport Layer - +-------------------------+ - | IP | ---> Network Layer - +-------------------------+ - | Link-Layer Protocol | ---> Link Layer - +-------------------------+ - | Physical Medium | ---> Physical Layer - +-------------------------+ - -
- - - This document describes the format of the protocol data units - passed between entities participating in TCPCL communications. This - document does not address: - - - - - - The format of protocol data units of the bundling protocol, as - those are defined elsewhere . - - - =20 - - Mechanisms for locating or identifying other bundle nodes within - an internet. - - - - - Operational logic or procedures used to implement this protocol. - - - - - - - Note that this document describes version 3 of the protocol. - Versions 0, 1, and 2 were never specified in any Internet Draft, - RFC, or any other public document. These prior versions of the - protocol were, however, implemented in - the DTN reference - implementation, in prior releases, hence the current version - number reflects the existence of those prior versions. - - - - -
- -
- -
=20 - -The following set of definitions are abbreviated versions of those - which appear in the Bundle - Protocol Specification. To the extent in which terms appear - in both documents, they are intended to have the same meaning. - - - - - A bundle is a protocol data unit of the DTN - bundle protocol. - - - =20 - A bundle payload (or simply - "payload") is the application data whose conveyance to the - bundle's destination is the purpose for the transmission of a - given bundle. - - - - A fragment is a bundle whose payload - contains a range of bytes from another bundle's payload. - - - - A bundle node (or simply a "node") is - any entity that can send and/or receive bundles. The particular - instantiation of this entity is deliberately unconstrained, - allowing for implementations in software libraries, long-running - processes, or even hardware. One component of the bundle node is - the implementation of a convergence layer adapter. - - - - A convergence layer - adapter (CLA) sends and receives bundles utilizing the services - of some 'native' internet protocol. This document describes the - manner in which a CLA sends and receives bundles when using the - TCP protocol for inter-node communication. - - - - A self describing - numeric value (SDNV) is a variable length encoding for integer - values, defined in the bundle protocol specification. - - - - -
- =20 -
- -This section contains definitions that are interpreted to be - specific to the operation of the TCPCL protocol, as described - below. - - - - - =20 - A TCP connection refers to a - transport connection using TCP as the transport protocol. - - - =20 - A TCPCL connection - (as opposed to a TCP connection) - is a TCPCL communication relationship between two bundle - nodes. The lifetime of a TCPCL connection is one-to-one with the lif= etime - of an underlying TCP connection. Therefore a TCPCL connection is - initiated when a bundle node initiates a TCP connection to be - established for the purposes of bundle communication. A TCPCL connec= tion is - terminated when the TCP connection ends, due either to one or - both nodes actively terminating the TCP connection or due to network - errors causing a failure of the TCP connection. For the remainder of= this - document, the term "connection" without the prefix "TCPCL" shall ref= er - to a TCPCL connection. - - - - The connection parameters - are a set of values used to affect the operation of the TCPCL - for a given connection. The manner in which these parameters are - conveyed to the bundle node and thereby to the TCPCL is - implementation-dependent. However, the mechanism by which two - bundle nodes exchange and negotiate the values to be used for a - given session is described in Section . - - - - The connection initiator is - the bundle node that causes the establishment of a new - connection by creating a new TCP connection (for example, by using - the connect() call in the BSD sockets API) and then following - the procedures described in . - - - - The connection acceptor is the - bundle node that establishes a connection in response to an - active connection attempt by another bundle node (for example, - by using the listen() and accept() calls of the BSD sockets API) - and then following the procedures described in . - - - - Transmission refers to the procedures - and mechanisms (described below) for conveyance of a bundle from - one node to another. - - - - - - -
- -
- -
- - - This protocol provides bundle conveyance over a TCP connection and - specifies the encapsulation of bundles as well as procedures for - TCP connection setup and teardown. The general operation of the protoc= ol - is as follows: - - - - First one node establishes a TCPCL connection to the other by - initiating a TCP connection. After setup of the TCP connection is - complete, an initial contact header is exchanged in both directions - to set parameters of the TCPCL connection and exchange a singleton - endpoint identifier for each node (not the singleton EID of any - application running on the node), to denote the bundle-layer - identity of each DTN node. This is used to assist in routing and - forwarding messages, e.g., to prevent loops. - - - - Once the TCPCL connection is established and configured in this - way, bundles can be transmitted in either direction. Each bundle - is transmitted in one or more logical segments of formatted bundle - data. Each logical data segment consists of a DATA_SEGMENT message - header, an SDNV containing the length of the segment, and finally - the byte range of the bundle data. The choice of the length to use - for segments is an implementation matter. The first segment for a - bundle must set the 'start' flag and the last one must set the - 'end' flag in the DATA_SEGMENT message header. - - - An optional feature of the protocol is for the receiving node to - send acknowledgments as bundle data segments arrive (ACK_SEGMENT). - The rationale behind these acknowledgments is to enable the sender - node to determine how much of the bundle has been received, so that - in case the connection is interrupted, it can perform reactive - fragmentation to avoid re-sending the already transmitted part of - the bundle. - - - When acknowledgments are enabled, then for each data segment that - is received, the receiving node sends an ACK_SEGMENT code followed - by an SDNV containing the cumulative length of the bundle that has - been received. Note that in the case of concurrent bidirectional - transmission, then ack segments may be interleaved with data - segments. - - - Another optional feature is that a receiver may interrupt the - transmission of a bundle at any point in time by replying with a - negative acknowledgment (REFUSE_BUNDLE) which causes the sender to - stop transmission of the current bundle, after completing - transmission of a partially sent data segment. Note: This - allows a receiver that detects it already has received a certain - bundle to interrupt transmission as early as possible and thus save - transmission capacity for other bundles. - - - For connections that are idle, a KEEPALIVE message may optionally - be sent at a negotiated interval. This is used to convey liveness - information. - - - Finally, before connections close, a SHUTDOWN message is sent on - the channel. After sending a SHUTDOWN message, the sender of this - message may send further acknowledgments (ACK_SEGMENT or - REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A - SHUTDOWN message may also be used to refuse a connection setup by a - peer. - - -
- - - The following figure visually depicts the protocol exchange for - a simple session, showing the connection establishment, and the - transmission of a single bundle split into three data segments - (of lengths L1, L2, and L3) from Node A to Node B. - - - - Note that the sending node may transmit multiple DATA_SEGMENT - messages without necessarily waiting for the corresponding - ACK_SEGMENT responses. This enables pipelining of messages on a - channel. Although this example only demonstrates a single bundle - transmission, it is also possible to pipeline multiple DATA_SEGMENT - messages for different bundles without necessarily waiting for - ACK_SEGMENT messages to be returned for each one. However, - interleaving data segments from different bundles is not allowed. - - - - - - No errors or rejections are shown in this example. - - -
- - - Node A Node B - =3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D - - +-------------------------+ +-------------------------+ - | Contact Header | -> <- | Contact Header | - +-------------------------+ +-------------------------+ - =20 - +-------------------------+ =20 - | DATA_SEGMENT (start) | -> =20 - | SDNV length [L1] | -> =20 - | Bundle Data 0..L1 | -> =20 - +-------------------------+ =20 - +-------------------------+ +-------------------------+ - | DATA_SEGMENT | -> <- | ACK_SEGMENT | - | SDNV length [L2] | -> <- | SDNV length [L1] | - | Bundle Data L1..L2 | -> +-------------------------+ - +-------------------------+ =20 - +-------------------------+ +-------------------------+ - | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | - | SDNV length [L3] | -> <- | SDNV length [L1+L2] | - | Bundle Data L2..L3 | -> +-------------------------+ - +-------------------------+ =20 - +-------------------------+ - <- | ACK_SEGMENT | - <- | SDNV length [L1+L2+L3] | - +-------------------------+ - - +-------------------------+ +-------------------------+ - | SHUTDOWN | -> <- | SHUTDOWN | - +-------------------------+ +-------------------------+ - -
- -
- -
- -
- - - For bundle transmissions to occur using the TCPCL, a TCPCL - connection must first be established between communicating nodes. - The manner in which a bundle node makes the decision to establish - such a connection is implementation-dependent. For example, some - connections may be opened proactively and maintained for as long as - is possible given the network conditions, while other connections - may be opened only when there is a bundle that is queued for - transmission and the routing algorithm selects a certain next hop - node. - - - - To establish a TCPCL connection, a node must first establish a TCP - connection with the intended peer node, typically by using the - services provided by the operating system. Port number 4556 has - been assigned by IANA as the well-known port number for the TCP - convergence layer. Other port numbers MAY be used per local - configuration. Determining a peer's port number (if different - from the well-known TCPCL port) is up to the implementation. - - - - If the node is unable to establish a TCP connection for any reason, - then it is an implementation matter to determine how to handle the - connection failure. A node MAY decide to re-attempt to establish - the connection, perhaps. If it does so, it MUST NOT overwhelm its - target with repeated connection attempts. Therefore, the node MUST - retry the connection setup only after some delay and it SHOULD use - a (binary) exponential backoff mechanism to increase this delay in - case of repeated failures. - - - - The node MAY declare failure after one or more connection attempts - and MAY attempt to find an alternate route for bundle data. - - - - Once a TCP connection is established, the connection initiator MUST - immediately transmit a contact header over the TCP connection. The - connection acceptor MUST also immediately transmit a contact - header over the TCP connection. The format of the contact header - is described in ). - - - - Upon receipt of the contact header, both nodes perform the - validation and negotiation procedures defined in - - - - - After receiving the contact header from the other node, either node - MAY also refuse the connection by sending a SHUTDOWN message. If - connection setup is refused a reason MUST be included in the - SHUTDOWN message.=20 - - -
- - -Once a TCP connection is established, both parties exchange a contact -header. This section describes the format of the contact header and -the meaning of its fields. - - =20 -
- - The format for the Contact Header is as follows: - - =20 - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+---------------+---------------+---------------+---------------+ -| magic=3D'dtn!' | -+---------------+---------------+---------------+---------------+ -| version | flags | keepalive_interval | -+---------------+---------------+---------------+---------------+ -| local EID length (SDNV) | -+---------------+---------------+---------------+---------------+ -| | -+ local EID (variable) + -| | -+---------------+---------------+---------------+---------------+ - -
- - -The fields of the contact header are: - - - - - A four byte field that always contains the - byte sequence 0x64 0x76 0x6e 0x21, i.e. the text string "dtn!". - - - =20 - A one byte field value containing the - current version of the protocol. - - - - A one byte field containing optional - connection flags. The first five bits are unused and MUST be set - to zero upon transmission and MUST be ignored upon reception. - The last three bits are interpreted as shown in table below. - - - - A two byte integer field - containing the number of seconds between exchanges of keepalive - messages on the connection (see ). - This value is in network byte order, as are all other multi-byte - fields described in this protocol. - - - - A variable length SDNV field - containing the length of the endpoint identifier (EID) for some - singleton endpoint in which the sending node is a member. A - four byte SDNV is depicted for clarity of the figure. - - - =20 - An octet string containing the EID - of some singleton endpoint in which the sending node is a - member, in the canonical format of <scheme - name>:<scheme-specific part>. A four byte EID - is shown the clarity of the figure. - - - - - - - - Value - Meaning - - 00000001 - Request acknowledgment of bundle segments. - - 00000010 - Request enabling of reactive fragmentation. - - 00000100 - Indicate support for negative acknowledgments. This flag MUST - NOT be set to '1' unless support for acknowledgments is also - indicated. - - - - - - The manner in which values are configured and chosen for the - various flags and parameters in the contact header is - implementation dependent. - - -
- -
- - -Upon reception of the contact header, both the TCPCL connection -initiator and the TCPCL connection acceptor follow the following -procedures for ensuring the validity of the TCPCL connection and to -negotiate values for the connection parameters. - - - -If the magic string is not present or is not valid, the connection -MUST be terminated. The intent of the magic string is to provide a -some protection against an inadvertent TCP connection by a different -protocol than the one described in this document. To prevent a flood -of repeated connections from a misconfigured application, a node MAY -elect to hold an invalid connection open and idle for some time before -closing it. - - - -If a node receives a contact header containing a version that is -greater than the current version of the protocol that the node -implements, then the node SHOULD interpret all fields and messages as -it would normally. If a node receives a contact header with a version -that is lower than the version of the protocol that the node -implements, the node may either terminate the connection due to the -version mismatch, or may adapt its operation to conform to the older -version of the protocol. This decision is an implementation matter. - - - -A node calculates the parameters for a TCPCL connection by negotiating -the values from its own preferences (conveyed by the contact header it -sent) with the preferences of the peer node (expressed in the contact -header that it received). This negotiation should proceed in the -following manner: - - - - - =20 - The segment acknowledgments enabled parameter is set to true - iff the corresponding flag is set in both contact headers. - - - - The reactive fragmentation enabled parameter is set to true iff - the corresponding flag is set in both contact headers. - - - Negative acknowledgments to interrupt transmission (actually: - refuse reception) of a bundle may only be used iff both peers - indicate support for negative acknowledgments in their contact - header. - - - The keealive_interval parameter should be set to the minimum - value from both contact headers. If one or both contact headers - contains the value zero, then the keepalive feature (described - in ) is disabled. - - - =20 - - - -Once this process of parameter negotiation is completed, the protocol -defines no additional mechanism to change the parameters of an -established connection; to effect such a change, the connection MUST -be terminated and a new connection established. - - - - -
- -
- -
- - -This section describes the protocol operation for the duration of an -established connection, including the mechanisms for transmitting -bundles over the connection. - - -
- - -After the initial exchange of a contact header, all messages -transmitted over the connection are denoted by a one octet header with -the following structure: - - - - 0 1 2 3 4 5 6 7=20 - +-+-+-+-+-+-+-+-+ - | type | flags | - +-+-+-+-+-+-+-+-+ - - - - Indicates the type of the message as per - below - - - - Optional flags defined on a per message type bas= is. - - - - The types and values for the message type code are as follows. - - - - - Type - Code - Comment - - DATA_SEGMENT - 0x1 - Indicates the transmission of a segment of bundle data, - described in . -   - - ACK_SEGMENT - 0x2 - Acknowledges reception of a data segment, described in - -   - - REFUSE_BUNDLE - 0x3 - Indicates that the transmission of the current bundle shall be - stopped, described in . -   - - KEEPALIVE - 0x4 - Keepalive message for the connection, described in - . -   - =20 - SHUTDOWN - 0x5 - Indicates that one of the nodes participating in the connection - wishes to cleanly terminate the connection, described in - . -   - - - - - Open Issue: Currently, the message code implicitly identifies the - expected message length, possibly in combination with some flags. - This may limit backwards compatible extensibility: an "old" - endpoint may not know about a "new" message code or extension flag - and hence may not be able to skip the unknown (part of the) - message, even though it would otherwise be perfectly capable of - interoperating (at reduced functionality). Therefore, we may want - to consider providing an explicit length indication if the message - length is more than a single octet. Options include: (a) always - including a length field, (b) using one bit of the flags to - indicate whether or not length field is present (which then would - be the case for all messages of more than one byte length), and (c) - relying on a new version number for all extensions. - - -
- -
- -
- - Each bundle is transmitted in one or more data segments. The - format of a data segment message follows: - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3=20 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x1 |0|0|S|E| length ... | contents.... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - - The type portion of the message header contains the value 0x1. - - =20 - - The flags portion of the message header octet contains two optional - values in the two low-order bits, denoted 'S' and 'E' above. The - 'S' bit MUST be set to one iff it precedes the transmission of the - first segment of a new bundle. The 'E' bit MUST be set to one when - transmitting the last segment of a bundle. - - - Determining the size of the segment is an implementation matter. - In particular, a node may, based on local policy or configuration, - only ever transmit bundle data in a single segment, in which case - both the 'S' and 'E' bits MUST be set to one. However, a node MUST - be able to receive a bundle that has been transmitted in any - segment size. - - - In the bundle protocol specification, a single bundle comprises a - primary bundle block, a payload block, and zero or more additional - bundle blocks. The relationship between the protocol blocks and - the convergence layer segments is an implementation-specific - decision. In particular, a segment MAY contain more than one - protocol block; alternatively, a single protocol block (such as the - payload) MAY be split into multiple segments. - - - However, a single segment MUST NOT contain data of more than a - single bundle. - - - Once a transmission of a bundle has commenced, the node MUST only - send segments containing sequential portions of that bundle until - it sends a segment with the 'E' bit set. - - - Following the message header, the length field is an SDNV - containing the number of bytes of bundle data that are transmitted - in this segment. Following this length is the actual data contents. - -
- -
- - - Although the TCP transport provides reliable transfer of data - between transport peers, the typical BSD sockets interface provides - no means to inform a sending application of when the receiving - application has processed some amount of transmitted data. Thus - after transmitting some data, a bundle protocol agent needs an - additional mechanism to determine whether the receiving agent has - successfully received the segment. - - - - To this end, the TCPCL protocol offers an optional feature whereby - a receiving node transmits acknowledgments of reception of data - segments. This feature is enabled if and only if during the - exchange of contact headers, both parties set the flag to indicate - that segment acknowledgments are enabled (see ). If so, then the receiver MUST - transmit a bundle acknowledgment header when it successfully - receives each data segment. - - -
- - The format of a bundle acknowledgment is as follows: - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3=20 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x2 |0|0|0|0| acknowledged length ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - - To transmit an acknowledgment, a node first transmits a message - header with the ACK_SEGMENT type code and all flags set to zero, - then transmits an SDNV containing the cumulative length of the - received segment(s) of the current bundle. - - - For example, suppose the sending node transmits four segments of - bundle data with lengths 100, 200, 500, and 1000 - respectively. After receiving the first segment, the node sends an - acknowledgment of length 100. After the second segment is - received, the node sends an acknowledgment of length 300. The third - and fourth acknowledgments are of length 800 and 1800 respectively. - - -
- -
- - - As bundles may be large, the TCPCL supports an optional mechanisms - by which a receiving node may indicate to the sender that it does - not want to receive the corresponding bundle. - - - To do so, upon receiving a DATA_SEGMENT message, the node MAY - transmit a REFUSE_BUNDLE message. As data segments and - acknowledgments may cross on the wire, the data segment (and thus - the bundle) that is being refused is implicitly identified by the - sequence in which positive and negative acknowledgments are - received. - - - The receiver MUST have acknowledged (positively or negatively) all - other received DATA_SEGMENTs before the one to be refused so that - the sender can identify the bundles accepted and refused by means - of a simple FIFO list of segments and acknowledgments. - - - The bundle refusal MAY be sent before the entire data segment is - received. If a sender receives a REFUSE_BUNDLE message, the sender - MUST complete the transmission of any partially-sent DATA_SEGMENT - message (so that the receiver stays in sync). The sender MUST NOT - commence transmission of any further segments of the rejected - bundle subsequently. Note, however, that this requirement does not - ensure that a node will not receive another DATA_SEGMENT for the - same bundle after transmitting a REFUSE_BUNDLE message since - messages may cross on the wire; if this happens, subsequent - segments of the bundle SHOULD be refused with a REFUSE_BUNDLE - message, too. - - - Note: If a bundle transmission if aborted in this way, the receiver - may not receive a segment with the 'E' flag set to '1' for the - aborted bundle. The beginning of the next bundle is identified by - the 'S' bit set to '1', indicating the start of a new bundle. - -
- -
- - The protocol includes a provision for transmission of keepalive - messages over the TCP connection to help determine if the - connection has been disrupted. - - - - As described in , one of the - parameters in the contact header is the keepalive_interval. Both - sides populate this field with their requested intervals (in - seconds) between keepalive messages. - - - - The format of a keepalive message is a one byte message type code - of KEEPALIVE (as described in , with no - additional data. Both sides SHOULD send a keepalive message - whenever the negotiated interval has elapsed with no transmission - of any message (keepalive or other). - - - - If no message (keepalive or other) has been received for at least - twice the keepalive interval, then either party may terminate the - session by transmitting a one byte message type code of SHUTDOWN - (as described in ) and closing the TCP - connection. - - - - Note: The keepalive interval should not be chosen too short as TCP - retransmissions may occur in case of packet loss. Those will have - to be triggered by a timeout (TCP RTO) which is dependent on the - measured RTT for the TCP connection so that keepalive message may - experience noticeable latency. - -
- -
- -
- - - This section describes the procedures for ending a TCPCL connection. - - -
- - To cleanly shut down a connection, a SHUTDOWN message MUST be - transmitted by either the initiator or the acceptor at any point - following complete transmission of any other message. In case - acknowledgments have been negotiated, it is advisable to - acknowledge all received data segments first and then shut down the - connection. - - -
- - The format of the shutdown message is as follows: - - - 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3=20 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 0x3 |0|0|R|D| reason (opt) | reconnection delay (opt) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - -
- - - It is possible for a node to convey additional information - regarding the reason for connection termination. To do so, the - node MUST set the 'R' bit in the message header flags, and transmit - a one-byte reason code immediately following the message - header. The specified values of the reason code are: - - - - Code - Meaning - Comment - - 0x00 - Idle timeout - The connection is being closed due to idleness. -   - - - 0x01 - Version mismatch - The node cannot conform to the specified TCPCL protocol - version. -   - - 0x02 - Busy - The node is too busy to handle the current connection. - - - - - It is also possible to convey a requested reconnection delay to - indicate how long the other node must wait before attempting - connection re-establishment. To do so, the node sets the 'D' bit in - the message header flags, then transmits an SDNV specifying the - requested delay, in seconds, following the message header (and - optionally the shutdown reason code). The value 0 SHALL be - interpreted as an infinite delay, i.e. that the connecting node - MUST NOT re-establish the connection. In contrast, if the node - does not wish to request a delay, it SHOULD omit the delay field - (and set the 'D' bit to zero). Note that in the figure above, a - two octet SDNV is shown for convenience of the presentation. - - - - A connection shutdown MAY occur immediately after TCP connection - establishment or reception of a contact header (and prior to any - further data exchange). This may, for example, be used to notify a - the initiator that the node is currently not capable of or willing - to communicate. However, a node MUST always send the contact - header to its peer first. - - - - If either node terminates a connection prematurely in this manner, - it SHOULD send a SHUTDOWN message and MUST indicate a reason code - unless the incoming connection did not include the magic string. - If a node does not want its peer to re-open the connection - immediately, it SHOULD set the 'D' bit in the flags and include a - reconnection delay to indicate when the peer is allowed to attempt - another connection setup. - - - - If a connection is to be terminated before another protocol message - has completed, then the node MUST NOT transmit the SHUTDOWN message - but still SHOULD close the TCP connection. In particular, if the - connection is to be closed (for whatever reason) while a node is in - the process of transmitting a bundle data segment, receiving node - is still expecting segment data and might erroneously interpret the - SHUTDOWN message to be part of the data segment. - -
- -
- - The protocol includes a provision for clean shutdown of idle TCP - connections. Determining the length of time to wait before closing - idle connections, if they are to be closed at all, is an - implementation and configuration matter. - - - - If there is a configured time to close idle links, then if no - bundle data (other than keepalive messages) has been received for - at least that amount of time, then either node MAY terminate the - connection by transmitting a SHUTDOWN message indicating the reason - code of 'idle timeout' (as described above). After receiving a - SHUTDOWN message in response, both sides may close the TCP - connection. - - -
-
- -
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described - in .
- -
- - One security consideration for this protocol relates to the fact - that nodes present their endpoint identifier as part of the - connection header exchange. It would be possible for a node to - fake this value and present the identity of a singleton endpoint - in which the node is not a member, essentially masquerading as - another DTN node. If this identifier is used without further - verification as a means to determine which bundles are transmitted - over the connection, then the node that has falsified its identity - may be able to obtain bundles that it should not have. - - - - These concerns may be mitigated through the use of - the Bundle Security - Protocols. In particular, the Bundle Authentication Header - defines mechanism for secure exchange of bundles between DTN nodes. - Thus an implementation could delay trusting the presented endpoint - identifier until the node can securely validate that its peer is in - fact the only member of the given singleton endpoint. - - =20 - - Another consideration for this protocol relates to denial of - service attacks. A node may send a large amount of data over a TCP - connection, requiring the receiving node to either handle the data, - attempt to stop the flood of data by sending a REFUSE_BUNDLE - message, or forcibly terminate the connection. This burden could - cause denial of service on other, well-behaving connections. There - is also nothing to prevent a malicious node from continually - establishing connections and repeatedly trying to send copious - amounts of bundle data. - - -
- -
- - Port number 4556 has been assigned as the default port for the - TCP convergence layer. - -
- - - - - - - - Key words for use in RFCs to Indicate Requirement Levels</= title> - <author initials=3D"S." surname=3D"Bradner" fullname=3D"Scott Bra= dner"> - <organization abbrev=3D"Harvard University"> - Harvard University - </organization> - </author> - <date month=3D"March" year=3D"1997"/> - </front> - <seriesInfo name=3D"RFC" value=3D"2119"/> - </reference> - - <reference anchor=3D"refs.dtnarch"> - <front> - <title>Delay-Tolerant Network Architecture - - - MCI/Jet Propulsion Laboratory - - - - - - - =20 - - - Bundle Protocol Specification - - The MITRE Corporation - - - =20 - - - Jet Propulsion Laboratory - - - - - - - - =20 - - - Bundle Security Protocol Specification - - - The MITRE Corporation - - - =20 - - - Trinity College Dublin - - - - - - SPARTA, Inc - - - - - - - - - =20 - - Delay Tolerant Networking Reference Implementation - - - - - - - - diff -r 8b0d483af1e2 -r e62055127255 doc/draft-lindgren-dtnrg-prophet-02.tx= t --- a/doc/draft-lindgren-dtnrg-prophet-02.txt Sat Dec 12 17:10:03 2009 +000= 0 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2687 +0,0 @@ - - -DTN Research Group A. Lindgren -Internet-Draft A. Doria -Expires: September 6, 2006 Lulea University of Technology - March 5, 2006 - - - Probabilistic Routing Protocol for Intermittently Connected Networks - draft-lindgren-dtnrg-prophet-02 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on September 6, 2006. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines PRoPHET, a Probabilistic Routing Protocol using - History of Encounters and Transitivity. PRoPHET is a routing - protocol for intermittently connected networks, where there is no - guarantee that a fully connected path between source and destination - exists at any time, rendering traditional routing protocols unable to - deliver messages between hosts. These networks are examples of - networks where the Delay-Tolerant Network architecture[1] is - applicable. The document presents an architectural overview followed - - - -Lindgren & Doria Expires September 6, 2006 [Page 1] -=0C -Internet-Draft PRoPHET March 2006 - - - by the protocol specification. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.2 Relation to the Delay-Tolerant Networking architecture . . 8 - 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1 PRoPHET . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1.1 Delivery predictability calculation . . . . . . . . . 9 - 2.1.2 Forwarding Strategies and Queueing Policies . . . . . 11 - 2.2 Bundle Agent to Routing Agent Interface . . . . . . . . . 12 - 2.3 Lower Layer Requirements and Interface . . . . . . . . . . 12 - 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 13 - 3.1 Neighbor Awareness . . . . . . . . . . . . . . . . . . . . 13 - 3.2 Information Exchange Phase . . . . . . . . . . . . . . . . 13 - 3.2.1 Routing Information Base Dictionary . . . . . . . . . 14 - 3.3 Routing Algorithm . . . . . . . . . . . . . . . . . . . . 14 - 3.4 Bundle Passing . . . . . . . . . . . . . . . . . . . . . . 15 - 3.4.1 Custody . . . . . . . . . . . . . . . . . . . . . . . 15 - 3.5 When a Bundle Reaches its Destination . . . . . . . . . . 16 - 3.6 Forwarding Strategies . . . . . . . . . . . . . . . . . . 16 - 3.7 Queueing Policies . . . . . . . . . . . . . . . . . . . . 18 - 3.8 Aging of Delivery Predictability . . . . . . . . . . . . . 19 - 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 4.2 Header . . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 4.3 TLV Structure . . . . . . . . . . . . . . . . . . . . . . 24 - 4.4 TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 4.4.1 Hello TLV . . . . . . . . . . . . . . . . . . . . . . 24 - 4.4.2 Error TLV . . . . . . . . . . . . . . . . . . . . . . 26 - 4.4.3 Routing Information Base Dictionary TLV . . . . . . . 27 - 4.4.4 Routing Information Base TLV . . . . . . . . . . . . . 28 - 4.4.5 Bundle Offer and Response TLV . . . . . . . . . . . . 29 - 5. Detailed Operation . . . . . . . . . . . . . . . . . . . . . . 31 - 5.1 High Level State Tables . . . . . . . . . . . . . . . . . 31 - 5.2 Hello Procedure . . . . . . . . . . . . . . . . . . . . . 33 - 5.2.1 State Tables . . . . . . . . . . . . . . . . . . . . . 35 - 5.3 Information exchange and bundle passing phase . . . . . . 36 - 5.3.1 State Tables . . . . . . . . . . . . . . . . . . . . . 37 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 - 6.1 Attacks on the operation of the protocol . . . . . . . . . 40 - 6.1.1 Black hole attack . . . . . . . . . . . . . . . . . . 40 - 6.1.2 Limited black hole attack/identity spoofing . . . . . 41 - 6.1.3 Fake PRoPHET ACKs . . . . . . . . . . . . . . . . . . 41 - 6.1.4 Bundle store overflow . . . . . . . . . . . . . . . . 42 - 6.1.5 Bundle store overflow with delivery predictability - manipulation . . . . . . . . . . . . . . . . . . . . . 42 - - - -Lindgren & Doria Expires September 6, 2006 [Page 2] -=0C -Internet-Draft PRoPHET March 2006 - - - 6.2 Interactions with External Routing Domains . . . . . . . . 43 - 7. Implementation Experience . . . . . . . . . . . . . . . . . . 43 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45 - A. PRoPHET Example . . . . . . . . . . . . . . . . . . . . . . . 45 - B. Neighbor Discovery Example . . . . . . . . . . . . . . . . . . 46 - Intellectual Property and Copyright Statements . . . . . . . . 48 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 3] -=0C -Internet-Draft PRoPHET March 2006 - - -1. Introduction - - The Probabilistic Routing Protocol using History of Encounters and - Transitivity (PRoPHET) algorithm enables communication between - participating nodes wishing to communicate in an intermittently - connected network where at least some of the nodes are mobile. One - of the most basic requirements for 'traditional' (IP) networking is - that there must exist a fully connected path between communication - endpoints for the duration of a communication session in order for - communication to be possible. There are, however, a number of - scenarios where connectivity is intermittent so that this is not the - case (thus rendering the end-to-end use of traditional networking - protocols impossible), but where it still is desirable to allow - communication between nodes (see Section 1.1 for a survey of such - scenarios). - - To introduce the work, consider a network of mobile nodes using - wireless communication with a limited range which is less than the - typical excursion distances over which the nodes travel. - Communication between a pair of nodes at a particular instant is only - possible when the distance between the nodes is less than the range - of the wireless communication. This means that, even if messages are - forwarded through other nodes acting as intermediate routes, there is - no guarantee of finding a viable continuous path when it is needed to - transmit a message. - - One way to enable communication in such scenarios, is by allowing - messages to be buffered at intermediate nodes for a longer time than - normally occurs in the queues of conventional routers (c.f. Delay - Tolerant Networking [1]). It would then be possible to exploit the - mobility of a subset of the nodes to bring messages closer to their - destination by transferring messages to other nodes as they meet. - Figure 1 shows how the mobility of nodes in such a scenario can be - used to eventually deliver a message to its destination. In this - figure, the four sub-figures (a) - (d) represent the physical - positions of four nodes (A, B, C, and D) at four time instants, - increasing from (a) to (d) and associated radio ranges. At the start - time node A has a message (indicated by a * next to that node) to be - delivered to node D, but there does not exist a path between nodes A - and D because of the limited range of available wireless connections. - As shown in sub-figures (a) - (d), the mobility of the nodes allows - the message to first be transferred to node B, then to node C, and - when finally node C moves within range of node D, it can deliver the - message to its final destination. This technique is known as - 'transitive networking'. - - Real users are not likely to move around randomly, but rather move in - a predictable fashion based on human traffic patterns (e.g., roads or - - - -Lindgren & Doria Expires September 6, 2006 [Page 4] -=0C -Internet-Draft PRoPHET March 2006 - - - foot paths), and on repeating behavioral patterns (e.g., going to - work or the market and returning home). This means that if a node - has visited a location or been in contact with a certain node several - times before, it is likely that it will visit that location or meet - that node again. - - In previously discussed mechanisms to enable communication in - intermittently connected networks, such as Epidemic Routing[3], very - general approaches have been taken to the problem at hand. There - have, however, not been any attempts to make use of assumed knowledge - of different (mobility) properties of the nodes in the network in a - truly distributed way. - - In an environment where buffer space and bandwidth are infinite, - Epidemic Routing will give an optimal solution to the problem of - routing in an intermittently connected network with regard to message - delivery ratio and latency. However, in most cases neither bandwidth - nor buffer space is infinite, but instead they are rather scarce - resources, especially in the case of sensor networks. We define an - alternative to Epidemic Routing, with lower demands on buffer space - and bandwidth, and with equal or better performance in cases where - those resources are limited, and without loss of generality in - scenarios where it is applicable. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 5] -=0C -Internet-Draft PRoPHET March 2006 - - - +----------------------------+ +----------------------------+ - | ___ | | ___ | - | ___ / \ | | / \ | - | / \ ( D ) | | ( D ) | - | ( B ) \___/ | | ___ \___/ | - | \___/ ___ | | /___\ ___ | - |___ / \ | | (/ B*\) / \ | - | \ ( C ) | | (\_A_/) ( C ) | - | A* ) \___/ | | \___/ \___/ | - |___/ | | | - +----------------------------+ +----------------------------+ - (a) Time t (b) Time (t + dt) - +----------------------------+ +----------------------------+ - | _____ ___ | | ___ ___ | - | / / \ \ / \ | | / \ /___\ | - | ( (B C* ) ( D ) | | ( B ) (/ D*\) | - | \_\_/_/ \___/ | | \___/ (\_C_/) | - | ___ | | ___ \___/ | - | / \ | | / \ | - | ( A ) | | ( A ) | - | \___/ | | \___/ | - | | | | - +----------------------------+ +----------------------------+ - (c) Time (t + 2*dt) (d) Time (t + 3*dt) - - - Figure 1: Example of transitive communication - - This document presents a framework for probabilistic routing in - intermittently connected networks, using an assumption of non-random - mobility of nodes to improve the delivery rate of messages while - keeping buffer usage and communication overhead at a low level. - First, a probabilistic metric called delivery predictability is - defined. The document then goes on to define a probabilistic routing - protocol using this metric. - -1.1 Background - - The kinds of communication networks addressed in this document are - only viable for applications that can tolerate long delays and are - able to deal with extended periods of being disconnected. In - practice there are many different scenarios and situations where - communication is inherently intermittent, and in which it is of high - value to develop methods of communication despite the limitations on - applications. This section presents a selection of situations where - it appears that these kinds of communication offer valuable solutions - to realistic problems. - - - - -Lindgren & Doria Expires September 6, 2006 [Page 6] -=0C -Internet-Draft PRoPHET March 2006 - - - The semi-nomadic Saami population of reindeer herders in the north of - Sweden follow the movement of the reindeer and when in their summer - camps, no fixed infrastructure is available. The herders would find - it useful to be able to communicate with the rest of the world - through, for example, mobile relays attached to snowmobiles and all- - terrain vehicles (ATVs), or carried as small devices in a backpack, - to (for example) obtain weather forecasts, conduct herd business, - receive RSS feeds, send and receive personal email, and maintain the - supply of educational material for children in the parties[6]. - Similar problems exist between rural villages in India and in other - regions where the Internet infrastructure is less well developed or - is only available at prices which are beyond the means of the local - population. The DakNet project[7] has deployed store-and-forward - ring networks connecting a number of villages through relays on buses - and motorcycles in India and Cambodia. - - While satellite networks often rely on very well defined trajectories - and predictable encounters, there are cases when connectivity between - them can be intermittent and opportunistic. In military war-time - scenarios and disaster recovery situations, soldiers, human rights - observers, or rescue personnel are often in hostile environments - where no infrastructure can be assumed to be present, or if present, - cannot be relied upon. Furthermore, the units may be sparsely - distributed so that connectivity between them is intermittent and - infrequent. - - In sensor networks, a large number of sensors are usually deployed in - the area in which measurements are to be performed. To ensure - connectivity among the sensors and to get measurements from the - entire area, it is common to deploy a very large number of sensors. - If sensors can be mobile and transitive communication techniques can - be used between them, the number of sensors required can be reduced, - and new areas where regular sensor networks have been too expensive - or difficult to deploy, can be monitored. - - Experiments have been done with attaching sensors to seals, vastly - increasing the number of oceanic temperature readings compared to - using a number of fixed sensors, and in a similar project sensors are - attached to whales[5]. To allow scientists to analyze the collected - data, it must somehow be transferred to a data sink, even though - connectivity among the seals and whales is very sparse and - intermittent, so the mobility of the animals (and their occasional - encounters with each other and networked buoys at feeding grounds) - must be relied upon for successful data delivery. - - Resembling the vast areas of the oceans are the plains of Africa in - that there are many remote areas with almost no fixed infrastructure - and where satellite connectivity is prohibitively expensive. In the - - - -Lindgren & Doria Expires September 6, 2006 [Page 7] -=0C -Internet-Draft PRoPHET March 2006 - - - ZebraNet project, an attempt is made to gain a better understanding - of the life and movements of the wildlife in a certain part of Africa - by equipping zebras with tracking collars communicating in fashions - similar to the ones described above. Yet another example concerns - weather monitoring over large areas such as a national park, where a - number of electronic display boards showing weather reports from - other parts of the park have been installed. By equipping hikers - with small networked devices, their mobility through the park can be - used to spread the weather information throughout the entire park. - -1.2 Relation to the Delay-Tolerant Networking architecture - - The Delay-Tolerant Networking (DTN) architecture[1] defines an - architecture for communication in environments where traditional - communication protocols can not be used due to excessive delays, link - outages and other extreme conditions. The intermittently connected - networks considered here are a subset of those covered by the DTN - architecture. The DTN architecture defines routes to be computed - based on a collection of 'contacts' indicating the start time, - duration, endpoints, forwarding capacity and latency of a link in the - topology graph. These contacts may be deterministic, or may be - derived from estimates. The architecture defines some different - types of intermittent contacts. The ones called opportunistic and - predicted are the ones addressed by this protocoll. - - Opportunistic contacts are those that are not scheduled, but rather - present themselves unexpectedly and frequently arise due to node - mobility. Predicted contacts are like opportunistic contacts, but - based on some information, it might be possible to draw some - statistical conclusion on if a contact will be present soon. - - The DTN architecture also defines the bundle protocol [2], which - provides a way for applications to 'bundle' an entire session, - including both data and meta-data, into a single message, or bundle, - that can be sent as a unit. The bundling protocol also provides end- - to-end addressing and reliability. We build on the bundling - protocol, using bundles as the basic data transfer unit. - -2. Architecture - -2.1 PRoPHET - - This section describes the main architecture of PRoPHET, a - Probabilistic Routing Protocol using History of Encounters and - Transitivity. The protocol leverages the observations made on the - non-randomness of human mobility to improve routing performance. - Instead of only blindly flooding messages through the network, it - applies 'probabilistic routing'. - - - -Lindgren & Doria Expires September 6, 2006 [Page 8] -=0C -Internet-Draft PRoPHET March 2006 - - - To accomplish this, a probabilistic metric called 'delivery - predictability', 0 <=3D P_(A,B) <=3D 1, is established at every node A - for each known destination B. This indicates how likely it is that - this node will be able to deliver a message to that destination. - - When two PRoPHET nodes meet, they exchange summary vectors which - contain the identifiers of the bundles each node carries, and also a - delivery predictability vector containing the delivery predictability - information for destinations known by the nodes. This additional - information is used to update the internal delivery predictability - vector as described below. After that, the information in the - summary vector is used to decide which messages to request from the - other node based on the forwarding strategy used (as discussed in - Section 2.1.2). - -2.1.1 Delivery predictability calculation - - As stated above, PRoPHET relies on calculating a metric based on the - probability of encountering a certain node, and using that to support - the decision of whether or not to forward a message to a certain - node. In the equations that follow, the updates are being performed - by node A, and P_(A,B) is the delivery predictability value that node - A has stored for the destination B. If no delivery predictability - values is stored for a particular destination B, P_(A,B) is - considered to be zero. Recommended settings for the various - parameters are given in Section 3.3. The calculation of the delivery - predictabilities has three parts. When two nodes meet, the first - thing they do is to update the delivery predictability for each - other, so that nodes that are often encountered have a high delivery - predictability. This calculation is shown in Equation 1, where 0 <=3D - P_encounter <=3D 1 is an initialization constant. - - P_(A,B) =3D P_(A,B)_old + ( 1 - P_(A,B)_old ) * P_encounter (1) - - If a pair of nodes do not encounter each other during an interval, - they are less likely to be good forwarders of messages to each other, - thus the delivery predictability values must age, being reduced in - the process. The aging equation is shown in Equation 2, where 0 <=3D - gamma <=3D 1 is the aging constant, and K is the number of time units - that have elapsed since the last time the metric was aged. The time - unit used can differ, and should be defined based on the application - and the expected delays in the targeted network. How to set this - properly is discussed in Section 3.8. - - P_(A,B) =3D P_(A,B)_old * gamma^K (2) - - The delivery predictability also has a transitive property, that is - based on the observation that if node A frequently encounters node B, - - - -Lindgren & Doria Expires September 6, 2006 [Page 9] -=0C -Internet-Draft PRoPHET March 2006 - - - and node B frequently encounters node C, then node C probably is a - good node to forward messages destined for node A to. Equation 3 - shows how this transitivity affects the delivery predictability, - where 0 <=3D beta <=3D 1 is a scaling constant that controls how large = an - impact the transitivity should have on the delivery predictability. - - P_(A,C) =3D P_(A,C)_old + ( 1 - P_(A,C)_old ) * P_(A,B) * - P_(B,C) * beta (3) - - -2.1.1.1 Optional delivery predictability optimizations - -2.1.1.1.1 Smoothing - - To give the delivery predictability a smoother rate of change, a node - MAY apply one of the following methods to smooth the metric: - 1. Keep a list of NUM_P (the recommended value is 4, which has been - shown in simulations to give a good tradeoff between smoothness - and rate of response to changes) values for each destination - instead of only a single value. The list is held in order of - acquisition. When a delivery predictability is updated, the - value at the 'newest' position in the list is used as input to - the equations in Section 2.1.1. The oldest value in the list is - then discarded and the new value is written in the 'newest' - position of the list. When a delivery predictability value is - needed (either for sending to a peering PRoPHET node, or for - making a forwarding decision), the average of the values in the - list is calculated, and that value is then used. If less than - NUM_P values have been entered into the list, only the positions - that have been filled should be used for the averaging. - 2. In addition to keeping the delivery predictability as described - in Section 2.1.1, a node MAY also keep an exponential weighted - moving average (EWMA) of the delivery predictability. The EWMA - is then used for making forwarding decisions and to report to - peering nodes, but the value calculated according to - Section 2.1.1 is still used as input to the calculations of new - delivery predictabilities. The EWMA is calculated according to - Equation 4, where 0 <=3D alpha <=3D 1 is the weight of the most - current value. - - P_ewma =3D P_ewma_old * (1 - alpha) + P * alpha (4) - - The appropriate choice of smoothing algorithm in various - circumstances is the subject of ongoing research and a future version - of this protocol specification may contain additional advice. - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 10] -=0C -Internet-Draft PRoPHET March 2006 - - -2.1.1.1.2 Removal of low delivery predictabilities - - To reduce the data to be transferred between two nodes, a node MAY - treat delivery predictabilities smaller than epsilon, where epsilon - is a small number, as if they were zero, and thus they do not need to - be included in the list sent during the information exchange phase. - If this optimization is used, care must be taken to select epsilon to - be smaller than delivery predictability values normally present in - the network for destinations for which this node is a forwarder. It - is possible that epsilon could be calculated based on delivery - predictability ranges and the amount they change historically, but - this has not been investigate yet. - -2.1.2 Forwarding Strategies and Queueing Policies - - In traditional routing protocols, choosing where to forward a message - is usually a simple task; the message is sent to the neighbor that - has the path to the destination with the lowest cost (often the - shortest path). Normally the message is also only sent to a single - node since the reliability of paths is relatively high. However, in - the settings we envision here, things are radically different. The - first possibility that must be considered when a message arrives at a - node is that there might not be a path to the destination available, - so the node has to buffer the message and upon each encounter with - another node, the decision must be made on whether or not to transfer - a particular message. Furthermore, it may also be sensible to - forward a message to multiple nodes to increase the probability that - a message is really delivered to its destination. - - Unfortunately, these decisions are not trivial to make. In some - cases it might be sensible to select a fixed threshold and only give - a message to nodes that have a delivery predictability over that - threshold for the destination of the message. On the other hand, - when encountering a node with a low delivery predictability, it is - not certain that a node with a higher metric will be encountered - within reasonable time. Thus, there can also be situations where we - might want to be less strict in deciding who to give messages to. - Furthermore, there is the problem of deciding how many nodes to give - a certain message to. Distributing a message to a large number of - nodes will of course increase the probability of delivering that - particular message to its destination, but this comes at the cost of - consuming more system resources for message storage and possibly - reducing the probability of other messages being delivered. On the - other hand, giving a message to only a few nodes (maybe even just a - single node) will use less system resources, but the probability of - delivering a message is lower, and the delay incurred high. - - When resources are constrained, nodes may suffer from storage - - - -Lindgren & Doria Expires September 6, 2006 [Page 11] -=0C -Internet-Draft PRoPHET March 2006 - - - shortage, and may have to drop bundles before they have been - delivered to their destinations. Similarly to when deciding whether - or not to forward a message, deciding which message to drop to still - maintain good performance might require different policies in - different scenarios. - - Nodes MAY define their own forwarding strategies and queueing - policies that take into account the special conditions applicable to - the nodes, and local resource constraints. Some default strategies - and policies that should be suitable for most normal operation are - defined in Section 3.6 and Section 3.7. - -2.2 Bundle Agent to Routing Agent Interface - - To enable the PRoPHET routing agent to operate properly, it must be - aware of the bundles stored at the node, and it must also be able to - tell the bundle agent of that node to send a bundle to a peering - node. Therefore, the bundle agent needs to provide the following - interface/functionality to the routing agent: - Get Bundle List - Returns a list of the stored bundles and their attributes to the - routing agent. - Send Bundle - Makes the bundle agent send a specified bundle. - Accept Bundle - Gives the bundle agent a new bundle to store. - Bundle Delivered - Tells the bundle agent that a bundle was delivered to its - destination. - Drop Bundle - Makes the bundle agent drop a specified bundle. - -2.3 Lower Layer Requirements and Interface - - PRoPHET can be run on a large number of underlying networking - technologies. To accomodate its operation on all kinds of lower - layers, it requires the lower layers to provide the following - functionality and interfaces. - Neighbor discovery and maintenance - A PRoPHET node needs to know the identity of its neighbors and - when new neighbors appear and old neighbors disappear. Some - wireless networking technologies might already contain - mechanisms for detecting neighbors and maintaining this state. - To avoid redundancies and inefficiencies, neighbor discovery is - thus not included as a part of PRoPHET, but PRoPHET relies on - such mechanism in lower layers. The lower layers MUST provide - the two functions listed below. If the underlying wireless - networking technology does not support such services, a simple - - - -Lindgren & Doria Expires September 6, 2006 [Page 12] -=0C -Internet-Draft PRoPHET March 2006 - - - neighbor discovery scheme using local broadcasts of beacon - messages could be run in-between PRoPHET and the underlying - layer. An example of a simple neighbor discovery mechanism that - could be used is shown in Appendix B. - New Neighbor - Signals to the PRoPHET agent that a new node has become a - neighbor. A neighbor is here defined as another node that - is currently within communication range of the wireless - networking technology in use. The PRoPHET agent should now - start the Hello procedure as described in Section 5.2. - Neighbor Gone - Signals to the PRoPHET agent that one of its neighbors have - left. - Local Address - An address used by the underlying communication layer (e.g. an - IP or MAC address) that identifies the sender address of the - current message. This address must be unique among the nodes - that can currently communicate, and is only used in conjunction - with the Instance numbers to identify a communicating pair of - nodes as described in Section 4.2. - -3. Protocol Overview - -3.1 Neighbor Awareness - - Since the operation of the protocol is dependent on the encounters of - nodes running PRoPHET, the nodes must be able to detect when a new - neighbor is present. The protocol may be run on several different - networking technologies, and as some of them might already have - methods available for detecting neighbors, PRoPHET does not include a - mechanism for neighbor discovery. Instead, it requires the - underlying layer to provide a mechanism to notify the protocol of - when neighbors appear and disappear as described in Section 2.3. - - When a new neighbor has been detected, the protocol starts to set up - a link with that node through the Hello message exchange as described - in Section 5.2. Once the link has been set up the protocol continues - to the Information Exchange Phase (see Section 3.2). - - -3.2 Information Exchange Phase - - The first step in the Information Exchange Phase is for the protocol - to send a Routing Information Base Dictionary TLV to the node it is - peering with. This is a dictionary of the addresses of the nodes - that will be listed in the Routing Information Base. After this, a - Routing Information Base TLV is sent. This TLV contains a list of - the addresses that the node has heard of, and the corresponding - - - -Lindgren & Doria Expires September 6, 2006 [Page 13] -=0C -Internet-Draft PRoPHET March 2006 - - - delivery predictabilities for those nodes, and flags describing the - capabilities of the sending node. Upon reception of this TLV, the - node updates its delivery predictability table according to the - equations in Section 2.1.1, and using its forwarding strategy (see - Section 2.1.2) determines which of its stored bundles it wishes to - offer the peering node. After making this decision, a Bundle Offer - TLV is prepared, listing the bundle identifiers and their - destinations for all bundles it wishes to offer the other node. If - the Bundle Offer TLV lists a bundle for which the destination was not - included in the first Routing Information Base Dictionary TLV sent, a - new such TLV is sent first with an incremental update of the - dictionary. When the peering node has a dictionary with all - necessary addresses, the Bundle Offer TLV is sent to it. The Bundle - Offer TLV also contains a list of PRoPHET ACKs (see Section 3.5). - This phase of the protocol is described in more detail in - Section 5.3. - - When a new bundle arrives at a node, the node MAY inspect its list of - available neighbors, and if one of them is a cadidate to forward the - bundle, a new Bundle Offer TLV MAY be sent to that node. If two - nodes remain connected over a longer period of time, the Information - Exchange Phase will be periodically re-initiated to allow new - delivery predictability information to be spread through the network - and new bundle exchanges to take place. - -3.2.1 Routing Information Base Dictionary - - To reduce the overhead of the protocol, the Routing Information Base - and Bundle Offer/Request TLVs utilize an address dictionary. This - dictionary maps long variable length addresses as defined in [1] to - shorter 16 bit identifiers that are used in place of the addresses in - subsequent TLVs. The dictionary established only persist through a - single encounter with a node (while the same link set up by the Hello - procedure, with the same instance numbers, remains). - -3.3 Routing Algorithm - - The basic routing algorithm of the protocol is described in - Section 2.1. The algorithm uses some parameter values in the - calculation of the delivery predictability metric. These parameters - are configurable depending on the usage scenario, but Figure 2 - provides some recommended default values. - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 14] -=0C -Internet-Draft PRoPHET March 2006 - - - Recommended parameter values - - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Parameter | Recommended value | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | P_encounter | 0.75 | - +----------------------------------+ - | beta | 0.25 | - +----------------------------------+ - | gamma | 0.99 | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - Figure 2 - - -3.4 Bundle Passing - - Upon reception of the Bundle Offer TLV, the node inspects the list of - bundles and decides which bundles it is willing to store for future - forwarding, or that it is able to deliver to their destination. This - decision has to be made using local policies and considering - parameters such as available buffer space. For each such acceptable - bundle, the node sends a Bundle Request TLV to its peering node, - which in response to that sends the requested bundle. If a node has - some bundles it would prefer to receive ahead of others offered (e.g. - bundles that it can deliver to their final destination), it MAY - request the bundles in that priority order. This is often desireable - as there is no guarantee that the nodes will remain in contact with - each other for long enough to transfer all the acceptable bundles. - Otherwise, the node SHOULD assume that the bundles are listed in a - priority order determined by the peering node's forwarding strategy, - and request bundles in that order. - - -3.4.1 Custody - - To free up local resources, a node MAY give custody of a bundle to - another node that offers custody (which is found out during the - information exchange phase). This is done to move the retransmission - requirement further toward the destination. The concept of custody - transfer, and more details on the motivation for its use can be found - in [1]. When a node accepts custody of a bundle, it MUST keep that - bundle until it gets an ACK confirming that it has been delivered to - its destination, until another node accepts custody of the bundle, or - until the bundle's time to live has expired. When custody of a - bundle has been accepted by another node, the previous custodian MAY - - - -Lindgren & Doria Expires September 6, 2006 [Page 15] -=0C -Internet-Draft PRoPHET March 2006 - - - delete that bundle if appropriate to free up local resources. - - The exact policy to use when deciding when to offer and accept - custody is something that each node must decide, and is not currently - defined. It is believed that the custody policy in most cases will - be a stricter version of the forwarding strategy. - -3.5 When a Bundle Reaches its Destination - - When a bundle reaches its destination, a PRoPHET ACK for that bundle - is issued. A PRoPHET ACK is a confirmation that a bundle has been - delivered to its destination in the PRoPHET network (bundles might - traverse several different types of networks using different routing - protocols; thus, this might not be the final destination of the - bundle). When nodes exchange Bundle Offer TLVs, bundles that have - been ACKed are also listed, having the "PRoPHET ACK" flag set. The - node that receive this list updates its own list of ACKed bundles to - be the union of its previous list and the received list. To prevent - the list of ACKed bundles growing indefinitely, each PRoPHET ACK - should have a timeout that MUST NOT be longer than the timeout of the - bundle to which the ACK corresponds. - - Nodes MAY keep track of which nodes they have sent PRoPHET ACKs for - certain bundles to, and MAY in that case refrain from sending - multiple PRoPHET ACKs for the same bundle to the same node. - - If necessary in order to preserve system resources, nodes MAY drop - PRoPHET ACKs prematurely, but SHOULD refrain from doing so if - possible. - - It is important to keep in mind that PRoPHET ACKs and bundle ACKs[2] - are different things. PRoPHET ACKs are only valid within the PRoPHET - part of the network, while bundle ACKs are end-to-end acknowledgments - that may go outside of the PRoPHET network. Care should be taken to - ensure that bundle acknowledgments as well as PRoPHET ACKs are - created in an efficient way. - -3.6 Forwarding Strategies - - During the information exchange phase, nodes need to decide on which - bundles they wish to exchange with the peering node. Because of the - large number of scenarios and environments that PRoPHET can be used - in, and because of the wide range of devices that may be used, it is - not certain that this decision will be based on the same strategy in - every case. Therefore, each node uses a _forwarding strategy_ to - make this decision. Nodes may define their own strategies, but this - section defines a few basic forwarding strategies that nodes can use. - Note: If the node being encountered is the destination of any of the - - - -Lindgren & Doria Expires September 6, 2006 [Page 16] -=0C -Internet-Draft PRoPHET March 2006 - - - bundles being carried, those bundles SHOULD be offered to the - destination, even if that would violate the forwarding strategy. - Some of the forwarding strategies listed here have been evaluated - (together with a number of queueing policies) through simulations, - and more information about that and recommendations on which - strategies to use in different situations can be found in [4]. - - We use the following notation in our descriptions below. A and B are - the nodes that meet, and the strategies are described as they would - be applied by node A. The destination node is D. P_(X,Y) denotes the - delivery predictability stored at node X for destination Y, and NF is - the number of times A has given the bundle to some other node. - GRTR - Forward the bundle only if P_(B,D) > P_(A,D). - When two nodes meet, a bundle is sent to the other node if the - delivery predictability of the destination of the bundle is - higher at the other node. The first node does not delete the - bundle after sending it as long as there is sufficient buffer - space available (since it might encounter a better node, or even - the final destination of the bundle in the future). - GTMX - Forward the bundle only if P_(B,D) > P_(A,D) && NF < NF_max. - This strategy is like the previous one, but each bundle is given - to at most NF_max other nodes apart from the destination. - GRTR+ - Forward the bundle only if Equation 5 holds, where P_max is the - largest delivery predictability reported by a node to which the - bundle has been sent so far. - - P_(B,D) > P_(A,D) && P_(B,D) > P_max (5) - - This strategy is like GRTR, but nodes keep track of the largest - delivery predictability of any node it has forwarded this bundle - to, and only forward the bundle again if the currently - encountered node has a greater delivery predictability than the - maximum previously encountered. - GTMX+ - Forward the bundle only if Equation 6 holds. - - P_(B,D) > P_(A,D) && P_(B,D) > P_max && NF < NF_max (6) - - This strategy is like GTMX, but nodes keep track of P_max as in - GRTR+. - GRTRSort - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 17] -=0C -Internet-Draft PRoPHET March 2006 - - - Select bundles in descending order of the value of P_(B,D) - - P_(A,D). Forward the bundle only if P_(B,D) > P_(A,D). - This strategy is like GRTR, but instead of just going through - the bundle queue linearly, this strategy looks at the difference - in delivery predictabilites for each bundle between the two - nodes, and forwards the bundles with the largest difference - first. As bandwidth limitations or disrupted connections may - result in not all bundles that would be desirable being - exchanged, it could be desirable to first send bundles that get - a large improvement in delivery predictability. - GRTRMax - Select bundles in descending order of P_(B,D). Forward the - bundle only if P_(B,D) > P_(A,D). This strategy begins by - considering the bundles for which the encountered node has the - highest delivery predictability. The motivation for doing this - is the same as in GRTRSort, but based on the idea that it is - better to give bundles to nodes with high absolute delivery - predictabilities, instead of trying to maximize the improvement. - -3.7 Queueing Policies - - Because of limited buffer resources, nodes may need to drop some - bundles. As is the case with the forwarding strategies, which bundle - to drop is also dependent on the scenario. Therefore, each node also - has a queuing policy that determines how its bundle queue is handled. - This section defines a few basic queueing policies, but nodes MAY use - other policies if desired. Some of the queueing policies listed here - have been evaluated (together with a number of forwarding strategies) - through simulations. More information about that and recommendations - on which policies to use in different situations can be found in [4]. - FIFO - Handle the queue in a FIFO order. The bundle that was first - entered into the queue is the first bundle to be dropped. - MOFO - Evict most forwarded first - In an attempt to maximize the delivery rate of bundles, this - policy requires that the routing agent keeps track of the number - of times each bundle has been forwarded to some other node. The - bundle that has been forwarded the largest number of times is - the first to be dropped. - MOPR - Evict most favorably forwarded first - Keep a variable FAV for each bundle in the queue, initialized to - zero. Each time the bundle is forwarded, update FAV according - to Equation 7, where P is the predictability metric the node the - bundle is forwarded to has for its destination. - - FAV_new =3D FAV_old + ( 1 - FAV_old ) * P (7) - - The bundle with the highest FAV value is the first to be - - - -Lindgren & Doria Expires September 6, 2006 [Page 18] -=0C -Internet-Draft PRoPHET March 2006 - - - dropped. - Linear MOPR - Evict most favorably forwarded first; linear increase - Keep a variable FAV for each bundle in the queue, initialized to - zero. Each time the bundle is forwarded, update FAV according - to Equation 8, where P is the predictability metric the node the - bundle is forwarded to has for its destination. - - FAV_new =3D FAV_old + P (8) - - The bundle with the highest FAV value is the first to be - dropped. - SHLI - Evict shortest life time first - As described in [2], each bundle has a timeout value specifying - when it no longer is meaningful to its application and should be - deleted. Since bundles with short remaining time to life will - soon be dropped anyway, this policy decides to drop the bundle - with the shortest remaining life time first. To successfully - use a policy like this, there need to be some form of time - synchronization between nodes so that it is possible to know the - exact lifetimes of bundles. This is however not specific to - this routing protocol, but a more general DTN problem. - LEPR - Evict least probable first - Since the node is least likely to deliver a bundle for which it - has a low delivery predictability, drop the bundle for which the - node has the lowest delivery predictability, and that has been - forwarded at least MF times, which is a minimum number of - forwards that a bundle must have been forwarded before being - dropped (if such a bundle exists). - - More than one queueing policy MAY be combined in an ordered set, - where the first policy is used primarily, the second only being used - if there is a need to tie-break between bundles given the same - eviction priority by the primary policy, and so on. As an example, - one could select the queueing policy to be {MOFO; SHLI; FIFO}, which - would start by dropping the bundle that has been forwarded the - largest number of times. If more than one bundle has been forwarded - the same number of times, the one with the shortest remaining life - time will be dropped, and if that also is the same, the FIFO policy - will be used to drop the bundle first received. - - It is worth noting that obviously nodes MUST NOT drop bundles for - which it has custody unless the lifetime expires. - -3.8 Aging of Delivery Predictability - - To ensure proper properties of the delivery predictabilities, the - parameters determining the rate of aging used for the metric must be - set depending on the scenario in which the protocol will be - - - -Lindgren & Doria Expires September 6, 2006 [Page 19] -=0C -Internet-Draft PRoPHET March 2006 - - - operating. Implementations and experiments have given some - experience on how to do this, but this is still ongoing work, and no - conclusive guidelines on how to set the parameters currently exist. - -4. Message Formats - -4.1 Messages - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Header ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ TLV 1 ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | . | - ~ . ~ - | . | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ TLV n ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 3: Basic message format - - - - - - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 20] -=0C -Internet-Draft PRoPHET March 2006 - - -4.2 Header - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Version | Flags | Result | Code | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Receiver Instance | Sender Instance | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Transaction Identifier | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |S| SubMessage Number | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Message Body ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 4: Header - - Version - This version of the PRoPHET Protocol =3D 1. - Flags - TBD - Result - Field that is used to indicate whether a response is required - to the request message if the outcome is successful. A value of - "NoSuccessAck" indicates that the request message does not - expect a response if the outcome is successful, and a value of - "AckAll" indicates that a response is expected if the outcome is - successful. In both cases a failure response MUST be generated - if the request fails. - In a response message, the result field can have two values: - "Success," and "Failure". The "Success" results indicates a - success response. All messages that belong to the same success - response will have the same Transaction Identifier. The - "Success" result indicates a success response that may be - contained in a single message or the final message of a success - response spanning multiple messages. - ReturnReceipt is a result field used to indicate that an - acknowledgement is required for the message. The default for - Messages is that the controller will not acknowledge responses. - In the case where an acknowledgement is required, it will set - the Result Field to ReturnReceipt in the header of the Message. - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 21] -=0C -Internet-Draft PRoPHET March 2006 - - - The encoding of the result field is: - - NoSuccessAck: Result =3D 1 - AckAll: Result =3D 2 - Success: Result =3D 3 - Failure: Result =3D 4 - ReturnReceipt Result =3D 5 - - Code - Field gives further information concerning the result in a - response message. It is mostly used to pass an error code in a - failure response but can also be used to give further - information in a success response message or an event message. - In a request message, the code field is not used and is set to - zero. - If the Code field indicates that the Error TLV is included in - the message, further information on the error will be found in - the Error TLV, which MUST be the the first TLV after the header. - - The encoding is: - - PRoPHET Error messages 0x000 - 0x099 - Reserved 0x0A0 - 0x0FE - Error TLV in message 0x0FF - - Sender Instance - For messages during the Hello phase with the Hello SYN, Hello - SYNACK, and Hello ACK functions, it is the sender's instance - number for the link. It is used to detect when the link comes - back up after going down or when the identity of the entity at - the other end of the link changes. The instance number is a 18- - bit number that is guaranteed to be unique within the recent - past and to change when the link or node comes back up after - going down. Zero is not a valid instance number. For the - RSTACK function, the Sender Instance field is set to the value - of the Receiver Instance field from the incoming message that - caused the RSTACK function to be generated. Messages sent after - the Hello phase is completed should use the sender's instance - number for the link. - Receiver Instance - For messages during the Hello phase with the Hello SYN, Hello - SYNACK, and Hello ACK functions, is what the sender believes is - the current instance number for the link, allocated by the - entity at the far end of the link. If the sender of the message - does not know the current instance number at the far end of the - link, this field SHOULD be set to zero. For the RSTACK message, - the Receiver Instance field is set to the value of the Sender - Instance field from the incoming message that caused the RSTACK - - - -Lindgren & Doria Expires September 6, 2006 [Page 22] -=0C -Internet-Draft PRoPHET March 2006 - - - message to be generated. Messages sent after the Hello phase is - completed should use what the sender believes is the current - instance number for the link, allocated by the entity at the far - end of the link. - Transaction Identifier - Used to associate a message with its response message. This - should be set in request messages to a value that is unique for - the sending host within the recent past. Reply messages contain - the Transaction Indentifier of the request they are responding - to. - S-flag - If S is set then the SubMessage Number field indicates the total - number of SubMessage segments that compose the entire message. - If it is not set then the SubMessage Number field indicates the - sequence number of this SubMessage segment within the whole - message. the S field will only be set in the first sub-message - of a sequence. - submessage number - When a message is segmented because it exceeds the MTU of the - link layer, each segment will include a submessage number to - indicate its position. Alternatively, if it is the first - submessage in a sequence of submessages, the S flag will be set - and this field will contain the total count of submessage - segments. - Length - Length in octets of this message including headers and message - body. If the message is fragmented, this field contains the - length of this submessage. - - The protocol also uses a pseudo header with information that MUST be - provided by the underlying communication layer. The following pseudo - header fields are defined: - - Sender Local Address - An address used by the underlying communication layer as - described in Section 2.3 that identifies the sender address of - the current message. This address must be unique among the - nodes that can currently communicate, and is only used in - conjunction with the Receiver Local Address and the Receiver - Instance and Sender Instance to identify a communicating pair of - nodes. - Receiver Local Address - An address used by the underlying communication layer as - described in Section 2.3 that identifies the receiver address of - the current message. This address must be unique among the - nodes that can currently communicate, and is only used in - conjunction with the Sender Local Address and the Receiver - Instance and Sender Instance to identify a communicating pair of - - - -Lindgren & Doria Expires September 6, 2006 [Page 23] -=0C -Internet-Draft PRoPHET March 2006 - - - nodes. - -4.3 TLV Structure - - All TLVs have the following format, and can be nested. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type | TLV Flags | TLV Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ TLV Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 7: TLV Format - - TLV Type - Specific TLVs are defined in Section 4.4. Each TLV will have - fields defined that are specific to the function of that TLV. - TLV Flags - These are defined per TLV type. - TLV Length - Length of the TLV in octets, including the TLV header and any - nested TLVs. - -4.4 TLVs - -4.4.1 Hello TLV - - The Hello TLV is used to set up and maintain a link between two - PRoPHET nodes. Hello messages with the SYN function are transmitted - periodically as beacons. The Hello TLV is the first TLV exchanged - between two PRoPHET nodes when they encounter each other. No other - TLVs can be exchanged until the first Hello sequenece is completed. - - Once a communication link is established between two PRoPHET nodes, - the Hello TLV will be sent once for each interval as defined in the - interval timer. If a node experiences the lapse of HELLO_DEAD Hello - intervals without receiving a Hello TLV on an ESTAB connection (as - defined in the state machine in Section 5.2), the connection SHOULD - be assumed broken. - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 24] -=0C -Internet-Draft PRoPHET March 2006 - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type=3D0x01 | resv | HF | TLV Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Timer | Name Length | Sender Name (variable) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - Figure 8: Hello TLV Format - - HF - Specifies the function of the Hello TLV. Four functions are - specified for the Hello TLV: - - SYN: HF =3D 1 - SYNACK: HF =3D 2 - ACK: HF =3D 3 - RSTACK: HF =3D 4. - - TLV Data - Timer - The Timer field is used to inform the receiver of the timer - value used in the Hello processing of the sender. The timer - specifies the nominal time between periodic Hello messages. It - is a constant for the duration of a session. The timer field is - specified in units of 100ms. - Name Length - The Name Length field is used to specify the length of the - Sender Name field in octets. If the name has already been sent - at least once in a message with the current Sender Instance, a - node MAY choose to set this field to zero, omitting the Sender - Name from the Hello TLV. - Sender Name - The Sender Name field specifies the routable DTN name of the - sender that is to be used in updating routing information and - making forwarding decisions. - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 25] -=0C -Internet-Draft PRoPHET March 2006 - - -4.4.2 Error TLV - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV type=3D0x02 | Flags | TLV Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Data ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 10: Error TLV Format - - TLV Flags - TBD - TLV Data - TBD - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 26] -=0C -Internet-Draft PRoPHET March 2006 - - -4.4.3 Routing Information Base Dictionary TLV - - The Routing Information Base Dictionary includes the list of - addresses used in making routing decisions. The referents remain - constant for the duration of a session over a link where the instance - numbers remain the same and can be used by both the Routing - Information Base messages and the bundle offer messages. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV type=3D0xA0 | Flags | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIBD Entry Count | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ ~ - ~ Variable Length Routing Address Strings ~ - ~ ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Routing Address String - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | String ID 1 | Length | Resv | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ Routing Address String 1(variable) ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | . | - ~ . ~ - | . | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | String ID n | Length | Resv | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | | - ~ Routing Address String n ~ - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 11: Routing Information Base Dictionary - - TLV Flags - TBD - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 27] -=0C -Internet-Draft PRoPHET March 2006 - - - RIBD Entry Count - Number of entries in the database - String ID 16 bit identifier that is constant for the duration of a - session. String ID zero is predefined as the node initiating - the session through sending the Hello SYN message, and String ID - one is predefined as the node responding with the Hello SYNACK - message. - Length - Length of Address String. - -4.4.4 Routing Information Base TLV - - The Routing Information Base lists the destinations a node knows of, - and the delivery predictabilities it has associated with them. This - information is needed by the PRoPHET algorithm to make decisions on - routing and forwarding. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type=3D0xA1 | Flags | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIB String Count | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIB String ID 1 | P-Value | RIB Flag 1 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ . ~ - ~ . ~ - ~ . ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RIBD String ID n | P-Value | RIB Flags n | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 12: Routing Information Base Header - - Flags - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 28] -=0C -Internet-Draft PRoPHET March 2006 - - - The encoding of the Header flag field relates to the - capabilities of the Source node sending the RIB: - - Flag 0: Relay Node 0b1 - Flag 1: Custody Node 0b1 - Flag 2: Internet GW Node 0b1 - Flag 3: Reserved 0b1 - Flag 4: Reserved 0b1 - Flag 5: Reserved 0b1 - Flag 6: Reserved 0b1 - Flag 7: Reserved 0b1 - - RIB String Count - Number of routing entries in the TLV - RIB String ID - ID string as predefined in the dictionary TLV. - P-value - Delivery predictability for the destination of this entry as - calculated according to the equations in Section 2.1.1. The - encoding of this field is a linear mapping from [0,1] to [0, - 0xFF]. - RIB Flag - - The encoding of the RIB flag field is: - - Flag 0: Relay Node 0b1 - Flag 1: Custody Node 0b1 - Flag 2: Internet GW Node 0b1 - Flag 3: Reserved 0b1 - Flag 4: Reserved 0b1 - Flag 5: Reserved 0b1 - Flag 6: Reserved 0b1 - Flag 7: Reserved 0b1 - - -4.4.5 Bundle Offer and Response TLV - - After the routing information has been passed, the node will ask the - other node to review available bundles and determine which bundles it - will accept for relay. The source relay will determine which bundles - to offer based on relative delivery predictabilities as explained in - Section 3.6. The Bundle Offer TLV also lists the bundles that a - PRoPHET acknowledgement has been issued for. Those bundles have the - PRoPHET ACK flag set in their entry in the list. When a node - receives a PRoPHET ACK for a bundle, it MUST remove any copies of - that bundle from its buffers, but SHOULD keep an entry of the - acknowledged bundle to be able to further propagate the PRoPHET ACK. - - - - -Lindgren & Doria Expires September 6, 2006 [Page 29] -=0C -Internet-Draft PRoPHET March 2006 - - - The Response message is identical to the request message with the - exception that the flag indicate acceptance of the bundle. - - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | TLV Type=3D0xA2 | Flags | Length | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Bundle Offer Count | Reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Bundle Dest String Id 1 | B_flags | resv | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Bundle 1 Creation Timestamp | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - ~ . ~ - ~ . ~ - ~ . ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Bundle Dest String Id n | B_flags | resv | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Bundle n Creation Timestamp | - | | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - Figure 15: Bundle Offer and Response - - TLV Flags - TBD - Bundle Offer Count - Number of bundle offer entries. - Bundle Dest String Id - ID string of the destination of the bundle as predefined in the - dictionary TLV. - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 30] -=0C -Internet-Draft PRoPHET March 2006 - - - The encoding of the B_Flags in the request are: - - Flag 0: Custody Offered 0b1 - Flag 1: Reserved 0b1 - Flag 2: Reserved 0b1 - Flag 3: Reserved 0b1 - Flag 4: Reserved 0b1 - Flag 5: Reserved 0b1 - Flag 6: Reserved 0b1 - Flag 7: PRoPHET ACK 0b1 - - The encoding of the B_flag values in the response are: - - Flag 0: Custody Accepted 0b1 - Flag 1: Bundle Accepted 0b1 - Flag 2: Reserved 0b1 - Flag 3: Reserved 0b1 - Flag 4: Reserved 0b1 - Flag 5: Reserved 0b1 - Flag 6: Reserved 0b1 - Flag 7: Reserved 0b1 - - - -5. Detailed Operation - - In this section, some more details on the operation of PRoPHET is - given along with state tables to help in implementing the protocol. - -5.1 High Level State Tables - - This section gives high level state tables for the operation of - PRoPHET. The following sections will describe each part of the - operation in more detail (including state tables for the internal - states of those procedures). - - The following states are used in the state tables: - WAIT_NB This is the state all nodes start in. Nodes remain in this - state until they are notified that a new neighbor is available. - At that point, the Hello procedure should be started with the - new neighbor, and the node move into the HELLO state. It does - also need to remain in the WAIT_NB state to ensure that it can - detect new neighbors. This can be handled by creating a new - thread or process that enters the HELLO state and takes care of - the communication with the new neighbor while the parent - remains in WAIT_NB. - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 31] -=0C -Internet-Draft PRoPHET March 2006 - - - HELLO Nodes are in the HELLO state from when a new neighbor is - detected until the Hello procedure is completed and a link is - established (which happens when the Hello procedure enters the - ESTAB state as described in Section 5.2). If the node is - notified that the neighbor is no longer in range before a link - has been established, it returns to the WAIT_NB state. - INFO_EXCH After a link has been set up by the Hello procedure, a node - enters the INFO_EXCH state where the information exchange and - bundle passing is done. The node remains in this state as long - as Information Exchange Phase TLVs (Routing RIB, Routing RIB - Dictionary) and bundle passing TLVs (Bundle Offer, Bundle - Request) are being received. When an empty Bundle Request TLV - (i.e., no more bundles to send) is received, the node starts a - timer and enters the WAIT_INFO state. If the node is notified - that the neighbor is no longer in range before all information - and bundles have been exchanged, it returns to the WAIT_NB - state. - WAIT_INFO Nodes enter the WAIT_INFO state after a completed - Information Exchange Phase and bundle passing phase. Nodes - remain in this state until a timer expires that means that the - Information Exchange Phase should be reinitiated. If the node - is notified that the neighbor is no longer in range before the - timer has expired, it returns to the WAIT_NB state. - - - - State: WAIT_NB - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | New Neighbor | Start Hello procedure for neighbor| HELLO | - | | Keep waiting for more neighbors | WAIT_NB | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: HELLO - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Hello TLV rcvd | | HELLO | - +------------------+-----------------------------------+-----------+ - | Enter ESTAB state| Start Information Exchange Phase | INFO_EXCH | - +------------------+-----------------------------------+-----------+ - - - -Lindgren & Doria Expires September 6, 2006 [Page 32] -=0C -Internet-Draft PRoPHET March 2006 - - - | Neighbor Gone | | WAIT_NB | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: INFO_EXCH - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - |Info Exch TLV rcvd| | INFO_EXCH | - +------------------+-----------------------------------+-----------+ - | No more bundles | Start timer | WAIT_INFO | - +------------------+-----------------------------------+-----------+ - | Neighbor Gone | | WAIT_NB | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - State: WAIT_INFO - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Timer expires | Restart Information Exchange Phase| INFO_EXCH | - +------------------+-----------------------------------+-----------+ - | Neighbor Gone | | WAIT_NB | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - Note x: - -5.2 Hello Procedure - - The Hello TLV procedure is described by the following rules and state - tables. - - The rules and state tables use the following operations: - o The "Update Peer Verifier" operation is defined as storing the - values of the Sender Instance and Sender Local Address fields from - a Hello SYN or Hello SYNACK function received from the entity at - the far end of the link. - - - - -Lindgren & Doria Expires September 6, 2006 [Page 33] -=0C -Internet-Draft PRoPHET March 2006 - - - o The procedure "Reset the link" is defined as: - 1. Generate a new instance number for the link. - 2. Delete the peer verifier (set to zero the values of Sender - Instance and Sender Local Address previously stored by the - Update Peer Verifier operation). - 3. Send a SYN message. - 4. Enter the SYNSENT state. - o The state tables use the following Boolean terms and operators: - A The Sender Instance in the incoming message matches the - value stored from a previous message by the "Update Peer - Verifier" operation. - B The Sender Instance and Sender Local Address fields in the - incoming message match the values stored from a previous - message by the "Update Peer Verifier" operation. - C The Receiver Instance and Receiver Local Address fields in - the incoming message match the values of the Sender Instance - and Sender Local Address used in outgoing Hello SYN, Hello - SYNACK, and Hello ACK messages. - SYN A Hello SYN TLV has been received. - SYNACK A Hello SYNACK TLV has been received. - ACK A Hello ACK TLV has been received. - "&&" Represents the logical AND operation - "||" Represents the logical OR operation - "!" Represents the logical negation (NOT) operation. - o A timer is required for the periodic generation of Hello SYN, - Hello SYNACK, and Hello ACK messages. The value of the timer is - announced in the Timer field. To avoid synchronization effects, - uniformly distributed random jitter of +/-5% of the Timer field - SHOULD be added to the actual interval used for the timer. - There are two independent events: the timer expires, and a packet - arrives. The processing rules for these events are: - - Timer Expires: Reset Timer - If state =3D SYNSENT Send SYN - If state =3D SYNRCVD Send SYNACK - If state =3D ESTAB Send ACK - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 34] -=0C -Internet-Draft PRoPHET March 2006 - - - Packet Arrives: - If incoming message is an RSTACK: - If (A && C && !SYNSENT) Reset the link - Else discard the message. - If incoming message is a SYN, SYNACK, or ACK: - Response defined by the following State Tables. - If incoming message is any other PRoPHET TLV and - state !=3D ESTAB: - Discard incoming message. - If state =3D SYNSENT Send SYN (Note 1) - If state =3D SYNRCVD Send SYNACK (Note 1) - - Note 1: No more than two SYN or SYNACK messages should be - sent within any time period of length defined by the timer. - - o A connection across a link is considered to be achieved when the - protocol reaches the ESTAB state. All TLVs, other than Hello - TLVs, that are received before synchronisation is achieved, will - be discarded. - -5.2.1 State Tables - - - - State: SYNSENT - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | - +------------------+-----------------------------------+-----------+ - | SYNACK && !C | Send RSTACK | SYNSENT | - +------------------+-----------------------------------+-----------+ - | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | - +------------------+-----------------------------------+-----------+ - | ACK | Send RSTACK | SYNSENT | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 35] -=0C -Internet-Draft PRoPHET March 2006 - - - State: SYNRCVD - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | - +------------------+-----------------------------------+-----------+ - | SYNACK && !C | Send RSTACK | SYNRCVD | - +------------------+-----------------------------------+-----------+ - | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | - +------------------+-----------------------------------+-----------+ - | ACK && B && C | Send ACK | ESTAB | - +------------------+-----------------------------------+-----------+ - | ACK && !(B && C) | Send RSTACK | SYNRCVD | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: ESTAB - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | SYN || SYNACK | Send ACK (note 2) | ESTAB | - +------------------+-----------------------------------+-----------+ - | ACK && B && C | Send ACK (note 3) | ESTAB | - +------------------+-----------------------------------+-----------+ - | ACK && !(B && C) | Send RSTACK | ESTAB | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - Note 2: No more than two ACKs should be sent within any time - period of length defined by the timer. Thus, one ACK MUST be sent - every time the timer expires. In addition, one further ACK may be - sent between timer expirations if the incoming message is a SYN or - SYNACK. This additional ACK allows the Hello functions to reach - synchronisation more quickly. - - Note 3: No more than one ACK should be sent within any time period - of length defined by the timer. - -5.3 Information exchange and bundle passing phase - - After the Hello messages have been exchanged, and the nodes are in - the ESTAB state, the information exchange and bundle passing phase is - - - -Lindgren & Doria Expires September 6, 2006 [Page 36] -=0C -Internet-Draft PRoPHET March 2006 - - - initiated. This section describes the procedure and shows the state - transitions necessary in this phase, and the following sections - describe the various TLVs passed in this phase in detail. - -5.3.1 State Tables - - This section shows the state transitions that nodes goes through - during the information exchange and bundle passing phase. State - tables are given for a "Listener" and for a "Initiator". Both nodes - should assume both roles during this phase, and this can be done - either concurrently or sequentially, depending on the implementation. - - - Listener: - --------- - - State: WAIT_DICT - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Dictionary rcvd | Update local dictionary (note 1) | WAIT_RIB | - +------------------+-----------------------------------+-----------+ - | ACK received | | WAIT_DICT | - +------------------+-----------------------------------+-----------+ - | Timeout(peer) | Send ACK (note 2) | WAIT_DICT | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: WAIT_RIB - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | RIB received | Update P ; Send offer (note 3) | OFFER | - +------------------+-----------------------------------+-----------+ - | ACK received | | WAIT_DICT | - +------------------+-----------------------------------+-----------+ - | Dictionary rcvd | Update local dictionary | WAIT_RIB | - +------------------+-----------------------------------+-----------+ - | Bundle req rcd | Send ACK | WAIT_DICT | - +------------------+-----------------------------------+-----------+ - | Timeout(peer) | Send ACK | WAIT_DICT | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - -Lindgren & Doria Expires September 6, 2006 [Page 37] -=0C -Internet-Draft PRoPHET March 2006 - - - State: OFFER - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Bundle req rcvd | Send requested bundle(s) | OFFER | - | #req bundles!=3D0 | | | - +------------------+-----------------------------------+-----------+ - | Bundle req rcvd | (note 4) | WAIT_DICT | - | #req bundles=3D=3D0 | | = | - +------------------+-----------------------------------+-----------+ - | ACK received | | WAIT_DICT | - +------------------+-----------------------------------+-----------+ - | Timeout(info) | Resend bundle offer (note 5) | OFFER | - +------------------+-----------------------------------+-----------+ - | Dict/ACK rcvd | Resend bundle offer | OFFER | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - Note 1: Both the dictionary and the RIB TLVs may come in the same - PRoPHET message. In that case, the state will change to WAIT_RIB - and the RIB will then immediately be processed. - - Note 2: Send an ACK if the timer for the peering node expires. - Either the link has been broken, and then the link setup will - restart, or it will trigger the information exchange phase to - restart. - - Note 3: When the RIB is received it is possible for the PRoPHET - agent to update its delivery predictabilities according to - Section 2.1.1. This and the RIB is then used together with the - forwarding strategy in use to create a bundle offer TLV. This is - sent to the peering node. - - Note 4: No more bundles are requested by the other node, transfer - is complete. - - Note 5: No response to the bundle offer has been received before - the timer expired, so we resend the bundle offer. - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 38] -=0C -Internet-Draft PRoPHET March 2006 - - - Initiator: - ---------- - - State: CREATE_DR - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Always | Create & send dict & RIB (note 1) | SEND_DR | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: SEND_DR - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Timeout(info) | Resend dictionary & RIB (note 2) | SEND_DR | - +------------------+-----------------------------------+-----------+ - | Bundle offer rcvd| Send bundle request | REQUEST | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - State: REQUEST - - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Condition | Action | New State | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | Timeout(info) | Send bundle request for | REQUEST | - | | missing bundles (note 3) | | - +------------------+-----------------------------------+-----------+ - | Bundle rcvd && | Wait for more bundles | REQUEST | - | REQ not fulfilled| (note 4) | | - +------------------+-----------------------------------+-----------+ - | Bundle rcvd && | Send empty bundle request | REQUEST | - | REQ fulfilled | (note 4) | | - +------------------+-----------------------------------+-----------+ - | ACK received | | CREATE_DR | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 39] -=0C -Internet-Draft PRoPHET March 2006 - - - - Note 1: The Initiator always starts by creating dictionary and RIB - TLVs, and send them to its peering node. - - Note 2: No response to the RIB has been received before the timer - expired, so we resend the dictionary and RIB TLVs. - - Note 3: If the timer expires, and not all requested bundles have - been received, send a new bundle request for the missing bundles. - - Note 4: While bundles are received, but there still are requested - bundles that have not been received, continue waiting for more - bundles. If all desired bundles have been received, send an empty - bundles request message to the peering node to signal that no more - bundles should be passed. - -6. Security Considerations - - Currently, PRoPHET does not specify any special security measures. - As a routing protocol for intermittently connected networks, PRoPHET - is a target for various attacks. The various known possible - vulnerabilities are discussed in this section. - - The attacks described here are not problematic if all nodes in the - network can be trusted and are working towards a common goal. If - there exist such a set of nodes, but there also exist malicious - nodes, these security problems can be solved by introducing an - authentication mechanism when two nodes meet, for example using a - public key system. Thus, only nodes that are known to be members of - the trusted group of nodes are allowed to participate in the routing. - This of course introduces the additional problem of key distribution, - but that is not addressed here. - -6.1 Attacks on the operation of the protocol - - There are a number of kinds of attacks on the operation of the - protocol that it would be possible to stage on a PRoPHET network. - The attacks and possible remedies are listed here. - -6.1.1 Black hole attack - - A malicious node sets its delivery predictabilities for all nodes to - 1, and does not forward any bundles. This has two effects, both - causing messages to be drawn towards the black hole, instead of to - its correct destination. - 1. A node encountering a malicious node will try to send all its - bundles to the malicious node, creating the belief that the - bundle has been very favorably forwarded. Depending on the - - - -Lindgren & Doria Expires September 6, 2006 [Page 40] -=0C -Internet-Draft PRoPHET March 2006 - - - forwarding strategy and queueing policy in use, this might hamper - future forwarding of the bundle and/or lead to premature dropping - of the bundle. - 2. Due to the transitivity, the delivery predictabilities reported - by the malicious node will affect the delivery predictabilities - of other nodes. This will create a gradient for all destinations - with the black hole as the "center of gravity" towards which all - bundles traverse. This should be particularly severe in - connected parts of the network. - -6.1.2 Limited black hole attack/identity spoofing - - A malicious node misrepresents itself by claiming to be someone else. - The effects of this attack are: - 1. The effects of the black hole attack listed above hold for this - attack as well, with the exception that only the delivery - predictabilities and bundles for one particular destination are - affected. This could be used to "steal" the data that should be - going to a particular node. - 2. In addition to the above problems, PRoPHET ACKs will be issued - for the bundles that are delivered to the malicious node. This - will cause these bundles to be removed from the network, reducing - the chance that they will reach their real destination. - -6.1.2.1 Attack detection - - It is possible for the destination to detect that this kind of attack - has occurred (but it will not be able to prevent it) if it receives a - PRoPHET ACK for a message destined to itself but for which it did not - receive the corresponding bundle. - -6.1.2.2 Attack prevention/solution - - To prevent this attack, some form of authentication between nodes - that meet is needed. One way to achieve this is to use public key - cryptography, but then the problem of key distribution needs to be - solved. - -6.1.3 Fake PRoPHET ACKs - - A malicious node may issue fake PRoPHET ACKs for all bundles (or only - bundles for a certain destination if the attack is targeted at a - single node) carried by nodes it meet. The affected bundles will be - deleted from the network, greatly reducing their probability of be - delivered to the destination. - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 41] -=0C -Internet-Draft PRoPHET March 2006 - - -6.1.3.1 Attack prevention/solution - - If a public key cryptography system is in place, this attack can be - prevented by mandating that all PRoPHET ACKs be signed by the - destination. Similarly to other solutions using public key - cryptography, this introduces the problem of key distribution. - -6.1.4 Bundle store overflow - - After encountering and receiving the delivery predictability - information from the victim, a malicious node may generate a large - number of bogus bundles for the destination for which the victim has - the highest delivery predictability. This will cause the victim to - most likely accept these bundles, filling up its bundle storage, - possibly at the expense of other, legitimate, bundles. This problem - is transient as the messages will be removed when the victim meets - the destination and delivers the messages. - -6.1.4.1 Attack detection - - If it is possible for the destination to figure out that the bundles - it is receiving are bogus, it could report that malicious actions are - underway. - -6.1.4.2 Attack prevention/solution - - This attack could be prevented by requiring sending nodes to sign all - bundles they send. By doing this, intermediate nodes could verify - the integrity of the messages before accepting them for forwarding. - -6.1.5 Bundle store overflow with delivery predictability manipulation - - A more sophisticated version of the attack in the previous section - can be attempted. The effect of the previous attack was lessened - since the destination node of the bogus bundles existed. This caused - bogus bundles to be purged from the network when the destination was - encountered. The malicious node may now use the transitive property - of the protocol to boost the victim's delivery predictabilities for a - non-existent destination. After this, it creates a large number of - bogus bundles for this non-existent destination and offers them to - the victim. As before, these bundles will fill up the bundle storage - of the victim. The impact of this attack will be greater as there is - no probability of the destination being encountered and the bundles - being acked. Thus, they will remain in the bundle storage until they - time out (the malicious node may set the timeout to a large value) or - until they are evicted by the queueing policy. - - The delivery predictability for the fake destination may spread in - - - -Lindgren & Doria Expires September 6, 2006 [Page 42] -=0C -Internet-Draft PRoPHET March 2006 - - - the network due to the transitivity, but this is not a problem, as it - will eventually age and fade away. - - The impact of this attack could be increased if multiple malicious - nodes collude, as network resources can be consumed at a greater - speed and at many different places in the network simultaneously. - -6.2 Interactions with External Routing Domains - - Users may opt to connect two regions of sparsely connected nodes - through a connected network such as the Internet where another - routing protocol is running. To this network, PRoPHET traffic would - look like any other application layer data. Extra care must be taken - in setting up these gateway nodes and their interconnections to make - sure that malicious nodes cannot use them to launch attacks on the - infrastructure of the connected network. In particular, the traffic - generated should not be significantly more than what a single regular - user end host could create on the network. - -7. Implementation Experience - - Currently, two independent implementations of the PRoPHET protocol - exist. The first implementation is written in Java, and has been - optimized to run on the Lego MindStorms platform that has very - limited resources. Due to the resource constraints, some parts of - the protocol have been simplified or omitted, but the implementation - contains all the important mechanisms to ensure proper protocol - operation. The implementation is also highly modular and can be run - on another system with only minor modifications (it has currently - been shown to run on the Lego MindStorms platform and on regular - laptops). The other implementation is written in C++ and runs in the - OmNet++ simulator to enable testing and evaluation of the protocol - and new features. Experience and feedback from the implementors on - early versions of the protocol have been incorporated into the - current version. - - A prototype implementation of the protocol in C++ that targets Linux - systems is currently being implemented and is expected to be - available in June 2006. - -8. Acknowledgements - - We would like to thank Olov Schelen, and Kaustubh S. Phanse for - valuable discussions regarding various aspects of the protocol. - Elwyn Davies has contributed with lots of feedback, both on the - technical details of the the protocol as well as the structure of the - draft. The Hello TLV mechanism is loosely based on Adjacency message - developed for RFC3292. Luka Birsa has provided us with feedback from - - - -Lindgren & Doria Expires September 6, 2006 [Page 43] -=0C -Internet-Draft PRoPHET March 2006 - - - doing two implementations of the protocol based on various - preliminary versions of the draft. His feedback has helped us make - the draft easier to read for an implementor and has improved the - protocol. - -9. References - - [1] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., - Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network - Architecture", Internet Draft draft-irtf-dtnrg-arch-04.txt, - December 2005. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - Internet Draft draft-irtf-dtnrg-bundle-spec-04.txt, - November 2005. - - [3] Vahdat, A. and D. Becker, "Epidemic Routing for Partially - Connected Ad Hoc Networks", Duke University Technical Report CS- - 200006, April 2000. - - [4] Lindgren, A. and K. Phanse, "Evaluation of Queueing Policies and - Forwarding Strategies for Routing in Intermittently Connected - Networks", Proceedings of COMSWARE 2006 , January 2006. - - [5] Small, T. and Z. Haas, "The Shared Wireless Infostation Model - - A New Ad Hoc Networking Paradigm (or Where there is a Whale, - there is a Way)", Proceedings of The Fourth ACM International - Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc - 2003) pp 233-244, June 2003. - - [6] Doria, A., Uden, M., and D. Pandey, "Providing connectivity to - the Saami nomadic community", Proceedings of the 2nd - International Conference on Open Collaborative Design for - Sustainable Innovation (dyd 02), Bangalore, India , - December 2002. - - [7] Pentland, A., Fletcher, R., and A. Hasson, "A Road to Universal - Broadband Connectivity", Proceedings of the 2nd International - Conference on Open Collaborative Design for Sustainable - Innovation (dyd 02), Bangalore, India , December 2002. - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 44] -=0C -Internet-Draft PRoPHET March 2006 - - -Authors' Addresses - - Anders F. Lindgren - Lulea University of Technology - Lulea SE-971 87 - Sweden - - Phone: +46920491489 - Email: dugdale@sm.luth.se - URI: http://www.sm.luth.se/~dugdale - - - Avri Doria - Lulea University of Technology - Lulea SE-971 87 - Sweden - - Phone: - Email: avri@acm.org - URI: http://psg.com/~avri - -Appendix A. PRoPHET Example - - To help grasp the concepts of PRoPHET, an example is provided to give - a understanding of the transitive property of the delivery - predictability, and the basic operation of PRoPHET. In Figure 20, we - revisit the scenario where node A has a message it wants to send to - node D. In the bottom right corner of subfigures a)-c), the delivery - predictability tables for the nodes are shown. Assume that nodes C - and D encounter each other frequently (Figure 20a) ), making the - delivery predictability values they have for each other high. Now - assume that node C also frequently encounters node B (Figure 20b) ). - B and C will get high delivery predictability values for each other, - and the transitive property will also increase the value B has for D - to a medium level. Finally, node B meets node A (Figure 20c) ) that - has a message for node D. Figure 20d) shows the message exchange - between node A and node B. Summary vectors and delivery - predictability information is exchanged, delivery predictabilities - are updated, and node A then realized that P_(b,d) > P_(a,d), and - thus forwards the message for D to node B. - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 45] -=0C -Internet-Draft PRoPHET March 2006 - - - +----------------------------+ +----------------------------+ - | | | | - | C | | D | - | D | | | - | B | | B C | - | | | | - | | | | - | | | | - | | | | - | A* | | A* | - +-------------+--------------+ +-------------+--------------+ - | A | B | C | D | | A | B | C | D | - |B:low |A:low |A:low |A:low | |B:low |A:low |A:low |A:low | - |C:low |C:low |B:low |B:low | |C:low |C:high|B:high |B:low | - |D:low |D:low |D:high |C:high| |D:low |D:med |D:high |C:high| - +-------------+--------------+ +-------------+--------------+ - a) b) - +----------------------------+ A B - | | | | - | D | |Summary vector&delivery pred| - | | |--------------------------->| - | C | |Summary vector&delivery pred| - | | |<---------------------------| - | | | | - | B* | Update delivery predictabilities - | A | | | - | | Packet for D not in SV | - +-------------+--------------+ P(b,d)>P(a,d) | - | A | B | C | D | Thus, send | - |B:low |A:low |A:low |A:low | | | - |C:med |C:high|B:high |B:low | | Packet for D | - |D:low+|D:med |D:high |C:high| |--------------------------->| - +-------------+--------------+ | | - c) d) - - Figure 20: PRoPHET example - - -Appendix B. Neighbor Discovery Example - - This section outlines an example of a simple neighbor discovery - protocol that can be run in-between PRoPHET and underlying layer in - case lower layers do not provide methods for neighbor discovery. It - assumes that the underlying layer supports broadcast messages as - would be the case if a wireless infrastructure was involved. - - Each node needs to maintain a list of its active neighbors. The - operation of the protocol is as follows: - - - -Lindgren & Doria Expires September 6, 2006 [Page 46] -=0C -Internet-Draft PRoPHET March 2006 - - - 1. Every BEACON_INTERVAL milliseconds, the node does a local - broadcast of a beacon that contains its identity and address, as - well as the BEACON_INTERVAL value used by the node. - 2. Upon reception of a beacon, the following can happen: - 1. The sending node is already in the list of active neighbors. - Update its entry in the list with the current time, and the - node's BEACON_INTERVAL if it has changed. - 2. The sending node is not in the list of active neighbors. Add - the node to the list of active neighbors and record the - current time and the node's BEACON_INTERVAL. Notify the - PRoPHET agent that a new neighbor is available ("New - Neighbor", as described in Section 2.3). - 3. If a beacon has not been received from a node in the list of - active neighbors within a time period of NUM_ACCEPTED_LOSSES * - BEACON_INTERVAL (for the BEACON_INTERVAL used by that node), it - should be assumed that this node is no longer a neighbor. The - entry for this node should be removed from the list of active - neighbors, and the PRoPHET agent should be notified that a - neighbor has left ("Neighbor Gone", as described in Section 2.3). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Lindgren & Doria Expires September 6, 2006 [Page 47] -=0C -Internet-Draft PRoPHET March 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Lindgren & Doria Expires September 6, 2006 [Page 48] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/draft-symington-dtnrg-bundle-multi= cast-custodial-00.txt --- a/doc/draft-symington-dtnrg-bundle-multicast-custodial-00.txt Sat Dec 1= 2 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2184 +0,0 @@ - - - -DTN Research Group S. Symington -Internet-Draft R. Durst -Expires: February 2, 2007 K. Scott - The MITRE Corporation - August 1, 2006 - - - Delay-Tolerant Networking Custodial Multicast Extensions - draft-symington-dtnrg-bundle-multicast-custodial-00 - -Status of this Memo - - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on February 2, 2007. - -Copyright Notice - - Copyright (C) The Internet Society (2006). - -Abstract - - This document defines optional extensions to the Bundle Protocol [2] - for supporting the custodial multicast delivery of bundles within a - Delay-Tolerant Network (DTN). The protocol extensions described - herein may be used to support custody transfer and custody-based - reforwarding during the transmission of a bundle from a single source - node to multiple destination nodes. - - - - -Symington, et al. Expires February 2, 2007 [Page 1] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Related Documents . . . . . . . . . . . . . . . . . . . . 4 - 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 - 2. The Basic Problems of Custodial Multicast . . . . . . . . . . 7 - 3. Objectives, Assumptions, and Design Principles . . . . . . . . 8 - 3.1. Custodial Multicast Objectives . . . . . . . . . . . . . . 8 - 3.2. Assumptions and Design Principles for Custodial - Multicast Extensions . . . . . . . . . . . . . . . . . . . 9 - 4. Multicast Routing Protocol Requirements and Desired - Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.1. Only CMC-nodes may be branching points . . . . . . . . . . 12 - 4.2. Multicast delivery paths must be trees . . . . . . . . . . 12 - 4.3. If convergence layer multicast is used, the forwarding - node must know the number of next-hop recipient nodes . . 13 - 4.4. CMC nodes should keep track of de-registration - requests in order to be able to distinguish delayed - de-registrations from routing failures . . . . . . . . . . 14 - 5. Overview of Mechanisms for Supporting Custodial Multicast . . 16 - 5.1. Special Responsibilities of Custodial Nodes . . . . . . . 17 - 5.2. Special Responsibilities of (Non-Custodial) Branching - Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 6. Identifying Bundle Copies . . . . . . . . . . . . . . . . . . 21 - 7. Proxy EID Extension Block . . . . . . . . . . . . . . . . . . 23 - 8. Bundle Protocol Extensions to Support Custody Transfer and - Retransmission for Multicast Bundles . . . . . . . . . . . . . 24 - 8.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.2. Bundle Processing Steps for Custodial Multicast Bundles . 24 - 8.2.1. Bundle Forwarding . . . . . . . . . . . . . . . . . . 24 - 8.2.2. Forwarding Contraindicated . . . . . . . . . . . . . . 27 - 8.2.3. Forwarding Failed . . . . . . . . . . . . . . . . . . 28 - 8.2.4. Bundle Reception . . . . . . . . . . . . . . . . . . . 28 - 8.2.5. Local Bundle Delivery . . . . . . . . . . . . . . . . 28 - 8.2.6. Custody Transfer . . . . . . . . . . . . . . . . . . . 29 - 8.2.7. Custody Acceptance . . . . . . . . . . . . . . . . . . 29 - 8.2.8. Custody Release . . . . . . . . . . . . . . . . . . . 30 - 8.2.9. Custody Transfer Success . . . . . . . . . . . . . . . 30 - 8.2.10. Custody Transfer Failure . . . . . . . . . . . . . . . 31 - 8.2.11. Bundle Deletion . . . . . . . . . . . . . . . . . . . 32 - 8.3. Reception of Custody Signals . . . . . . . . . . . . . . . 33 - 9. Performance Impact . . . . . . . . . . . . . . . . . . . . . . 34 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 37 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 37 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 - - - -Symington, et al. Expires February 2, 2007 [Page 2] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - Intellectual Property and Copyright Statements . . . . . . . . . . 39 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 3] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -1. Introduction - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [1]. - - Multicasting as defined in the DTN context is the ability of a source - bundle node to transmit a bundle to a destination multicast endpoint - without necessarily having to originate a separate bundle for each - bundle node that is registered in that endpoint. The Bundle Protocol - [2] is designed to support delivery of bundles to all types of - endpoints (singleton, anycast, and multicast), but it only supports - custodial delivery (custody transfer and custody-based re-forwarding) - of bundles that are sent to singleton endpoints. Its custodial - delivery mechanisms are not applicable to bundles sent to multicast - endpoints. - - The Bundle Protocol extensions to support custodial multicast that - are described in this document are OPTIONAL for deployment with the - Bundle Protocol. Use of these extensions is also OPTIONAL. Bundle - Protocol implementations that claim to be custodial-multicast-capable - (CMC) MUST support all of the features defined herein, as well as all - of the features defined in the Bundle Protocol [2]. In addition, in - any given network that purports to support custodial multicast - delivery, a multicast routing protocol is also required to set up the - multicast distribution path. The extensions defined in this document - are multicast-routing-protocol-independent in the sense that they are - designed to work with any multicast routing protocol, providing that - the multicast routing protocol meets certain requirements, which are - defined in Section 4. - -1.1. Related Documents - - This document is best read and understood within the context of the - following other DTN documents: - - - The Delay-Tolerant Network Architecture [5] defines the - architecture for delay-tolerant networks, but only briefly - discusses multicasting. - - - The Bundle Protocol Specification [2] defines the format and - processing of the blocks used to implement the basic bundle - protocol. This document does not explicitly discuss DTN - multicast, but it does define two concepts that are important for - supporting multicast: - - the concept of endpoints that contain multiple nodes, all of - which are intended recipients of a bundle, and - - - -Symington, et al. Expires February 2, 2007 [Page 4] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - the concept that a node may both deliver and forward a bundle - and, when forwarding a bundle, may forward it to multiple next- - hop nodes. - - The Bundle Protocol also defines custody transfer procedures that - apply to bundles that are destined for singleton endpoints; these - custody transfer procedures, however, are explicitly stated to be - applicable only to bundles that are destined for singleton - endpoints and, therefore, by implication, not to be applicable to - bundles that are destined for multicast endpoints. - - - Delay-Tolerant Networking Bundle-in-Bundle Encapsulation [3] - defines the format and processing of the Bundle-in-Bundle - Encapsulation Administrative Record, which is used to enable the - transmission of one or more bundles encapsulated in another bundle - as part of that bundle's payload (e.g., one or more multicast - bundles encapsulated in a singleton bundle). - -1.2. Terminology - - Multicast Endpoint - A bundle endpoint that is permitted to contain - multiple nodes and that has as its minimum reception group (see [2]) - all of the nodes registered in that endpoint. - - Branching Point - A bundle's delivery path has a branching point at a - particular node if in the course of delivering the bundle to its - minimum reception set that node either: - - -delivers the bundle at that node and forwards it to at least one - next hop node, or - - forwards the bundle to more than one next hop node. - - A node that is a branching point for a bundle is said to "branch" - that bundle. - - Singleton Bundle - a bundle that has a singleton endpoint ID as its - destination. - - Multicast Bundle - a bundle that has a multicast endpoint ID as its - destination. - - Custodial Multicast Bundle - a Bundle that has a multicast endpoint - ID as its destination and that has its custody transfer requested - flag (in the bundle processing flags field) set to 1. - - Custodial-multicast-capable (CMC) node - a node that implements all - of the features defined in this document, as well as all of the - - - -Symington, et al. Expires February 2, 2007 [Page 5] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - features defined in the Bundle Protocol [2]. - - Non-Custodial-multicast-capable (non-CMC) node - a node that does not - implement all of the features defined in this document and all of the - features defined in the Bundle Protocol [2]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 6] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -2. The Basic Problems of Custodial Multicast - - Custody transfer and retransmission, which are defined for singleton - bundles in the Bundle Protocol [2], are fundamentally complicated - when applied to multicast bundles. Upon receipt of a multicast - bundle, a bundle node may deliver the bundle at that node, forward - the bundle to one or more next-hop nodes, or both. If a node - delivers a bundle and forwards it to at least one next hop node or - forwards the bundle to more than one next hop node, then the bundle's - path is said to have a branching point at that node. Branching - points cause additional copies of a bundle to be created. A node - that takes custody of a multicast bundle and then delivers and/or - forwards it becomes responsible for all copies of that bundle that it - delivers or forwards. In addition, nodes may be branching points for - bundles without being custodians for those bundles, so a node that - takes custody of a bundle is not only responsible for all copies of - that bundle that it delivers or forwards; it also becomes responsible - for all copies of the bundle that may be created as a result of - downstream branching at other, non-custodial, branching nodes, until - the copy is deleted, custody of the copy is transferred to another - node, or the copy is delivered. Fulfilling this responsibility for - all downstream copies is complicated by the fact that the custodian - does not necessarily have any way of knowing whether or how many - times a bundle that it forwards will be branched downstream. - - Therefore, to support custodial delivery of multicast bundles, this - document defines mechanisms to enable a custodian of a multicast - bundle to determine when all downstream copies of a bundle have - either been delivered or have been taken custody of by a downstream - node, and to determine when a specific downstream undelivered bundle - may need to be retransmitted. In addition, for purposes of - conserving bandwidth, it defines a mechanism to enable bundle copies - to be reforwarded selectively, to only those downstream branches of - the delivery path that have not yet received them, rather than being - forwarded indiscriminately to all downstream nodes. - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 7] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -3. Objectives, Assumptions, and Design Principles - -3.1. Custodial Multicast Objectives - - The objectives of the custodial multicast extensions defined in this - document are to increase the likelihood that - - -each custodial multicast bundle that is sent will be delivered to - as many of its destination nodes as possible prior to bundle - expiration and, - - -if a custodial multicast bundle needs to be re-forwarded in the - course of being transmitted from source to destination, the cost - of reforwarding it from the custodian (in terms of the routing - metric in use) will be less than the cost of reforwarding it from - the source node or, ideally, though not necessarily, from any - previous custodian nodes. - - A third objective of custodial multicast delivery, which is not an - objective that is addressed in this document, is to enable delivery - of bundles to a node whose registration request for the multicast - endpoint may be late or delayed. Even though this registration - request had not yet propagated through the network sufficiently to - graft the destination node onto the distribution tree when the bundle - was sent, a custodian of the bundle can forward the bundle toward the - late-registering node when the custodian is notified of its - registration. - - If a bundle has a singleton destination EID, then custodial delivery - enables it to be stored in the network until the destination node - registers to receive it and notification of this registration request - is able to propagate to the custodian (providing the bundle doesn't - expire first) so that the custodian can forward the bundle toward the - destination. Once such a bundle that is sent to a singleton EID - reaches the (single) node that registers with that EID, the bundle - may be deleted at its current custodian because it will not need to - be delivered to any other destination node. If a bundle has a - multicast destination EID, on the other hand, there is no limit to - the number of such registrations that may be received. Custodians of - multicast bundles may store those bundles in the network until they - expire in order to ensure that the bundle will be available for - forwarding to every node that registers late or the registration - request of which is delayed. As pointed out in [7], due to the - unique characteristics of frequent partitioning and consequently - large transfer delays in DTNs, destination endpoint registration - changes during data transfer may be the norm rather than the - exception. - - - - -Symington, et al. Expires February 2, 2007 [Page 8] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - The protocol extensions defined in this document focus only on - defining mechanisms to meet the first two objectives presented above. - They do not address the mechanics of re-forwarding multicast bundles - to late-registering nodes. - -3.2. Assumptions and Design Principles for Custodial Multicast - Extensions - - A node may be a branching point for a bundle without taking custody - of that bundle. It is not feasible to expect or require that every - branching point node will always take custody of a bundle. The - extensions defined in this document, therefore, take into account the - possibility that some branching point nodes may not become custodians - of the custodial multicast bundles that they branch. - - Although we cannot require all branching nodes to become custodians - for bundles that they branch, we do require all branching nodes to - maintain a small amount of additional state for each custodially- - transferred bundle that they branch. Maintaining this state - information enables non-custodial branching nodes to keep track of - the custody status of each copy of the bundles that they branch. - Given that a bundle's custodian has no awareness of the existence of - copies of the bundle that are created at non-custodial branching - nodes downstream of it, the non-custodial branching nodes must act as - "proxy custodian" in the sense that they must keep track of the - custody status of each copy they create and in turn report this - status upstream to the bundle's actual custodian. - - Custodial branching nodes must store a copy of the bundle, re-forward - it if necessary, and maintain custody state per bundle copy that they - branch rather than just per bundle (as currently defined in the - Bundle Protocol). Non-custodial branching nodes are not required to - retain a copy of the bundle or re-forward it, but they are, like - custodial nodes, required to maintain custody state per bundle copy - that they branch (see Section 5 and Section 8.2.1). - - If a node's forwarding information indicates that it must branch a - multicast bundle but it does not have the storage capacity or other - resources necessary to pose as a proxy custodian by maintaining - custody state per copy of the bundle that it branches then the node - must report this difficulty to the previous upstream custodian or - proxy custodian and it must not deliver or forward the bundle as a - custodially transferred bundle. - - Unless a custodian is going to re-forward a bundle when needed, the - custodian cannot be of any use in helping to achieve the two - objectives that we have identified as our objectives for custodial - multicast. Therefore, the extensions we define must include not only - - - -Symington, et al. Expires February 2, 2007 [Page 9] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - the capability to re-forward a multicast bundle when necessary, but - the ability to determine when re-forwarding is necessary. In the - singleton case, a custodian may receive an explicit notification (in - the form of a "Failed" custody signal) or an implicit notification - (in the form of an expired custody timer) that it should retransmit a - bundle. In the singleton case, a custodian may also receive explicit - notification (in the form of a "Succeeded" custody signal) when a - bundle of which it has custody has been either delivered or taken - custody of by another node. When enough time has elapsed, as - measured by the custody timer timing out, during which the custodian - has not received a "Succeeded" custody signal for a bundle, the - custodian may re-forward the bundle. - - In the multicast case, in order for the custodian of a multicast - bundle to know whether or not it needs to re-forward that bundle, the - custodian need not necessarily know the delivery status of each - downstream copy of the bundle. It does, however, need to know - whether or not there is at least one downstream copy of the bundle - that has not yet been delivered or taken custody of. If there is, - and the custody timer for that copy expires, the custodian must re- - forward the bundle copy downstream to at least the next-hop node(s) - with which the expiring timer is associated. A major component of - the extensions that we are defining, therefore, is a mechanism by - which a custodian can be notified when all downstream copies of a - bundle for which it is custodian have either been delivered or taken - custody of. A second component is a mechanism whereby the custodian - can be explicitly notified of an undelivered downstream copy of a - bundle that has been deleted. In our extensions, analogous to the - way that custody signals operate for the singleton case in the Bundle - Protocol, receipt of a "Succeeded" custody signal for all copies of - the bundle that a custodian has branched indicates that all - downstream copies have either been delivered or taken custody of. - Failure to receive a "Succeeded" custody signal before a custody - timer times out indicates that one or more bundle copies associated - with that timer has not yet been delivered or taken custody of (and - thus may need to be retransmitted). Receipt of a "Failed" custody - signal indicates that the referenced bundle copy was deleted before - being delivered or taken custody of (and thus may need to be - retransmitted). - - There is an inherent tradeoff between robustness of delivery and - bandwidth conservation when custody transfer is requested for a - multicast bundle. These extensions give bandwidth conservation - priority over robustness of delivery by default, but local policy may - override this. Unless overridden by local policy that specifically - attempts to adapt the multicast delivery path in response to network - dynamism, custodians and non-custodial branching nodes, by default, - should not forward a multicast bundle copy for which a successful - - - -Symington, et al. Expires February 2, 2007 [Page 10] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - custody signal has already been received. Bundles should only be re- - forwarded to those next-hop nodes that have downstream copies of the - bundle that have not yet been delivered or taken custody of. Because - the multicast delivery path is assumed to be a tree (see Section 4), - if a node receives a bundle of which it has already been or currently - is a custodian, the bundle is assumed to be in an unintentional loop - and should be dropped without sending any concomitant custody signal - to the asserted custodian of the received bundle. - - For a more detailed discussion of the objectives, assumptions, and - design principles underpinning these protocol extensions for - supporting custodial multicast, see [8]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 11] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -4. Multicast Routing Protocol Requirements and Desired Features - - In order for the custodial multicast extensions defined in this - document to work correctly, the multicast routing protocol that is - used to set up the delivery path for custodial multicast bundles must - meet certain requirements, which are discussed in the following - subsections. - -4.1. Only CMC-nodes may be branching points - - As discussed in Section 3.2 and Section 5.2, non-custodial branching - nodes are required to have the capability to maintain state - information per bundle copy that they branch. Because this special - capability is required of all branching nodes, in order for custodial - multicast transfer to work correctly, either: - - -the network used for custodial multicast delivery must consist - only of CMC-nodes, or - - -the multicast routing protocols responsible for delivery path - formation must be capable of distinguishing CMC-nodes from nodes - that implement only the base Bundle Protocol (non-CMC-nodes) and - they must enforce the restriction that only CMC-nodes are - permitted to be branching points. - - If there are nodes that serve as branching points for multicast - bundles that do not have the capabilities defined in this document, - the custody transfer procedures defined in this document will not - work correctly. Therefore, in order to support custodial multicast - in a network that consists of both CMC and non-CMC nodes, the - multicast routing protocols used must enforce the restriction that - only CMC nodes are permitted to be branching points in the delivery - path. In order for multicast routing protocols to be able to - distinguish CMC-nodes from nodes that support only the base Bundle - Protocol, when CMC-nodes register, they must make known their status - as CMC-nodes and this information regarding their status as CMC-nodes - must be propagated along with the registration information among the - nodes that participate in multicast routing. - -4.2. Multicast delivery paths must be trees - - DTN multicast routing protocols are required to operate over trees - rather than meshes. This requirement serves two purposes: - - -the extensions defined herein are based on the principle that a - bundle is only branched when that branching is required to enable - the bundle to reach a destination node. Thus, every copy of the - bundle created as a result of branching is assumed to be destined - - - -Symington, et al. Expires February 2, 2007 [Page 12] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - for a unique destination node. For the extensions to work - efficiently, it cannot be the case that two different copies are - destined for the same destination node. Hence, the delivery path - must be a tree. - - -requiring the multicast delivery path to be a tree facilitates - the detection of unintentional loops, which can be extremely - wasteful of bandwidth when multicast, and especially custodial - multicast, is used. Because the multicast delivery path is - required to be a tree, any bundle that is received a second time - may be assumed either to have been re-forwarded by a custodian or - to be in an unintentional loop. If such a bundle is received by a - node that is or has already been a custodian of the bundle, it can - be assumed to be in an unintentional loop. It may therefore be - safely be dropped and there is no need to send a concomitant - custody signal to its asserted custodian. - -4.3. If convergence layer multicast is used, the forwarding node must - know the number of next-hop recipient nodes - - If DTN multicast is running over an underlying convergence layer - protocol that has inherent best-effort multicast transmission - capabilities (e.g. a Local Area Network) and DTN multicast endpoint - IDs are associated with underlying convergence layer multicast - addresses, a bundle received at a DTN endpoint ID that is bound to an - underlying convergence layer multicast address could in turn be - multicast out toward its multiple destinations using that convergence - layer. Using the best-effort multicast capabilities provided by some - convergence layers, there is no way for the forwarder of such a - multicast bundle to know in advance the expected number of - recipients. Although from the standpoint of the DTN bundle protocol - agent only a single copy of a bundle is being sent on a particular - multicast-capable convergence layer, in effect there are multiple - next-hop nodes that this single copy is intended to reach. When a - best-effort multicast-capable convergence layer is used to distribute - DTN multicast bundles such that the forwarding node does not know the - number of expected next hops that are reachable via the convergence - layer, it is impossible for the bundle's custodian to know if and - when all destinations have received the bundle. - - If unicast forwarding is being used on a given convergence layer, the - receipt of a "Succeeded" custody signal associated with a particular - bundle copy forwarded using that convergence layer means that all - downstream copies of that copy have been either delivered or taken - custody of. If multicast forwarding is being used on a given - convergence layer then, although only a single bundle is being - forwarded, this bundle may have multiple next hops. Therefore, in - order for such a configuration to be able to be used to support - - - -Symington, et al. Expires February 2, 2007 [Page 13] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - custodial multicast, the bundle node that is forwarding the bundle - onto the convergence layer: - - -must be a CMC-node, and - - -must know the number of next-hop nodes that the bundle is - expected to reach using that convergence layer, so that it can - maintain state for this number of copies. - -4.4. CMC nodes should keep track of de-registration requests in order - to be able to distinguish delayed de-registrations from routing - failures - - In the same way that there is a delay between when a node registers - and when that registration propagates through the network to graft - that node onto the distribution tree, there may also be a delay - between when a node de-registers with a multicast EID and when that - de-registration propagates through the network to prune that node - from the distribution tree. As a result, a situation may arise in - which a de-registration request has reached some nodes but not others - such that a bundle could be forwarded by a custodian (which has not - yet received notice of the de-registration request) and later - received at some downstream non-branching node (which has received - the de-registration request) that does not have any next-hop nodes to - which the bundle should be forwarded (because the node that recently - de-registered was the only node downstream of this node that had been - in the multicast endpoint). In this situation, the bundle cannot be - forwarded because there is no known route to its destination. Nor - should it be forwarded, because there is no intended destination - downstream of it. If the node at which this situation occurs has - kept track of the fact that it received a de-registration - notification for the multicast EID in question, it can distinguish - this type of situation from a real routing failure. Instead of - sending a "Failed" custody signal, the node that cannot forward the - bundle because a downstream node has recently de-registered from the - multicast EID should send a "Succeeded" custody signal for this - multicast bundle, because a "Succeeded" custody signal indicates that - there are no remaining copies of the bundle downstream of this node - that need to be either delivered or taken custody of. If the node at - which this situation occurs has not kept track of the de-registration - notifications it has received and so cannot distinguish this - situation from a real routing failure, it will send a "Failed" - custody signal for this multicast bundle to the bundle's current - custodian, and the custodian will re-forward the bundle toward the - node at which the routing failure occurred. Eventually either the - bundle will time out or the de-registration request notification will - propagate to a branching point upstream such that the routing failure - will no longer exist. Hence, having nodes in the multicast - - - -Symington, et al. Expires February 2, 2007 [Page 14] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - distribution tree keep track of de-registration requests is not - required in order for the custodial multicast extensions to work - correctly, but it does eliminate unnecessary custody signal - transmissions and bundle retransmissions. State on de-registration - request notifications received does not have to be maintained - indefinitely at any given node. De-registered endpoint IDs may be - stored with a record of the time at which the de-registration request - notification was received. The de-registered endpoint ID may be - deleted from the state information when enough time has elapsed to - allow the de-registration request to reasonably be assumed to have - propagated through the network. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 15] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -5. Overview of Mechanisms for Supporting Custodial Multicast - - The following are circumstances under which a custodian may want to - re-forward a multicast bundle: - - -The custodian received a "Failed" custody signal for the bundle - from a specific node, in which case it wants to retransmit the - bundle to that node (and, assuming the network is relatively - stable, it may want to conserve bandwidth by encapsulating [3] the - multicast bundle in a singleton bundle for bandwidth-efficient - transmission to the node that originally generated the "Failed" - custody signal; this node can then de-encapsulate the multicast - bundle and forward it further), or - - -One or more of the custodian's custody timers for the bundle - timed out, in which case it wants to re-forward the bundle on (at - least) all downstream branches of the distribution path that are - associated with the expiring timer(s). - - -Notification of a new or delayed registration for a multicast EID - is received. - - The protocol extensions defined in this document do not address the - mechanics of re-forwarding bundles to newly-registering or delayed- - registration nodes. They do, however, enable a custodian to - determine whether a bundle needs to be re-forwarded by ensuring that - the custodian will be able to: - - -receive "Failed" custody signals for arbitrary bundle copies from - nodes downstream in the delivery path - - -be aware of whether or not there exists a downstream copy of that - bundle that has not been delivered or taken custody of when its - custody timer times out. - - Custody status notification is provided to each custodian of a - multicast bundle in the same way that it is provided to each - custodian of a singleton bundle: by having downstream nodes send - either "Succeeded" or "Failed" custody signals to the custodian, as - appropriate. In the multicast case, however, the custodian must keep - track of the custody status of each copy of each bundle it forwards. - When the custodian receives a "Succeeded" custody signal for each of - the copies that it branched, the custodian is assured that every - downstream copy has either been delivered or taken custody of. Until - the custodian receives such a signal for any given copy that it - forwarded, it must assume that there is at least one copy of the - bundle on that copy's branch of the distribution tree that has - neither been delivered nor taken custody of. - - - -Symington, et al. Expires February 2, 2007 [Page 16] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - Although the custodian expects one "Succeeded" custody signal per - bundle copy that it branched, there may be more copies of the bundle - created downstream of it. These copies, however, must be kept track - of by the non-custodial branching nodes that create them. When all - copies created by a non-custodial branching node have either been - delivered or taken custody of, the branching node sends a "Succeeded" - custody signal to report this to the bundle's previous upstream - custodian or branching node, and so forth, until the status of every - copy that the custodian branched is reported to the custodian. There - is no need for the custodian itself to be made aware of every copy of - the bundle that is created downstream of it. To achieve this - "relayed" custody signal transmission, every non-custodial node that - is a branching point for a multicast bundle, upon receipt of that - bundle, takes note of its current custodian and then places its own - EID into the bundle to list itself as custodian for that bundle - before forwarding the bundle (even though it really is not the - custodian of the bundle in the sense that it is not storing a copy of - the bundle in permanent storage, nor does it consider itself - responsible for retransmitting the bundle). In this way, each - branching point node is assured that it will receive any custody - signals that may be generated for the bundle copies that it branches. - - Non-CMC and CMC nodes alike are permitted to originate and deliver - custodial multicast bundles, to register in multicast EIDS, and to - forward custodial multicast bundles to a single next-hop node. As is - made clear in the Bundle Protocol, however, non-CMC nodes, are not - permitted to take custody of multicast bundles. In order for a node - to be able to become a custodian for a multicast bundle, the node - must implement the procedures defined in this specification, which - make it a CMC node. - - In addition, nodes that implement only the base bundle protocol are - not permitted to be branching points in the distribution path for a - custodially-transferred multicast bundle. In order for a node to be - able to be a branching point in the distribution path of a - custodially-transferred multicast bundle, the node must be a CMC - node. The following sub-sections discuss the specific - responsibilities that CMC-nodes must fulfill in order to act as - custodians or branching points in support of the delivery of - custodial multicast bundles. - -5.1. Special Responsibilities of Custodial Nodes - - When a CMC-node becomes custodian of a multicast bundle, that - custodial node takes on responsibilities similar to those that are - taken on by a custodian of a singleton bundle. The main difference, - however, is that the custodian of a multicast bundle must maintain - custody-related state information per copy of that bundle that it - - - -Symington, et al. Expires February 2, 2007 [Page 17] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - branches rather than just per bundle. Specifically, the custodian of - a given multicast bundle: - - -MUST " maintain a list of the copies of that bundle that it has - branched along with the EID/convergence layer to which each copy - was delivered or forwarded. - - -MUST keep track of which of these copies for which it has - received a "Succeeded" custody signal. - - -MUST retain the multicast bundle that it takes custody of--in - persistent storage if possible-- until the bundle expires - (assuming that accommodating late- or delayed-registering - destination nodes is not a concern) or until it receives a - "Succeeded" custody signal for each of the copies of the bundle - that it branched (which indicates that all downstream copies of - that bundle have either been delivered or taken custody of). - - -MUST maintain at least one retransmission timer for the bundle; - possibly one timer per copy it has branched. - - -SHOULD retransmit the copy (or copies) of the bundle - corresponding to the retransmission timer when the retransmission - timer expires. - - -SHOULD retransmit a copy of the bundle referred to by a received - "Failed" custody signal, perhaps encapsulated (see [3]) in a - unicast bundle sent to the "Failed" signal's source. - - -MUST destroy a retransmission timer when "Succeeded" custody - signals for all bundle copies associated with that timer have been - received - - -MUST delete a multicast bundle and all its associated custodial - state information when the bundle expires - - -MUST maintain a list of unexpired bundles for which it has ever - been a custodian. - -5.2. Special Responsibilities of (Non-Custodial) Branching Nodes - - If a node is a branching point for a custodial multicast bundle but - it does not take custody of that custodial multicast bundle, the node - must pose as a proxy custodian by inserting its own EID into the - custodian field of the bundle so that it will receive custody signals - (if sent) for all copies of the bundle that it branches. In - particular, in order to support custodial delivery of a multicast - bundle, a non-custodial branching node: - - - -Symington, et al. Expires February 2, 2007 [Page 18] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - -MUST maintain a list of the copies of that bundle that it has - branched along with the EID/convergence layer to which each copy - was delivered or forwarded. - - -MUST keep track of the "Succeeded" custody signals received. - - -MUST notify the appropriate upstream node (e.g. the node that had - been listed as the bundle's custodian when the bundle was - received, which is either the bundle's "real" custodian or the - most recent proxy custodian that may in turn pass the signal - upstream until it eventually reaches its real custodian) when a - "Succeeded" custody signal is received for all of the copies of - the bundle that it branched (which indicates that all downstream - copies of that bundle have either been delivered or taken custody - of). - - -If custody transfer failure is reported for any of the downstream - copies that the bundle branched, it MUST generate a replacement - "Failed" custody signal and send it to the appropriate upstream - node, inserting a Proxy EID extension block (see Section 7) into - this bundle (if there is not one in there already) that identifies - the endpoint of the source of the original "Failed" custody - signal. - - -Upon receipt of a custodial multicast bundle, determine not only - to which next-hop nodes the bundle should be forwarded in order to - reach all of the nodes in its multicast endpoint, but also from - which of these next-hop nodes (if any) the branching node has - already received a "Succeeded" custody signal for this bundle. By - default, but subject to network stability conditions and local - policy, the bundle SHOULD be forwarded to only those next-hop - nodes for which a "Succeeded" custody signal for the bundle has - not been received. - - -If the node does not have sufficient resources to maintain the - state information required of it in order for it to branch a - particular multicast bundle, it MUST send a "Failed" custody - signal to the appropriate upstream node. It MAY (subject to - policy) reset the custody transfer requested bit and branch the - bundle. If the branching node resets the custody transfer - requested bit and branches the bundle, the reason code in the - "Failed" custody signal MUST be the new reason code, "Bundle - Forwarded Non-Custodially". (Note that this new reason code must - be defined in the Bundle Protocol Specification.) If the - branching node does not reset the custody transfer requested bit - and branch the bundle, the reason code in the "Failed" custody - signal MUST be "Depleted Storage". In addition, if the node's - resource depletion is expected to last a while, the node MAY - - - -Symington, et al. Expires February 2, 2007 [Page 19] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - change the way it represents itself to the multicast routing - protocol (subject to the specifics of that protocol), thereby - actively seeking to not be a branching point in any multicast - distribution paths. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 20] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -6. Identifying Bundle Copies - - The node responsibilities described above require branching nodes to - be able to distinguish the various copies of a given bundle that they - deliver or forward from each other, so that when a custody signal is - received, the receiving node can determine not only which bundle it - refers to, but which particular copy of the bundle that was branched - it refers to. Furthermore, in order to perform bandwidth-efficient - retransmissions that target only those next-hop nodes that still have - downstream copies of the bundle for which "Succeeded" custody signals - have not been received, the node receiving a custody signal must be - able to determine to which next-hop node the particular copy of the - bundle referred to by that signal had been forwarded. Because we - cannot rely on the fact that the custody signal for a given bundle - copy will always be returned via the same route along which the - bundle was forwarded, the requirement that branching nodes be able to - distinguish among bundle copies requires the branching node to - somehow mark each bundle copy uniquely. This marking could be - accomplished using a to-be-defined bundle extension header, but such - a technique would require each branching node to add such a header, - thereby adding to the size of the bundle. It would also require that - procedures be defined for determining when these headers could be - deleted from the bundle, and in general it would complicate the - protocol. Instead, we recommend that a certain portion of the EID - that the branching node inserts into the bundle's custodian field be - used as a copy identifier. For example, suppose a node is forwarding - a multicast bundle to two different next-hop nodes. This node could - be registered in two singleton EIDs, e.g., NodeA:1 and NodeA:2 and it - can be uniquely identified by only the scheme name (e.g., "NodeA:") - portion the EID [9]. The node places EID NodeA:1 in the current - custodian field of the bundle that it forwards to the first next-hop - node and EID NodeA:2 in the current custodian field of the bundle - that it forwards to the second next-hop node. When it receives a - custody signal back for this bundle, it can use the EID to which the - signal was sent to determine to which copy of the bundle the signal - refers. This technique of distinguishing the multicast bundle copies - from each other is conserving of both bandwidth and protocol - complexity. Ideally, it would be defined as part of the multicast - EID naming scheme and integrated with the routing protocols to the - extent that only one registration per node would have to be - propagated because only a certain portion of the EID would be used to - route to each node. - - Note, however, that as topology changes, new EIDS would need to be - created to accommodate newly-discovered/encountered neighbors, and - old EIDs would not be able to be recovered until after the latest - expiration time of any bundle containing that EID. Hence, branching - nodes that use this technique to distinguish among bundle copies - - - -Symington, et al. Expires February 2, 2007 [Page 21] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - would also have to keep track of the largest expiration time of the - bundles associated with each next-hop EID. - - Note also that depending on the type of convergence layer being used - to forward the bundle copy, the bundle copy may no longer be - identified uniquely when it is received at its next-hop node. If a - copy is forwarded on a unicast convergence layer, then it is expected - to be received at exactly one next-hop node, and the EID placed in - the current custodian field, for example, can be used to identify it - uniquely both when it is forwarded and when it is received. If a - copy is forwarded over a multicast convergence layer, however, then - the EID that is placed in the current custodian field is only - guaranteed to identify the copy uniquely when the copy is forwarded; - there is no guarantee that this copy will still be uniquely - identified by that current custodian EID when it is received, because - it may be received at multiple next-hop nodes and thereby become - several different copies, all of which have the same EID in the - current custodian field. Therefore, if a custodial multicast bundle - is forwarded over a multicast convergence layer, the forwarding node - must know the number of next-hop nodes to which it is destined (as - discussed in Section 4.3). The EID placed in the current custodial - field will be the same in each copy of the bundle received at these - next-hop nodes. Therefore, for purposes of keeping track of - "Succeeded" custody signals received, the forwarding node must expect - the appropriate number of custody signals referring to bundles with - this particular current custodian EID. For purposes of - retransmission as a result of the custody timer associated with these - copies timing out or as a result of the receipt of a "Failed" custody - signal associated with one of these copies, a copy re-forwarded on - the multicast convergence layer will reach all next-hop nodes that - are reachable via that convergence layer and will not be targeted to - reach any specific one of these next-hop nodes in particular. - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 22] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -7. Proxy EID Extension Block - - This section defines the format of the Proxy EID Extension Block that - a proxy custodian inserts into a "Failed" custody signal to inform - the real custodian that eventually receives the "Failed" signal (or a - replacement of the "Failed" signal) the endpoint ID of the node that - was originally the source of the "Failed" signal. For more - discussion of when this block is inserted into a bundle containing a - "Failed" custody signal and how it is processed, see Section 8.2.10. - - The Proxy EID Extension Block uses the Canonical Bundle Block Format - as defined in the Bundle Protocol [2]. That is, it is comprised of - the following elements: - - -Block-type code (one byte) - defined as in all bundle protocol - blocks except the primary bundle block (as described in the Bundle - Protocol). The block type code for the Proxy EID Extension Block - is 0x06 - - -Block processing control flags (one byte) - defined as in all - bundle protocol blocks except the primary bundle block (as - described in the Bundle Protocol). In order for custodial - multicast transfer to be supported correctly in a network that - consists of a mixture of CMC-nodes and non-CMC-nodes, the - following block processing control flags MUST NOT be set: - - -Discard block if it can't be processed. - - -Discard bundle if block can't be processed. - - -Block data length (SDNV) - defined as in all bundle protocol - blocks except the primary bundle block. SDNV encoding is - described in the bundle protocol. - - -Block-type-specific data field as follows: - - -Original Source EID - Contains the endpoint ID of the node - that originally generated the "Failed" custody signal. - - The Structure of a Proxy EID Extension Block is as follows: - - Proxy EID Extension Block Format: - +-----+------+-------+----------------+ - |Type |Flags |Length |Original Source | - | | | | Endpoint ID | - +-----+------+-------+----------------+ - - Figure 1 - - - -Symington, et al. Expires February 2, 2007 [Page 23] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -8. Bundle Protocol Extensions to Support Custody Transfer and - Retransmission for Multicast Bundles - - The Bundle Protocol defines custody transfer and retransmission only - for singleton bundles. Nodes that implement only the bundle protocol - are not capable of generally supporting the custody transfer and - retransmission of multicast bundles. They are only capable of - supporting the custodial delivery of multicast bundles if they serve - neither as custodians nor as branching points in the delivery path. - The sections below define the custody transfer and retransmission - capabilities that a node must have in order to be CMC and to - therefore be capable of supporting custodial transfer and - retransmission for multicast bundles regardless of where that node is - located in the delivery path. - - All nodes that are going to either take custody of a multicast bundle - or serve as a branching point of a multicast bundle must implement - not only the Bundle Protocol but also the following extensions to the - Bundle Protocol in order to be able to support custodial multicast. - Nodes that are neither custodians nor branching points may - participate in the delivery of custodial multicast bundles without - implementing these extensions. If custodial multicast is to be - supported in a network that consists of both CMC nodes and non-CMC - nodes, the multicast routing protocol is required to build the - distribution path with only CMC nodes as branching points. - -8.1. Definitions - - Custody - Custody of a bundle whose destination is a multicast - endpoint is released when notification is received for each copy of - the bundle that was delivered or forwarded by the custodian that some - other node has accepted custody of the copy, the copy has been - delivered at some destination node, or the bundle has been explicitly - deleted for some reason, such as lifetime expiration. - -8.2. Bundle Processing Steps for Custodial Multicast Bundles - - The specific steps for processing a custodial multicast bundle at - each node are defined as follows. - -8.2.1. Bundle Forwarding - - This section augments section 4.4 of the Bundle Protocol [2]. It - defines those steps for forwarding bundles that are specific to - custodial multicast bundles. - - If the bundle will be forwarded to more than one next-hop node and - the forwarding node has not accepted custody of the bundle, then the - - - -Symington, et al. Expires February 2, 2007 [Page 24] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - node MUST determine if it has sufficient resources to serve as a - branching point for the bundle. If it cannot serve as a branching - point, the node MUST send a "Failed" custody signal to the upstream - node that is listed as the bundle's custodian (which is either the - "real custodian" or the most recent proxy custodian that will in turn - pass the signal upstream until it eventually reaches the real - custodian). It may also (subject to policy) reset the custody - transfer requested bit and deliver and/or forward the bundle. If the - branching node is delivering or forwarding the bundle (non- - custodially), the reason code in the "Failed" custody signal must be - the new reason code, "Bundle Forwarded Non-Custodially". If the - branching node is not delivering or forwarding the bundle, the reason - code in the "Failed" custody signal must be "Depleted Storage". - - If the node does have sufficient resources to enable it to serve as a - non-custodial branching point, then: - - -The node must note the endpoint ID of the bundle's current - custodian and store it with the custodial state information - associated with the bundle. - - -The node must change the current custodian endpoint ID in the - bundle's primary header to the endpoint ID of one of the singleton - endpoints in which the node is registered. In order to be able to - identify each copy uniquely and associate each copy of the bundle - with the next-hop node to which it will be delivered or forwarded, - the node may use a separate custodian endpoint ID for each copy of - the bundle that it delivers or forwards. Alternatively, it may - mark the copy in some other as-yet-undefined way. (Note that if - the node is forwarding a copy on a multicast convergence layer and - this copy is expected to reach multiple next-hop endpoints, each - of the copies received at each of these next-hop nodes will have - the same custodian EID.) - - -The node must also keep track of whether the bundle is being - delivered and each of the copies that is being forwarded (both - explicit copies and copies that may be engendered by the use of a - multicast convergence layer), along with whether or not a - "Succeeded" custody signal has been received corresponding to each - of these copies. (If a copy is being forwarded on a unicast - convergence layer, a single custody signal related to that copy is - expected. If a copy is forwarded on a multicast convergence - layer, n custody signals associated with that copy are expected, - where n is the number of next-hop nodes reachable via that - convergence layer in the delivery tree.) - - In all, the custodial state information that a non-custodial - branching point node is required to maintain for each multicast - - - -Symington, et al. Expires February 2, 2007 [Page 25] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - bundle for which it is a branching point consists of: - - -an indication of whether or not the bundle was delivered at this - node, - - -a list of the next-hop EIDs to which the bundle was forwarded - (including the number of next-hop nodes associated with each EID - for those next-hop EIDs that are reachable via multicast - convergence layers) - - -a list of the next-hop nodes for which a corresponding - "Succeeded" custody signal has been received, and - - -the endpoint ID that was in the current custodian field of the - bundle when it was received. - - -the largest expiration time of all bundles associated with each - next-hop EID (to ensure uniqueness when recovering custodian EID - values to be used to distinguish among bundle copies). - - This custodial state information must be maintained for each branched - bundle until the bundle expires or until the node itself sends a - "Succeeded" custody signal for the bundle to the endpoint ID that was - in the current custodian field of the bundle when it was received, at - which time the information may be deleted. - - Note that even though the branching node is not becoming a true - custodian for a given multicast bundle, it is inserting its own - endpoint ID into the custodian field before forwarding the bundle, so - that it may receive either a "Succeeded" or a "Failed" custody signal - for each copy of the bundle that it forwards. If a node that is not - the custodian of the multicast bundle receives a "Succeeded" custody - signal, this MUST be noted in the custodial state information for the - bundle, relative to the next-hop branch from which the custody signal - was received. - - The processing steps to be taken next may be determined by policy, - which would be influenced by network stability characteristics and - would involve the tradeoff between bandwidth conservation versus - robustness of delivery. In the absence of a policy to the contrary, - custodial multicast is assumed to favor bandwidth conservation over - robustness of delivery. So by default, when a bundle is received, - the node must consult its custodial state information to determine - for which of the next-hop endpoints to which it should be forwarded, - if any, the node has already received a "Succeeded" custody signal - for the bundle. If the bundle has already been delivered at this - node and a "Succeeded" custody signal received back confirming this - delivery, the bundle should not be delivered again. Similarly, the - - - -Symington, et al. Expires February 2, 2007 [Page 26] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - bundle should not be re-forwarded to any next-hop endpoints for which - all expected "succeed" custody signals have already been received for - this bundle, because the prior receipt of either of these signals - indicates that at some previous time there were no longer any copies - of the bundle downstream of that next-hop endpoint that needed to be - either delivered or have their custody transferred. If a policy to - the contrary is in place that favors robustness of delivery over - bandwidth conservation, then when a bundle is received, it should be - forwarded out to all next-hop endpoints, even if it has previously - been forwarded to some of those endpoints and "Succeeded" custody - signals corresponding to one or more of those endpoints have been - received back. - -8.2.2. Forwarding Contraindicated - - This section augments section 4.4.1 of the Bundle Protocol [2]. It - defines the procedures for handling a forwarding contraindication for - a bundle whose destination is a multicast endpoint. - - As described in [7], there is a delay, which in a DTN could - potentially be substantial, between when a node registers with a - multicast EID and when that registration propagates fully throughout - the network. (Although [7] discusses this potentially substantial - delay in terms of multicast EIDs, it exists relative to registration - requests for singleton EIDs as well.) Analogously, there may also be - a substantial delay between when a node de-registers with a - (multicast or singleton) EID and when that de-registration propagates - fully throughout the network. As a result, it might not be uncommon - for a situation to arise in which a de-registration request has - reached some nodes but not others such that a bundle could be - forwarded by a custodian (which has not yet received notice of the - de-registration request) and later received at some downstream node - (which has received the de-registration request) that does not have - any next-hop nodes to which the bundle should be forwarded (because - the node that recently de-registered was the only node downstream of - this node that had been in the multicast endpoint). In this - situation, forwarding of the bundle is determined to be - contraindicated because of the "No known route to destination from - here" reason listed in Table 5 of the Bundle Protocol specification - [2]. According to the Bundle Protocol specification, the bundle - protocol agent must determine whether or not to declare a failure in - forwarding in this case. - - If the bundle protocol agent at which this situation occurs has - recorded the fact that it received a deregistration request - notification for the EID in question, it can distinguish this - forwarding contraindication from a forwarding failure. Instead of - declaring a forwarding failure, the bundle protocol agent should send - - - -Symington, et al. Expires February 2, 2007 [Page 27] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - a "Succeeded" custody signal for this multicast bundle. A - "Succeeded" custody signal indicates that there are no remaining - copies of the bundle downstream of this node that need to be either - delivered or taken custody of. In order to be able to distinguish - this type of forwarding contraindication from a forwarding error, - bundle protocol agents should keep track of de-registration request - notifications received in addition to registration request - notifications received. - - If the bundle protocol agent at which this situation occurs is not - recording the de-registration request notifications it receives, it - will not be able to distinguish this situation in which forwarding is - contraindicated because a downstream node has recently de-registered - from the bundle's destination endpoint from a real forwarding - failure. Hence, it will declare a forwarding failure. - -8.2.3. Forwarding Failed - - This section augments section 4.4.2 of the Bundle Protocol [2]. It - defines the procedures for handling forwarding failure for a bundle - whose destination is a multicast endpoint. - - Procedures for handling failure of custody transfer for a custodial - multicast bundle are the same as those for a singleton bundle: the - bundle protocol agent MUST generate a "Failed" custody signal for the - bundle, destined for the bundle's current custodian; the custody - signal MUST contain a reason code corresponding to the reason for - which forwarding was determined to be contraindicated. - -8.2.4. Bundle Reception - - This section augments section 4.6 of the Bundle Protocol [2]. It - defines the procedures for handling redundancy of custody transfer - for a bundle whose destination is a multicast endpoint. - - step 1: When a custodial multicast bundle is received, if the bundle - has the same source EID, creation timestamp, and fragment offset as a - bundle that the receiving node is currently or has previously been - custodian of, then by default the bundle's "Dispatch pending" - retention constraint SHOULD be removed and the node SHOULD NOT send a - "Succeeded" custody signal for this bundle. - -8.2.5. Local Bundle Delivery - - This section augments section 4.7 of the Bundle Protocol [2]. It - defines the procedures for reporting custodial delivery for a bundle - whose destination is a multicast endpoint. - - - - -Symington, et al. Expires February 2, 2007 [Page 28] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - As soon as the bundle has been delivered, the bundle protocol agent - must report custodial delivery for multicast bundles as it does for - singleton bundles, namely, by generating a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - -8.2.6. Custody Transfer - - This section augments section 4.10 of the Bundle Protocol [2]. It - defines the conditions under which a node may accept custody of a - bundle whose destination is a multicast endpoint. - - As with singleton bundles, the decision as to whether or not to - accept custody of a bundle is an implementation matter; however, if - the bundle protocol agent has committed to accepting custody of the - bundle as described in step 1 of section 4.2 ("Bundle Transmission") - of the Bundle Protocol, then custody must be accepted. If the bundle - protocol agent elects to accept custody of the bundle, then it must - follow the custody acceptance procedure defined in Section 8.2.7 - -8.2.7. Custody Acceptance - - This section augments section 4.10.1 of the Bundle Protocol [2]. It - defines the procedures for acceptance of custody of a bundle whose - destination is a multicast endpoint. - - The retention constraint "Custody Accepted" must be added to the - bundle. - - If the "request custody acceptance reporting" flag in the bundle's - class of service field is set to 1, this flag MAY be ignored. - - The bundle protocol agent must generate a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - - The bundle protocol agent must assert the new current custodian for - the bundle. It does so by changing the current custodian endpoint ID - in the bundle's primary header to the endpoint ID of one of the - singleton endpoints in which the node is registered. - - The bundle protocol agent must establish and maintain state - information to keep track of each of the copies of this bundle that - it is either delivering or forwarding, the EIDs to which they are - being delivered or forwarded, the number of next-hop nodes expected - to be reached at each EID, and whether or not a "Succeeded" custody - signal has been received corresponding to each of these copies. - - The bundle protocol agent MAY set one custody transfer countdown - timer per bundle or it MAY set one custody transfer countdown timer - - - -Symington, et al. Expires February 2, 2007 [Page 29] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - per one or more copies of this bundle that it is branching; upon - expiration of one or more of these timers prior to expiration of the - bundle itself and prior to custody transfer success for the - associated copy (or copies) of the bundle, the custody transfer - failure procedure must be followed for that copy (or those copies) of - the bundle. The manner in which the countdown interval for such - timers is determined is an implementation matter. - - The bundle SHOULD be retained in persistent storage if possible. - -8.2.8. Custody Release - - This section augments section 4.10.2 of the Bundle Protocol [2]. It - defines the procedures for release of custody of a bundle whose - destination is a multicast endpoint. - - As with singleton bundles, when custody of a multicast bundle is - released, the "Custody accepted" retention constraint must be removed - from the bundle and all custody transfer timers and other state - information that have been established for this bundle, except for - the fact that the node has been a custodian of this bundle, must be - destroyed. - -8.2.9. Custody Transfer Success - - This section augments section 4.11 of the Bundle Protocol [2]. It - defines the procedures for determining custody transfer success for a - bundle whose destination is a multicast endpoint. - - Upon receipt of a "Succeeded" custody signal the receiving node MUST - note in its custodial state information for this bundle the receipt - of this signal in conjunction with the associated copy of the bundle - that the node had branched, because the receipt of this signal means - that there are no downstream copies of that copy of the bundle that - still need to be either delivered or have their custody transferred. - When a node has noted in its custodial state information for a given - bundle that such successful notification has been received for every - copy of that bundle that the node branched, meaning that there are no - downstream copies of any copy of the bundle that remain to be - delivered or taken custody of, then the node MUST check its custodial - state information for the referenced bundle to determine whether or - not it is in fact the "real" custodian for that bundle or whether it - is just a proxy custodian. - - If the node is the real custodian of the bundle then custody of the - bundle must be released as described in Section 8.2.8. - - If the node is a proxy custodian of the bundle, then the node MUST - - - -Symington, et al. Expires February 2, 2007 [Page 30] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - generate a "Succeeded" custody signal for the bundle, destined for - the node that it had noted in its custodial state information as - being the bundle's current custodian when the bundle was received. - It MAY destroy all custodial state information for the bundle except - for the fact that it has been a custodian for the bundle. (The node - may want to retain this custodial state information until the bundle - expires so that if the node receives the bundle again it will know - exactly to which next-hop nodes it was forwarded, assuming this - information is useful for efficiently transmitting bundles to late- - joining nodes.) - -8.2.10. Custody Transfer Failure - - This section augments section 4.12 of the Bundle Protocol [2]. It - defines the procedures for determining custody transfer failure for a - copy of a bundle whose destination is a multicast endpoint. - - Custody transfer for a multicast bundle copy is determined to have - failed at a custodial node when either (a) that node's custody - transfer timer that is associated with that copy of the bundle (if - any) expires or (b) a "Failed" custody signal for the bundle copy is - received at that node. Only custodial nodes have custody transfer - timers for bundles; non-custodial branching nodes do not. Both non- - custodial branching nodes and custodial nodes, however, may receive - "Failed" custody signals. - - Upon receipt of a "Failed" custody signal, the receiving node must - check its custodial state information for the referenced bundle copy - to determine whether or not it is in fact the "real" custodian for - that bundle copy or whether it is just a proxy custodian for that - bundle copy. - - If the receiving node is a proxy custodian of the bundle, then it - must generate a "Failed" custody signal for the bundle destined for - the node that it had noted in its custodial state information as - being the referenced bundle's current custodian when the bundle was - received. The "Failed" custody signal that is generated must be - identical to the "Failed" custody signal that was received, minus any - hop-by-hop headers that are not designed to remain in the bundle for - longer than one hop, and also with the source and destination EIDs - modified as follows: - - -the node must insert its own EID as the "Failed" custody signal's - source EID - - -the node must insert the EID of the node that it had noted in its - custodial state information as being the referenced bundle's - current custodian when the bundle was received as the "Failed" - - - -Symington, et al. Expires February 2, 2007 [Page 31] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - custody signal's destination EID. - - If the "Failed" custody signal that was received included a Proxy EID - extension block, the "Failed" custody signal that is generated must - also include this extension block. If the "Failed" custody signal - that was received did not include a Proxy EID extension block, then - the node must insert one before sending the "Failed" custody signal. - The EID that the node inserts into the Proxy EID block must be the - EID that was listed as the source node in the "Failed" custody signal - that was received. - - If the receiving node is the real custodian of the bundle copy then, - as noted above, custody transfer of the referenced bundle copy is - determined to have failed. If the "Failed" custody signal contains a - Proxy EID extension block, then the EID of the node that originally - generated the "Failed" custody signal is identified in the Proxy EID - extension block; otherwise, it is identified in the Source EID field - of the bundle containing the "Failed" custody signal. - - Upon determination of a custody transfer failure for a particular - multicast bundle copy, the action taken by the custodian depends on - the nature of the failure: - - -If custody transfer failure is inferred from expiration of a - custody transfer timer or is asserted by a "Failed" custody signal - with the "Depleted storage" or "No timely contact with next node - on route" reason code, the bundle protocol agent SHOULD retransmit - the bundle. It may re-forward the bundle to all next hop nodes - appropriate for reaching nodes in the multicast endpoint, it may - re-forward the bundle only to the next hop node(s) to which the - copy of the bundle referenced in the "Failed" custody signal or - associated with the expired timer had been forwarded, or it may - encapsulate the multicast bundle in a singleton bundle for - bandwidth-efficient transmission to the node that originally - generated the "Failed" custody signal (See [3]). - - -If custody transfer failure is asserted by a "Failed" custody - signal with the "Redundant Reception", "Destination EID - unintelligible", "Header unintelligible", or "No known route to - destination from here" reason code, the node SHOULD NOT retransmit - the bundle. - -8.2.11. Bundle Deletion - - This section augments section 4.13 of the Bundle Protocol [2]. It - defines the steps in deleting a custodial bundle whose destination is - a multicast endpoint. - - - - -Symington, et al. Expires February 2, 2007 [Page 32] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - - If the retention constraint "Custody accepted" currently prevents - this bundle from being discarded, then: - - -Custody of the node is released as described in Section 8.2.8 - - -A bundle deletion status report citing the reason for deletion - must be generated, destined for the bundle's report-to-endpoint - ID. - - All custodial state information being stored for this bundle MUST be - destroyed. - -8.3. Reception of Custody Signals - - This section augments section 5.3 of the Bundle Protocol [2]. It - defines the procedures that must be followed when custody signals for - multicast bundles are received. - - For each received custody signal for a multicast bundle that has the - Custody Transfer Succeeded flag set to 1, the administrative element - of the application agent must direct the bundle protocol agent to - follow the custody transfer success procedure in Section 8.2.9. - - For each received custody signal for a multicast bundle that has the - Custody Transfer Succeeded flag set to 0, the administrative element - of the application agent must direct the bundle protocol agent to - follow the custody transfer failure procedure in Section 8.2.10. - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 33] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -9. Performance Impact - - The mechanisms defined in this document attempt to conserve network - bandwidth and minimize the complexity of enhancements to the Bundle - Protocol. They increase the amount of state that will need to be - maintained at those bundle nodes that support these mechanisms. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 34] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -10. Security Considerations - - Although there are two documents that pertain to providing security - within DTN [4], [6], both of these documents address the security of - the Bundle Protocol when used to transmit bundles from a single - source to a single destination. They do not address the security of - multicast delivery within the bundle protocol. Therefore, how to - extend the Bundle Security Protocol to provide end-to-end protection - for bundles that are sent from a single source to multiple - destinations is yet to be determined. The use of the Bundle - Authentication Block (BAB) to provide hop-by-hop security protections - for bundles is expected to remain largely unchanged when applied - protecting multicast delivery. The Confidentiality Block (CB) and - the Payload Security Block (PSB), however, because they provide end- - to-end security, would be expected to require adaptation to provide - protection between a single source at one end of the transmission and - multiple destinations at the other end. - - This document does not consider the security aspects of enabling or - preventing a node from registering or de-registering with a - particular multicast endpoint ID, and thereby joining and leaving a - particular multicast group, although we acknowledge that security - considerations regarding joining and leaving groups are present and - significant. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 35] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -11. IANA Considerations - - None at this time. If the bundle protocol becomes a standards track - protocol, then we may want to consider having IANA establish a - register of header types. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 36] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -12. References - -12.1. Normative References - - [1] Bradner, S. and J. Reynolds, "Key words for use in RFCs to - Indicate Requirement Levels", RFC 2119, October 1997. - - [2] Scott, K. and S. Burleigh, "Bundle Protocol Specification", - draft-irtf-dtnrg-bundle-spec-05.txt, work-in-progress, - April 2006. - - [3] Symington, S., Durst, R., and K. Scott, "Delay-Tolerant - Networking Bundle-in-Bundle Encapsulation", - draft-irtf-dtnrg-bundle-encapsulation-00.txt, work-in-progress, - July 2006. - - [4] Symington, S., Farrell, S., and H. Weiss, "Bundle Security - Protocol Specification", - draft-irtf-dtnrg-bundle-security-01.txt, work-in-progress, - March 2006. - -12.2. Informative References - - [5] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., - Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Network - Architecture", draft-irtf-dtnrg-arch-05.txt, work-in-progress, - March 2006. - - [6] Farrell, S., Symington, S., and H. Weiss, "Delay-Tolerant - Network Security Overview", - draft-irtf-dtnrg-sec-overview-01.txt, work-in-progress, - March 2006. - - [7] Zhao, W., Ammar, M., and E. Zegura, "Multicasting in Delay - Tolerant Networks: Semantic Models and Routing Algorithms", - August 2005. - - [8] Symington, S., Durst, R., and K. Scott, "Custodial Multicast in - Delay Tolerant Networks", to be submitted for presentation at - the IEEE Consumer Communications and Networking Conference, - January 2007. - - [9] Burners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, - January 2005. - - - - - - -Symington, et al. Expires February 2, 2007 [Page 37] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -Authors' Addresses - - Susan Flynn Symington - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7209 - Email: susan@mitre.org - URI: http://mitre.org/ - - - Robert C. Durst - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-7535 - Email: durst@mitre.org - URI: http://mitre.org/ - - - Keith L. Scott - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 22102 - US - - Phone: +1 (703) 983-6547 - Email: kscott@mitre.org - URI: http://mitre.org/ - - - - - - - - - - - - - - - - - - -Symington, et al. Expires February 2, 2007 [Page 38] -=0C -Internet-Draft DTN Custodial Multicast Extensions August 2006 - - -Intellectual Property Statement - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - -Disclaimer of Validity - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - - -Copyright Statement - - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. - - -Acknowledgment - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - -Symington, et al. Expires February 2, 2007 [Page 39] -=0C diff -r 8b0d483af1e2 -r e62055127255 doc/external-router-interface.html --- a/doc/external-router-interface.html Sat Dec 12 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,255 +0,0 @@ - - - DTN External Router Interface

DTN External Router Interface

DRAFT

Ap= proved for Public Release; Distribution Unlimited. Case - Number: 06-1215

Copyright © = 2006 The MITRE Corporation. All rights reserved.

Revision Histor= y
Revision 0.90= 11.13.06
Table of Contents

Overview
Interface Operation
Protocol Elements
Rendezvous
Links and Contacts
Routes
Bundles
Peer Router Communication
Failure Recovery
A. New Configura= tion Directives
B. Interface Design FAQ

Overview

A new implementation architecture is under development that promises - to ease the task of adding new capabilities to DTN. Using generic exte= rnal - interfaces, third-party developers will be able to implement plug-in - modules without having to rewrite or understand the internal workings = of - the DTN2 reference implementation (RI). Plug-in modules are stand-alon= e - processes designed to work in collaboration with DTN. In the longer te= rm, - this effort provides the basis for extending commercial off-the-shelf - (COTS) DTN implementations with domain specific capabilities.

Th= e External Router Interface, documented here, is the first DTN - external interface designed to move bundle forwarding decisions to an - external process or processes. Benefits of this interface include:

=

  • Classified and proprie= tary bundle routing algorithms are - protected.

  • External routers may be written in any p= rogramming language (XML - based interface).

  • Prototyping of new bundle routing= algorithms is - streamlined.

  • Routing algorithms may be added and re= moved at runtime.

This guide is directed at external = router developers and to those - interested in an early product of the new DTN implementation architect= ure. - "Interface Operati= on" describes interface - fundamentals such as underlying protocols and message structure. "Protocol Elements" introd= uces the set of router - interface messages used for inter-process communication. Appendix A sum= marizes new configuration options - introduced with the DTN2 RI external router interface implementation. - Appendix= B is an interface design FAQ of - sorts that attempts to address questions that often arise when first - learning about the interface.

Important

Please note that the external router interface is still evolving - and will likely be modified as experience is gained externalizing DT= N - bundle routers. Future work on other interfaces, including - convergence-layer and storage interfaces, may also impact the interf= ace. - The latest "bleeding edge" version of the DTN2 RI includes support f= or - the external router interface documented here and is available at www.dtnrg.org.

=

Interfa= ce Operation

Before diving into the details, this = section discusses the overall - design and operation of the router interface. When compiled, the DTN2 = RI - 2.2.0 release (the latest formal DTN2 release as of this writing) prod= uces - one multi-threaded executable, a DTN daemon. This daemon is a complete= DTN - node; it accepts bundles from a number of built-in convergence layers, - provides persistent bundle storage, delivers bundles to local DTN - applications, selects routes using built-in routing logic, and forward= s - bundles to peer DTN nodes. For the purposes of this document, a forwarder is a DTN daemon as described above, but one - that depends on external routing processes to make bundle routing - decisions on its behalf.

The forwarder communicates with externa= l routing processes:

  • <= p>with an XML-based messaging protocol

  • using a well-known IP= v4 multicast address and UDP port

  • on local or remote hosts

Before forwarders and external routers can communicate= , they each - must join the all-routers multicast group (224.0.0.2) and bind to a - well-known UDP port. Forwarders are not aware if zero, one, or more - external routers have joined the multicast group. It is the responsibi= lity - of the system administrator to ensure router availability.

Nothi= ng in the interface design precludes running forwarders and - external routers on different hosts, however this approach is not - recommended especially in wireless and/or bandwidth-constrained - environments. The interface is fairly chatty, UDP is unreliable, and t= here - is a high risk of packet loss leading to a breakdown in synchronized - state. (The DTN2 RI external router interface is hard coded to use the - loopback interface and therefore requires forwarders and external rout= ers - to reside on the same host.)

Inter-process messages are XML-base= d and must be valid against the - external router X= ML schema. - Interface messages are broadly divided into four categories. Event - messages are issued by forwarders to indicate state changes that may b= e of - interest to external routers. Request messages are sent by external - routers to direct forwarders to perform an action (e.g. "forward the - bundle with ID 56 out link tcp0"). Query and report messages are used = by - external routers to synchronize their state with forwarders after boot= up - or during failure recovery. The proper usage and interpretation of eac= h - interface message is covered in the next section.

How does the f= orwarder authenticate external processes? It doesn't. - The forwarder makes the assumption that (local or remote) external rou= ters - are within the same security domain. In addition, system administrator= s - must ensure there exists one authoritative router or policy module per= DTN - "node”, or that multiple external routers are configured in a co= operative - manner to correctly handle all events.

In addition to external r= outers, other "read-only" types of - processes may join the all-routers multicast group. An external loggin= g - application, for example, could be written to display the current stat= e of - the forwarder simply by listening to external router interface message= s. - However, this concept is not pursued further in this document. The - following discussion is limited to inter-process communication between - forwarders and external routers.

Protocol Elements

=

This section describes each interface message according to purpose. - Hyper-links to generated schema documentation are located throughout t= he - text. To generate the documentation, cd to= the top level - directory of DTN2 source code and type make xsddo= c. You will - need xsddoc-1.0 - and java installed for this to work.

Rendezvous

When a forwarder is configured = for external routing, it - periodically multicasts hello messages to announce its presence to - external routers. Each hello message includes the EID of the sender = and - the interval in seconds between each message. For example, the - message

<dtn eid=3D"dtn://nodeX" - hello_interval=3D"30"/>

notifies external routers th= at the DTN forwarder with EID - dtn://nodeX is running and will send another hello message in 30 - seconds. Router implementations may filter incoming messages by EID = if - it becomes necessary to run more than one forwarder on a single - platform.

After routers receive one or more hello messages fro= m any (or a - specific) DTN node, they must synchronize their state with the - forwarder. Several routing interface messages are designed to facili= tate - state synchronization and have a common format. If x represents - meta-information of interest, the message x_query prompts the forwar= der - to send an x_report message. For example, a bundle_query - message asks the forwarder to generate and send a bundle_report - message.

Routers may query the forwarder for four types of - meta-information. contact_report - includes meta-information on all open connections between the local - forwarder and remote forwarders. Low-level convergence layer - meta-information is also included for each contact. link_report<= /a> - contains meta information on all forwarder links regardless of the - current state. route_report - is composed of meta-information on all static routes configured on t= he - DTN console (if any). bundle_report - lists meta-information on each bundle stored by the local - forwarder.

After synchronizing their state with a forwarder, e= xternal routers - process incoming events as they arrive and send requests when - necessary.

Links and = Contacts

DTN links represent a one way communicati= on channel to next hop - DTN nodes. Links are either explicitly created in the forwarder - configuration file (dtn.conf) or spr= ing into - existence as a result of the neighbor discovery mechanism. Four type= s of - links exist: always on, on - demand, scheduled, and - opportunistic. l= ink_created_event - messages announce the existence of new links and include such attrib= utes - as name, type, and destination EID along with other meta-information= . - link_deleted_event - notifies external routers that a named link has been destroyed. link_available_event - and link_unavailable_event - messages are automatically generated by the forwarder when links are - open or closed respectively.

The forwarder attempts to keep al= ways on and opportunistic links - open always. Scheduled links are automatically opened and closed - according to configured start and duration settings. On demand links= , - however, must be explicitly opened by the router using an = open_link_request. - After on demand links are idle for a set period of time (currently 3= 0 - seconds), they are closed by the forwarder.

When the state of = any link is either open or busy, a contact - element is also available which tracks connection and convergence la= yer - statistics that may be useful to routing algorithms. contac= t_up_event - and contact_down_event - messages notify routers when contacts are available or - unavailable.

Most link and contact messages carry a coarse "re= ason" attribute - to explain what prompted each link state change.

Routes

The primary fun= ction of DTN external routers is to maintain a - forwarding information base of optimal next hop DTN nodes for remote= EID - prefixes. Routes to remote EID prefixes are either statically - configured, learned from the DTN neighbor discovery mechanism, or - learned from peer router communications. Specific DTN routing algori= thms - and implementations are beyond the scope of this document.

Sta= tic routes may be configured in the forwarder configuration - file or directly on the DTN console. When static routes are specifie= d, a - route_add_event - is multicast to external routers. Router implementations may choose = to - add static routes to internal routing tables (possibly with an - identifying marker indicating the source or administrative distance)= or - simply ignore their existence. The route_delete_event - message is issued when a static route has been deleted at the DTN - console.

The external router interface does not include messag= es to support - the display of external routing tables on the DTN console. All but t= he - most simplistic external routers should have their own "console" for - configuration and routing table displays.

Bundles

Bundles arriving at a= forwarder, either from a remote DTN node or - from a local application, are announced with a bundle_= received_event - message. Bundle payload is not forwarded over the interface, only - meta-information.

When an opportunity exists to forward a bund= le, the external - router issues a send_bundle_request - which includes the local bundle id, name of the outgoing link, and t= he - desired forwarding behavior. Meta-information about the bundle shoul= d - not be erased until a positive acknowledgement is received from the - forwarder.

bundle_transmitted_event - states that a bundle has been successfully transmitted using the - identified contact. On reliable links, this means acknowledgements w= ere - received, on unreliable links, a best effort attempt was made to sen= d - the bundle. A failed transmission is indicated by the bundle_transmit_failed_event - message and may warrant a retransmission by the router if - possible.

For successfully transmitted bundles, routers can re= lease all - resources dedicated to tracking the bundle unless the sender had - requested custody transfer. If custody was requested, the router mus= t - continue to track the bundle until it receives a corresponding custo= dy - message. If custody was accepted by a downstream DTN node, a custody_signal_event - is generated. Bundle meta-information can now be released by the rou= ter. - If custody failed, indicated by the suc= ceeded - attribute in the custody_signal_event, - or the router receives a custody_timeout_event - (i.e. no response from a downstream DTN node), the router may attemp= t to - retransmit the bundle if possible.

bundle_expired= _event - notifies the router that a bundle has expired and is being deleted f= rom - the store. External routers should remove all records of the - bundle.

cancel_bundle_request - asks the forwarder to abort a previous send_bundle request if possib= le. - (As of this writing, cancel_bundle_request is not implemented in the - DTN2 RI.)

Peer Router= Communication

Many routing algorithms require inf= ormation exchange between peer - routers. Communication between peer DTN external routers boils down = to - identifying methods for sending and receiving router message bundles= . - Two methods are currently available; the first utilizes the DTN2 - application interface and the second is offered by the external rout= er - interface itself.

External router developers may elect to buil= d their external - routers with two personalities, to behave as an external router and = as a - DTN application. The external router interface handles all bundle - forwarding tasks while the application interface is used to send and - receive peer router messages. In order for this method to work, exte= rnal - routers must register with the forwarder as a DTN application and su= pply - a well-known service tag for bundle deliveries. It seems intuitive t= hat - the service tag would signify the routing algorithm. For example, an - external router implementing a flooding algorithm may register with = the - forwarder using the service tag "flood_rtr".

This approach off= ers several benefits: the DTN application - interface is reliable, there is no limit on bundle size, and - router-originated bundles follow the same path as "normal" applicati= on - bundles and are subject to the same policies. Cons include increased - development complexity and the fact that external routers can't spec= ify - an outgoing link using the application API. The forwarder defers to = the - external router the decision of where to forward router-originated - bundles.

The second alternative is to send locally generated b= undle - payloads to the forwarder on inject_bundle_request - messages. Destination EID, outgoing link, and other attributes requi= red - for bundle forwarding are supplied as well as the payload to inject. - Router-originated bundle payloads are assumed to be binary blobs and= are - Base64 encoded. No attempt is made to decode or process - router-originated bundle payloads except by the destination remote - router process. Forwarders notify external routers of successful or - failed transmissions in the same manner as "normal" bundles (I need = to - check this...). Unlike DTN application bundles, router injected bund= les - are not cached. If transmission fails, bundles are dropped.

At= boot-up, the external router interface registers with the - forwarder to receive all bundles destined to “ext.rtr/*”= . As in the - previous example, a service tag is chosen by the external router - developer to uniquely identify the router. Arriving bundles matching= the - registration "ext_rtr/*" are announced with the bundle= _delivery_event - message. Upon receipt of this message, routers must examine the bund= le's - destination EID to determine the intended recipient of the bundle. - Bundle payloads are read in or otherwise accessed using the filename - attribute associated with bundle payload meta-information.

=

Failure Recovery

Since IPC between forwarders and external routers is - connectionless, one process can fail without the other's immediate - knowledge. Consider the case where there is one forwarder process an= d - one external router process. Five states are possible 1) both proces= s - are up, 2) forwarder is up, external router is down, 3) forwarder is - down, external router is up, 4) forwarder crashes and comes back up - within a hello interval, and 5) both processes are down. Obviously, = Case - 1 does not belong in a Failure Recovery Section.

A discussion = of Case 2 yields an interesting point. The forwarder - does not monitor whether zero, one, or more external routers are run= ning - and/or are members of the all-routers multicast group. Event message= s - are multicast to the all-routers group, by the forwarder, regardless= of - external router state. When an external router is restarted, it shou= ld - immediately synchronize its state with the forwarder in much the sam= e - manner as the initial bootup sequence discussed in the previous - section.

There are two instances in the life of a forwarder wh= ere the hello - message includes an additional attribute. The "alert" attribute prov= ides - additional information about the overall state of the forwarder and - facilitates failure recovery in the remaining cases. Two values are - currently valid: "justBooted" and "shuttingDown". At bootup, the - forwarder always sends the "justBooted" alert with the first hello - message. When the forwarder is shut down in an orderly fashion (by - issuing "quit" at the console for example), a hello message is - immediately sent that includes the "shuttingDown" alert. However, if= the - forwarder should crash or is otherwise shutdown in an unorderly mann= er, - there is no guarantee that a "shuttingDown" alert will be sent.

<= p>For Case 3, the external router determines the forwarder is down - either by receiving a hello message with a "shuttingDown" alert or a= fter - hello interval seconds have passed without receiving a message. At t= his - point, the router must stop sending messages, wait until another hel= lo - message is received, synchronize its state with the forwarder, and - resume normal operations.

The external router knows it is deal= ing with Case 4 if it receives - a "justBooted" alert in less than or equal to one hello interval. Th= e - router must stop sending messages, synchronize its state with the - forwarder, and resume normal operations.

Towards the goal of m= aking DTN a turnkey solution, additional - "helper" processes are being developed whose sole purpose is to watc= h - and restart forwarders and external routers if and when they fail. - Helper processes will play a critical role in addressing Cases 2 - - 5.

A. New Configura= tion Directives

This section describes four new configuration direct= ives that - accompany the DTNRG RI external router interface.

To enable the = external router feature, set the forwarder router type - to "external".

route set type external

Next, provide the full pathname of the XML schema file "router.= xsd" - (originally located in the DTN2 source distribution daemon - directory).

route set schema <pathnam= e>

The remaining directives are optional (i.e. they have de= fault - values).

The default UDP port for external router communications= is 8001. To - change it, include the following directive in - dtn.conf.

route set server_port <udp port>

The number of seconds= between forwarder hello messages can also be - changed from the default of 30 seconds.

= route set hello_interval <seconds>

B. Interface Design FAQ

Why multicast?

= Why UDP?

Why XML?

...

\ No newline at end of file diff -r 8b0d483af1e2 -r e62055127255 doc/manual/.dtndebug --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/.dtndebug Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,103 @@ +%no_path # Don't display log path +#no_time # Don't display time stamp +#no_level # Don't display log level +#brief # Truncate log name to a fixed length and use brief error code= s +%color # Use terminal escape code to colorize output +%object # When possible, display the address of the object that gener= ated the log. +%classname # When possible, display the class that generated the log m= essage. + +/dtn/tclcmd/gettimeofday warn +/dtn/tclcmd/help warn +/dtn/tclcmd/debug warn +/dtn/tclcmd/api warn +/dtn/tclcmd/bundle warn +/dtn/tclcmd/interface warn +/dtn/tclcmd/link warn +/dtn/tclcmd/param warn +/dtn/tclcmd/registration warn +/dtn/tclcmd/route warn +/dtn/tclcmd/discovery warn +/dtn/tclcmd/prophet warn +/dtn/tclcmd/shutdown warn +/dtn/tclcmd/quit warn +/dtn/tclcmd/storage warn +/dtn/tclcmd/ecla warn +/dtn/tclcmd/console warn +/dtn/tclcmd/test warn +/dtn/tclcmd/debug warn +/dtn/tclcmd/log warn +/dtn/tclcmd debug + +/dtn/apiserver/notifier warn +/dtn/apiserver warn + +/dtn/apiclient warn +/dtn/interface/table warn +/dtn/interface debug + +/dtn/cl/udp/receiver/notifier warn +/dtn/cl/udp/iface/udp0 warn +/dtn/cl/udp warn +/dtn/cl/tcp/listener/notifier warn +/dtn/cl/tcp/iface/tcp0 warn +/dtn/cl/tcp warn +/dtn/cl/bt warn + +/dtn/contact/manager warn + +/dtn/route/flood warn=09 +/dtn/route debug + +/dtn/routing/flood/table warn + +/dtn/storage/bundles warn +/dtn/storage/globals warn +/dtn/storage/registrations warn +/dtn/storage/links warn +/dtn/storage debug + +/dtn/discovery/bt/notifier debug +/dtn/discovery/bt debug +/dtn/discovery/ip/sock warn +/dtn/discovery/ip warn +/dtn/discovery/table warn +/dtn/discovery debug + +/dtn/disc/bt/sdp/client debug +/dtn/btinquiry debug +/dtn/link/link1 warn +/dtn/link/link2 warn +/dtn/link/refs warn +/dtn/link debug + +/dtn/bundle/free warn +/dtn/bundle/list warn +/dtn/bundle/daemon/notifier warn +/dtn/bundle/daemon/loop warn +/dtn/bundle/daemon/msgqueue warn +/dtn/bundle/daemon info +/dtn/bundle info + +/dtn/registration/table warn +/dtn/registration warn + +/dtn/reg/ping warn +/dtn/reg warn + +/dtn/naming/endpoint warn +/dtn/naming debug + +/dtn/scheme/dtn warn + +/dtn debug + +/command/completion_notifier/notifier warn + +/oasys/util/uri warn + +/udpclient warn +/thread warn +/log warn +/timer warn +/dtnd debug +/ debug diff -r 8b0d483af1e2 -r e62055127255 doc/manual/arch.html --- a/doc/manual/arch.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/arch.html Sun Dec 13 21:46:12 2009 -0800 @@ -4,15 +4,284 @@ +

Architecture of DTN2

=20 - -In this page, you would find a sketch of how the whole thing -fits together. Please see the to do list -for information on how you can help. +

Implementation overview

+ +

+The following text is intended to provide a sketch of how the whole thing = fits together. It is a brief synopsis of DTN2s implementation, taken entire= ly from this paper by Michael Demmer and others. For more information = about DTN2's architecture and role as a platform for experimentation, see <= a +href=3D"http://www.cs.berkeley.edu/~demmer/papers/dtn-irb-tr-04-020.pdf">t= his paper. + +

+ +

The major message processing, management and application support module= s of the DTN Bundle forwarding system are provided below. The bundle router= module requires the most detailed information regarding the state of the s= ystem upon which to base routing decisions. Decisions made by the router ar= e passed as a set of instructions (actions) to the forwarder which is respo= nsible for executing the actions.

=20 + +

This separation between policy and function allows for easy extension, = modification, and replacement of the potentially complex router module.

+ +

Bundle Router and Bundle Forwarder

+ +

The router component implements all the route selection +and scheduling policy decision making. It takes as input a large variety o= f events that could potentially affect routing decisions and issues encoded= instructions that are passed to the bundle forwarder, which is in turn cha= rged with the responsibility to execute them. The forwarder executes the ro= uter=E2=80=99s decisions by interacting with the Convergence Layers, Regist= rations, and the Persistent Store. The separation of router from forwarder = represents an instance of separating policy from mechanism. Separating the = calculation of instructions from their execution helps to isolate the routi= ng code from changes in the other internal APIs. + +

Convergence Layers

+

Convergence Layers are the adapters between the DTN bundling protocols = and various underlying transports, similar to drivers within an operating s= ystem. At the most basic level, they perform basic data plane functions: a = particular layer must be able to transmit and receive bundles over a single= hop (in the overlay topology). In some cases they also process signaling i= nformation required by the bundle router (e.g. such as failed connections a= nd restarts). Convergence Layers are discussed in more detail in the follow= ing section.=20 + +

Persistent Store

+

Persistent storage is used to hold the contents of bundles during the s= tore-and-forward process. A common abstraction for persistent storage allow= s a particular system instance to select (at runtime) to use either a relat= ional database model or a simple file model. + +

Fragmentation Module

+

The fragmentation module is responsible for fragmenting and reassemblin= g bundle fragments. This module is capable of sending a signal to the bundl= e router when all the fragments of a subject bundle have been received. + +

Contact Manager

+

The Contact Manager is responsible for keeping track of which links are= currently available, any historical information regarding their connectivi= ty or performance, +and any known future schedules of when connectivity may be available. The = primary task of the contact manager is to transform the information learned= about contacts from +environment-specific mechanisms into abstract contact descriptions that ca= n be used by the bundle router. + +

Management Interface

+

The management interface is used to signal the bundle router about any = special policy constraints or preferences that may affect its data routing = decisions. It is implemented as a generic interprocess communication capabi= lity so that multiple applications or processes may be supported.=20 + +

Console / Config

+

The console/configuration module provides a command line interface and = an event loop for testing and debugging of the implementation, as well as a= structured method +to set initial configuration options. An embedded Tcl interpreter is used = to parse and execute user commands and settings.=20 + +

Application IPC / Registration Module

+

DTN applications are written to use a thin library that communicates wi= th the router via an inter-process communication channel. Most of this inte= raction relates to +sending and receiving application messages and manipulating message demult= iplexing bindings.=20 + =20 +

+ +

DTN2 API

+ +

API functions

+

+ + + + + + + + + + + + + + + + + + + + + +
Interface +Function +Returns +Comments + +
Open a new connection to the router. +extern int dtn_open(dtn_handle_t* handle) + DTN_SUCCESS | dtn_errno error code. + On success, initializes the handle parameter as a new handle +to the daemon and returns DTN_SUCCESS. On failure, sets handle to +NULL and returns a dtn_errno error code. + +
Close an open dtn handle. +extern int dtn_close(dtn_handle_t handle); +DTN_SUCCESS +Returns DTN_SUCCESS on success. + +
Get the error associated with the given handle. +extern int dtn_errno(dtn_handle_t handle); +TBC +None + +
Set the error associated with the given handle +extern void dtn_set_errno(dtn_handle_t handle, int err); +TBC +None + +
Build a local endpoint id +extern int dtn_build_local_eid(dtn_handle_t handle, + dtn_endpoint_id_t* local_eid, + const char* service_tag); +TBC +Build an appropriate local endpoint id by appending the specified +service tag to the daemon's preferred administrative endpoint id. + +
Create a dtn registration. +extern int dtn_register(dtn_handle_t handle, + dtn_reg_info_t* reginfo, + dtn_reg_id_t* newregid); +TBC +If the init_passive flag in the reginfo struct is true,=20 +the registration is initially in passive state, requiring=20 +a call to dtn_bind to activate it. Otherwise, the call to +dtn_bind is unnecessary as the registration will be created=20 +in the active state and bound to the handle. + +
Remove a dtn registration. +extern int dtn_unregister(dtn_handle_t handle, + dtn_reg_id_t regid); +TBC +If the registration is in the passive state (i.e. not bound to any +handle), it is immediately removed from the system. If it is in +active state and bound to the given handle, the removal is deferred +until the handle unbinds the registration or closes. This allows +applications to pre-emptively call unregister so they don't leak +registrations. + +
Check for an existing registration. +extern int dtn_find_registration(dtn_handle_t handle, + dtn_endpoint_id_t* eid, + dtn_reg_id_t* newregid); +DTN_SUCCESS | ENOENT +Check for an existing registration on the given endpoint id. +Return DTN_SUCCESS and fill in the registration id if it +exists, or return ENOENT if it doesn't. + +
Modify an existing registration. +extern int dtn_change_registration(dtn_handle_t handle, + dtn_reg_id_t regid, + dtn_reg_info_t *reginfo); +TBC +None + +
Associate a registration with the current ipc channel. +extern int dtn_bind(dtn_handle_t handle, dtn_reg_id_t regid); +TBC +Associate a registration with the current ipc channel. +This serves to put the registration in "active" mode. + +
Explicitly remove an association from the current ipc handle. +extern int dtn_unbind(dtn_handle_t handle, dtn_reg_id_t regid); +TBC +Note that this is also implicitly done when the handle is closed. +This serves to put the registration back in "passive" mode. + + +
Send a bundle.=20 +extern int dtn_send(dtn_handle_t handle, + dtn_reg_id_t regid, + dtn_bundle_spec_t* spec, + dtn_bundle_payload_t* payload, + dtn_bundle_id_t* id); +TBC +Send a bundle either from memory or from a file. + +
Cancel a bundle transmission. +extern int dtn_cancel(dtn_handle_t handle, + dtn_bundle_id_t* id); +TBC +None + +
Blocking receive for a bundle. +extern int dtn_recv(dtn_handle_t handle, + dtn_bundle_spec_t* spec, + dtn_bundle_payload_location_t location, + dtn_bundle_payload_t* payload, + dtn_timeval_t timeout); +TBC +Fill in the spec and payload structures with the bundle data.=20 +The location parameter indicates the manner by which the caller=20 +wants to receive payload data (i.e. either in memory or in a file).=20 +The timeout parameter specifies an interval in milliseconds to block=20 +on the server-side (-1 means infinite wait).=20 +

Note that it is advisable to call dtn_free_payload on the returned stru= cture,=20 +otherwise the XDR routines will memory leak. + +

Blocking query for new subscribers on a session.=20 +extern int dtn_session_update(dtn_handle_t handle, + unsigned int* status, + dtn_endpoint_id_t* session, + dtn_timeval_t timeout); +Indication that a subscriber was added or removed. +One or more registrations must have been bound to the handle=20 +with the SESSION_CUSTODY flag set. Returns an indication=20 +that the subscription state in the given session has changed=20 + + +
Return a file descriptor for the given handle.=20 +extern int dtn_poll_fd(dtn_handle_t handle); +File descriptor. +Return a file descriptor for the given handle. suitable for calling +poll() or select() in conjunction with a call to dtn_begin_poll(). + +
Begin a polling period for incoming bundles.=20 +extern int dtn_begin_poll(dtn_handle_t handle, dtn_timeval_t timeo= ut); +File descriptor=20 +Returns a file descriptor suitable for calling poll() or select() on=20 +(similar to dtn_poll_fd). Note that dtn_bind() must have been=20 +previously called at least once on the handle. + +

If the kernel returns an indication that there is data ready on the +file descriptor, a call to dtn_recv will then return the bundle +ithout blocking, then dtn_poll must be called again to wait for +more bundles. + +

Also, no other API calls besides dtn_recv can be executed during a +polling period, so an app must call dtn_cancel_poll before trying +to run other API calls. + +

Cancel a polling interval. +extern int dtn_cancel_poll(dtn_handle_t handle); +TBC +None +
+ + +

Utility Functions

+ +

+ + + + + + + +
Interface +Function +Returns +Comments + +
Copy the contents of one eid into another. +extern void dtn_copy_eid(dtn_endpoint_id_t* dst, dtn_endpoint_id_t= * src); +TBC +None + +
Parse a string into an endpoint id structure. +extern int dtn_parse_eid_string(dtn_endpoint_id_t* eid, const char= * str); +TBC +Parse a string into an endpoint id structure, validating that it is +in fact a valid endpoint id (i.e. a URI + +
Set the value of the given payload structure +extern int dtn_set_payload(dtn_bundle_payload_t* payload, + dtn_bundle_payload_location_t location, + char* val, int len); + 0 | DTN_ESIZE=20 +Set the value of the given payload structure to either a memory +buffer or a file location.Returns: 0 on success, DTN_ESIZE if the memory l= ocation is +selected and the payload is too big. + + + +
Free dynamic storage. +void dtn_free_payload(dtn_bundle_payload_t* payload); +TBC +Frees dynamic storage allocated by the xdr for a bundle payload in dtn= _recv. + +
Return a string version of a status report reason code. +const char* dtn_status_report_reason_to_str(dtn_status_report_reas= on_t err); +String +None +
=20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-bt.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/cl-bt.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,36 @@ + + + DTN2 Manual: Bluetooth Convergence Layer + + + +

Bluetooth Convergence Layer +

+ +

+In Bluetooth, piconets are formed by one Master connecting to up to seven = Slaves. The device performing connect() is the Master and the device perfo= rming listen()/accept() is the Slave. To add a bluetooth interface in your = config file, use: + + +

+Syntax: interface add name CL [arg=3Dval arg=3Dval2 a= rgN=3DvalN...] +

Example: interface add bluetooth0 bt channel=3D10 +

Valid arguments for arg are: + +

+ + + +
arg +Possible settings +Default +Comments + +
channel +number (channel) +10 +The bluetooth RFCOMM channel +
+

Note + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-eth.html --- a/doc/manual/cl-eth.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/cl-eth.html Sun Dec 13 21:46:12 2009 -0800 @@ -8,8 +8,36 @@ =20

-This page is not yet done. Please see the todo -list for information on how you can help finish this manual. +The EthConvergenceLayer provides access to any ethernet interfaces that +support RAW sockets. It periodically sends beacons out on each interface=20 +to support neighbor discovery. (this may change later). To add an ethernet= =20 +interface in your config file, use: + + +

+Syntax: interface add string://interface CL [arg=3Dva= l arg=3Dval2 argN=3DvalN...] +

Example: interface add string://eth0 eth beacon_interval=3D1 +

Valid arguments for arg are: +

+ + + +
arg +Possible settings +Default +Comments + +
beacon_interval +number (seconds) +1 +The Ethernet discovery beacon +
+

Note +

link next hop parameter next hop must be set to an Ethernet hard= ware Address +

Theoretically, any router type should work. +

Beacons timeout every 2.5 seconds by default=20 +

The max size for and Ethernet packet is 1518 bytes +

The maximum bundle size is s that of the UDP datagram (65507 bytes) =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-extcl.html --- a/doc/manual/cl-extcl.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/cl-extcl.html Sun Dec 13 21:46:12 2009 -0800 @@ -14,6 +14,7 @@ CLA, giving its name (usually the name of the protocol that the CLA implements) to the ECL.

+

ECLA Commands

The following commands are available to control the ECL. The commands are of the form:
@@ -130,5 +131,7 @@ connects. In this case, links will remain UNAVAILABLE until the CLA connects.

+ +For more more information see E= xternal Router Interface document diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-file.html --- a/doc/manual/cl-file.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/cl-file.html Sun Dec 13 21:46:12 2009 -0800 @@ -6,11 +6,32 @@

File Convergence Layer

+

DO NOT USE - NOT WORKING 12/11/09 +

+To add a file interface in your config file, use: + =20

-This page is not yet done. Please see the todo -list for information on how you can help finish this manual. +Syntax: interface add name CL [arg=3Dval arg=3Dval2 a= rgN=3DvalN...] +

Example: interface add file0 file +

Valid arguments for arg are: +

+ + + +
arg +Possible settings +Default +Comments =20 +
secs_per_scan +number (seconds) +5 +Directory scan interval +
+

Note +The ssp part of the next hop URI (the contact EID) MUST be of the form: /p= ath1/path2. +The given directory indicated by the spp part MUST exist and the permissio= ns MUST be correct =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-norm.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/cl-norm.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,359 @@ + + + DTN2 Manual: NORM Convergence Layer + + + +

NORM Convergence Layer +

+ +

+A Nack-Oriented Reliable Multicast (NORM) convergence layer. The NORM protocol is de= signed to provide end-to-end reliable transport of bulk data objects or str= eams over generic IP multicast routing and forwarding services. NORM uses a= selective, negative acknowledgement (NACK) mechanism for transport reliabi= lity and offers additional protocol mechanisms to conduct reliable multicas= t sessions with limited "a priori" coordination among senders and receivers= . A congestion control scheme is specified to allow the NORM protocol fairl= y share available network bandwidth with other transport protocols such as = Transmission Control Protocol (TCP).=20 +

It is capable of operating with both reciprocal multicast routing among= senders and receivers and with asymmetric connectivity (possibly a unicast= return path) from the senders to receivers. The protocol offers a number o= f features to allow different types of applications or possibly other highe= r level transport protocols to utilize its service in different ways. The p= rotocol leverages the use of FEC-based repair and other IETF reliable multi= cast transport (RMT) building blocks in its design. Norm sessions persist a= cross link down/up events in order to take full advantage of the built-up t= x cache used to satisfy repair requests. + +

Common Configurations +

---------------------

+ +

Here are some basic examples to get you started. The full list of link= :w + +parameters are summarized in the next section. + +

Assume DTN nodes A, B, and C can communicate over an IP network. +

+ + + + + + +
EID +IPv4 Address + +
dtn://node_a +10.1.101.1 + +
dtn://node_b +10.1.102.1 + +
dtn://node_c +10.1.103.1 + +
dtn://node_d +10.1.104.1 +
+

Point-to-point link A <-> B

+ +

Below are the "link add" directives for an always-on unicast link betwe= en +nodes A and B. Congestion control is enabled (cc) with a maximum tx rate +of 230Kbps. "ack" places the remote node in the acking_list; positive +acknowledgment is expected after zero of more nack-based repair cycles. +"ack" may reduce the number of flush messages. +

+

Node A configuration +

link add link_to_b 10.1.102.1:4557 ALWAYSON norm remote_eid=3Dd= tn://node_b cc ack rate=3D230000 +

Node B configuration +

link add link_to_a 10.1.101.1:4557 ALWAYSON norm remote_eid=3Dd= tn://node_a cc ack rate=3D230000 + +

One-to-many multicast A -> B,C,D

+ +

For a one-to-many multicast link, use "link add" on the node sourcing d= ata and +use "interface add" on the sink nodes. The Node A "acking_list" requests = postive +acknowledgments from Nodes B and C (after zero or more nack-based repair +cycles). Delivery to Node D may not succeeed because it's not in the acki= ng_list. +"nodeid" might be needed for senders and/or receivers when nodes are multi= -homed. +

+

Node A configuration +

link add link_to_bc 239.255.0.1:4558 ALWAYSON norm multicast_in= terface=3Deth0 remote_eid=3Ddtn://group=20 +cc rate=3D230000 acking_list=3D10.1.102.1,10.1.103.1 +

Node B configuration +

interface add norm0 norm multicast_interface=3Deth0 group_addr= =3D239.255.0.1 nodeid=3D10.1.102.1 +

Node C configuration + i

interface add norm0 norm multicast_interface=3Deth0 group_addr= =3D239.255.0.1 nodeid=3D10.1.103.1 +

Node D configuration +

interface add norm0 norm multicast_interface=3Deth0 group_addr= =3D239.255.0.1 nodeid=3D10.1.104.1 + +

Many-to-many

+ +

For a many-to-many multicast link, use "link add" on all the nodes sour= cing data. +Below, all nodes can send to and receive from the multicast group. Note t= he +acking_list is adjusted accordingly in each directive. +

+

Node A configuration +

link add link_to_bc 239.255.0.1:4558 ALWAYSON norm multicast_in= terface=3Deth0 remote_eid=3Ddtn://group=20 +cc rate=3D230000 acking_list=3D10.1.102.1,10.1.103.1,10.1.104.1 +

Node B configuration +

link add link_to_bc 239.255.0.1:4558 ALWAYSON norm multicast_in= terface=3Deth0 remote_eid=3Ddtn://group=20 +cc rate=3D230000 acking_list=3D10.1.101.1,10.1.103.1,10.1.104.1 +

Node C configuration +

link add link_to_bc 239.255.0.1:4558 ALWAYSON norm multicast_in= terface=3Deth0 remote_eid=3Ddtn://group=20 +cc rate=3D230000 acking_list=3D10.1.101.1,10.1.102.1,10.1.104.1 +

Node D configuration +

link add link_to_bc 239.255.0.1:4558 ALWAYSON norm multicast_i= nterface=3Deth0 remote_eid=3Ddtn://group=20 +cc rate=3D230000 acking_list=3D10.1.101.1,10.1.102.1,10.1.103.1 + +

Link Parameters +

---------------

+ +To add a norm interface in your config file, use: +

+Syntax: link add name nexthop type norm [<= i>arg=3Dval arg2=3Dval2 argN=3DvalN...] +

Valid arguments for arg are: + +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
arg +Possible settings +Default +Comments + +
cc +true or false +false + Whether NORM congestion control is enabled. + +
rate +number (bps) +64000 + Rate of NORM link in bits per second (bps). If congestion control is +enabled (see cc) this is the maximum achievable rate. + +
nodeid +string (hostname || IPv4 address) +none + Uniquely identify this node on the NORM link with an IPv4 address. +(Normally only needed for multi-homed nodes). + +
segment_size +number (bytes) +1400 + Maximum payload size of NORM sender messages in bytes (not incl. +NORM message header fields). + +
local_port +number (port) +4558 + (NORM interfaces only) Local UDP port to listen on for=20 +incoming multicast traffic. + +
remote_addr +number (bytes) +acquired from the "link add" directive + Remote NORM link IP address (not used -- normally acquired from the=20 +"link add" directive) + +
remote_port +number (port) +4557 + Remote NORM link port. (not used -- normally acquired from the "link +add" directive) + +
multicast_interface +interface +tbc + The host interface to use when working with multicast groups. + +
group_addr +IP address (IPv4) +tbc + (NORM interfaces only) Multicast IPv4 address to join. =20 +For multicast links, the group address is acquired from=20 +the "link add" directive. + + + +
tx_robust_factor +number=20 +20 + The number of flush messages sent at the end of each transmission. +Flush messages are used to prompt receivers to request needed repairs. +With "acking_list" or "ack", periodic flush messages cease once positive +ack(s) are received. + +
rx_robust_factor +number +20 + The number of times a receiver will nack for repairs before giving up= . + +
tos +number (marking) +0 + DSCP marking (0-64) for all bundles on a specific link +Size of the receive buffer for each NORM link. + +
acking_list +string (comma delimited list) +tbc + (multicast links) A comma separated list of IPv4 addresses (NORM node= ids) that must +positively ack sender-initiated flush messages (once any nack-based +repair process has completed). + +
ack +tbc +tbc + A shorthand way of requesting positive acks from the remote end of un= icast +links. + +
silent +true or false +false +"silent" receivers do not originate any NORM traffic and must rely on=20 +proactive FEC for repairs. + +
ecn +true or false +false + Whether NORM explicit congestion notification support is enabled. +Size of the receive buffer for each NORM link. + + +
object_size +number (objects) +0 +Partition large DTN bundles into multiple NORM data objects for +transmission. With the default of zero bytes, no object partitioning +is performed. Setting object size to a relatively small value, e.g. +50000 bytes, may be useful in some contention based networks (see +tx_spacer). This feature is similar in concept to proactive bundle +fragmentation or "bundle MTU" (neither yet implemented in DTN2). +(see tx_spacer).=20 + +
tx_spacer +number (ms) +0 + When combined with object_size, tx_spacer may be used to add a=20 +constant pause time (ms) between successive NORM data object=20 +transmissions. On contention based networks, this pause time may=20 +give other nodes a chance to transmit. + +
keepalive_intvl +number (ms) +5000 +For DTN opportunistic links, keepalive_intvl is the number of +miliseconds between successive keepalive packets. Opportunistic +links are made unavailable when three remote keepalive packets are +missed. In addition, reliable mode links send watermarks at +keepalive intervals. + +
fec_buf_size +number (bytes) +1048576 + The number of bytes allocated for sender calculated FEC segments and = repair state. + +
block_size +number (source symbol segments) +64 + The number of source symbol segments per coding block for the systema= tic Reed-Solomon FEC code used in the NRL NORM implementation. + +
num_parity +number (parity blocks) +16 + The maximum number of parity blocks the sender is willing to calculat= e per coding block. + +
auto_parity +number (messages) +0 + The number of "auto-parity" messages sent at the end of each coding b= lock. + +
backoff_factor +number (factor)=20 +0.0 for unicast; 4.0 for multicast links + Used to scale various timeouts during the NACK repair process. + +
group_size +number=20 +1000 + Group size is advertised to the receiver group where it is used in=20 +calculating backoff timers. Due to encoding techniques in the NORM=20 +header, 1000 receivers is the smallest value allowed by the NORM=20 +protocol. + +
tx_cache_size_max +number (bytes) +20971520 + Size of the NORM object cache per link. + +
tx_cache_count_min +number (objects) +8 + At at minimum, this many objects are allowed to be enqueued in the=20 +NORM engine regardless of the object sizes. After the tx_cache_count_min=20 +value is surpassed, cache size contraints are in effect (see tx_cache_size= _max). + +
tx_cache_count_max +number (objects) +1024 + The maximum number of objects that may be enqueued for transmission=20 +with the NORM engine assuming the total size is less that tx_cache_size_ma= x. + +
rx_buf_size +number (bytes) +300000 + Size of the receive buffer for each NORM link. + +
+ +

Note +

Requirements +

------------

+ +

+NORM libraries from the Naval Research Lab + +

    +
  • Download norm-n= ightlybuild.tgz (tested with version 1.4b4) + and protolib-n= ightlybuild.tgz + +
  • Unpack the norm code. cd into the norm top-level directory + and unpack the protolib code there. + +
  • For linux, cd into the unix directory and type +

    make -f Makefile.linux +

    make -f Makefile.linux libnorm.a + +

  • Copy libnorm.a and ../protolib/unix/libProtokit.a to + /usr/lib or /usr/local/lib + +
  • Copy ../common/normApi.h to /usr/include or /usr/local/include +
+ +

Installation +

------------

+ +

Configure DTN2 using '--with-norm' and (re)compile. + +

Add NORM links to dtn.conf, for example: +

link add norm_link remote_host:4557 ALWAYSON norm + + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-null.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/cl-null.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,35 @@ + + + DTN2 Manual: Null Convergence Layer + + + +

Null Convergence Layer +

+ +

+The Null convergence layer consumes all bundles immediately and does no ac= tual transmission, roughly similar to /dev/null. To add a null interface in= your config file, use: + + +

Syntax: interface add name CL [arg=3Dval arg=3Dval= 2 argN=3DvalN...] +

Example: interface add null0 null +

Valid arguments for arg are: + +

+ + + +
arg +Possible settings +Default +Comments + +
can_transmit +true or false +true +Whether null CL can transmit +
+

Note + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/cl-serial.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/cl-serial.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,70 @@ + + + DTN2 Manual: Serial Convergence Layer + + + +

Serial Convergence Layer +

+ +

+When using the Serial convergence layer a connection is either a receiver = or a sender. First it parses and attempts to resolve the next hop address a= nd if able to do so opens a tty. To add a serial interface in your config f= ile, use: + +

Syntax: interface add name CL [arg=3Dval arg=3Dval= 2 argN=3DvalN...] +

Example: interface add serial0 serial +

Valid arguments for arg are: + +

+ + + + + + + +
arg +Possible settings +Default +Comments + +
hexdump +true or false +false +Whether to log a hexdump of all traffic + +
initstr +string +"" +String to initialize the tty + +
ispeed +number +19200 +Input speed on the tty + +
ospeed +number=20 +19200 +Output speed on the tty + +
sync_interval +number +1000 +Interval to send initial sync bits + + + +
+

Note +

+The side which initiates the active connect is not necessarily the sender. +

+The serial CL first attempt to parse the next hop address and if unable to= do so, the link can't be opened. If it can it opens the tty and set the tt= y parameters and initializes the timer. If there's a dialing string, it wil= l attempt to send it, reserve space in the buffer and send a sync byte to k= ick things off.=20 +

+During the session it will check that it hasn't been too long since it got= some data from the other side and if it has it will time out the connectio= n. +

=20 +Once data is received on the channel, it means the other side is up and tr= ying to sync, so it will send the contact header + + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/compiling.html --- a/doc/manual/compiling.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/compiling.html Sun Dec 13 21:46:12 2009 -0800 @@ -8,16 +8,21 @@ =20

+ +

Compilation / Installation Instructions

+

--------------------------------------- +

At the moment, DTN2 comes in source form only. Before you can install it and start using it, you need to compile it. =20

On Unix

=20

-First, unpack the release. +First, download DTN2 and ensure it has met all r= equirements. For released versions, see the SourceForge DTN2 release Pa= ge and unpack the release. =20 

$ gunzip -c DTN2-X.Y.Z.tgz | tar xvf -
=20 +

For the latest ("bleeding edge") version of the code see the section on= Mercurial

Next, configure and compile DTN2: (the -C argument to configure enables the cache which speeds up the process) =20 @@ -25,6 +30,15 @@ $ sh configure -C $ make =20 +

Note that by default, the configure script will also run configure +inside the oasys/ subdirectory. The -C argument enables the autoconf +variable cache, which speeds up configuration.=20 + +

Note that if you need to make changes to the configure.ac script or +one of the helper scripts in aclocal/*.ac, run build-configure.sh to +recreate configure and then check in both your changes as well as the +newly generated configure script. +

If you just want to play with DTN2 to learn how it works, you can stop here. You can use all the programs as a regular user, with them in the source code directories. There's no need to do a full install @@ -34,25 +48,175 @@ into /usr, and some people prefer to put files in /usr/local. =20 -

Fetching the source code with CVS

+ +

Mercurial

=20 +

You can also access the latest ("bleeding edge") version of the code us= ing mercurial. The various repositories are hosted at the DTNRG SourceForge= repositories and = can be cloned using: +

+ % hg clone http://dtn.hg.sourceforge.net/hgweb/dtn/oasys
+ % hg clone http://dtn.hg.sourceforge.net/hgweb/dtn/DTN2=20
+
+

See Using Mercuri= al for more information on using mercurial. Please be aware this code m= ay be under frequent developmental changes, so your mileage may vary. For d= etailed information on using mercurial with the SourceForge repositories please see the mercu= rial access mechanisms. In addition, if you grab the development co= py in this way, any README files or other docs may not be quite up to date. + +

If you plan on contributing code changes, please read the CONTRIBUTING file that = describes the coding conventions for the project. + +

Please report any bugs to the Bugs tracker. + +

Getting Started

+--------------- + +

A good place to start for playing around with DTN is to look at the +manual and tutorials (see doc/manual/index.html). This set of +documentation explains some of the configuration and applications. If +you find omissions or errors, please feel free to post updates and +corrections to dtn-users@mailman.dtnrg.org. + +

Reporting Bugs / Other Help

+--------------------------- +

A bug tracking system is in place. Please direct bug reports to an= d +direct questions to dtn-bugs@mailman.dtnrg.org. + +

DTN2 Directory Structure

+------------------------

-We will try our best to propagate bug fixes to the current release of -the software. In some cases, however, you may want to get the source -code from the anonymous CVS repository instead. Please understand that -you're using pre-alpha software if you use the copy from CVS. We tr= y -to keep what's in CVS working, but it is under active development, and -you might see bugs. Before reporting them, please always use "cvs up" -to get the newest copy, then recompile and reproduce the bug. +

+applib/		    application interface library and ipc layer
+apps/		    example dtn applications
+doc/		    documentation
+daemon/		    dtn router daemon sources
+ideas/		    temporary code idea repository
+servlib/	    dtn router internals
+|-- bundling	    bundle management and forwarding logic
+|-- cmd		    tcl based command interface
+|-- contacts
+|-- conv_layers	    convergence layers
+|-- discovery
+|-- gcm
+|-- naming	    endpoint identifier schemes
+|-- prophet	    prophet router=20
+|-- reg		    local registrations
+|-- routing	    bundle routing logic
+|-- security	    bundle security protocol
+|-- session
+`-- storage	    persistent storage management
+sim/		    simulation framework
+test/		    unit tests and other test files
+test-utils/	    test scripts and utilities
+
+ +

External Requirements

+--------------------- +

+

 +

Optional External Packages

+-------------------------- +

+

    +
  • bonjour +
=20 -
$ cvs -d :pserver:anonymous@code.dtnrg.org:/orig login
-(password is "bundles")
-$ cvs -d :pserver:anonymous@code.dtnrg.org:/orig checkout DTN2
+

Optional Internal Packages

+-------------------------- +

+

    +
  • NORM convergence layer support +
  • Bundle Security Protocol support (see Note on BSP= ) +
+ + +

Note - Oasys/

+-------------------------- +

Before compiling DTN2 please compile Oasys-1.3.0+ (must be=20 +installed or located in DTN2 or ../). For released versions, see the Sourc= eForge DTN2 release Page and unpack the release. + +

$ gunzip -c oasys-X.Y.Z.tgz | tar xvf -
+ +

For the latest ("bleeding edge") version of the code see the section on= Mercurial +

Next, configure and compile oasys: + +

$ cd oasys (or oasys-X.Y.Z)
+$ sh configure
+$ make
+ +

Support for the +following DTN2 options should be specified when configuring +oasys + +

specify location / support of: +

    =20 +
  • Python=20 +
  • tcl =20 +
  • google perftools +
  • expat +
  • xerces-c +
  • xsd tool +
  • Berkeley DB =20 +
  • mysql=20 +
  • postgres =20 +
+

compile with or without support for: + +

    +
  • bluetooth=20 +
  • zlib=20 +
  • tclreadline +
  • profiling +
  • google profiling +
  • assembly-based atomic functions +
+

enable or disable: +

    +
  • oasys debugging +
  • oasys memory debugging +
  • oasys lock debugging +
  • oasys optimization +
+ +

Installation of BSP

+-------------------------- +

The standard ciphersuites require, amongst other things,=20 +an implementation of sha-256 message digest algorithm. + +

The DTN reference code uses OpenSSL for cryptographic +and related functions. Unfortunately, some versions of +OpenSSL do not include sha-256. + +

The "configure" process checks for the availability of +sha-256 and provides an error if it is not found. + +

If your system's OpenSSL does not have sha-256 then you=20 +can either upgrade it or build and use a local version=20 +of OpenSSL. OpenSSL can be obtained from +openssl.org + +

OpenSSL 0.9.8 version include sha-256 by default. If your +system uses version 0.9.7 and you do not wish to upgrade +then you can enable sha-256 in later versions of 0.9.7, +such as 0.9.7l and 0.9.7m. To enable sha-256, specify "fips" +when running "Configure". + +

If you wish to leave you system installation untouched and +build against a local version, then configure dtn using +./configure --with-bsp --with-openssl=3D/path/to/openssl + +

Mac OS X note: for Mac OS X users ONLY. If you build dtn +against a local OpenSSL using "--with-openssl=3D/path/to/openssl" +you MUST also specify with it LDFLAGS=3D"-Wl,-search_paths_first".=20 +The configuration for OS X users would then be=20 +./configure --with-bsp --with-openssl=3D/path/to/openssl LDFL +

+ +

Installation of norm

+-------------------------- +

Please see the norm installation<= /a> instructions. =20

On Windows

=20

-DTN2 does not yet work as a native Windows application. It does, +DTN2 does not yet work as a native Windows application. It might, however, work with the Cygwin environment. =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/configuration.html --- a/doc/manual/configuration.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/configuration.html Sun Dec 13 21:46:12 2009 -0800 @@ -75,18 +75,63 @@

bundle

=20

You can use the bundle command to see the status of -bundles currently being held by your dtnd. While testing a DTN, -you can also inject bundles.=20 +bundles currently being held by your dtnd.=20 =20 -

Getting statistics

+

+Syntax: bundle command [id] +
+Example: storage set type berkeleydb + +

+Use the bundle command to get high level information on the bundl= e and bundle daemon statistcs, + +

+ + + + + + + +
Command +Comments +
stats +list bundle statistics. + +
daemon_stats +list bundle daemon statistics. + +
reset_stats +reset bundle statistics. + +
list +list all bundle. + +
ids +list all bundle IDs. +
+ +

While testing a DTN, you can also inject bundles.=20 +

+Syntax: bundle inject src dest payload opt1=3D= val1, opt2=3Dval2 optN=3DvalN... +
+Example: bundle inject dtn://source.dtn dtn://dest.dtn payload + + +

Getting bundle and bundle daemon statistics

=20

The bundle stats command shows the following counts:

  • pending +
  • custody
  • received -
  • locally delivered +
  • delivered +
  • generated
  • transmitted
  • expired +
  • duplicate +
  • deleted +
  • injected
=20

Pending is the current count of bundles in dtnd's store, which may @@ -97,9 +142,15 @@ The other counters are unsigned 32-bit integers, and will roll over accordingly. =20 -

At present there is no way to zero the counters other than by -restarting the server. +

bundle reset_stats may be used to reset currently maintained st= atistics. =20 +

The bundle daemon_stats command shows the following counts: +

    +
  • pending_events +
  • processed_event +
  • pending_timers +
+

Getting a list of pending bundles

=20

@@ -116,6 +167,7 @@ implementations will never see the bundle ID. However, you can use the bundle ID with the following commands to inspect the bundles. =20 +

Looking at a bundle

=20

Using bundle info bundle-id, you can see more @@ -124,6 +176,7 @@ printable characters in it, you can see it formatted as a text file using bundle dump_ascii bundle-id. =20 +

Injecting a bundle

=20

@@ -157,6 +210,53 @@ (But there's a bug that makes this not work right. Try dumping out a bundle you made this way to see an assert.) =20 + +

console

+

The console command is used spawn interpreter on=20 +stdin/stdout, set the console prompt string and set the console=20 +listening address and port number. + +

console cmd

+

+Syntax: console set arg +
+Example: console set prompt "$shorthostname dtn% " +

+ + + + + + +
Variable +Possible settings +Default +Comments + +
stdio +None=20 +stdio=20 +spawn interpreter on stdin/stdout + +
addr +A.B.C.D +127.0.0.1 +console listening address + +
port +number +0 +console listening port + +
prompt +string +shorthostname [lindex [split [info hostname] .] 0] dtn% +console prompt string + + + +
+

debug

=20 @@ -170,27 +270,288 @@ in use using debug dump_memory. After doing one dump, you can get diffs with debug dump_memory_diffs. =20 +

For information on debugging and configuring logging of the dtn=20 +daemon please see the logging section and .dtndebug + + +

discovery

+ +

The discovery command is used to configure the abstraction=20 +of a neighbor discovery agent. Much like Interface, Discovery is generally= =20 +created by the configuration file / console. Derived classes (such as=20 +IPDiscovery) typically bind to a UDP socket to listen for neighbor beacons= . =20 +Bluetooth has built-in discovery mechanisms, so BluetoothDiscovery polls=20 +via Inquiry instead of listening on a socket. + +

To advertise a local convergence layer, register its local address (and= port)=20 +by calling "discovery add". For each registered CL, Discovery will=20 +advertise (outbound) the CL's presence to neighbors,and distribute=20 +(inbound) each event of neighbor discovery to each CL. + + +

The discovery add command

+

+This command is used to add a discovery agent. +

+Syntax: discovery add discovery_name cl-type [ args ] +
+

+Example: discovery add udp0d ip port=3D9556 +
+

+Example : discovery add btd bt +
+

+Example: discovery add bonjourd bonjour + +

+ + + + +
Variable +Possible settings +Comments + +
discovery_name +string + A name string to identify the discovery agent + +
cl-type +bt | ip | bonjour + The convergence layer type.=20 +
+ + +

+ + + + + + + + +
args +Possible settings +Comments + +
port +number + Discovery port number if IP based + +
continue_on_error +true or false + Whether to continue on an error + +
addr +A.B.C.D + IPv4 address of .. + +
local_addr +A.B.C.D + IPv4 address of .. + +
multicast_ttl +number + Multicast time to live + +
unicast +true or false + Whether is unicast +
+ +

The discovery announce command

+

+This command is used to announce the address of a local interface (converg= ence layer). +

+Syntax: discovery announce cl-name discovery_name= cl-type [ args ] +
+

+Example discovery announce udp0 udp0d udp interval=3D10 +
+

+Example discovery announce bt0 btd bt interval=3D1 +

+ + + + +
args +Possible settings +Comments + +
cl_addr +A.B.C.D + IPv4 address of CL to announce + +
cl_port +number (port) + port number of CL to announce +
+ +

The discovery remove command

+

+This command is used to remove an announcement for a local interface. +

+Syntax: discovery remove announce discovery_name<= /tt> +
+

+Example: discovery remove bt0 btd +
+ +

The discovery del command

+

+This command is used to delete a discovery agent. +

+Syntax: discovery del discovery_name +
+

+Example: discovery del btd +
+ +

The discovery list command

+

+This command is used to list agents and their announcement parameters. +

+Syntax: discovery list +
+

+Example: discovery list +
+ + + +

ecla

+

The ecla command is used to control the external convergence l= ayer (ECL) is the gateway between DTN2 and convergence layer adapters (CLAs= ) running outside of DTN2. Please see ec= la for details. + +

+Syntax: ecla command +
+Example: ecla set create_discovered_links + + +

gettimeofday

+

The gettimeofday command is used to print the result of gettim= eofday() in secs.usecs format. + +

+Syntax: gettimeofday +
+Example: gettimeofday +

help

=20

You can get help on any of the additional TCL commands in dtnd's TCL interpreter using the help command. +

+Syntax: help command +
+Example: help interface + + + + + + + + + + + + + + + + + + + + +
Command +Comments + +
bundle +print bundle and bundle daemon statistics and interact with the bundle= daemon. Also used to examine, dump, expire, cancel and inject bundles. + +
console +set console parameters + +
debug +Command for memory debugging. Only available if "--enable-debug-memory= " was given to the configure script.=20 +
discovery +add, delete and list discovery agent and announce parameters + +
ecla +list and set the external convergence layer adapter parameters + +
gettimeofday +print the result of gettimeofday() in secs.usecs format. + +
help +print the help documentation for cmd. + +
interface +add, delete and list interface parameters. + +
link +add, delete, reconfigure and list link parameters and statistics. Also= used to modify default CLA parameters. + +
log +set log and debug file pathname and level and prefix. Also used to rot= ate log file, reparse rule file and list filter rules. + +
param +set various dtnd daemon parameters and policy. + +
prophet +manipulate the prophet routing protocol. These parameters should be ma= nipulated under the route command interface like other DTN routing algorith= ms and protocols. + +
quit +shutdown the daemon + +
registration +add, delete and list endpoint (EID) registrations and modify registrat= ion logger. + +
route +add, delete, list routes, select and configure routing algorithms/prot= ocols. Can be used to set various route parameters including setting of typ= e, next hop routes, route priority, interaction with discovery, DTLSR param= eters, and external route parameters. =20 + +
shutdown +gracefully shutdown the dtnd daemon. + +
storage +set storage backend type, parameters and view statistics. + +
test +Command for developer tests=20 + +
+ +

interface

=20 -

Use the interface commands to add and delete interfaces to the +

Use the interface command to add and delete interfaces to the networks that your dtnd will talk on. =20 +

Adding an interface

=20

Syntax: interface add interface-name convergence-layer [= args ] +


Example: interface add tcp0 tcp
-Example: interface add udp0 udp local_host=3D1.2.3.4 local_port=3D9999= - +
+Example: interface add udp0 udp local_host=3D1.2.3.4 local_port=3D9999=
+
+Example: interface add bt0 bt channel=3D10
+
+Example: interface add eth string://eth0 beacon_interval=3D1
+
+Example: interface add null

When dtnd encounters an interface add command, it checks to make sure the named interface has not been created before. Next, it looks for a matching convergence layer.=20 @@ -213,8 +574,15 @@

  • udp
  • eth
  • file +
  • bt +
  • serial +
  • norm +
  • extcl +
  • null + =20 +

    Deleting an interface

    =20

    @@ -228,6 +596,7 @@ stops listening for new bundles and cleans up any resources it was using. =20 +

    Listing the interfaces

    =20

    @@ -245,7 +614,7 @@ The log command deals with the log file, and the log messages in it. You can add messages of your own to the log file, or trigger various actions related to the log file. - +

    Logging a message of your own

    Syntax: log log-path log-level log-string @@ -257,6 +626,7 @@ log file. The log-path and log-level are used to filter out messages, as described in the section on Logging. =20 +

    Set the log prefix

    =20

    @@ -319,7 +689,204 @@ .dtndebug file and take into account any new rules that it finds for showing or hiding messages. =20 - + + +

    param

    + +

    +The param command is used to configure policy parameters. +

    param set

    +

    +Syntax: param set arg val +
    +Example: param set link_min_retry_interval 30 + +

    + + + + + + + + + + + + + + + + + +
    arg +Possible settings +Default +Comments + +
    payload_test_no_remove +true or false +false +Whether not to remove bundles (for testing). + +
    early_deletion +true or false +true +Whether to delete forwarded / delivered bundles before they've expired + +
    suppress_duplicates +true or false +true +Whether to not route bundles that are a duplicate of any currently pen= ding bundle + +
    accept_custody +true or false +true +Whether to accept custody when requested=20 + +
    reactive_frag_enabled +true or false +true +Whether reactive fragmentation is enabled + +
    retry_reliable_unacked +true or false +true +Whether to retry unacked transmissions on reliable CLs + +
    test_permuted_delivery +true or false +false +Whether to permute the order of bundles before delivering to registrat= ions. + +
    injected_bundles_in_memory +true or false +false +Whether injected bundles are held in memory by default. + +
    is_singleton_default +unknown|singleton|multinode +TBC +How to set the is_singleton bit for unknown schemes. + +
    glob_unknown_schemes +true or false +false +Whether unknown schemes use glob-based matching for registrations and = routes. + +
    link_min_retry_interval +number (interval in seconds) +TBC +Default minimum connection retry interval for links. + +
    link_max_retry_interval +number (interval in seconds) +TBC +Default maximum connection retry interval for links. + +
    custody_timer_min +number (seconds) +TBC +Default value for custody timer min. + +
    custody_timer_lifetime_pct +number (per cent) +TBC +Default value for custody timer lifetime percentage + +
    custody_timer_max +number (seconds) +TBC +Default value for custody timer max. + +
    + +     +

    prophet

    + +

    +The prophet command is used to configure the prophet router. This= command should not be here but under route like all= other DTN routing protocol and algorithm commands. +Please see prophet router for = detailed infomation. + +

    quit

    + +

    +The quit command is used to shutdown the DTN2 daemon. It is the s= ame as shutdown. +

    +Syntax: quit +
    +Example: quit + + +

    registration

    +

    +A registration is used to represent an "application" endpoint ID registrat= ion, loosely defined to also include internal router mechanisms that consum= e bundles. Registration state is stored persistently in the database. + +

    +The registration command is used add, delete and list EID regist= rations. + +

    registration add

    +

    +Syntax: registration add opt endpoint = +
    +Example: registration add tcl dtn:alex +

    + + + + +
    opt +Possible settings +Comments + +
    opt +logger or tcl +Whether to add a logger or tcl representation + +
    endpoint +An EID (URI) +The EID which you wish to add a registration for + +
    + +

    +The logger option is used mostly for testing registrations. When created, = this sets up a new registration within the daemon, and for any bundles that= arrive, outputs logs of the bundle header fields as well as the payload da= ta (if ascii). The implementation is structured as a thread that blocks (fo= rever) waiting for bundles to arrive on the registration's bundle list, the= n logging the bundles and looping again. The logpath is set to /dtn/reg/log= ging/. +

    + + +

    registration delete

    +

    +Syntax: registration del reg_id +
    +Example: registration del 14 + +     +

    registration list

    +

    +Syntax: registration list +
    +Example: registration list + +     +

    registration dump_tcl

    +

    dump_tcl is used to dump a tcl representation of the registration using= its registration id. +

    +Syntax: registration dump_tcl reg_id +
    +Example: registration dump_tcl 14 + +     +

    shutdown

    + +

    +The shutdown command is used to shutdown the DTN2 daemon. It is t= he same as quit. +

    +Syntax: shutdown +
    +Example: shutdown + + +=20

    storage

    =20

    @@ -481,8 +1048,8 @@ Frequency to check for Berkeley DB deadlocks (zero disables locking). =20 - -

    Notes

    +     +

    Storage Notes

    =20

    Tidy is useful when there are pending bundles in the system that you do not want dtnd to continue to try to deliver. If you allow dtnd @@ -531,6 +1098,24 @@ Whether or not to automatically add routes for next hop links . =20 +add +dest link/endpoint [opts] =20 +N/A +Add a static route + + =20 +del +dest link/endpoint =20 +N/A +Delete a static route + + +dump +N/A =20 +N/A +print all of the static routes + + open_discovered_links true, false true @@ -554,7 +1139,423 @@ 600 Default timeout for upstream subscription. =20 + +dtlsr_area +string +tbc +DTLSR Administrative area for the local node. + + +dtlsr_weight_fn +number +10 +DTLSR weight function for the graph. + + +dtlsr_weight_shift +number +0 +DTLSR scale factor to scale the weight on down links factor by which t= o age the cost of a link based on its uptimei. As a link's uptime goes to z= ero, the cost increases by 10x the original cost.=20 + + +dtlsr_uptime_factor +number +10 +DTLSR aging pct for cost of down links. + + +dtlsr_keep_down_links +true or false +true +DTLSR whether or not to keep down links in the graph, marking them as = stale. + + +dtlsr_recompute_delay +number (seconds) +1 +DTLSR delay (in seconds) after receiving an LSA when we recompute the = routes. Needed to prevent some flapping. + + +dtlsr_aging_interval +number (seconds) +5 +DTLSR interval after which we locally recompute the routes to properly= age links that we believe to be down. + + +dtlsr_lsa_interval +number (seconds) +3600 +DTLSR interval at which we proactively send new LSA. Default is once p= er hour. + + +dtlsr_min_lsa_interval +number (seconds) +5 +DTLSR minimum interval between LSA transmission. Default is once per f= ive seconds.=20 + + +dtlsr_lsa_lifetime +number (seconds) +86400 +DTLSR expiration time for lsa announcements (default is 24 hours). + + +server_port +number (port) +8001 +UDP port for IPC with external router(s) + + +hello_interval +number (seconds) +30 +Seconds between hello messages with external router(s) + + +schema +string (pathname) +/router.xsd +Location of the external router interface message schema + + +xml_server_validation +true or false +true +Perform xml validation on plug-in interface messages when using extern= al router(s) + + +xml_client_validation +true or false +false +Include meta-info in xml messages so plug-in routers can perform valid= ation when using external router(s) +=20 + + +

    Router Notes

    + +

    TCARouter is an implementation of the TCA bundle routing algorithm. +A TCARouter is a specialized TableBasedRouter where the route +table is manipulated in response to certain control bundles +(for example, a "register" bundle, or a "change-of-address" bundle). +Specialized routing logic is then applied in order to route late-bound +bundles addressed to a mobile node, to the mobile's current location +in the network. + +The main interface point is the overridden handle_bundle_received +function which tests for the special TCA bundles (control bundles and +late-bound data bundles). +=20 + +

    link

    + +

    +A link is an abstraction for a DTN link, i.e. a one way communication chan= nel to +a next hop node in the DTN overlay. Use the link command +to configure the manner in which DTN2 will establish a communications +channel to a next hop node. You may set the following variables: + +

    + + +

    link cmd

    +

    +Syntax: link cmd name +
    +Example: link delete trinity_od =20 +

    + + + + + + + +
    cmd +name +Comments + +
    Open +String +open a link=20 + +
    close +String +Close a link + +
    delete=20 +String +Delete a link + +
    state +String +Get state of a link + +
    stats +String +Get link statistics +
    + +     +

    link set_available

    +

    +Syntax: link set_available name avail +
    +Example: link set_available trinity_od true + +

    + + + + + + +
    Variable +Possible settings +Default +Comments + +
    name +String +N/A +Specify a name of a link + +
    avail +true or false +true +hacky way to make the link available (only used with set_available<= /i>) +
    + +     +

    link reconfigure

    +

    +Syntax: link reconfigure name opt=3Dval opt2=3Dval2 optN=3Dv= alN +
    +Example: link reconfigure trinity_od mtu=3D1024 idle_close_t= ime=3D35 + +     +

    link set_cl_defaults

    +

    +Syntax: link set_cl_defaults name conv_layer opt=3Dva= l opt2=3Dval2 optN=3DvalN +
    +Example: link set_cl_defaults trinity_od tcp mtu=3D10= 24 idle_close_time=3D35 + +     +

    link add

    +

    +Syntax: link add name nexthop type conv_layer<= /i> opt=3Dval opt2=3Dval2 optN=3DvalN +
    +Example: link add trinity_od 192.168.1.2 ONDEMAND= tcp mtu=3D1024 potential_downtime=3D25 =20 + +

    + + + + + + + + + + + + + + + + + + + +
    Variable +Possible settings +Default +Comments + +
    name +String +N/A +Specify a name of a link + +
    nexthop +String (address) +N/A +Specify the next hop node. For IP-based links (tcp or udp), +the nexthop should contain a DNS hostname or IP address, followed +optionally by a : and a port. If the port is not specified, the +default of 4556 is used. + +
    type +Link type (see note) +ALLWAYSON, ONDEMAND, SCHEDULED, OPPORTUNISTIC +Specify the link type + +
    conv_layer +udp, tcp, bt, file, eth, norm, null, extcl, serial +N/A +Specify a Convergence Layer Adapter (CLA) +
    opt =20 +Possible settings +Default +Comments + +
    mtu +number (MTU) +Set by link type +The MTU of the link, used to control proactive fragmentation. + +
    min_retry_interval +number (seconds) +Set by link type +The minimum amount to wait between attempts to re-open the link. Defau= lt is set by the various link types but can be overridden by configuration = parameters. + +
    max_retry_interval +number (seconds) +Set by link type +The minimum amount to wait between attempts to re-open the link. Defau= lt is set by the various link types but can be overridden by configuration = parameters. + +
    idle_close_time +number (seconds) +30 for ONDEMAND or 0 for OPPORTUNISTIC & ALLWAYSON +Idle time before the link is closed. MUST be zero for always on links = (i.e. they are never closed). Default is 30 seconds for on demand links, ze= ro for opportunistic links. + +
    potential_downtime +number (seconds) +30 +A conservative estimate of the maximum amount of time that the link ma= y be down during 'normal' operation. Used by routing algorithms to determin= e how long to leave bundles queued on the down link before rerouting them. + +
    prevhop_hdr +true or false +false +Indicates whether or not to send the previous hop header on this link. + +
    cost +number (abstract cost) +100 +The abstract cost of the link, used by routing algorithms. +
    qlimit_bundles_high +number (bundles) +tbc + The high limits on the number of bundles that should be queued on the= link. The high limits are used to indicate whether or not more bundles can= be queued onto the link to effect backpressure from the convergence layers= . + +
    qlimit_bundles_low +number (bundles) +tbc +The low limits on the number of bundles that should be queued on the l= ink. The low limits can be used by the router to determine when to re-scan = the pending bundle lists. + +
    qlimit_bytes_high +number (bytes) +tbc + The high limits on the number of bytes that should be queued on the l= ink. The high limits are used to indicate whether or not more bundles can b= e queued onto the link to effect backpressure from the convergence layers. + +
    qlimit_bytes_low +number (bytes) +tbc +The low limits on the number of bytes that should be queued on the lin= k. The low limits can be used by the router to determine when to re-scan th= e pending bundle lists. + +
    retry_interval +number (seconds) +min_retry_interval +The seconds to wait between attempts to re-open an unavailable link. I= nitially set to min_retry_interval, then doubles up to max_retry_interval + +
    + +     +

    Link Notes

    + + +

    Links are of types as discussed in the DTN architecture +ALWAYSON, ONDEMAND, SCHEDULED, OPPORTUNISTIC. The key differences from an=20 +implementation perspective are "who" and "when" manipulates=20 +the link state regarding availability. + +

    ONDEMAND links are initializd in the AVAILABLE state, as one would +expect. It remains in this state until a router explicitly opens +it. An ONDEMAND link can then be closed either due to connection +failure or because the link has been idle for too long, both +triggered by the convergence layer. If an ONDEMAND link is closed +due to connection failure, then the contact manager is notified of +this event and periodically tries to re-establish the link. + +

    For OPPORTUNISTIC links the availability state is set by the code +which detects that there is a new link available to be used. SCHEDULED=20 +links have their availability dictated by the schedule implementation. + +

    All links in the OPEN state have an associated contact that +represents an actual connection. Every link has a unique name=20 +associated with it which is used to identify it. The name is=20 +configured explicitly when the link is created. + + +

    Getting link statistics

    + +

    The link dump command shows the following attributes for all = links: +

      +
    • link +
    • nexthop +
    • remote eid +
    • type +
    • clayer +
    • state +
    + +

    The link dump name command shows the following detaile= d attributes for a specified link: +

      +
    • Link=20 +
    • clayer +
    • type +
    • state +
    • deleted +
    • nexthop +
    • remote eid +
    • mtu +
    • min_retry_interval +
    • max_retry_interval +
    • idle_close_time +
    • potential_downtime +
    • prevhop_hdr +
    • reactive_frag_enabled +
    • sendbuf_len +
    • recvbuf_len +
    • data_timeout +
    • test_read_delay +
    • test_write_delay +
    • test_recv_delay +
    • segment_ack_enabled +
    • negative_ack_enabled +
    • keepalive_interval +
    • segment_length +
    • local_addr +
    • remote_addr +
    • remote_port +
    + +

    The link stats name command shows the following counts= for a specified link: +

      +
    • contact_attempts +
    • contacts +
    • bundles_transmitted=20 +
    • bytes_transmitted=20 +
    • bundles_queued +
    • bytes_queued=20 +
    • bundles_inflight +
    • bytes_inflight +
    • bundles_cancelled +
    • uptime=20 +
    • throughput_bps +
    • bundles_deferred +
    + +     +

    test

    + +

    +The test command is used by developers to test the DTN2 daemon. I= t is capable of generating a segfault, triggering a panic or false assert. +

    +Syntax: test cmd +
    +Example: test segfault + =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/external-router-interface.h= tml --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/external-router-interface.html Sun Dec 13 21:46:12 2009 -0= 800 @@ -0,0 +1,255 @@ + + + DTN External Router Interface

    DTN External Router Interface

    DRAFT

    Ap= proved for Public Release; Distribution Unlimited. Case + Number: 06-1215

    Copyright © = 2006 The MITRE Corporation. All rights reserved.

    Revision Histor= y
    Revision 0.90= 11.13.06
    Table of Contents

    Overview
    Interface Operation
    Protocol Elements
    Rendezvous
    Links and Contacts
    Routes
    Bundles
    Peer Router Communication
    Failure Recovery
    A. New Configura= tion Directives
    B. Interface Design FAQ

    Overview

    A new implementation architecture is under development that promises + to ease the task of adding new capabilities to DTN. Using generic exte= rnal + interfaces, third-party developers will be able to implement plug-in + modules without having to rewrite or understand the internal workings = of + the DTN2 reference implementation (RI). Plug-in modules are stand-alon= e + processes designed to work in collaboration with DTN. In the longer te= rm, + this effort provides the basis for extending commercial off-the-shelf + (COTS) DTN implementations with domain specific capabilities.

    Th= e External Router Interface, documented here, is the first DTN + external interface designed to move bundle forwarding decisions to an + external process or processes. Benefits of this interface include:

    =

    • Classified and proprie= tary bundle routing algorithms are + protected.

    • External routers may be written in any p= rogramming language (XML + based interface).

    • Prototyping of new bundle routing= algorithms is + streamlined.

    • Routing algorithms may be added and re= moved at runtime.

    This guide is directed at external = router developers and to those + interested in an early product of the new DTN implementation architect= ure. + "Interface Operati= on" describes interface + fundamentals such as underlying protocols and message structure. "Protocol Elements" introd= uces the set of router + interface messages used for inter-process communication. Appendix A sum= marizes new configuration options + introduced with the DTN2 RI external router interface implementation. + Appendix= B is an interface design FAQ of + sorts that attempts to address questions that often arise when first + learning about the interface.

    Important

    Please note that the external router interface is still evolving + and will likely be modified as experience is gained externalizing DT= N + bundle routers. Future work on other interfaces, including + convergence-layer and storage interfaces, may also impact the interf= ace. + The latest "bleeding edge" version of the DTN2 RI includes support f= or + the external router interface documented here and is available at www.dtnrg.org.

    =

    Interfa= ce Operation

    Before diving into the details, this = section discusses the overall + design and operation of the router interface. When compiled, the DTN2 = RI + 2.2.0 release (the latest formal DTN2 release as of this writing) prod= uces + one multi-threaded executable, a DTN daemon. This daemon is a complete= DTN + node; it accepts bundles from a number of built-in convergence layers, + provides persistent bundle storage, delivers bundles to local DTN + applications, selects routes using built-in routing logic, and forward= s + bundles to peer DTN nodes. For the purposes of this document, a forwarder is a DTN daemon as described above, but one + that depends on external routing processes to make bundle routing + decisions on its behalf.

    The forwarder communicates with externa= l routing processes:

    • <= p>with an XML-based messaging protocol

    • using a well-known IP= v4 multicast address and UDP port

    • on local or remote hosts

    Before forwarders and external routers can communicate= , they each + must join the all-routers multicast group (224.0.0.2) and bind to a + well-known UDP port. Forwarders are not aware if zero, one, or more + external routers have joined the multicast group. It is the responsibi= lity + of the system administrator to ensure router availability.

    Nothi= ng in the interface design precludes running forwarders and + external routers on different hosts, however this approach is not + recommended especially in wireless and/or bandwidth-constrained + environments. The interface is fairly chatty, UDP is unreliable, and t= here + is a high risk of packet loss leading to a breakdown in synchronized + state. (The DTN2 RI external router interface is hard coded to use the + loopback interface and therefore requires forwarders and external rout= ers + to reside on the same host.)

    Inter-process messages are XML-base= d and must be valid against the + external router X= ML schema. + Interface messages are broadly divided into four categories. Event + messages are issued by forwarders to indicate state changes that may b= e of + interest to external routers. Request messages are sent by external + routers to direct forwarders to perform an action (e.g. "forward the + bundle with ID 56 out link tcp0"). Query and report messages are used = by + external routers to synchronize their state with forwarders after boot= up + or during failure recovery. The proper usage and interpretation of eac= h + interface message is covered in the next section.

    How does the f= orwarder authenticate external processes? It doesn't. + The forwarder makes the assumption that (local or remote) external rou= ters + are within the same security domain. In addition, system administrator= s + must ensure there exists one authoritative router or policy module per= DTN + "node”, or that multiple external routers are configured in a co= operative + manner to correctly handle all events.

    In addition to external r= outers, other "read-only" types of + processes may join the all-routers multicast group. An external loggin= g + application, for example, could be written to display the current stat= e of + the forwarder simply by listening to external router interface message= s. + However, this concept is not pursued further in this document. The + following discussion is limited to inter-process communication between + forwarders and external routers.

    Protocol Elements

    =

    This section describes each interface message according to purpose. + Hyper-links to generated schema documentation are located throughout t= he + text. To generate the documentation, cd to= the top level + directory of DTN2 source code and type make xsddo= c. You will + need xsddoc-1.0 + and java installed for this to work.

    Rendezvous

    When a forwarder is configured = for external routing, it + periodically multicasts hello messages to announce its presence to + external routers. Each hello message includes the EID of the sender = and + the interval in seconds between each message. For example, the + message

    <dtn eid=3D"dtn://nodeX" + hello_interval=3D"30"/>

    notifies external routers th= at the DTN forwarder with EID + dtn://nodeX is running and will send another hello message in 30 + seconds. Router implementations may filter incoming messages by EID = if + it becomes necessary to run more than one forwarder on a single + platform.

    After routers receive one or more hello messages fro= m any (or a + specific) DTN node, they must synchronize their state with the + forwarder. Several routing interface messages are designed to facili= tate + state synchronization and have a common format. If x represents + meta-information of interest, the message x_query prompts the forwar= der + to send an x_report message. For example, a bundle_query + message asks the forwarder to generate and send a bundle_report + message.

    Routers may query the forwarder for four types of + meta-information. contact_report + includes meta-information on all open connections between the local + forwarder and remote forwarders. Low-level convergence layer + meta-information is also included for each contact. link_report<= /a> + contains meta information on all forwarder links regardless of the + current state. route_report + is composed of meta-information on all static routes configured on t= he + DTN console (if any). bundle_report + lists meta-information on each bundle stored by the local + forwarder.

    After synchronizing their state with a forwarder, e= xternal routers + process incoming events as they arrive and send requests when + necessary.

    Links and = Contacts

    DTN links represent a one way communicati= on channel to next hop + DTN nodes. Links are either explicitly created in the forwarder + configuration file (dtn.conf) or spr= ing into + existence as a result of the neighbor discovery mechanism. Four type= s of + links exist: always on, on + demand, scheduled, and + opportunistic. l= ink_created_event + messages announce the existence of new links and include such attrib= utes + as name, type, and destination EID along with other meta-information= . + link_deleted_event + notifies external routers that a named link has been destroyed. link_available_event + and link_unavailable_event + messages are automatically generated by the forwarder when links are + open or closed respectively.

    The forwarder attempts to keep al= ways on and opportunistic links + open always. Scheduled links are automatically opened and closed + according to configured start and duration settings. On demand links= , + however, must be explicitly opened by the router using an = open_link_request. + After on demand links are idle for a set period of time (currently 3= 0 + seconds), they are closed by the forwarder.

    When the state of = any link is either open or busy, a contact + element is also available which tracks connection and convergence la= yer + statistics that may be useful to routing algorithms. contac= t_up_event + and contact_down_event + messages notify routers when contacts are available or + unavailable.

    Most link and contact messages carry a coarse "re= ason" attribute + to explain what prompted each link state change.

    Routes

    The primary fun= ction of DTN external routers is to maintain a + forwarding information base of optimal next hop DTN nodes for remote= EID + prefixes. Routes to remote EID prefixes are either statically + configured, learned from the DTN neighbor discovery mechanism, or + learned from peer router communications. Specific DTN routing algori= thms + and implementations are beyond the scope of this document.

    Sta= tic routes may be configured in the forwarder configuration + file or directly on the DTN console. When static routes are specifie= d, a + route_add_event + is multicast to external routers. Router implementations may choose = to + add static routes to internal routing tables (possibly with an + identifying marker indicating the source or administrative distance)= or + simply ignore their existence. The route_delete_event + message is issued when a static route has been deleted at the DTN + console.

    The external router interface does not include messag= es to support + the display of external routing tables on the DTN console. All but t= he + most simplistic external routers should have their own "console" for + configuration and routing table displays.

    Bundles

    Bundles arriving at a= forwarder, either from a remote DTN node or + from a local application, are announced with a bundle_= received_event + message. Bundle payload is not forwarded over the interface, only + meta-information.

    When an opportunity exists to forward a bund= le, the external + router issues a send_bundle_request + which includes the local bundle id, name of the outgoing link, and t= he + desired forwarding behavior. Meta-information about the bundle shoul= d + not be erased until a positive acknowledgement is received from the + forwarder.

    bundle_transmitted_event + states that a bundle has been successfully transmitted using the + identified contact. On reliable links, this means acknowledgements w= ere + received, on unreliable links, a best effort attempt was made to sen= d + the bundle. A failed transmission is indicated by the bundle_transmit_failed_event + message and may warrant a retransmission by the router if + possible.

    For successfully transmitted bundles, routers can re= lease all + resources dedicated to tracking the bundle unless the sender had + requested custody transfer. If custody was requested, the router mus= t + continue to track the bundle until it receives a corresponding custo= dy + message. If custody was accepted by a downstream DTN node, a custody_signal_event + is generated. Bundle meta-information can now be released by the rou= ter. + If custody failed, indicated by the suc= ceeded + attribute in the custody_signal_event, + or the router receives a custody_timeout_event + (i.e. no response from a downstream DTN node), the router may attemp= t to + retransmit the bundle if possible.

    bundle_expired= _event + notifies the router that a bundle has expired and is being deleted f= rom + the store. External routers should remove all records of the + bundle.

    cancel_bundle_request + asks the forwarder to abort a previous send_bundle request if possib= le. + (As of this writing, cancel_bundle_request is not implemented in the + DTN2 RI.)

    Peer Router= Communication

    Many routing algorithms require inf= ormation exchange between peer + routers. Communication between peer DTN external routers boils down = to + identifying methods for sending and receiving router message bundles= . + Two methods are currently available; the first utilizes the DTN2 + application interface and the second is offered by the external rout= er + interface itself.

    External router developers may elect to buil= d their external + routers with two personalities, to behave as an external router and = as a + DTN application. The external router interface handles all bundle + forwarding tasks while the application interface is used to send and + receive peer router messages. In order for this method to work, exte= rnal + routers must register with the forwarder as a DTN application and su= pply + a well-known service tag for bundle deliveries. It seems intuitive t= hat + the service tag would signify the routing algorithm. For example, an + external router implementing a flooding algorithm may register with = the + forwarder using the service tag "flood_rtr".

    This approach off= ers several benefits: the DTN application + interface is reliable, there is no limit on bundle size, and + router-originated bundles follow the same path as "normal" applicati= on + bundles and are subject to the same policies. Cons include increased + development complexity and the fact that external routers can't spec= ify + an outgoing link using the application API. The forwarder defers to = the + external router the decision of where to forward router-originated + bundles.

    The second alternative is to send locally generated b= undle + payloads to the forwarder on inject_bundle_request + messages. Destination EID, outgoing link, and other attributes requi= red + for bundle forwarding are supplied as well as the payload to inject. + Router-originated bundle payloads are assumed to be binary blobs and= are + Base64 encoded. No attempt is made to decode or process + router-originated bundle payloads except by the destination remote + router process. Forwarders notify external routers of successful or + failed transmissions in the same manner as "normal" bundles (I need = to + check this...). Unlike DTN application bundles, router injected bund= les + are not cached. If transmission fails, bundles are dropped.

    At= boot-up, the external router interface registers with the + forwarder to receive all bundles destined to “ext.rtr/*”= . As in the + previous example, a service tag is chosen by the external router + developer to uniquely identify the router. Arriving bundles matching= the + registration "ext_rtr/*" are announced with the bundle= _delivery_event + message. Upon receipt of this message, routers must examine the bund= le's + destination EID to determine the intended recipient of the bundle. + Bundle payloads are read in or otherwise accessed using the filename + attribute associated with bundle payload meta-information.

    =

    Failure Recovery

    Since IPC between forwarders and external routers is + connectionless, one process can fail without the other's immediate + knowledge. Consider the case where there is one forwarder process an= d + one external router process. Five states are possible 1) both proces= s + are up, 2) forwarder is up, external router is down, 3) forwarder is + down, external router is up, 4) forwarder crashes and comes back up + within a hello interval, and 5) both processes are down. Obviously, = Case + 1 does not belong in a Failure Recovery Section.

    A discussion = of Case 2 yields an interesting point. The forwarder + does not monitor whether zero, one, or more external routers are run= ning + and/or are members of the all-routers multicast group. Event message= s + are multicast to the all-routers group, by the forwarder, regardless= of + external router state. When an external router is restarted, it shou= ld + immediately synchronize its state with the forwarder in much the sam= e + manner as the initial bootup sequence discussed in the previous + section.

    There are two instances in the life of a forwarder wh= ere the hello + message includes an additional attribute. The "alert" attribute prov= ides + additional information about the overall state of the forwarder and + facilitates failure recovery in the remaining cases. Two values are + currently valid: "justBooted" and "shuttingDown". At bootup, the + forwarder always sends the "justBooted" alert with the first hello + message. When the forwarder is shut down in an orderly fashion (by + issuing "quit" at the console for example), a hello message is + immediately sent that includes the "shuttingDown" alert. However, if= the + forwarder should crash or is otherwise shutdown in an unorderly mann= er, + there is no guarantee that a "shuttingDown" alert will be sent.

    <= p>For Case 3, the external router determines the forwarder is down + either by receiving a hello message with a "shuttingDown" alert or a= fter + hello interval seconds have passed without receiving a message. At t= his + point, the router must stop sending messages, wait until another hel= lo + message is received, synchronize its state with the forwarder, and + resume normal operations.

    The external router knows it is deal= ing with Case 4 if it receives + a "justBooted" alert in less than or equal to one hello interval. Th= e + router must stop sending messages, synchronize its state with the + forwarder, and resume normal operations.

    Towards the goal of m= aking DTN a turnkey solution, additional + "helper" processes are being developed whose sole purpose is to watc= h + and restart forwarders and external routers if and when they fail. + Helper processes will play a critical role in addressing Cases 2 - + 5.

    A. New Configura= tion Directives

    This section describes four new configuration direct= ives that + accompany the DTNRG RI external router interface.

    To enable the = external router feature, set the forwarder router type + to "external".

    route set type external

    Next, provide the full pathname of the XML schema file "router.= xsd" + (originally located in the DTN2 source distribution daemon + directory).

    route set schema <pathnam= e>

    The remaining directives are optional (i.e. they have de= fault + values).

    The default UDP port for external router communications= is 8001. To + change it, include the following directive in + dtn.conf.

    route set server_port <udp port>

    The number of seconds= between forwarder hello messages can also be + changed from the default of 30 seconds.

    = route set hello_interval <seconds>

    B. Interface Design FAQ

    Why multicast?

    = Why UDP?

    Why XML?

    ...

    \ No newline at end of file diff -r 8b0d483af1e2 -r e62055127255 doc/manual/html/doxygen.css --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/html/doxygen.css Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,441 @@ +body, table, div, p, dl { + font-family: Lucida Grande, Verdana, Geneva, Arial, sans-serif; + font-size: 12px; +} + +/* @group Heading Levels */ + +h1 { + text-align: center; + font-size: 150%; +} + +h2 { + font-size: 120%; +} + +h3 { + font-size: 100%; +} + +/* @end */ + +caption { + font-weight: bold; +} + +div.qindex, div.navtab{ + background-color: #e8eef2; + border: 1px solid #84b0c7; + text-align: center; + margin: 2px; + padding: 2px; +} + +div.qindex, div.navpath { + width: 100%; + line-height: 140%; +} + +div.navtab { + margin-right: 15px; +} + +/* @group Link Styling */ + +a { + color: #153788; + font-weight: normal; + text-decoration: none; +} + +.contents a:visited { + color: #1b77c5; +} + +a:hover { + text-decoration: underline; +} + +a.qindex { + font-weight: bold; +} + +a.qindexHL { + font-weight: bold; + background-color: #6666cc; + color: #ffffff; + border: 1px double #9295C2; +} + +.contents a.qindexHL:visited { + color: #ffffff; +} + +a.el { + font-weight: bold; +} + +a.elRef { +} + +a.code { +} + +a.codeRef { +} + +/* @end */ + +dl.el { + margin-left: -1cm; +} + +.fragment { + font-family: monospace, fixed; + font-size: 105%; +} + +pre.fragment { + border: 1px solid #CCCCCC; + background-color: #f5f5f5; + padding: 4px 6px; + margin: 4px 8px 4px 2px; +} + +div.ah { + background-color: black; + font-weight: bold; + color: #ffffff; + margin-bottom: 3px; + margin-top: 3px +} + +div.groupHeader { + margin-left: 16px; + margin-top: 12px; + margin-bottom: 6px; + font-weight: bold; +} + +div.groupText { + margin-left: 16px; + font-style: italic; +} + +body { + background: white; + color: black; + margin-right: 20px; + margin-left: 20px; +} + +td.indexkey { + background-color: #e8eef2; + font-weight: bold; + border: 1px solid #CCCCCC; + margin: 2px 0px 2px 0; + padding: 2px 10px; +} + +td.indexvalue { + background-color: #e8eef2; + border: 1px solid #CCCCCC; + padding: 2px 10px; + margin: 2px 0px; +} + +tr.memlist { + background-color: #f0f0f0; +} + +p.formulaDsp { + text-align: center; +} + +img.formulaDsp { +=09 +} + +img.formulaInl { + vertical-align: middle; +} + +/* @group Code Colorization */ + +span.keyword { + color: #008000 +} + +span.keywordtype { + color: #604020 +} + +span.keywordflow { + color: #e08000 +} + +span.comment { + color: #800000 +} + +span.preprocessor { + color: #806020 +} + +span.stringliteral { + color: #002080 +} + +span.charliteral { + color: #008080 +} + +span.vhdldigit {=20 + color: #ff00ff=20 +} + +span.vhdlchar {=20 + color: #000000=20 +} + +span.vhdlkeyword {=20 + color: #700070=20 +} + +span.vhdllogic {=20 + color: #ff0000=20 +} + +/* @end */ + +.search { + color: #003399; + font-weight: bold; +} + +form.search { + margin-bottom: 0px; + margin-top: 0px; +} + +input.search { + font-size: 75%; + color: #000080; + font-weight: normal; + background-color: #e8eef2; +} + +td.tiny { + font-size: 75%; +} + +.dirtab { + padding: 4px; + border-collapse: collapse; + border: 1px solid #84b0c7; +} + +th.dirtab { + background: #e8eef2; + font-weight: bold; +} + +hr { + height: 0; + border: none; + border-top: 1px solid #666; +} + +/* @group Member Descriptions */ + +.mdescLeft, .mdescRight, +.memItemLeft, .memItemRight, +.memTemplItemLeft, .memTemplItemRight, .memTemplParams { + background-color: #FAFAFA; + border: none; + margin: 4px; + padding: 1px 0 0 8px; +} + +.mdescLeft, .mdescRight { + padding: 0px 8px 4px 8px; + color: #555; +} + +.memItemLeft, .memItemRight, .memTemplParams { + border-top: 1px solid #ccc; +} + +.memTemplParams { + color: #606060; +} + +/* @end */ + +/* @group Member Details */ + +/* Styles for detailed member documentation */ + +.memtemplate { + font-size: 80%; + color: #606060; + font-weight: normal; + margin-left: 3px; +} + +.memnav { + background-color: #e8eef2; + border: 1px solid #84b0c7; + text-align: center; + margin: 2px; + margin-right: 15px; + padding: 2px; +} + +.memitem { + padding: 0; +} + +.memname { + white-space: nowrap; + font-weight: bold; +} + +.memproto, .memdoc { + border: 1px solid #84b0c7;=09 +} + +.memproto { + padding: 0; + background-color: #d5e1e8; + font-weight: bold; + -webkit-border-top-left-radius: 8px; + -webkit-border-top-right-radius: 8px; + -moz-border-radius-topleft: 8px; + -moz-border-radius-topright: 8px; +} + +.memdoc { + padding: 2px 5px; + background-color: #eef3f5; + border-top-width: 0; + -webkit-border-bottom-left-radius: 8px; + -webkit-border-bottom-right-radius: 8px; + -moz-border-radius-bottomleft: 8px; + -moz-border-radius-bottomright: 8px; +} + +.paramkey { + text-align: right; +} + +.paramtype { + white-space: nowrap; +} + +.paramname { + color: #602020; + white-space: nowrap; +} +.paramname em { + font-style: normal; +} + +/* @end */ + +/* @group Directory (tree) */ + +/* for the tree view */ + +.ftvtree { + font-family: sans-serif; + margin: 0.5em; +} + +/* these are for tree view when used as main index */ + +.directory { + font-size: 9pt; + font-weight: bold; +} + +.directory h3 { + margin: 0px; + margin-top: 1em; + font-size: 11pt; +} + +/* +The following two styles can be used to replace the root node title +with an image of your choice. Simply uncomment the next two styles, +specify the name of your image and be sure to set 'height' to the +proper pixel height of your image. +*/ + +/* +.directory h3.swap { + height: 61px; + background-repeat: no-repeat; + background-image: url("yourimage.gif"); +} +.directory h3.swap span { + display: none; +} +*/ + +.directory > h3 { + margin-top: 0; +} + +.directory p { + margin: 0px; + white-space: nowrap; +} + +.directory div { + display: none; + margin: 0px; +} + +.directory img { + vertical-align: -30%; +} + +/* these are for tree view when not used as main index */ + +.directory-alt { + font-size: 100%; + font-weight: bold; +} + +.directory-alt h3 { + margin: 0px; + margin-top: 1em; + font-size: 11pt; +} + +.directory-alt > h3 { + margin-top: 0; +} + +.directory-alt p { + margin: 0px; + white-space: nowrap; +} + +.directory-alt div { + display: none; + margin: 0px; +} + +.directory-alt img { + vertical-align: -30%; +} + +/* @end */ + +address { + font-style: normal; + color: #333; +} diff -r 8b0d483af1e2 -r e62055127255 doc/manual/html/tabs.css --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/html/tabs.css Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,105 @@ +/* tabs styles, based on http://www.alistapart.com/articles/slidingdoors *= / + +DIV.tabs +{ + float : left; + width : 100%; + background : url("tab_b.gif") repeat-x bottom; + margin-bottom : 4px; +} + +DIV.tabs UL +{ + margin : 0px; + padding-left : 10px; + list-style : none; +} + +DIV.tabs LI, DIV.tabs FORM +{ + display : inline; + margin : 0px; + padding : 0px; +} + +DIV.tabs FORM +{ + float : right; +} + +DIV.tabs A +{ + float : left; + background : url("tab_r.gif") no-repeat right top; + border-bottom : 1px solid #84B0C7; + font-size : 80%; + font-weight : bold; + text-decoration : none; +} + +DIV.tabs A:hover +{ + background-position: 100% -150px; +} + +DIV.tabs A:link, DIV.tabs A:visited, +DIV.tabs A:active, DIV.tabs A:hover +{ + color: #1A419D; +} + +DIV.tabs SPAN +{ + float : left; + display : block; + background : url("tab_l.gif") no-repeat left top; + padding : 5px 9px; + white-space : nowrap; +} + +DIV.tabs INPUT +{ + float : right; + display : inline; + font-size : 1em; +} + +DIV.tabs TD +{ + font-size : 80%; + font-weight : bold; + text-decoration : none; +} + + + +/* Commented Backslash Hack hides rule from IE5-Mac \*/ +DIV.tabs SPAN {float : none;} +/* End IE5-Mac hack */ + +DIV.tabs A:hover SPAN +{ + background-position: 0% -150px; +} + +DIV.tabs LI.current A +{ + background-position: 100% -150px; + border-width : 0px; +} + +DIV.tabs LI.current SPAN +{ + background-position: 0% -150px; + padding-bottom : 6px; +} + +DIV.navpath +{ + background : none; + border : none; + border-bottom : 1px solid #84B0C7; + text-align : center; + margin : 2px; + padding : 2px; +} diff -r 8b0d483af1e2 -r e62055127255 doc/manual/index.html --- a/doc/manual/index.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/index.html Sun Dec 13 21:46:12 2009 -0800 @@ -8,37 +8,122 @@ =20
      -
    • Getting Started - +
    • Getting Started + =20 -
    • Tutorials - +
    • Tutorials + =20 -
    • Reference - +
    • Reference +
    • Manual Contruction Topics
      • Style Guide for manual writers diff -r 8b0d483af1e2 -r e62055127255 doc/manual/intro.html --- a/doc/manual/intro.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/intro.html Sun Dec 13 21:46:12 2009 -0800 @@ -51,8 +51,9 @@

        Though DTN2 appeals to researchers, it is also intended to be high-quality, production-grade code ready for use in real world deployments. It has already been deployed to Cambodia and India -as part of the TIER -Project, and we +as part of the TIER, +Project, to Swedish Lapland as part of the=20 +N4C project, and we hope to see it deployed to many other environments that need to benefits of a DTN. =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/latex/FreeSans.ttf Binary file doc/manual/latex/FreeSans.ttf has changed diff -r 8b0d483af1e2 -r e62055127255 doc/manual/latex/Makefile --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/latex/Makefile Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,19 @@ +all: clean refman.pdf + +pdf: refman.pdf + +refman.pdf: refman.tex + pdflatex refman.tex + makeindex refman.idx + pdflatex refman.tex + latex_count=3D5 ; \ + while egrep -s 'Rerun (LaTeX|to get cross-references right)' refman.log &= & [ $$latex_count -gt 0 ] ;\ + do \ + echo "Rerunning latex...." ;\ + pdflatex refman.tex ;\ + latex_count=3D`expr $$latex_count - 1` ;\ + done + + +clean: + rm -f *.ps *.dvi *.aux *.toc *.idx *.ind *.ilg *.log *.out refman.pdf diff -r 8b0d483af1e2 -r e62055127255 doc/manual/latex/doxygen.sty --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/latex/doxygen.sty Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,86 @@ +\NeedsTeXFormat{LaTeX2e} +\ProvidesPackage{doxygen} +\RequirePackage{calc} +\RequirePackage{array} +\pagestyle{fancyplain} +\newcommand{\clearemptydoublepage}{\newpage{\pagestyle{empty}\cleardoublep= age}} +\renewcommand{\chaptermark}[1]{\markboth{#1}{}} +\renewcommand{\sectionmark}[1]{\markright{\thesection\ #1}} +\lhead[\fancyplain{}{\bfseries\thepage}] + {\fancyplain{}{\bfseries\rightmark}} +\rhead[\fancyplain{}{\bfseries\leftmark}] + {\fancyplain{}{\bfseries\thepage}} +\rfoot[\fancyplain{}{\bfseries\scriptsize Generated on Tue Sep 29 11:49:49= 2009 for dtn2 by Doxygen }]{} +\lfoot[]{\fancyplain{}{\bfseries\scriptsize Generated on Tue Sep 29 11:49:= 49 2009 for dtn2 by Doxygen }} +\cfoot{} +\newenvironment{Code} +{\footnotesize} +{\normalsize} +\newcommand{\doxyref}[3]{\textbf{#1} (\textnormal{#2}\,\pageref{#3})} +\newenvironment{DocInclude} +{\footnotesize} +{\normalsize} +\newenvironment{VerbInclude} +{\footnotesize} +{\normalsize} +\newenvironment{Image} +{\begin{figure}[H]} +{\end{figure}} +\newenvironment{ImageNoCaption}{}{} +\newenvironment{CompactList} +{\begin{list}{}{ + \setlength{\leftmargin}{0.5cm} + \setlength{\itemsep}{0pt} + \setlength{\parsep}{0pt} + \setlength{\topsep}{0pt} + \renewcommand{\makelabel}{\hfill}}} +{\end{list}} +\newenvironment{CompactItemize} +{ + \begin{itemize} + \setlength{\itemsep}{-3pt} + \setlength{\parsep}{0pt} + \setlength{\topsep}{0pt} + \setlength{\partopsep}{0pt} +} +{\end{itemize}} +\newcommand{\PBS}[1]{\let\temp=3D\\#1\let\\=3D\temp} +\newlength{\tmplength} +\newenvironment{TabularC}[1] +{ +\setlength{\tmplength} + {\linewidth/(#1)-\tabcolsep*2-\arrayrulewidth*(#1+1)/(#1)} + \par\begin{tabular*}{\linewidth} + {*{#1}{|>{\PBS\raggedright\hspace{0pt}}p{\the\tmplength}}|} +} +{\end{tabular*}\par} +\newcommand{\entrylabel}[1]{ + {\parbox[b]{\labelwidth-4pt}{\makebox[0pt][l]{\textbf{#1}}\vspace{1.5\b= aselineskip}}}} +\newenvironment{Desc} +{\begin{list}{} + { + \settowidth{\labelwidth}{40pt} + \setlength{\leftmargin}{\labelwidth} + \setlength{\parsep}{0pt} + \setlength{\itemsep}{-4pt} + \renewcommand{\makelabel}{\entrylabel} + } +} +{\end{list}} +\newenvironment{Indent} + {\begin{list}{}{\setlength{\leftmargin}{0.5cm}} + \item[]\ignorespaces} + {\unskip\end{list}} +\setlength{\parindent}{0cm} +\setlength{\parskip}{0.2cm} +\addtocounter{secnumdepth}{1} +\sloppy +\usepackage[T1]{fontenc} +\makeatletter +\renewcommand{\paragraph}{\@startsection{paragraph}{4}{0ex}% + {-3.25ex plus -1ex minus -0.2ex}% + {1.5ex plus 0.2ex}% + {\normalfont\normalsize\bfseries}} +\makeatother +\stepcounter{secnumdepth} +\stepcounter{tocdepth} diff -r 8b0d483af1e2 -r e62055127255 doc/manual/latex/refman.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/latex/refman.tex Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,50 @@ +\documentclass[a4paper]{book} +\usepackage{a4wide} +\usepackage{makeidx} +\usepackage{fancyhdr} +\usepackage{graphicx} +\usepackage{multicol} +\usepackage{float} +\usepackage{textcomp} +\usepackage{alltt} +\usepackage{times} +\usepackage{ifpdf} +\ifpdf +\usepackage[pdftex, + pagebackref=3Dtrue, + colorlinks=3Dtrue, + linkcolor=3Dblue, + unicode + ]{hyperref} +\else +\usepackage[ps2pdf, + pagebackref=3Dtrue, + colorlinks=3Dtrue, + linkcolor=3Dblue, + unicode + ]{hyperref} +\usepackage{pspicture} +\fi +\usepackage[utf8]{inputenc} +\usepackage{doxygen} +\makeindex +\setcounter{tocdepth}{3} +\renewcommand{\footrulewidth}{0.4pt} +\begin{document} +\begin{titlepage} +\vspace*{7cm} +\begin{center} +{\Large dtn2 \\[1ex]\large 2.6 }\\ +\vspace*{1cm} +{\large Generated by Doxygen 1.5.8}\\ +\vspace*{0.5cm} +{\small Tue Sep 29 11:49:49 2009}\\ +\end{center} +\end{titlepage} +\clearemptydoublepage +\pagenumbering{roman} +\tableofcontents +\clearemptydoublepage +\pagenumbering{arabic} +\printindex +\end{document} diff -r 8b0d483af1e2 -r e62055127255 doc/manual/license.html --- a/doc/manual/license.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/license.html Sun Dec 13 21:46:12 2009 -0800 @@ -6,46 +6,210 @@

        License

        - -First, a brief word from our lawyers: - 
        -IMPORTANT: READ BEFORE DOWNLOADING, COPYING, INSTALLING OR USING. By
-downloading, copying, installing or using the software you agree to
-this license. If you do not agree to this license, do not download,
-install, copy or use the software.
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
=20
-Intel Open Source License
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
=20
-Copyright (c) 2004 Intel Corporation. All rights reserved.
+   1. Definitions.
=20
-Redistribution and use in source and binary forms, with or without
-modification, are permitted provided that the following conditions are
-met:
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document=
.
=20
-  Redistributions of source code must retain the above copyright
-  notice, this list of conditions and the following disclaimer.
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
=20
-  Redistributions in binary form must reproduce the above copyright
-  notice, this list of conditions and the following disclaimer in the
-  documentation and/or other materials provided with the distribution.
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
=20
-  Neither the name of the Intel Corporation nor the names of its
-  contributors may be used to endorse or promote products derived from
-  this software without specific prior written permission.
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
=20
-THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE INTEL OR
-ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+      "Source" form shall mean the preferred form for making modifications=
,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modificatio=
ns
+      represent, as a whole, an original work of authorship. For the purpo=
ses
+      of this License, Derivative Works shall not include works that remai=
n
+      separable from, or merely link (or bind by name) to the interfaces o=
f,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright own=
er
+      or by an individual or Legal Entity authorized to submit on behalf o=
f
+      the copyright owner. For the purposes of this definition, "submitted=
"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control syste=
ms,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution.=
"
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made=
,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing th=
e
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this Licens=
e.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied=
.
+   See the License for the specific language governing permissions and
+   limitations under the License.
+
        =20 diff -r 8b0d483af1e2 -r e62055127255 doc/manual/logging.html --- a/doc/manual/logging.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/logging.html Sun Dec 13 21:46:12 2009 -0800 @@ -13,23 +13,45 @@ levels for each log path. =20

        +The logging in DTN is organized into hierarchical paths.=20 +The basic idea is that a logf command contains an arbitrary log path, +a level, and a printf-style body. For example: +

        +logf("/some/path", LOG_INFO, "something happened %d times", count); + + + +

        .dtndebug

        If the file ~/.dtndebug exists, it can be used to customize which log messages are emitted and which are ignored. It is read -one line at a time. Lines may start with "#" to indicate a +from the top down, one line at a time. Lines may start with "#" to indicat= e a comment. Blank lines are ignored. Any other line should have a logpath in the left column, and a log level in the right column. The columns are separated by spaces and/or tabs. =20

        -For instance, this .dtndebug file makes the default -level info, but causes debug info to be printed for all link +For instance, this .dtndebug file makes the default level for=20 +/dtn/* to be info, but causes debug info to be printed for all link operations other than for tcp0. =20 

        # example .dtndebug file
=20
-/		info
-/link/tcp0	info
-/link		debug
        +/dtn/link/tcp0 info +/dtn/link debug +/dtn info +
    • + +

    =20 +Note that the order is important. If /dtn info was place=20 +first in the list the entries this would have the effect of overriding=20 +entries after to log level info. + +

    # example .dtndebug file
+
+/dtn            info
+/dtn/link/tcp0  info
+/dtn/link       debug  =20
+
    =20

    In dtnd, the log messages go out to standard out, by default. You can change that using the "-o filename" option to dtnd. @@ -45,28 +67,78 @@

  • always =20 -

    Below is an incomplete list of log paths used by the DTN2 -implementation. You can find others by observing output with -logging turned up to the maximum ("/ debug") or by searching -for logpath in the source code. +

    =20 +

    ~/.dtndebug file options

    + +

    There are several options that can be used to customize the display +of debug output, and these options are specified on a line in the +.dtndebug file prefixed with '%'

    A detailed example of a .dtndebug fil= e with + options (incomplete!) is provided here.

    -
    /dtnd dtnd server startup/operation -
    /dtnserver dtnd internals -
    /interface interface management -
    /link/$linkname link management -
    /storage/$dbtype database operations -
    /route routing related messages -
    /tcl Errors from TCL (the underlying interpreter) -
    /assert Failing assertions -
    /apisrv API Server -
    /apisrv/sock API Server (socket-specific messages) -
    /cl/tcp TCP Convergence Layer -
    /cl/tcp/conn/$ip:$port connection specific messages -
    /cl/udp UDP Convergence Layer -
    /contact/bundles   -
    /registration   + +
    no_path Don't display log path +
    no_time Don't display time stamp +
    no_level Don't display log level +
    brief Truncate log name to a fixed length and use brief er= ror codes +
    color Use terminal escape code to colorize output +
    object When possible, display the address of the object th= at=20 +generated the log. +
    classname When possible, display the class that generated th= e log message. +
    +

    See comments in oasys/debug/{Log,Logger}.h for a more in-depth explanat= ion. + +

    Logging Targets

    + +

    Below is an incomplete list of logging targets used by the DTN2 +implementation. You can find others by observing output with +logging turned up to the maximum ("/ debug" || dtnd -l debug) or by search= ing +for logpath in the source code. +

    + + +
    /command Singleton tcl command interpre= ter +
    /command/<command_name> Specific command "command_name= " +
    /log Internal logging system +
    /timer Timer system +
    /thread Threading system + +
    /dtnd DTN daemon wrapper +
    /dtn/bundle/actions BundleActions interface +
    /dtn/bundle/daemon BundleDaemon forwarder and bas= ic logic +
    /dtn/bundle/fragmentation Fragmentation related code +
    /dtn/bundle/list/<name> BundleList data structure +
    /dtn/bundle/protocol Bundle wire protocol +
    /dtn/bundle/refs Reference counting for in-memo= ry bundle objs +
    /dtn/cl/<name> Convergence layer +
    /dtn/cl/tcp TCP Convergence Layer +
    /dtn/cl/udp UDP Convergence Laye +
    /dtn/cl/tcp/conn TCP convergence layer connecti= on +
    /dtn/contact/manager Contact Managment +
    /dtn/interface/table Local Interface table +
    /dtn/link/<name> Links to next-hop peers +
    /dtn/link/<name>/contact Open contact on links +
    /dtn/route/<name> BundleRouter <name> +
    /dtn/registration/<regid> Registration +
    /dtn/registration/table Table of registrations +
    /dtn/storage/bundles Storage backend for bundles +
    /dtn/storage/global Storage backend for global dat= a +
    /dtn/interface interface management +
    /dtn/tclcmd Errors from TCL commands +
    /dtn/apiserver API Server +
    /dtn/apiclient API Client +
    /dtn/discovery$name discovery +
    /dtn/discovery/ip IP discovery +
    /dtn/discovery/bt Bluetooth discovery +
    /dtn/bundle Bundle +
    /dtn/bundle/actions BundleActions interface +
    /dtn/bundle/daemon BundleDaemon forwarder and basic logic +
    /dtn/bundle/fragmentation Fragmentation related code +
    /dtn/bundle/list/$name BundleList data structure +
    /dtn/bundle/protocol Bundle wire protocol +
    /dtn/bundle/refs Reference counting for in-memory bundle objs +
    /dtn/contact/manager Contact manager 
    =20

    Rereading the .dtndebug file

    diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtncat.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtncat.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,52 @@ + + + DTN2 Man pages: dtncat + + + +

    dtncat +

    + +

    +

    NAME +

    +

    +dtncat - source bundles from stdin or receive bundles to stdout. Resem= bles the nc (netcat) unix program + +

    SYNOPSIS +

    =20 +

    +To source bundles from stdin: +

    +usage: dtncat [opts] -s EID -d EID +

    +To receive bundles to stdout: +

    +usage: dtncat [opts] -l EID +

    DESCRIPTION +

    +

    common options: +

    + -v verbose
+ -h/H help
+ -i regid registration id for listening
+receive only options (-l option required):
+ -l eid receive bundles destined for eid (instead of sending)
+ -n count exit after count bundles received (-l option required)
+send only options (-l option prohibited):
+ -s eid|demux_string source eid
+ -d eid|demux_string destination eid
+ -r eid|demux_string reply to eid
+ -e time expiration time in seconds (default: one hour)
+ -c request custody transfer
+ -C request custody transfer receipts
+ -D request for end-to-end delivery receipt
+ -R request for bundle reception receipts
+ -F request for bundle forwarding receipts
+ -w wait for bundle status reports
+ -S sequence_id sequence id vector
+ -O obsoletes_id obsoletes id vector
+
    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtncp.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtncp.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,30 @@ + + + DTN2 Man pages: dtncp + + + +

    dtncp +

    + +

    +

    NAME +

    +

    +dtncp - copy a bundle to a valid destination eid +

    SYNOPSIS +

    =20 +

    =20 +usagedtncp [-D] [--expiration sec] filename destination_eid remote-nam= e + =20 +

    Remote filename is optional; defaults to the local filename. + +

    -D disables acknowledgements +

    Bundle expiration time is in seconds +

    +dtncp [-c count] [-i interval] [-e expiration] eid +

    DESCRIPTION +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtncpd.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtncpd.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,25 @@ + + + DTN2 Man pages: dtncpd + + + +

    dtncpd +

    + +

    +

    NAME +

    +

    +dtncpd - receive a bundle + +

    SYNOPSIS +

    =20 +

    +dtncpd [ directory ] +

    optional directory parameter is where incoming files will get put (defa= ults to: /var/dtn/dtncpd-incoming) +

    DESCRIPTION +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtnd.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtnd.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,41 @@ + + + DTN2 Man pages: dtnd + + + +

    dtnd +

    + +

    +

    NAME +

    +

    +dtnd - the dtn daemon + +

    SYNOPSIS +

    =20 +

    +To source bundles from stdin: +

    +usage: dtnd [opts] +

    DESCRIPTION +

    +

    common options: +

    +  -h, --help			show usage
+  -v, --version			print version information and exit
+  -o, --output	<output>	file name for logging output (default - indi=
cates stdout)
+  -l <level>			default log level [debug|warn|info|crit]
+  -s, --seed <seed>	 	random number generator seed
+  -d, --daemonize		run as a daemon
+  -c, --conf <conf>		set the configuration file
+  -t, --tidy			clear database and initialize tables on startup
+  --init-db			initialize database on startup
+  --console-addr <addr>		set the console listening addr (default off=
)
+  --console-port <port>		set the console listening port (default off=
)
+  -i <id>			set the test id
+
    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtnping.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtnping.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,24 @@ + + + DTN2 Man pages: dtnping + + + +

    dtnping +

    + +

    +

    NAME +

    +

    +dtnping - send a bundle to a valid destination eid or "localhost", in = which case we just use the local daemon + +

    SYNOPSIS +

    =20 +

    +dtnping [-c count] [-i interval] [-e expiration] eid +

    DESCRIPTION +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtnrecv.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtnrecv.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,24 @@ + + + DTN2 Man pages: dtnping + + + +

    dtnping +

    + +

    +

    NAME +

    +

    +dtnping - send a bundle to a valid destination eid or "localhost", in = which case we just use the local daemon + +

    SYNOPSIS +

    =20 +

    +dtnping [-c count] [-i interval] [-e expiration] eid +

    DESCRIPTION +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtnsend.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtnsend.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,53 @@ + + + DTN2 Man pages: dtnsend + + + +

    dtnsend +

    + +

    +

    NAME +

    +

    +dtnsend - sends a bundle with payload of file, tmpfile, message, or da= te + +

    SYNOPSIS +

    =20 +

    +usage: dtnsend [opts] -s <source_eid> -d <dest_eid> -t <= ;type> -p <payload> +

    DESCRIPTION +

    +

    common options: +

    + -v verbose
+ -h help
+ -s <eid|demux_string> source eid)
+ -d <eid|demux_string> destination eid)
+ -r <eid|demux_string> reply to eid)
+ -t <f|t|m|d> payload type: file, tmpfile, message, or date
+ -p <filename|string> payload data
+ -e <time> expiration time in seconds (default: one hour)
+ -P <priority> one of bulk, normal, expedited, or reserved
+ -i <regid> registration id for reply to
+ -n <int> copies of the bundle to send
+ -z <time> msecs to sleep between transmissions
+ -c request custody transfer
+ -C request custody transfer receipts
+ -D request for end-to-end delivery receipt
+ -X request for deletion receipt
+ -R request for bundle reception receipts
+ -F request for bundle forwarding receipts
+ -1 assert destination endpoint is a singleton
+ -N assert destination endpoint is not a singleton
+ -W set the do not fragment option
+ -w wait for bundle status reports
+ -E <int> include extension block and specify type
+ -M <int> include metadata block and specify type
+ -O <int> flags to include in extension/metadata block
+ -S <string> extension/metadata block content
+
    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/man_dtntunnel.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/man_dtntunnel.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,24 @@ + + + DTN2 Man pages: dtnping + + + +

    dtnping +

    + +

    +

    NAME +

    +

    +dtnping - send a bundle to a valid destination eid or "localhost", in = which case we just use the local daemon + +

    SYNOPSIS +

    =20 +

    +dtnping [-c count] [-i interval] [-e expiration] eid +

    DESCRIPTION +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_dtlsr.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_dtlsr.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,14 @@ + + + DTN2 Manual: DTLSR Protocol + + + +

    DTLSR PROTOCOL +

    + +

    +Delay Tolerant Link State Routing (DTLSR) is modelled closely on classic l= ink state algorithms. As the network state changes, link state announcement= s are flooded throughout the network. Each node maintains a graph represent= ing its current view of the state of the network, and uses a shortest path = computation e.g. Dijkstra to find routes for messages. Each node in the sys= tem is assigned to an administrative area, and a link state protocol instan= ce operates only within a single area. This helps to constrain the size of = the network graph and limits the scope of announcement messages, if require= d. Nodes that have neighbors in other areas learn the set of endpoint ident= ifers reachable via the other area and announce themselves as a gateway to = those endpoint identifers. For more information please see the route command. + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_external.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_external.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,20 @@ + + + DTN2 Manual: External Router + + + +

    External Router +

    + +

    +ExternalRouter provides a plug-in interface for third-party +routing protocol implementations.Events received from BundleDaemon=20 +are serialized into XML messages and UDP multicasted to external=20 +bundle router processes. XML actions received on the interface are=20 +validated, transformed into events, and placed on the global event=20 +queue. For more information please see the ecla command. + + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_flood.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_flood.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,35 @@ + + + DTN2 Manual: Flood Router + + + +

    Flood Router +

    + +

    +This is the implementation of a flooding based bundle router. + +

    +In the implementation an internal BundleList is maintaned in which=20 +all bundles are kept until their expiration time. This prevents=20 +the main daemon logic from opportunistically deleting bundles when=20 +they've been transmitted. + +

    +Whenever a new link arrives, we add a wildcard route to the table. +Then when a bundle arrives, we can stick it on the all_bundles list +and just call the base class route_bundle function. The core base +class logic then makes sure that a copy of the bundle is forwarded +exactly once to each neighbor.For more information please see the=20 +route command. + +

    +Note: At present this will forward a bundle back to the node from=20 +which it arrived.=20 + + +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_prophet.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_prophet.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,195 @@ + + + DTN2 Manual: Prophet Router + + + +

    Prophet Router +

    + +

    +This is the implementation of a Prophet router. Prophet is an acronym for = "probabilistic routing protocol using history of encounters and transitivit= y." The protocol operates on the assumption that human mobility is non-rand= om, and that a knowledge of the history of previous encounters is a good in= dicator of future encounters. By leveraging transitive relays in combinatio= n with this history of encounters, Prophet exponentially increases its chan= ces of successfully delivering messages. + +

    The protocol has an initialization phase (HELLO), which in turn is depe= ndent on dynamic NeighborDiscovery. After establishing a peering session ac= ross the newly-formed dynamic link, the peers alternate as listener and ini= tiator in the Information Exchange phase. The initiator begins by sending a= dictionary (RIBD) and a routing information base (RIB) to the listening pe= er. The listener responds by sending a list of bundles (possibly 0 entries)= destined for nodes listed in the initiator's RIB, according to its forward= ing strategy. The initiator requests bundles from the bundle offer, and con= cludes the protocol by sending an empty request after it has received all t= he requested bundles. The nodes switch roles to complete the other half of = the protocol, then idle for 1/2 of HELLO_DEAD intervals before repeating th= e Information Exchange. For more information please see the prophet command. + +

    Design

    + +

    See the PRoPHET website. + +

    The DTN2 Prophet router is based on the March 2006 Prophet internet dra= ft (Prophet I-D, hereafter). The ProphetRouter class extends BundleRouter a= nd serves as the Prophet interface to the DTN bundling system. prophet::Con= troller is a member of ProphetRouter + +

    Implementation

    + +

    prophet::Node represents an individual route. prophet::Table is a colle= ction of these routes. prophet::Encounter implements the protocol between P= rophet peers. prophet::ProphetTLV manages the serialization and deserializa= tion of protocol messages. prophet::Dictionary manages the indexing of the = routes in prophet::Table into a RIBD for the protocol exchange. prophet::Fw= dStrategy is the base comparator for the various strategies. prophet::Repos= itory is a priority queue that enforces the queuing policy, using the runti= me selected comparator inherited from prophet::QueueComp. prophet::BundleOf= fer creates a sorted index of bundles to be sent as a Bundle offer, based o= n the forwarding strategy's comparator and its prophet::Decider. + + +

    prophet

    + +

    +The prophet command is used to configure the prophet router. This= command should not be here but under route like all= other DTN routing protocols and algorithms. +

    prophet set

    +

    +Syntax: prophet cmd arg val +
    +Example: prophet set hello_dead 100 + +You may set the +following variables: + +

    + + + + + + + + + + + + + +
    Variable +Possible settings +Default +Comments + +
    age_period +seconds +TBC +The timeout, in seconds, of the timer that calculates Prophet nodes' a= ging. The same value is used by the timer that expires Prophet ACKs. + +
    beta +number (scale factor) +0.25 +The scaling factor for the transivity of predictability; the Prophet I= -D recommends a default value of 0.25. + +
    encounter +number (initialization value) +0.75 +The initialization value for the direct-contact predictability calcula= tion. + +
    epsilon +number (predictability value) +TBC +The minimum predictability value before the route is discarded. The gr= anularity of an eight-bit value limits this to 0.0039 (1/255). + +
    gamma +number (initialization value) +0.99 +The aging constant used to diminish the predictability value of a rout= e over time. + + +
    hello_dead +number +TBC +The maximum number of HELLO_INTERVALs before a remote session with a P= rophet peer is considered unreachable.=20 + +
    internet_gw +flag +TBC +The flag that describes whether the Prophet router bridges to the Inte= rnet DTN region. Currently not used.=20 + +
    kappa +number(ms) +TBC +The number of milliseconds in a given time unit, referenced by Equatio= n 2 (predictability aging), p. 9, section 2.1.1 of the Prophet I-D.=20 + +
    max_forward +number +TBC +The maximum number of times a bundle may be forwarded by the GTMX forw= arding strategy.=20 + +
    min_forward +number +TBC +The minimum number of times a bundle may be forwarded before eviction = by the LEPR queuing policy.=20 + +
    relay_node +flag +TBC +The flag that describes whether this Prophet node will relay bundles t= o other nodes.=20 +
    + + +

    + +

    To set the queue policy to one of the following, invoke prophet que= ue_policy=3Dpolicyname. Queue policies are discussed in detail = in the Prophet I-D on p. 18, section 3.7. + +

    + + + + + + + + +
    policyname +Comments + +
    fifo +First In First Out: evict oldest first + +
    mofo +Evict most forwarded first + =20 +
    mopr +Evict most favorably forwarded first + +
    lmopr +Evict most favorably forwarded first (linear increase) + +
    shli +Evict shortest lifetime first (the bundle that will expire soonest) + +
    lepr +Evict least probable first (lowest predictability) + +
    + + +

    prophet fwd_strategy

    + +

    To set the forwarding strategy to one of the following, invoke prop= het fwd_strategy=3Dstrategy. Forwarding strategies are discusse= d in detail in the Prophet I-D on p. 16, section 3.6. + +

    + + + + + + + + +
    strategy +Comments + +
    grtr +Forward if remote's predictability is greater than local's + +
    gtmx +Forward if grtr and the bundle has been forwarded less than max_forwar= d + +
    grtr_plus +Forward if grtr and remote's predictability is greater than max predic= tability seen so far + +
    gtmx_plus +Forward if grtr_plus and the bundle has been forwarded less than max_f= orward + +
    grtr_sort +Forward if grtr and sort descending by P_remote - P_local (subtract lo= cal predictability from remote's predictability) + +
    grtr_max +Forward if grtr and sort descending by remote's predictability +
    +

    prophet hello_interval

    + +

    To set the longest acceptable delay between protocol messages, invoke <= tt>prophet hello_intervalinterval where interval is a nu= mber of the range 1 through 255 inclusive, representin +g time units of 100ms. Set the interval to 255 for a maximum acceptable de= lay of 25.5 seconds. + +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_static.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_static.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,22 @@ + + + DTN2 Manual: Static Routing Protocol + + + +

    Static Routing Protocol +

    + +

    +This is the implementation of the basic bundle routing algorithm +that only does static routing. Routes can be parsed from a +configuration file or injected via the command line and/or +management interfaces. + +As a result, the class simply uses the default event handlers from +the table based router implementation. For more information please see=20 +the route command. +

    + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_tca-gateway.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_tca-gateway.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,29 @@ + + + DTN2 Manual: tca-router Routing Algorithm + + + +

    tca-router Routing Algorithm +

    + +

    +This is the implementation of the TCA bundle routing algorithm. +

    +A TCARouter is a specialized TableBasedRouter where the route +table is manipulated in response to certain control bundles +(for example, a "register" bundle, or a "change-of-address" bundle). +Specialized routing logic is then applied in order to route late-bound +bundles addressed to a mobile node, to the mobile's current location +in the network. +

    +The main interface point is the overridden handle_bundle_received +function which tests for the special TCA bundles (control bundles and +late-bound data bundles). For more information please see the=20 +route command. + + + + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/ro_tca-router.html --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/doc/manual/ro_tca-router.html Sun Dec 13 21:46:12 2009 -0800 @@ -0,0 +1,29 @@ + + + DTN2 Manual: tca-router Routing Algorithm + + + +

    tca-router Routing Algorithm +

    + +

    +This is the implementation of the TCA bundle routing algorithm. +

    +A TCARouter is a specialized TableBasedRouter where the route +table is manipulated in response to certain control bundles +(for example, a "register" bundle, or a "change-of-address" bundle). +Specialized routing logic is then applied in order to route late-bound +bundles addressed to a mobile node, to the mobile's current location +in the network. +

    +The main interface point is the overridden handle_bundle_received +function which tests for the special TCA bundles (control bundles and +late-bound data bundles). For more information please see the=20 +route command. + + + + + + diff -r 8b0d483af1e2 -r e62055127255 doc/manual/todo.html --- a/doc/manual/todo.html Sat Dec 12 17:10:03 2009 +0000 +++ b/doc/manual/todo.html Sun Dec 13 21:46:12 2009 -0800 @@ -3,7 +3,7 @@ is not done. Claim it to make sure no one else is duplicating the effort by sending a note to the mailing list. When you have a completed file, or a patch to an existing file, send it to the list so -that Michael or someone else can check it in for you. +that Alex or someone else can check it in for you. =20

    Here's a todo list of things you could choose to do. It is in order diff -r 8b0d483af1e2 -r e62055127255 doc/rfc5050.txt --- a/doc/rfc5050.txt Sat Dec 12 17:10:03 2009 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,2803 +0,0 @@ - - - - - - -Network Working Group K. Scott -Request for Comments: 5050 The MITRE Corporation -Category: Experimental S. Burleigh - NASA Jet Propulsion Laboratory - November 2007 - - - Bundle Protocol Specification - -Status of This Memo - - This memo defines an Experimental Protocol for the Internet - community. It does not specify an Internet standard of any kind. - Discussion and suggestions for improvement are requested. - Distribution of this memo is unlimited. - -IESG Note - - This RFC is not a candidate for any level of Internet Standard. The - IETF disclaims any knowledge of the fitness of this RFC for any - purpose and in particular notes that the decision to publish is not - based on IETF review for such things as security, congestion control, - or inappropriate interaction with deployed protocols. The RFC Editor - has chosen to publish this document at its discretion. Readers of - this document should exercise caution in evaluating its value for - implementation and deployment. See RFC 3932 for more information. - -Abstract - - This document describes the end-to-end protocol, block formats, and - abstract service description for the exchange of messages (bundles) - in Delay Tolerant Networking (DTN). - - This document was produced within the IRTF's Delay Tolerant - Networking Research Group (DTNRG) and represents the consensus of all - of the active contributors to this group. See http://www.dtnrg.org - for more information. - - - - - - - - - - - - - - -Scott & Burleigh Experimental [Page 1] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 - 3. Service Description . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Implementation Architectures . . . . . . . . . . . . . . . 9 - 3.3. Services Offered by Bundle Protocol Agents . . . . . . . . 11 - 4. Bundle Format . . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.1. Self-Delimiting Numeric Values (SDNVs) . . . . . . . . . . 12 - 4.2. Bundle Processing Control Flags . . . . . . . . . . . . . 13 - 4.3. Block Processing Control Flags . . . . . . . . . . . . . . 15 - 4.4. Endpoint IDs . . . . . . . . . . . . . . . . . . . . . . . 16 - 4.5. Formats of Bundle Blocks . . . . . . . . . . . . . . . . . 17 - 4.5.1. Primary Bundle Block . . . . . . . . . . . . . . . . . 19 - 4.5.2. Canonical Bundle Block Format . . . . . . . . . . . . 22 - 4.5.3. Bundle Payload Block . . . . . . . . . . . . . . . . . 23 - 4.6. Extension Blocks . . . . . . . . . . . . . . . . . . . . . 24 - 4.7. Dictionary Revision . . . . . . . . . . . . . . . . . . . 24 - 5. Bundle Processing . . . . . . . . . . . . . . . . . . . . . . 24 - 5.1. Generation of Administrative Records . . . . . . . . . . . 25 - 5.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 26 - 5.3. Bundle Dispatching . . . . . . . . . . . . . . . . . . . . 26 - 5.4. Bundle Forwarding . . . . . . . . . . . . . . . . . . . . 27 - 5.4.1. Forwarding Contraindicated . . . . . . . . . . . . . . 28 - 5.4.2. Forwarding Failed . . . . . . . . . . . . . . . . . . 29 - 5.5. Bundle Expiration . . . . . . . . . . . . . . . . . . . . 29 - 5.6. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 30 - 5.7. Local Bundle Delivery . . . . . . . . . . . . . . . . . . 31 - 5.8. Bundle Fragmentation . . . . . . . . . . . . . . . . . . . 32 - 5.9. Application Data Unit Reassembly . . . . . . . . . . . . . 33 - 5.10. Custody Transfer . . . . . . . . . . . . . . . . . . . . . 34 - 5.10.1. Custody Acceptance . . . . . . . . . . . . . . . . . . 34 - 5.10.2. Custody Release . . . . . . . . . . . . . . . . . . . 35 - 5.11. Custody Transfer Success . . . . . . . . . . . . . . . . . 35 - 5.12. Custody Transfer Failure . . . . . . . . . . . . . . . . . 35 - 5.13. Bundle Deletion . . . . . . . . . . . . . . . . . . . . . 36 - 5.14. Discarding a Bundle . . . . . . . . . . . . . . . . . . . 36 - 5.15. Canceling a Transmission . . . . . . . . . . . . . . . . . 36 - 5.16. Polling . . . . . . . . . . . . . . . . . . . . . . . . . 36 - 6. Administrative Record Processing . . . . . . . . . . . . . . . 37 - 6.1. Administrative Records . . . . . . . . . . . . . . . . . . 37 - 6.1.1. Bundle Status Reports . . . . . . . . . . . . . . . . 38 - 6.1.2. Custody Signals . . . . . . . . . . . . . . . . . . . 41 - 6.2. Generation of Administrative Records . . . . . . . . . . . 44 - 6.3. Reception of Custody Signals . . . . . . . . . . . . . . . 44 - - - - - -Scott & Burleigh Experimental [Page 2] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - 7. Services Required of the Convergence Layer . . . . . . . . . . 44 - 7.1. The Convergence Layer . . . . . . . . . . . . . . . . . . 44 - 7.2. Summary of Convergence Layer Services . . . . . . . . . . 45 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 47 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 47 - Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 49 - Appendix B. Comments . . . . . . . . . . . . . . . . . . . . . . 49 - -1. Introduction - - This document describes version 6 of the Delay Tolerant Networking - (DTN) "bundle" protocol (BP). Delay Tolerant Networking is an end- - to-end architecture providing communications in and/or through highly - stressed environments. Stressed networking environments include - those with intermittent connectivity, large and/or variable delays, - and high bit error rates. To provide its services, BP sits at the - application layer of some number of constituent internets, forming a - store-and-forward overlay network. Key capabilities of BP include: - - o Custody-based retransmission - - o Ability to cope with intermittent connectivity - - o Ability to take advantage of scheduled, predicted, and - opportunistic connectivity (in addition to continuous - connectivity) - - o Late binding of overlay network endpoint identifiers to - constituent internet addresses - - For descriptions of these capabilities and the rationale for the DTN - architecture, see [ARCH] and [SIGC]. [TUT] contains a tutorial-level - overview of DTN concepts. - - This is an experimental protocol, produced within the IRTF's Delay - Tolerant Networking Research Group (DTNRG) and represents the - consensus of all of the active contributors to this group. If this - protocol is used on the Internet, IETF standard protocols for - security and congestion control should be used. - - BP's location within the standard protocol stack is as shown in - Figure 1. BP uses the "native" internet protocols for communications - within a given internet. Note that "internet" in the preceding is - used in a general sense and does not necessarily refer to TCP/IP. - The interface between the common bundle protocol and a specific - - - -Scott & Burleigh Experimental [Page 3] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - internetwork protocol suite is termed a "convergence layer adapter". - Figure 1 shows three distinct transport and network protocols - (denoted T1/N1, T2/N2, and T3/N3). - - +-----------+ +-----------+ - | BP app | | BP app | - +---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+ - | BP v | | ^ BP v | | ^ BP v | | ^ BP | - +---------v-+ +-^---------v-+ +-^---------v-+ +-^---------+ - | Trans1 v | + ^ T1/T2 v | + ^ T2/T3 v | | ^ Trans3 | - +---------v-+ +-^---------v-+ +-^---------v + +-^---------+ - | Net1 v | | ^ N1/N2 v | | ^ N2/N3 v | | ^ Net3 | - +---------v-+ +-^---------v + +-^---------v-+ +-^---------+ - | >>>>>>>>^ >>>>>>>>>>^ >>>>>>>>^ | - +-----------+ +-------------+ +-------------+ +-----------+ - | | | | - |<--- An internet --->| |<--- An internet --->| - | | | | - - Figure 1: The Bundle Protocol Sits at - the Application Layer of the Internet Model - - This document describes the format of the protocol data units (called - bundles) passed between entities participating in BP communications. - The entities are referred to as "bundle nodes". This document does - not address: - - o Operations in the convergence layer adapters that bundle nodes use - to transport data through specific types of internets. (However, - the document does discuss the services that must be provided by - each adapter at the convergence layer.) - - o The bundle routing algorithm. - - o Mechanisms for populating the routing or forwarding information - bases of bundle nodes. - -2. Requirements Notation - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - - - - - - - - -Scott & Burleigh Experimental [Page 4] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -3. Service Description - -3.1. Definitions - - Bundle - A bundle is a protocol data unit of the DTN bundle - protocol. Each bundle comprises a sequence of two or more - "blocks" of protocol data, which serve various purposes. Multiple - instances of the same bundle (the same unit of DTN protocol data) - might exist concurrently in different parts of a network -- - possibly in different representations -- in the memory local to - one or more bundle nodes and/or in transit between nodes. In the - context of the operation of a bundle node, a bundle is an instance - of some bundle in the network that is in that node's local memory. - - Bundle payload - A bundle payload (or simply "payload") is the - application data whose conveyance to the bundle's destination is - the purpose for the transmission of a given bundle. The terms - "bundle content", "bundle payload", and "payload" are used - interchangeably in this document. The "nominal" payload for a - bundle forwarded in response to a bundle transmission request is - the application data unit whose location is provided as a - parameter to that request. The nominal payload for a bundle - forwarded in response to reception of that bundle is the payload - of the received bundle. - - Fragment - A fragment is a bundle whose payload block contains a - fragmentary payload. A fragmentary payload is either the first N - bytes or the last N bytes of some other payload -- either a - nominal payload or a fragmentary payload -- of length M, such that - 0 < N < M. - - Bundle node - A bundle node (or, in the context of this document, - simply a "node") is any entity that can send and/or receive - bundles. In the most familiar case, a bundle node is instantiated - as a single process running on a general-purpose computer, but in - general the definition is meant to be broader: a bundle node might - alternatively be a thread, an object in an object-oriented - operating system, a special-purpose hardware device, etc. Each - bundle node has three conceptual components, defined below: a - "bundle protocol agent", a set of zero or more "convergence layer - adapters", and an "application agent". - - Bundle protocol agent - The bundle protocol agent (BPA) of a node is - the node component that offers the BP services and executes the - procedures of the bundle protocol. The manner in which it does so - is wholly an implementation matter. For example, BPA - functionality might be coded into each node individually; it might - be implemented as a shared library that is used in common by any - - - -Scott & Burleigh Experimental [Page 5] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - number of bundle nodes on a single computer; it might be - implemented as a daemon whose services are invoked via inter- - process or network communication by any number of bundle nodes on - one or more computers; it might be implemented in hardware. - - Convergence layer adapters - A convergence layer adapter (CLA) sends - and receives bundles on behalf of the BPA, utilizing the services - of some 'native' internet protocol that is supported in one of the - internets within which the node is functionally located. The - manner in which a CLA sends and receives bundles is wholly an - implementation matter, exactly as described for the BPA. - - Application agent - The application agent (AA) of a node is the node - component that utilizes the BP services to effect communication - for some purpose. The application agent in turn has two elements, - an administrative element and an application-specific element. - The application-specific element of an AA constructs, requests - transmission of, accepts delivery of, and processes application- - specific application data units; the only interface between the - BPA and the application-specific element of the AA is the BP - service interface. The administrative element of an AA constructs - and requests transmission of administrative records (status - reports and custody signals), and it accepts delivery of and - processes any custody signals that the node receives. In addition - to the BP service interface, there is a (conceptual) private - control interface between the BPA and the administrative element - of the AA that enables each to direct the other to take action - under specific circumstances. In the case of a node that serves - simply as a "router" in the overlay network, the AA may have no - application-specific element at all. The application-specific - elements of other nodes' AAs may perform arbitrarily complex - application functions, perhaps even offering multiplexed DTN - communication services to a number of other applications. As with - the BPA, the manner in which the AA performs its functions is - wholly an implementation matter; in particular, the administrative - element of an AA might be built into the library or daemon or - hardware that implements the BPA, and the application-specific - element of an AA might be implemented either in software or in - hardware. - - Bundle endpoint - A bundle endpoint (or simply "endpoint") is a set - of zero or more bundle nodes that all identify themselves for BP - purposes by some single text string, called a "bundle endpoint ID" - (or, in this document, simply "endpoint ID"; endpoint IDs are - described in detail in Section 4.4 below). The special case of an - endpoint that never contains more than one node is termed a - "singleton" endpoint; every bundle node must be a member of at - least one singleton endpoint. Singletons are the most familiar - - - -Scott & Burleigh Experimental [Page 6] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - sort of endpoint, but in general the endpoint notion is meant to - be broader. For example, the nodes in a sensor network might - constitute a set of bundle nodes that identify themselves by a - single common endpoint ID and thus form a single bundle endpoint. - *Note* too that a given bundle node might identify itself by - multiple endpoint IDs and thus be a member of multiple bundle - endpoints. - - Forwarding - When the bundle protocol agent of a node determines - that a bundle must be "forwarded" to an endpoint, it causes the - bundle to be sent to all of the nodes that the bundle protocol - agent currently believes are in the "minimum reception group" of - that endpoint. The minimum reception group of an endpoint may be - any one of the following: (a) ALL of the nodes registered in an - endpoint that is permitted to contain multiple nodes (in which - case forwarding to the endpoint is functionally similar to - "multicast" operations in the Internet, though possibly very - different in implementation); (b) ANY N of the nodes registered in - an endpoint that is permitted to contain multiple nodes, where N - is in the range from zero to the cardinality of the endpoint (in - which case forwarding to the endpoint is functionally similar to - "anycast" operations in the Internet); or (c) THE SOLE NODE - registered in a singleton endpoint (in which case forwarding to - the endpoint is functionally similar to "unicast" operations in - the Internet). The nature of the minimum reception group for a - given endpoint can be determined from the endpoint's ID (again, - see Section 4.4 below): for some endpoint ID "schemes", the nature - of the minimum reception group is fixed - in a manner that is - defined by the scheme - for all endpoints identified under the - scheme; for other schemes, the nature of the minimum reception - group is indicated by some lexical feature of the "scheme-specific - part" of the endpoint ID, in a manner that is defined by the - scheme. - - Registration - A registration is the state machine characterizing a - given node's membership in a given endpoint. Any number of - registrations may be concurrently associated with a given - endpoint, and any number of registrations may be concurrently - associated with a given node. Any single registration must at any - time be in one of two states: Active or Passive. A registration - always has an associated "delivery failure action", the action - that is to be taken when a bundle that is "deliverable" (see - below) subject to that registration is received at a time when the - registration is in the Passive state. Delivery failure action - must be one of the following: - - * defer "delivery" (see below) of the bundle subject to this - registration until (a) this bundle is the least recently - - - -Scott & Burleigh Experimental [Page 7] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - received of all bundles currently deliverable subject to this - registration and (b) either the registration is polled or else - the registration is in the Active state; or - - * "abandon" (see below) delivery of the bundle subject to this - registration. - - An additional implementation-specific delivery deferral procedure - may optionally be associated with the registration. While the - state of a registration is Active, reception of a bundle that is - deliverable subject to this registration must cause the bundle to - be delivered automatically as soon as it is the least recently - received bundle that is currently deliverable subject to the - registration. While the state of a registration is Passive, - reception of a bundle that is deliverable subject to this - registration must cause delivery of the bundle to be abandoned or - deferred as mandated by the registration's current delivery - failure action; in the latter case, any additional delivery - deferral procedure associated with the registration must also be - performed. - - Delivery - Upon reception, the processing of a bundle that has been - sent to a given node depends on whether or not the receiving node - is registered in the bundle's destination endpoint. If it is, and - if the payload of the bundle is non-fragmentary (possibly as a - result of successful payload reassembly from fragmentary payloads, - including the original payload of the received bundle), then the - bundle is normally "delivered" to the node's application agent - subject to the registration characterizing the node's membership - in the destination endpoint. A bundle is considered to have been - delivered at a node subject to a registration as soon as the - application data unit that is the payload of the bundle, together - with the value of the bundle's "Acknowledgement by application is - requested" flag and any other relevant metadata (an implementation - matter), has been presented to the node's application agent in a - manner consistent with the state of that registration and, as - applicable, the registration's delivery failure action. - - Deliverability, Abandonment - A bundle is considered "deliverable" - subject to a registration if and only if (a) the bundle's - destination endpoint is the endpoint with which the registration - is associated, (b) the bundle has not yet been delivered subject - to this registration, and (c) delivery of the bundle subject to - this registration has not been abandoned. To "abandon" delivery - of a bundle subject to a registration is simply to declare it no - longer deliverable subject to that registration; normally only - registrations' registered delivery failure actions cause - deliveries to be abandoned. - - - -Scott & Burleigh Experimental [Page 8] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Deletion, Discarding - A bundle protocol agent "discards" a bundle - by simply ceasing all operations on the bundle and functionally - erasing all references to it; the specific procedures by which - this is accomplished are an implementation matter. Bundles are - discarded silently; i.e., the discarding of a bundle does not - result in generation of an administrative record. "Retention - constraints" are elements of the bundle state that prevent a - bundle from being discarded; a bundle cannot be discarded while it - has any retention constraints. A bundle protocol agent "deletes" - a bundle in response to some anomalous condition by notifying the - bundle's report-to endpoint of the deletion (provided such - notification is warranted; see Section 5.13 for details) and then - arbitrarily removing all of the bundle's retention constraints, - enabling the bundle to be discarded. - - Transmission - A transmission is a sustained effort by a node's - bundle protocol agent to cause a bundle to be sent to all nodes in - the minimum reception group of some endpoint (which may be the - bundle's destination or may be some intermediate forwarding - endpoint) in response to a transmission request issued by the - node's application agent. Any number of transmissions may be - concurrently undertaken by the bundle protocol agent of a given - node. - - Custody - To "accept custody" upon forwarding a bundle is to commit - to retaining a copy of the bundle -- possibly re-forwarding the - bundle when necessary -- until custody of that bundle is - "released". Custody of a bundle whose destination is a singleton - endpoint is released when either (a) notification is received that - some other node has accepted custody of the same bundle; (b) - notification is received that the bundle has been delivered at the - (sole) node registered in the bundle's destination endpoint; or - (c) the bundle is explicitly deleted for some reason, such as - lifetime expiration. The condition(s) under which custody of a - bundle whose destination is not a singleton endpoint may be - released are not defined in this specification. To "refuse - custody" of a bundle is to decide not to accept custody of the - bundle. A "custodial node" of a bundle is a node that has - accepted custody of the bundle and has not yet released that - custody. A "custodian" of a bundle is a singleton endpoint whose - sole member is one of the bundle's custodial nodes. - -3.2. Implementation Architectures - - The above definitions are intended to enable the bundle protocol's - operations to be specified in a manner that minimizes bias toward any - particular implementation architecture. To illustrate the range of - interoperable implementation models that might conform to this - - - -Scott & Burleigh Experimental [Page 9] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - specification, four example architectures are briefly described - below. - - 1. Bundle protocol application server - - A single bundle protocol application server, constituting a - single bundle node, runs as a daemon process on each computer. - The daemon's functionality includes all functions of the bundle - protocol agent, all convergence layer adapters, and both the - administrative and application-specific elements of the - application agent. The application-specific element of the - application agent functions as a server, offering bundle protocol - service over a local area network: it responds to remote - procedure calls from application processes (on the same computer - and/or remote computers) that need to communicate via the bundle - protocol. The server supports its clients by creating a new - (conceptual) node for each one and registering each such node in - a client-specified endpoint. The conceptual nodes managed by the - server function as clients' bundle protocol service access - points. - - 2. Peer application nodes - - Any number of bundle protocol application processes, each one - constituting a single bundle node, run in ad-hoc fashion on each - computer. The functionality of the bundle protocol agent, all - convergence layer adapters, and the administrative element of the - application agent is provided by a library to which each node - process is dynamically linked at run time. The application- - specific element of each node's application agent is node- - specific application code. - - 3. Sensor network nodes - - Each node of the sensor network is the self-contained - implementation of a single bundle node. All functions of the - bundle protocol agent, all convergence layer adapters, and the - administrative element of the application agent are implemented - in simplified form in Application-Specific Integrated Circuits - (ASICs), while the application-specific element of each node's - application agent is implemented in a programmable - microcontroller. Forwarding is rudimentary: all bundles are - forwarded on a hard-coded default route. - - - - - - - - -Scott & Burleigh Experimental [Page 10] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - 4. Dedicated bundle router - - Each computer constitutes a single bundle node that functions - solely as a high-performance bundle forwarder. Many standard - functions of the bundle protocol agent, the convergence layer - adapters, and the administrative element of the application agent - are implemented in ASICs, but some functions are implemented in a - high-speed processor to enable reprogramming as necessary. The - node's application agent has no application-specific element. - Substantial non-volatile storage resources are provided, and - arbitrarily complex forwarding algorithms are supported. - -3.3. Services Offered by Bundle Protocol Agents - - The bundle protocol agent of each node is expected to provide the - following services to the node's application agent: - - o commencing a registration (registering a node in an endpoint); - - o terminating a registration; - - o switching a registration between Active and Passive states; - - o transmitting a bundle to an identified bundle endpoint; - - o canceling a transmission; - - o polling a registration that is in the passive state; - - o delivering a received bundle. - -4. Bundle Format - - Each bundle shall be a concatenated sequence of at least two block - structures. The first block in the sequence must be a primary bundle - block, and no bundle may have more than one primary bundle block. - Additional bundle protocol blocks of other types may follow the - primary block to support extensions to the bundle protocol, such as - the Bundle Security Protocol [BSP]. At most one of the blocks in the - sequence may be a payload block. The last block in the sequence must - have the "last block" flag (in its block processing control flags) - set to 1; for every other block in the bundle after the primary - block, this flag must be set to zero. - - - - - - - - -Scott & Burleigh Experimental [Page 11] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -4.1. Self-Delimiting Numeric Values (SDNVs) - - The design of the bundle protocol attempts to reconcile minimal - consumption of transmission bandwidth with: - - o extensibility to address requirements not yet identified, and - - o scalability across a wide range of network scales and payload - sizes. - - A key strategic element in the design is the use of self-delimiting - numeric values (SDNVs). The SDNV encoding scheme is closely adapted - from the Abstract Syntax Notation One Basic Encoding Rules for - subidentifiers within an object identifier value [ASN1]. An SDNV is - a numeric value encoded in N octets, the last of which has its most - significant bit (MSB) set to zero; the MSB of every other octet in - the SDNV must be set to 1. The value encoded in an SDNV is the - unsigned binary number obtained by concatenating into a single bit - string the 7 least significant bits of each octet of the SDNV. - - The following examples illustrate the encoding scheme for various - hexadecimal values. - - 0xABC : 1010 1011 1100 - is encoded as - {1 00 10101} {0 0111100} - =3D 10010101 00111100 - - 0x1234 : 0001 0010 0011 0100 - =3D 1 0010 0011 0100 - is encoded as - {1 0 100100} {0 0110100} - =3D 10100100 00110100 - - 0x4234 : 0100 0010 0011 0100 - =3D 100 0010 0011 0100 - is encoded as - {1 000000 1} {1 0000100} {0 0110100} - =3D 10000001 10000100 00110100 - - 0x7F : 0111 1111 - =3D 111 1111 - is encoded as - {0 1111111} - =3D 01111111 - - Figure 2: SDNV Example - - - - -Scott & Burleigh Experimental [Page 12] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Note: Care must be taken to make sure that the value to be encoded is - (in concept) padded with high-order zero bits to make its bitwise - length a multiple of 7 before encoding. Also note that, while there - is no theoretical limit on the size of an SDNV field, the overhead of - the SDNV scheme is 1:7, i.e., one bit of overhead for every 7 bits of - actual data to be encoded. Thus, a 7-octet value (a 56-bit quantity - with no leading zeroes) would be encoded in an 8-octet SDNV; an - 8-octet value (a 64-bit quantity with no leading zeroes) would be - encoded in a 10-octet SDNV (one octet containing the high-order bit - of the value padded with six leading zero bits, followed by nine - octets containing the remaining 63 bits of the value). 148 bits of - overhead would be consumed in encoding a 1024-bit RSA encryption key - directly in an SDNV. In general, an N-bit quantity with no leading - zeroes is encoded in an SDNV occupying ceil(N/7) octets, where ceil - is the integer ceiling function. - - Implementations of the bundle protocol may handle as an invalid - numeric value any SDNV that encodes an integer that is larger than - (2^64 - 1). - - An SDNV can be used to represent both very large and very small - integer values. However, SDNV is clearly not the best way to - represent every numeric value. For example, an SDNV is a poor way to - represent an integer whose value typically falls in the range 128 to - 255. In general, though, we believe that SDNV representation of - numeric values in bundle blocks yields the smallest block sizes - without sacrificing scalability. - -4.2. Bundle Processing Control Flags - - The bundle processing control flags field in the primary bundle block - of each bundle is an SDNV; the value encoded in this SDNV is a string - of bits used to invoke selected bundle processing control features. - The significance of the value in each currently defined position of - this bit string is described here. Note that in the figure and - descriptions, the bit label numbers denote position (from least - significant ('0') to most significant) within the decoded bit string, - and not within the representation of the bits on the wire. This is - why the descriptions in this section and the next do not follow - standard RFC conventions with bit 0 on the left; if fields are added - in the future, the SDNV will grow to the left, and using this - representation allows the references here to remain valid. - - - - - - - - - -Scott & Burleigh Experimental [Page 13] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - 2 1 0 - 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |Status Report|Class of Svc.| General | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - Figure 3: Bundle Processing Control Flags Bit Layout - - The bits in positions 0 through 6 are flags that characterize the - bundle as follows: - - 0 -- Bundle is a fragment. - - 1 -- Application data unit is an administrative record. - - 2 -- Bundle must not be fragmented. - - 3 -- Custody transfer is requested. - - 4 -- Destination endpoint is a singleton. - - 5 -- Acknowledgement by application is requested. - - 6 -- Reserved for future use. - - The bits in positions 7 through 13 are used to indicate the bundle's - class of service. The bits in positions 8 and 7 constitute a two-bit - priority field indicating the bundle's priority, with higher values - being of higher priority: 00 =3D bulk, 01 =3D normal, 10 =3D expedited,= 11 - is reserved for future use. Within this field, bit 8 is the most - significant bit. The bits in positions 9 through 13 are reserved for - future use. - - The bits in positions 14 through 20 are status report request flags. - These flags are used to request status reports as follows: - - 14 -- Request reporting of bundle reception. - - 15 -- Request reporting of custody acceptance. - - 16 -- Request reporting of bundle forwarding. - - 17 -- Request reporting of bundle delivery. - - 18 -- Request reporting of bundle deletion. - - 19 -- Reserved for future use. - - - - -Scott & Burleigh Experimental [Page 14] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - 20 -- Reserved for future use. - - If the bundle processing control flags indicate that the bundle's - application data unit is an administrative record, then the custody - transfer requested flag must be zero and all status report request - flags must be zero. If the custody transfer requested flag is 1, - then the sending node requests that the receiving node accept custody - of the bundle. If the bundle's source endpoint ID is "dtn:none" (see - below), then the bundle is not uniquely identifiable and all bundle - protocol features that rely on bundle identity must therefore be - disabled: the bundle's custody transfer requested flag must be zero, - the "Bundle must not be fragmented" flag must be 1, and all status - report request flags must be zero. - -4.3. Block Processing Control Flags - - The block processing control flags field in every block other than - the primary bundle block is an SDNV; the value encoded in this SDNV - is a string of bits used to invoke selected block processing control - features. The significance of the values in all currently defined - positions of this bit string, in order from least significant - position in the decoded bit string (labeled '0') to most significant - (labeled '6'), is described here. - - 0 - 6 5 4 3 2 1 0 - +-+-+-+-+-+-+-+ - | Flags | - +-+-+-+-+-+-+-+ - - Figure 4: Block Processing Control Flags Bit Layout - - 0 - Block must be replicated in every fragment. - - 1 - Transmit status report if block can't be processed. - - 2 - Delete bundle if block can't be processed. - - 3 - Last block. - - 4 - Discard block if it can't be processed. - - 5 - Block was forwarded without being processed. - - 6 - Block contains an EID-reference field. - - - - - - -Scott & Burleigh Experimental [Page 15] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - For each bundle whose primary block's bundle processing control flags - (see above) indicate that the bundle's application data unit is an - administrative record, the "Transmit status report if block can't be - processed" flag in the block processing flags field of every other - block in the bundle must be zero. - - The 'Block must be replicated in every fragment' bit in the block - processing flags must be set to zero on all blocks that follow the - payload block. - -4.4. Endpoint IDs - - The destinations of bundles are bundle endpoints, identified by text - strings termed "endpoint IDs" (see Section 3.1). Each endpoint ID - conveyed in any bundle block takes the form of a Uniform Resource - Identifier (URI; [URI]). As such, each endpoint ID can be - characterized as having this general structure: - - < scheme name > : < scheme-specific part, or "SSP" > - - As used for the purposes of the bundle protocol, neither the length - of a scheme name nor the length of an SSP may exceed 1023 bytes. - - Bundle blocks cite a number of endpoint IDs for various purposes of - the bundle protocol. Many, though not necessarily all, of the - endpoint IDs referred to in the blocks of a given bundle are conveyed - in the "dictionary" byte array in the bundle's primary block. This - array is simply the concatenation of any number of null-terminated - scheme names and SSPs. - - "Endpoint ID references" are used to cite endpoint IDs that are - contained in the dictionary; all endpoint ID citations in the primary - bundle block are endpoint ID references, and other bundle blocks may - contain endpoint ID references as well. Each endpoint ID reference - is an ordered pair of SDNVs: - - o The first SDNV contains the offset within the dictionary of the - first character of the referenced endpoint ID's scheme name. - - o The second SDNV contains the offset within the dictionary of the - first character of the referenced endpoint ID's SSP. - - This encoding enables a degree of block compression: when the source - and report-to of a bundle are the same endpoint, for example, the - text of that endpoint's ID may be cited twice yet appear only once in - the dictionary. - - - - - -Scott & Burleigh Experimental [Page 16] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - The scheme identified by the < scheme name > in an endpoint ID is a - set of syntactic and semantic rules that fully explain how to parse - and interpret the SSP. The set of allowable schemes is effectively - unlimited. Any scheme conforming to [URIREG] may be used in a bundle - protocol endpoint ID. In addition, a single additional scheme is - defined by the present document: - - o The "dtn" scheme, which is used at minimum in the representation - of the null endpoint ID "dtn:none". The forwarding of a bundle to - the null endpoint is never contraindicated, and the minimum - reception group for the null endpoint is the empty set. - - Note that, although the endpoint IDs conveyed in bundle blocks are - expressed as URIs, implementations of the BP service interface may - support expression of endpoint IDs in some internationalized manner - (e.g., Internationalized Resource Identifiers (IRIs); see [RFC3987]). - -4.5. Formats of Bundle Blocks - - This section describes the formats of the primary block and payload - block. Rules for processing these blocks appear in Section 5 of this - document. - - Note that supplementary DTN protocol specifications (including, but - not restricted to, the Bundle Security Protocol [BSP]) may require - that BP implementations conforming to those protocols construct and - process additional blocks. - - The format of the two basic BP blocks is shown in Figure 5 below. - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Experimental [Page 17] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Primary Bundle Block - +----------------+----------------+----------------+----------------+ - | Version | Proc. Flags (*) | - +----------------+----------------+----------------+----------------+ - | Block length (*) | - +----------------+----------------+---------------------------------+ - | Destination scheme offset (*) | Destination SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Source scheme offset (*) | Source SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Report-to scheme offset (*) | Report-to SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Custodian scheme offset (*) | Custodian SSP offset (*) | - +----------------+----------------+----------------+----------------+ - | Creation Timestamp time (*) | - +---------------------------------+---------------------------------+ - | Creation Timestamp sequence number (*) | - +---------------------------------+---------------------------------+ - | Lifetime (*) | - +----------------+----------------+----------------+----------------+ - | Dictionary length (*) | - +----------------+----------------+----------------+----------------+ - | Dictionary byte array (variable) | - +----------------+----------------+---------------------------------+ - | [Fragment offset (*)] | - +----------------+----------------+---------------------------------+ - | [Total application data unit length (*)] | - +----------------+----------------+---------------------------------+ - - - Bundle Payload Block - +----------------+----------------+----------------+----------------+ - | Block type | Proc. Flags (*)| Block length(*) | - +----------------+----------------+----------------+----------------+ - / Bundle Payload (variable) / - +-------------------------------------------------------------------+ - - Figure 5: Bundle Block Formats - - (*) Notes: - - The bundle processing control ("Proc.") flags field in the Primary - Bundle Block is an SDNV and is therefore variable length. A three- - octet SDNV is shown here for convenience in representation. - - The block length field of the Primary Bundle Block is an SDNV and is - therefore variable length. A four-octet SDNV is shown here for - convenience in representation. - - - -Scott & Burleigh Experimental [Page 18] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Each of the eight offset fields in the Primary Bundle Block is an - SDNV and is therefore variable length. Two-octet SDNVs are shown - here for convenience in representation. - - The Creation Timestamp time field in the Primary Bundle Block is an - SDNV and is therefore variable length. A four-octet SDNV is shown - here for convenience in representation. - - The Creation Timestamp sequence number field in the Primary Bundle - Block is an SDNV and is therefore variable length. A four-octet SDNV - is shown here for convenience in representation. - - The Lifetime field in the Primary Bundle Block is an SDNV and is - therefore variable length. A four-octet SDNV is shown here for - convenience in representation. - - The dictionary length field of the Primary Bundle Block is an SDNV - and is therefore variable length. A four-octet SDNV is shown here - for convenience in representation. - - The fragment offset field of the Primary Bundle Block is present only - if the Fragment flag in the block's processing flags byte is set to - 1. It is an SDNV and is therefore variable length; a four-octet SDNV - is shown here for convenience in representation. - - The total application data unit length field of the Primary Bundle - Block is present only if the Fragment flag in the block's processing - flags byte is set to 1. It is an SDNV and is therefore variable - length; a four-octet SDNV is shown here for convenience in - representation. - - The block processing control ("Proc.") flags field of the Payload - Block is an SDNV and is therefore variable length. A one-octet SDNV - is shown here for convenience in representation. - - The block length field of the Payload Block is an SDNV and is - therefore variable length. A two-octet SDNV is shown here for - convenience in representation. - -4.5.1. Primary Bundle Block - - The primary bundle block contains the basic information needed to - route bundles to their destinations. The fields of the primary - bundle block are: - - - - - - - -Scott & Burleigh Experimental [Page 19] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Version: A 1-byte field indicating the version of the bundle - protocol that constructed this block. The present document - describes version 0x06 of the bundle protocol. - - Bundle Processing Control Flags: The Bundle Processing Control - Flags field is an SDNV that contains the bundle processing control - flags discussed in Section 4.2 above. - - Block Length: The Block Length field is an SDNV that contains the - aggregate length of all remaining fields of the block. - - Destination Scheme Offset: The Destination Scheme Offset field - contains the offset within the dictionary byte array of the scheme - name of the endpoint ID of the bundle's destination, i.e., the - endpoint containing the node(s) at which the bundle is to be - delivered. - - Destination SSP Offset: The Destination SSP Offset field contains - the offset within the dictionary byte array of the scheme-specific - part of the endpoint ID of the bundle's destination. - - Source Scheme Offset: The Source Scheme Offset field contains the - offset within the dictionary byte array of the scheme name of the - endpoint ID of the bundle's nominal source, i.e., the endpoint - nominally containing the node from which the bundle was initially - transmitted. - - Source SSP Offset: The Source SSP Offset field contains the offset - within the dictionary byte array of the scheme-specific part of - the endpoint ID of the bundle's nominal source. - - Report-to Scheme Offset: The Report-to Scheme Offset field contains - the offset within the dictionary byte array of the scheme name of - the ID of the endpoint to which status reports pertaining to the - forwarding and delivery of this bundle are to be transmitted. - - Report-to SSP Offset: The Report-to SSP Offset field contains the - offset within the dictionary byte array of the scheme-specific - part of the ID of the endpoint to which status reports pertaining - to the forwarding and delivery of this bundle are to be - transmitted. - - Custodian Scheme Offset: The "current custodian endpoint ID" of a - primary bundle block identifies an endpoint whose membership - includes the node that most recently accepted custody of the - bundle upon forwarding this bundle. The Custodian Scheme Offset - field contains the offset within the dictionary byte array of the - scheme name of the current custodian endpoint ID. - - - -Scott & Burleigh Experimental [Page 20] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Custodian SSP Offset: The Custodian SSP Offset field contains the - offset within the dictionary byte array of the scheme-specific - part of the current custodian endpoint ID. - - Creation Timestamp: The creation timestamp is a pair of SDNVs that, - together with the source endpoint ID and (if the bundle is a - fragment) the fragment offset and payload length, serve to - identify the bundle. The first SDNV of the timestamp is the - bundle's creation time, while the second is the bundle's creation - timestamp sequence number. Bundle creation time is the time -- - expressed in seconds since the start of the year 2000, on the - Coordinated Universal Time (UTC) scale [UTC] -- at which the - transmission request was received that resulted in the creation of - the bundle. Sequence count is the latest value (as of the time at - which that transmission request was received) of a monotonically - increasing positive integer counter managed by the source node's - bundle protocol agent that may be reset to zero whenever the - current time advances by one second. A source Bundle Protocol - Agent must never create two distinct bundles with the same source - endpoint ID and bundle creation timestamp. The combination of - source endpoint ID and bundle creation timestamp therefore serves - to identify a single transmission request, enabling it to be - acknowledged by the receiving application (provided the source - endpoint ID is not "dtn:none"). - - Lifetime: The lifetime field is an SDNV that indicates the time at - which the bundle's payload will no longer be useful, encoded as a - number of seconds past the creation time. When the current time - is greater than the creation time plus the lifetime, bundle nodes - need no longer retain or forward the bundle; the bundle may be - deleted from the network. - - Dictionary Length: The Dictionary Length field is an SDNV that - contains the length of the dictionary byte array. - - Dictionary: The Dictionary field is an array of bytes formed by - concatenating the null-terminated scheme names and SSPs of all - endpoint IDs referenced by any fields in this Primary Block - together with, potentially, other endpoint IDs referenced by - fields in other TBD DTN protocol blocks. Its length is given by - the value of the Dictionary Length field. - - Fragment Offset: If the Bundle Processing Control Flags of this - Primary block indicate that the bundle is a fragment, then the - Fragment Offset field is an SDNV indicating the offset from the - start of the original application data unit at which the bytes - comprising the payload of this bundle were located. If not, then - the Fragment Offset field is omitted from the block. - - - -Scott & Burleigh Experimental [Page 21] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Total Application Data Unit Length: If the Bundle Processing - Control Flags of this Primary block indicate that the bundle is a - fragment, then the Total Application Data Unit Length field is an - SDNV indicating the total length of the original application data - unit of which this bundle's payload is a part. If not, then the - Total Application Data Unit Length field is omitted from the - block. - -4.5.2. Canonical Bundle Block Format - - Every bundle block of every type other than the primary bundle block - comprises the following fields, in this order: - - o Block type code, expressed as an 8-bit unsigned binary integer. - Bundle block type code 1 indicates that the block is a bundle - payload block. Block type codes 192 through 255 are not defined - in this specification and are available for private and/or - experimental use. All other values of the block type code are - reserved for future use. - - o Block processing control flags, an unsigned integer expressed as - an SDNV. The individual bits of this integer are used to invoke - selected block processing control features. - - o Block EID reference count and EID references (optional). If and - only if the block references EID elements in the primary block's - dictionary, the 'block contains an EID-reference field' flag in - the block processing control flags is set to 1 and the block - includes an EID reference field consisting of a count of EID - references expressed as an SDNV followed by the EID references - themselves. Each EID reference is a pair of SDNVs. The first - SDNV of each EID reference contains the offset of a scheme name in - the primary block's dictionary, and the second SDNV of each - reference contains the offset of a scheme-specific part in the - dictionary. - - o Block data length, an unsigned integer expressed as an SDNV. The - Block data length field contains the aggregate length of all - remaining fields of the block, i.e., the block-type-specific data - fields. - - o Block-type-specific data fields, whose format and order are type- - specific and whose aggregate length in octets is the value of the - block data length field. All multi-byte block-type-specific data - fields are represented in network byte order. - - - - - - -Scott & Burleigh Experimental [Page 22] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - +-----------+-----------+-----------+-----------+ - |Block type | Block processing ctrl flags (SDNV)| - +-----------+-----------+-----------+-----------+ - | Block length (SDNV) | - +-----------+-----------+-----------+-----------+ - / Block body data (variable) / - +-----------+-----------+-----------+-----------+ - - Figure 6: Block Layout without EID Reference List - - - +-----------+-----------+-----------+-----------+ - |Block Type | Block processing ctrl flags (SDNV)| - +-----------+-----------+-----------+-----------+ - | EID Reference Count (SDNV) | - +-----------+-----------+-----------+-----------+ - | Ref_scheme_1 (SDNV) | Ref_ssp_1 (SDNV) | - +-----------+-----------+-----------+-----------+ - | Ref_scheme_2 (SDNV) | Ref_ssp_2 (SDNV) | - +-----------+-----------+-----------+-----------+ - | Block length (SDNV) | - +-----------+-----------+-----------+-----------+ - / Block body data (variable) / - +-----------+-----------+-----------+-----------+ - - Figure 7: Block Layout Showing Two EID References - -4.5.3. Bundle Payload Block - - The fields of the bundle payload block are: - - Block Type: The Block Type field is a 1-byte field that indicates - the type of the block. For the bundle payload block, this field - contains the value 1. - - Block Processing Control Flags: The Block Processing Control Flags - field is an SDNV that contains the block processing control flags - discussed in Section 4.3 above. - - Block Length: The Block Length field is an SDNV that contains the - aggregate length of all remaining fields of the block - which is - to say, the length of the bundle's payload. - - Payload: The Payload field contains the application data carried by - this bundle. - - That is, bundle payload blocks follow the canonical format of the - previous section with the restriction that the 'block contains an - - - -Scott & Burleigh Experimental [Page 23] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - EID-reference field' bit of the block processing control flags is - never set. The block body data for payload blocks is the application - data carried by the bundle. - -4.6. Extension Blocks - - "Extension blocks" are all blocks other than the primary and payload - blocks. Because extension blocks are not defined in the Bundle - Protocol specification (the present document), not all nodes - conforming to this specification will necessarily instantiate Bundle - Protocol implementations that include procedures for processing (that - is, recognizing, parsing, acting on, and/or producing) all extension - blocks. It is therefore possible for a node to receive a bundle that - includes extension blocks that the node cannot process. - - Whenever a bundle is forwarded that contains one or more extension - blocks that could not be processed, the "Block was forwarded without - being processed" flag must be set to 1 within the block processing - flags of each such block. For each block flagged in this way, the - flag may optionally be cleared (i.e., set to zero) by another node - that subsequently receives the bundle and is able to process that - block; the specifications defining the various extension blocks are - expected to define the circumstances under which this flag may be - cleared, if any. - -4.7. Dictionary Revision - - Any strings (scheme names and SSPs) in a bundle's dictionary that are - referenced neither from the bundle's primary block nor from the block - EID reference field of any extension block may be removed from the - dictionary at the time the bundle is forwarded. - - Whenever removal of a string from the dictionary causes the offsets - (within the dictionary byte array) of any other strings to change, - all endpoint ID references that refer to those strings must be - adjusted at the same time. Note that these references may be in the - primary block and/or in the block EID reference fields of extension - blocks. - -5. Bundle Processing - - The bundle processing procedures mandated in this section and in - Section 6 govern the operation of the Bundle Protocol Agent and the - Application Agent administrative element of each bundle node. They - are neither exhaustive nor exclusive. That is, supplementary DTN - protocol specifications (including, but not restricted to, the Bundle - Security Protocol [BSP]) may require that additional measures be - taken at specified junctures in these procedures. Such additional - - - -Scott & Burleigh Experimental [Page 24] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - measures shall not override or supersede the mandated bundle protocol - procedures, except that they may in some cases make these procedures - moot by requiring, for example, that implementations conforming to - the supplementary protocol terminate the processing of a given - incoming or outgoing bundle due to a fault condition recognized by - that protocol. - -5.1. Generation of Administrative Records - - All initial transmission of bundles is in response to bundle - transmission requests presented by nodes' application agents. When - required to "generate" an administrative record (a bundle status - report or a custody signal), the bundle protocol agent itself is - responsible for causing a new bundle to be transmitted, conveying - that record. In concept, the bundle protocol agent discharges this - responsibility by directing the administrative element of the node's - application agent to construct the record and request its - transmission as detailed in Section 6 below. In practice, the manner - in which administrative record generation is accomplished is an - implementation matter, provided the constraints noted in Section 6 - are observed. - - Under some circumstances, the requesting of status reports could - result in an unacceptable increase in the bundle traffic in the - network. For this reason, the generation of status reports is - mandatory only in one case, the deletion of a bundle for which - custody transfer is requested. In all other cases, the decision on - whether or not to generate a requested status report is left to the - discretion of the bundle protocol agent. Mechanisms that could - assist in making such decisions, such as pre-placed agreements - authorizing the generation of status reports under specified - circumstances, are beyond the scope of this specification. - - Notes on administrative record terminology: - - o A "bundle reception status report" is a bundle status report with - the "reporting node received bundle" flag set to 1. - - o A "custody acceptance status report" is a bundle status report - with the "reporting node accepted custody of bundle" flag set to - 1. - - o A "bundle forwarding status report" is a bundle status report with - the "reporting node forwarded the bundle" flag set to 1. - - o A "bundle delivery status report" is a bundle status report with - the "reporting node delivered the bundle" flag set to 1. - - - - -Scott & Burleigh Experimental [Page 25] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - o A "bundle deletion status report" is a bundle status report with - the "reporting node deleted the bundle" flag set to 1. - - o A "Succeeded" custody signal is a custody signal with the "custody - transfer succeeded" flag set to 1. - - o A "Failed" custody signal is a custody signal with the "custody - transfer succeeded" flag set to zero. - - o The "current custodian" of a bundle is the endpoint identified by - the current custodian endpoint ID in the bundle's primary block. - -5.2. Bundle Transmission - - The steps in processing a bundle transmission request are: - - Step 1: If custody transfer is requested for this bundle - transmission and, moreover, custody acceptance by the source node - is required, then either the bundle protocol agent must commit to - accepting custody of the bundle -- in which case processing - proceeds from Step 2 -- or the request cannot be honored and all - remaining steps of this procedure must be skipped. The bundle - protocol agent must not commit to accepting custody of a bundle if - the conditions under which custody of the bundle may be accepted - are not satisfied. The conditions under which a node may accept - custody of a bundle whose destination is not a singleton endpoint - are not defined in this specification. - - Step 2: Transmission of the bundle is initiated. An outbound - bundle must be created per the parameters of the bundle - transmission request, with current custodian endpoint ID set to - the null endpoint ID "dtn:none" and with the retention constraint - "Dispatch pending". The source endpoint ID of the bundle must be - either the ID of an endpoint of which the node is a member or the - null endpoint ID "dtn:none". - - Step 3: Processing proceeds from Step 1 of Section 5.4. - -5.3. Bundle Dispatching - - The steps in dispatching a bundle are: - - Step 1: If the bundle's destination endpoint is an endpoint of - which the node is a member, the bundle delivery procedure defined - in Section 5.7 must be followed. - - Step 2: Processing proceeds from Step 1 of Section 5.4. - - - - -Scott & Burleigh Experimental [Page 26] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -5.4. Bundle Forwarding - - The steps in forwarding a bundle are: - - Step 1: The retention constraint "Forward pending" must be added to - the bundle, and the bundle's "Dispatch pending" retention - constraint must be removed. - - Step 2: The bundle protocol agent must determine whether or not - forwarding is contraindicated for any of the reasons listed in - Figure 12. In particular: - - * The bundle protocol agent must determine which endpoint(s) to - forward the bundle to. The bundle protocol agent may choose - either to forward the bundle directly to its destination - endpoint (if possible) or to forward the bundle to some other - endpoint(s) for further forwarding. The manner in which this - decision is made may depend on the scheme name in the - destination endpoint ID but in any case is beyond the scope of - this document. If the agent finds it impossible to select any - endpoint(s) to forward the bundle to, then forwarding is - contraindicated. - - * Provided the bundle protocol agent succeeded in selecting the - endpoint(s) to forward the bundle to, the bundle protocol agent - must select the convergence layer adapter(s) whose services - will enable the node to send the bundle to the nodes of the - minimum reception group of each selected endpoint. The manner - in which the appropriate convergence layer adapters are - selected may depend on the scheme name in the destination - endpoint ID but in any case is beyond the scope of this - document. If the agent finds it impossible to select - convergence layer adapters to use in forwarding this bundle, - then forwarding is contraindicated. - - Step 3: If forwarding of the bundle is determined to be - contraindicated for any of the reasons listed in Figure 12, then - the Forwarding Contraindicated procedure defined in Section 5.4.1 - must be followed; the remaining steps of Section 5 are skipped at - this time. - - Step 4: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1, then the custody - transfer procedure defined in Section 5.10.2 must be followed. - - - - - - - -Scott & Burleigh Experimental [Page 27] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Step 5: For each endpoint selected for forwarding, the bundle - protocol agent must invoke the services of the selected - convergence layer adapter(s) in order to effect the sending of the - bundle to the nodes constituting the minimum reception group of - that endpoint. Determining the time at which the bundle is to be - sent by each convergence layer adapter is an implementation - matter. - - To keep from possibly invalidating bundle security, the sequencing - of the blocks in a forwarded bundle must not be changed as it - transits a node; received blocks must be transmitted in the same - relative order as that in which they were received. While blocks - may be added to bundles as they transit intermediate nodes, - removal of blocks that do not have their 'Discard block if it - can't be processed' flag in the block processing control flags set - to 1 may cause security to fail. - - Step 6: When all selected convergence layer adapters have informed - the bundle protocol agent that they have concluded their data - sending procedures with regard to this bundle: - - * If the "request reporting of bundle forwarding" flag in the - bundle's status report request field is set to 1, then a bundle - forwarding status report should be generated, destined for the - bundle's report-to endpoint ID. If the bundle has the - retention constraint "custody accepted" and all of the nodes in - the minimum reception group of the endpoint selected for - forwarding are known to be unable to send bundles back to this - node, then the reason code on this bundle forwarding status - report must be "forwarded over unidirectional link"; otherwise, - the reason code must be "no additional information". - - * The bundle's "Forward pending" retention constraint must be - removed. - -5.4.1. Forwarding Contraindicated - - The steps in responding to contraindication of forwarding for some - reason are: - - Step 1: The bundle protocol agent must determine whether or not to - declare failure in forwarding the bundle for this reason. Note: - this decision is likely to be influenced by the reason for which - forwarding is contraindicated. - - - - - - - -Scott & Burleigh Experimental [Page 28] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Step 2: If forwarding failure is declared, then the Forwarding - Failed procedure defined in Section 5.4.2 must be followed. - Otherwise, (a) if the bundle's custody transfer requested flag (in - the bundle processing flags field) is set to 1, then the custody - transfer procedure defined in Section 5.10 must be followed; (b) - when -- at some future time - the forwarding of this bundle ceases - to be contraindicated, processing proceeds from Step 5 of - Section 5.4. - -5.4.2. Forwarding Failed - - The steps in responding to a declaration of forwarding failure for - some reason are: - - Step 1: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1, custody transfer - failure must be handled. Procedures for handling failure of - custody transfer for a bundle whose destination is not a singleton - endpoint are not defined in this specification. For a bundle - whose destination is a singleton endpoint, the bundle protocol - agent must handle the custody transfer failure by generating a - "Failed" custody signal for the bundle, destined for the bundle's - current custodian; the custody signal must contain a reason code - corresponding to the reason for which forwarding was determined to - be contraindicated. (Note that discarding the bundle will not - delete it from the network, since the current custodian still has - a copy.) - - Step 2: If the bundle's destination endpoint is an endpoint of - which the node is a member, then the bundle's "Forward pending" - retention constraint must be removed. Otherwise, the bundle must - be deleted: the bundle deletion procedure defined in Section 5.13 - must be followed, citing the reason for which forwarding was - determined to be contraindicated. - -5.5. Bundle Expiration - - A bundle expires when the current time is greater than the bundle's - creation time plus its lifetime as specified in the primary bundle - block. Bundle expiration may occur at any point in the processing of - a bundle. When a bundle expires, the bundle protocol agent must - delete the bundle for the reason "lifetime expired": the bundle - deletion procedure defined in Section 5.13 must be followed. - - - - - - - - -Scott & Burleigh Experimental [Page 29] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -5.6. Bundle Reception - - The steps in processing a bundle received from another node are: - - Step 1: The retention constraint "Dispatch pending" must be added - to the bundle. - - Step 2: If the "request reporting of bundle reception" flag in the - bundle's status report request field is set to 1, then a bundle - reception status report with reason code "No additional - information" should be generated, destined for the bundle's - report-to endpoint ID. - - Step 3: For each block in the bundle that is an extension block - that the bundle protocol agent cannot process: - - * If the block processing flags in that block indicate that a - status report is requested in this event, then a bundle - reception status report with reason code "Block unintelligible" - should be generated, destined for the bundle's report-to - endpoint ID. - - * If the block processing flags in that block indicate that the - bundle must be deleted in this event, then the bundle protocol - agent must delete the bundle for the reason "Block - unintelligible"; the bundle deletion procedure defined in - Section 5.13 must be followed and all remaining steps of the - bundle reception procedure must be skipped. - - * If the block processing flags in that block do NOT indicate - that the bundle must be deleted in this event but do indicate - that the block must be discarded, then the bundle protocol - agent must remove this block from the bundle. - - * If the block processing flags in that block indicate NEITHER - that the bundle must be deleted NOR that the block must be - discarded, then the bundle protocol agent must set to 1 the - "Block was forwarded without being processed" flag in the block - processing flags of the block. - - Step 4: If the bundle's custody transfer requested flag (in the - bundle processing flags field) is set to 1 and the bundle has the - same source endpoint ID, creation timestamp, and (if the bundle is - a fragment) fragment offset and payload length as another bundle - that (a) has not been discarded and (b) currently has the - retention constraint "Custody accepted", custody transfer - redundancy must be handled. Otherwise, processing proceeds from - Step 5. Procedures for handling redundancy in custody transfer - - - -Scott & Burleigh Experimental [Page 30] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - for a bundle whose destination is not a singleton endpoint are not - defined in this specification. For a bundle whose destination is - a singleton endpoint, the bundle protocol agent must handle - custody transfer redundancy by generating a "Failed" custody - signal for this bundle with reason code "Redundant reception", - destined for this bundle's current custodian, and removing this - bundle's "Dispatch pending" retention constraint. - - Step 5: Processing proceeds from Step 1 of Section 5.3. - -5.7. Local Bundle Delivery - - The steps in processing a bundle that is destined for an endpoint of - which this node is a member are: - - Step 1: If the received bundle is a fragment, the application data - unit reassembly procedure described in Section 5.9 must be - followed. If this procedure results in reassembly of the entire - original application data unit, processing of this bundle (whose - fragmentary payload has been replaced by the reassembled - application data unit) proceeds from Step 2; otherwise, the - retention constraint "Reassembly pending" must be added to the - bundle and all remaining steps of this procedure are skipped. - - Step 2: Delivery depends on the state of the registration whose - endpoint ID matches that of the destination of the bundle: - - * If the registration is in the Active state, then the bundle - must be delivered subject to this registration (see Section 3.1 - above) as soon as all previously received bundles that are - deliverable subject to this registration have been delivered. - - * If the registration is in the Passive state, then the - registration's delivery failure action must be taken (see - Section 3.1 above). - - Step 3: As soon as the bundle has been delivered: - - * If the "request reporting of bundle delivery" flag in the - bundle's status report request field is set to 1, then a bundle - delivery status report should be generated, destined for the - bundle's report-to endpoint ID. Note that this status report - only states that the payload has been delivered to the - application agent, not that the application agent has processed - that payload. - - - - - - -Scott & Burleigh Experimental [Page 31] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - * If the bundle's custody transfer requested flag (in the bundle - processing flags field) is set to 1, custodial delivery must be - reported. Procedures for reporting custodial delivery for a - bundle whose destination is not a singleton endpoint are not - defined in this specification. For a bundle whose destination - is a singleton endpoint, the bundle protocol agent must report - custodial delivery by generating a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - -5.8. Bundle Fragmentation - - It may at times be necessary for bundle protocol agents to reduce the - sizes of bundles in order to forward them. This might be the case, - for example, if the endpoint to which a bundle is to be forwarded is - accessible only via intermittent contacts and no upcoming contact is - long enough to enable the forwarding of the entire bundle. - - The size of a bundle can be reduced by "fragmenting" the bundle. To - fragment a bundle whose payload is of size M is to replace it with - two "fragments" -- new bundles with the same source endpoint ID and - creation timestamp as the original bundle -- whose payloads are the - first N and the last (M - N) bytes of the original bundle's payload, - where 0 < N < M. Note that fragments may themselves be fragmented, - so fragmentation may in effect replace the original bundle with more - than two fragments. (However, there is only one 'level' of - fragmentation, as in IP fragmentation.) - - Any bundle whose primary block's bundle processing flags do NOT - indicate that it must not be fragmented may be fragmented at any - time, for any purpose, at the discretion of the bundle protocol - agent. - - Fragmentation shall be constrained as follows: - - o The concatenation of the payloads of all fragments produced by - fragmentation must always be identical to the payload of the - bundle that was fragmented. Note that the payloads of fragments - resulting from different fragmentation episodes, in different - parts of the network, may be overlapping subsets of the original - bundle's payload. - - o The bundle processing flags in the primary block of each fragment - must be modified to indicate that the bundle is a fragment, and - both fragment offset and total application data unit length must - be provided at the end of each fragment's primary bundle block. - - o The primary blocks of the fragments will differ from that of the - fragmented bundle as noted above. - - - -Scott & Burleigh Experimental [Page 32] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - o The payload blocks of fragments will differ from that of the - fragmented bundle as noted above. - - o All blocks that precede the payload block at the time of - fragmentation must be replicated in the fragment with the lowest - offset. - - o All blocks that follow the payload block at the time of - fragmentation must be replicated in the fragment with the highest - offset. - - o If the 'Block must be replicated in every fragment' bit is set to - 1, then the block must be replicated in every fragment. - - o If the 'Block must be replicated in every fragment' bit is set to - zero, the block should be replicated in only one fragment. - - o The relative order of all blocks that are present in a fragment - must be the same as in the bundle prior to fragmentation. - -5.9. Application Data Unit Reassembly - - If the concatenation -- as informed by fragment offsets and payload - lengths -- of the payloads of all previously received fragments with - the same source endpoint ID and creation timestamp as this fragment, - together with the payload of this fragment, forms a byte array whose - length is equal to the total application data unit length in the - fragment's primary block, then: - - o This byte array -- the reassembled application data unit -- must - replace the payload of this fragment. - - o The "Reassembly pending" retention constraint must be removed from - every other fragment whose payload is a subset of the reassembled - application data unit. - - Note: reassembly of application data units from fragments occurs at - destination endpoints as necessary; an application data unit may also - be reassembled at some other endpoint on the route to the - destination. - - - - - - - - - - - -Scott & Burleigh Experimental [Page 33] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -5.10. Custody Transfer - - The conditions under which a node may accept custody of a bundle - whose destination is not a singleton endpoint are not defined in this - specification. - - The decision as to whether or not to accept custody of a bundle whose - destination is a singleton endpoint is an implementation matter that - may involve both resource and policy considerations; however, if the - bundle protocol agent has committed to accepting custody of the - bundle (as described in Step 1 of Section 5.2), then custody must be - accepted. - - If the bundle protocol agent elects to accept custody of the bundle, - then it must follow the custody acceptance procedure defined in - Section 5.10.1. - -5.10.1. Custody Acceptance - - Procedures for acceptance of custody of a bundle whose destination is - not a singleton endpoint are not defined in this specification. - - Procedures for acceptance of custody of a bundle whose destination is - a singleton endpoint are defined as follows. - - The retention constraint "Custody accepted" must be added to the - bundle. - - If the "request reporting of custody acceptance" flag in the bundle's - status report request field is set to 1, a custody acceptance status - report should be generated, destined for the report-to endpoint ID of - the bundle. However, if a bundle reception status report was - generated for this bundle (Step 1 of Section 5.6), then this report - should be generated by simply turning on the "Reporting node accepted - custody of bundle" flag in that earlier report's status flags byte. - - The bundle protocol agent must generate a "Succeeded" custody signal - for the bundle, destined for the bundle's current custodian. - - The bundle protocol agent must assert the new current custodian for - the bundle. It does so by changing the current custodian endpoint ID - in the bundle's primary block to the endpoint ID of one of the - singleton endpoints in which the node is registered. This may entail - appending that endpoint ID's null-terminated scheme name and SSP to - the dictionary byte array in the bundle's primary block, and in some - case it may also enable the (optional) removal of the current - custodian endpoint ID's scheme name and/or SSP from the dictionary. - - - - -Scott & Burleigh Experimental [Page 34] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - The bundle protocol agent may set a custody transfer countdown timer - for this bundle; upon expiration of this timer prior to expiration of - the bundle itself and prior to custody transfer success for this - bundle, the custody transfer failure procedure detailed in - Section 5.12 must be followed. The manner in which the countdown - interval for such a timer is determined is an implementation matter. - - The bundle should be retained in persistent storage if possible. - -5.10.2. Custody Release - - Procedures for release of custody of a bundle whose destination is - not a singleton endpoint are not defined in this specification. - - When custody of a bundle is released, where the destination of the - bundle is a singleton endpoint, the "Custody accepted" retention - constraint must be removed from the bundle and any custody transfer - timer that has been established for this bundle must be destroyed. - -5.11. Custody Transfer Success - - Procedures for determining custody transfer success for a bundle - whose destination is not a singleton endpoint are not defined in this - specification. - - Upon receipt of a "Succeeded" custody signal at a node that is a - custodial node of the bundle identified in the custody signal, where - the destination of the bundle is a singleton endpoint, custody of the - bundle must be released as described in Section 5.10.2. - -5.12. Custody Transfer Failure - - Procedures for determining custody transfer failure for a bundle - whose destination is not a singleton endpoint are not defined in this - specification. Custody transfer for a bundle whose destination is a - singleton endpoint is determined to have failed at a custodial node - for that bundle when either (a) that node's custody transfer timer - for that bundle (if any) expires or (b) a "Failed" custody signal for - that bundle is received at that node. - - Upon determination of custody transfer failure, the action taken by - the bundle protocol agent is implementation-specific and may depend - on the nature of the failure. For example, if custody transfer - failure was inferred from expiration of a custody transfer timer or - was asserted by a "Failed" custody signal with the "Depleted storage" - reason code, the bundle protocol agent might choose to re-forward the - bundle, possibly on a different route (Section 5.4). Receipt of a - "Failed" custody signal with the "Redundant reception" reason code, - - - -Scott & Burleigh Experimental [Page 35] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - on the other hand, might cause the bundle protocol agent to release - custody of the bundle and to revise its algorithm for computing - countdown intervals for custody transfer timers. - -5.13. Bundle Deletion - - The steps in deleting a bundle are: - - Step 1: If the retention constraint "Custody accepted" currently - prevents this bundle from being discarded, and the destination of - the bundle is a singleton endpoint, then: - - * Custody of the node is released as described in Section 5.10.2. - - * A bundle deletion status report citing the reason for deletion - must be generated, destined for the bundle's report-to endpoint - ID. - - Otherwise, if the "request reporting of bundle deletion" flag in - the bundle's status report request field is set to 1, then a - bundle deletion status report citing the reason for deletion - should be generated, destined for the bundle's report-to endpoint - ID. - - Step 2: All of the bundle's retention constraints must be removed. - -5.14. Discarding a Bundle - - As soon as a bundle has no remaining retention constraints it may be - discarded. - -5.15. Canceling a Transmission - - When requested to cancel a specified transmission, where the bundle - created upon initiation of the indicated transmission has not yet - been discarded, the bundle protocol agent must delete that bundle for - the reason "transmission cancelled". For this purpose, the procedure - defined in Section 5.13 must be followed. - -5.16. Polling - - When requested to poll a specified registration that is in the - Passive state, the bundle protocol agent must immediately deliver the - least recently received bundle that is deliverable subject to the - indicated registration, if any. - - - - - - -Scott & Burleigh Experimental [Page 36] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -6. Administrative Record Processing - -6.1. Administrative Records - - Administrative records are standard application data units that are - used in providing some of the features of the Bundle Protocol. Two - types of administrative records have been defined to date: bundle - status reports and custody signals. - - Every administrative record consists of a four-bit record type code - followed by four bits of administrative record flags, followed by - record content in type-specific format. Record type codes are - defined as follows: - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0001 | Bundle status report. | - +---------+--------------------------------------------+ - | 0010 | Custody signal. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 8: Administrative Record Type Codes - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0001 | Record is for a fragment; fragment | - | | offset and length fields are present. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 9: Administrative Record Flags - - All time values in administrative records are UTC times expressed in - "DTN time" representation. A DTN time consists of an SDNV indicating - the number of seconds since the start of the year 2000, followed by - an SDNV indicating the number of nanoseconds since the start of the - indicated second. - - The contents of the various types of administrative records are - described below. - - - - - -Scott & Burleigh Experimental [Page 37] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -6.1.1. Bundle Status Reports - - The transmission of 'bundle status reports' under specified - conditions is an option that can be invoked when transmission of a - bundle is requested. These reports are intended to provide - information about how bundles are progressing through the system, - including notices of receipt, custody transfer, forwarding, final - delivery, and deletion. They are transmitted to the Report-to - endpoints of bundles. - - +----------------+----------------+----------------+----------------+ - | Status Flags | Reason code | Fragment offset (*) (if - +----------------+----------------+----------------+----------------+ - present) | Fragment length (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Time of receipt of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of custody acceptance of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of forwarding of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of delivery of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Time of deletion of bundle X (a DTN time, if present) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp time (*) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp sequence number (*) | - +----------------+----------------+----------------+----------------+ - | Length of X's source endpoint ID (*) | Source - +----------------+---------------------------------+ + - endpoint ID of bundle X (variable) | - +----------------+----------------+----------------+----------------+ - - Figure 10: Bundle Status Report Format - - (*) Notes: - - The Fragment Offset field, if present, is an SDNV and is therefore - variable length. A three-octet SDNV is shown here for convenience in - representation. - - The Fragment Length field, if present, is an SDNV and is therefore - variable length. A three-octet SDNV is shown here for convenience in - representation. - - - - - - -Scott & Burleigh Experimental [Page 38] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - The Creation Timestamp fields replicate the Creation Timestamp fields - in the primary block of the subject bundle. As such they are SDNVs - (see Section 4.5.1 above) and are therefore variable length. Four- - octet SDNVs are shown here for convenience in representation. - - The source endpoint ID length field is an SDNV and is therefore - variable length. A three-octet SDNV is shown here for convenience in - representation. - - The fields in a bundle status report are: - - Status Flags: A 1-byte field containing the following flags: - - +----------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ - | 00000001 | Reporting node received bundle. | - +----------+--------------------------------------------+ - | 00000010 | Reporting node accepted custody of bundle.| - +----------+--------------------------------------------+ - | 00000100 | Reporting node forwarded the bundle. | - +----------+--------------------------------------------+ - | 00001000 | Reporting node delivered the bundle. | - +----------+--------------------------------------------+ - | 00010000 | Reporting node deleted the bundle. | - +----------+--------------------------------------------+ - | 00100000 | Unused. | - +----------+--------------------------------------------+ - | 01000000 | Unused. | - +----------+--------------------------------------------+ - | 10000000 | Unused. | - +----------+--------------------------------------------+ - - Figure 11: Status Flags for Bundle Status Reports - - Reason Code: A 1-byte field explaining the value of the flags in - the status flags byte. The list of status report reason codes - provided here is neither exhaustive nor exclusive; supplementary - DTN protocol specifications (including, but not restricted to, the - Bundle Security Protocol [BSP]) may define additional reason - codes. Status report reason codes are defined as follows: - - - - - - - - - - -Scott & Burleigh Experimental [Page 39] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0x00 | No additional information. | - +---------+--------------------------------------------+ - | 0x01 | Lifetime expired. | - +---------+--------------------------------------------+ - | 0x02 | Forwarded over unidirectional link. | - +---------+--------------------------------------------+ - | 0x03 | Transmission canceled. | - +---------+--------------------------------------------+ - | 0x04 | Depleted storage. | - +---------+--------------------------------------------+ - | 0x05 | Destination endpoint ID unintelligible. | - +---------+--------------------------------------------+ - | 0x06 | No known route to destination from here. | - +---------+--------------------------------------------+ - | 0x07 | No timely contact with next node on route.| - +---------+--------------------------------------------+ - | 0x08 | Block unintelligible. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 12: Status Report Reason Codes - - Fragment Offset: If the bundle fragment bit is set in the status - flags, then the offset (within the original application data unit) - of the payload of the bundle that caused the status report to be - generated is included here. - - Fragment length: If the bundle fragment bit is set in the status - flags, then the length of the payload of the subject bundle is - included here. - - Time of Receipt (if present): If the bundle-received bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was received at the reporting node is included here. - - Time of Custody Acceptance (if present): If the custody-accepted - bit is set in the status flags, then a DTN time indicating the - time at which custody was accepted at the reporting node is - included here. - - Time of Forward (if present): If the bundle-forwarded bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was first forwarded at the reporting node is included here. - - - - -Scott & Burleigh Experimental [Page 40] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Time of Delivery (if present): If the bundle-delivered bit is set - in the status flags, then a DTN time indicating the time at which - the bundle was delivered at the reporting node is included here. - - Time of Deletion (if present): If the bundle-deleted bit is set in - the status flags, then a DTN time indicating the time at which the - bundle was deleted at the reporting node is included here. - - Creation Timestamp of Subject Bundle: A copy of the creation - timestamp of the bundle that caused the status report to be - generated. - - Length of Source Endpoint ID: The length in bytes of the source - endpoint ID of the bundle that caused the status report to be - generated. - - Source Endpoint ID text: The text of the source endpoint ID of the - bundle that caused the status report to be generated. - -6.1.2. Custody Signals - - Custody signals are administrative records that effect custody - transfer operations. They are transmitted to the endpoints that are - the current custodians of bundles. - - Custody signals have the following format. - - Custody signal regarding bundle 'X': - - +----------------+----------------+----------------+----------------+ - | Status | Fragment offset (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Fragment length (*) (if present) | - +----------------+----------------+----------------+----------------+ - | Time of signal (a DTN time) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp time (*) | - +----------------+----------------+----------------+----------------+ - | Copy of bundle X's Creation Timestamp sequence number (*) | - +----------------+----------------+----------------+----------------+ - | Length of X's source endpoint ID (*) | Source - +----------------+---------------------------------+ + - endpoint ID of bundle X (variable) | - +----------------+----------------+----------------+----------------+ - - Figure 13: Custody Signal Format - - - - - -Scott & Burleigh Experimental [Page 41] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - (*) Notes: - - The Fragment Offset field, if present, is an SDNV and is therefore - variable length. A three-octet SDNV is shown here for convenience in - representation. - - The Fragment Length field, if present, is an SDNV and is therefore - variable length. A four-octet SDNV is shown here for convenience in - representation. - - The Creation Timestamp fields replicate the Creation Timestamp fields - in the primary block of the subject bundle. As such they are SDNVs - (see Section 4.5.1 above) and are therefore variable length. Four- - octet SDNVs are shown here for convenience in representation. - - The source endpoint ID length field is an SDNV and is therefore - variable length. A three-octet SDNV is shown here for convenience in - representation. - - The fields in a custody signal are: - - Status: A 1-byte field containing a 1-bit "custody transfer - succeeded" flag followed by a 7-bit reason code explaining the - value of that flag. Custody signal reason codes are defined as - follows: - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Experimental [Page 42] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - +---------+--------------------------------------------+ - | Value | Meaning | - +=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ - | 0x00 | No additional information. | - +---------+--------------------------------------------+ - | 0x01 | Reserved for future use. | - +---------+--------------------------------------------+ - | 0x02 | Reserved for future use. | - +---------+--------------------------------------------+ - | 0x03 | Redundant reception (reception by a node | - | | that is a custodial node for this bundle).| - +---------+--------------------------------------------+ - | 0x04 | Depleted storage. | - +---------+--------------------------------------------+ - | 0x05 | Destination endpoint ID unintelligible. | - +---------+--------------------------------------------+ - | 0x06 | No known route to destination from here. | - +---------+--------------------------------------------+ - | 0x07 | No timely contact with next node on route.| - +---------+--------------------------------------------+ - | 0x08 | Block unintelligible. | - +---------+--------------------------------------------+ - | (other) | Reserved for future use. | - +---------+--------------------------------------------+ - - Figure 14: Custody Signal Reason Codes - - Fragment offset: If the bundle fragment bit is set in the status - flags, then the offset (within the original application data unit) - of the payload of the bundle that caused the status report to be - generated is included here. - - Fragment length: If the bundle fragment bit is set in the status - flags, then the length of the payload of the subject bundle is - included here. - - Time of Signal: A DTN time indicating the time at which the signal - was generated. - - Creation Timestamp of Subject Bundle: A copy of the creation - timestamp of the bundle to which the signal applies. - - Length of Source Endpoint ID: The length in bytes of the source - endpoint ID of the bundle to which the signal applied. - - - - - - - -Scott & Burleigh Experimental [Page 43] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Source Endpoint ID text: The text of the source endpoint ID of the - bundle to which the signal applies. - -6.2. Generation of Administrative Records - - Whenever the application agent's administrative element is directed - by the bundle protocol agent to generate an administrative record - with reference to some bundle, the following procedure must be - followed: - - Step 1: The administrative record must be constructed. If the - referenced bundle is a fragment, the administrative record must - have the Fragment flag set and must contain the fragment offset - and fragment length fields. The value of the fragment offset - field must be the value of the referenced bundle's fragment - offset, and the value of the fragment length field must be the - length of the referenced bundle's payload. - - Step 2: A request for transmission of a bundle whose payload is - this administrative record must be presented to the bundle - protocol agent. - -6.3. Reception of Custody Signals - - For each received custody signal that has the "custody transfer - succeeded" flag set to 1, the administrative element of the - application agent must direct the bundle protocol agent to follow the - custody transfer success procedure in Section 5.11. - - For each received custody signal that has the "custody transfer - succeeded" flag set to 0, the administrative element of the - application agent must direct the bundle protocol agent to follow the - custody transfer failure procedure in Section 5.12. - -7. Services Required of the Convergence Layer - -7.1. The Convergence Layer - - The successful operation of the end-to-end bundle protocol depends on - the operation of underlying protocols at what is termed the - "convergence layer"; these protocols accomplish communication between - nodes. A wide variety of protocols may serve this purpose, so long - as each convergence layer protocol adapter provides a defined minimal - set of services to the bundle protocol agent. This convergence layer - service specification enumerates those services. - - - - - - -Scott & Burleigh Experimental [Page 44] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -7.2. Summary of Convergence Layer Services - - Each convergence layer protocol adapter is expected to provide the - following services to the bundle protocol agent: - - o sending a bundle to all bundle nodes in the minimum reception - group of the endpoint identified by a specified endpoint ID that - are reachable via the convergence layer protocol; and - - o delivering to the bundle protocol agent a bundle that was sent by - a remote bundle node via the convergence layer protocol. - - The convergence layer service interface specified here is neither - exhaustive nor exclusive. That is, supplementary DTN protocol - specifications (including, but not restricted to, the Bundle Security - Protocol [BSP]) may expect convergence layer adapters that serve BP - implementations conforming to those protocols to provide additional - services. - -8. Security Considerations - - The bundle protocol has taken security into concern from the outset - of its design. It was always assumed that security services would be - needed in the use of the bundle protocol. As a result, the bundle - protocol security architecture and the available security services - are specified in an accompanying document, the Bundle Security - Protocol specification [BSP]; an informative overview of this - architecture is provided in [SECO]. - - The bundle protocol has been designed with the notion that it will be - run over networks with scarce resources. For example, the networks - might have limited bandwidth, limited connectivity, constrained - storage in relay nodes, etc. Therefore, the bundle protocol must - ensure that only those entities authorized to send bundles over such - constrained environments are actually allowed to do so. All - unauthorized entities should be prevented from consuming valuable - resources. - - Likewise, because of the potentially long latencies and delays - involved in the networks that make use of the bundle protocol, data - sources should be concerned with the integrity of the data received - at the intended destination(s) and may also be concerned with - ensuring confidentiality of the data as it traverses the network. - Without integrity, the bundle payload data might be corrupted while - in transit without the destination able to detect it. Similarly, the - data source can be concerned with ensuring that the data can only be - used by those authorized, hence the need for confidentiality. - - - - -Scott & Burleigh Experimental [Page 45] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - Internal to the bundle-aware overlay network, the bundle nodes should - be concerned with the authenticity of other bundle nodes as well as - the preservation of bundle payload data integrity as it is forwarded - between bundle nodes. - - As a result, bundle security is concerned with the authenticity, - integrity, and confidentiality of bundles conveyed among bundle - nodes. This is accomplished via the use of three independent - security-specific bundle blocks, which may be used together to - provide multiple bundle security services or independently of one - another, depending on perceived security threats, mandated security - requirements, and security policies that must be enforced. - - The Bundle Authentication Block (BAB) ensures the authenticity and - integrity of bundles on a hop-by-hop basis between bundle nodes. The - BAB allows each bundle node to verify a bundle's authenticity before - processing or forwarding the bundle. In this way, entities that are - not authorized to send bundles will have unauthorized transmissions - blocked by security-aware bundle nodes. - - Additionally, to provide "security-source" to "security-destination" - bundle authenticity and integrity, the Payload Security Block (PSB) - is used. A "security-source" may not actually be the origination - point of the bundle but instead may be the first point along the path - that is security-aware and is able to apply security services. For - example, an enclave of networked systems may generate bundles but - only their gateway may be required and/or able to apply security - services. The PSB allows any security-enabled entity along the - delivery path, in addition to the "security-destination" (the - recipient counterpart to the "security-source"), to ensure the - bundle's authenticity. - - Finally, to provide payload confidentiality, the use of the - Confidentiality Block (CB) is available. The bundle payload may be - encrypted to provide "security-source" to "security-destination" - payload confidentiality/privacy. The CB indicates the cryptographic - algorithm and key IDs that were used to encrypt the payload. - - Note that removal of strings from the dictionary at a given point in - a bundle's end-to-end path, and attendant adjustment of endpoint ID - references in the blocks of that bundle, may make it necessary to re- - compute values in one or more of the bundle's security blocks. - - Bundle security must not be invalidated by forwarding nodes even - though they themselves might not use the Bundle Security Protocol. - In particular, the sequencing of the blocks in a forwarded bundle - must not be changed as it transits a node; received blocks must be - transmitted in the same relative order as that in which they were - - - -Scott & Burleigh Experimental [Page 46] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - received. While blocks may be added to bundles as they transit - intermediate nodes, removal of blocks that do not have their 'Discard - block if it can't be processed' flag in the block processing control - flags set to 1 may cause security to fail. - - Inclusion of the Bundle Security Protocol in any Bundle Protocol - implementation is RECOMMENDED. Use of the Bundle Security Protocol - in Bundle Protocol operations is OPTIONAL. - -9. IANA Considerations - - The "dtn:" URI scheme has been provisionally registered by IANA. See - http://www.iana.org/assignments/uri-schemes.html for the latest - details. - -10. References - -10.1. Normative References - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform - Resource Identifier (URI): Generic Syntax", RFC 3986, - STD 66, January 2005. - - [URIREG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and - Registration Procedures for New URI Schemes", RFC 4395, - BCP 115, February 2006. - -10.2. Informative References - - [ARCH] V. Cerf et. al., "Delay-Tolerant Network Architecture", - RFC 4838, April 2007. - - [ASN1] "Abstract Syntax Notation One (ASN.1), "ASN.1 Encoding - Rules: Specification of Basic Encoding Rules (BER), - Canonical Encoding Rules (CER) and Distinguished Encoding - Rules (DER)," ITU-T Rec. X.690 (2002) | ISO/IEC 8825- - 1:2002", 2003. - - [BSP] Symington, S., "Bundle Security Protocol Specification", - Work Progress, October 2007. - - [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, January 2005. - - - - - -Scott & Burleigh Experimental [Page 47] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - - [SECO] Farrell, S., Symington, S., Weiss, H., and P. Lovell, - "Delay-Tolerant Networking Security Overview", - Work Progress, July 2007. - - [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for - Challenged Internets", SIGCOMM 2003 . - - [TUT] Warthman, F., "Delay-Tolerant Networks (DTNs): A - Tutorial", . - - [UTC] Arias, E. and B. Guinot, ""Coordinated universal time UTC: - historical background and perspectives" in Journees - systemes de reference spatio-temporels", 2004. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Scott & Burleigh Experimental [Page 48] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -Appendix A. Contributors - - This was an effort of the Delay Tolerant Networking Research Group. - The following DTNRG participants contributed significant technical - material and/or inputs: Dr. Vinton Cerf of Google, Scott Burleigh, - Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, - Michael Demmer of the University of California at Berkeley, Robert - Durst, Keith Scott, and Susan Symington of The MITRE Corporation, - Kevin Fall of Intel Research, Stephen Farrell of Trinity College - Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of Ohio - University (most of Section 4.1), and Howard Weiss of SPARTA, Inc. - (text of Section 8). - -Appendix B. Comments - - Please refer comments to dtn-interest@mailman.dtnrg.org. The Delay - Tolerant Networking Research Group (DTNRG) Web site is located at - http://www.dtnrg.org. - -Authors' Addresses - - Keith L. Scott - The MITRE Corporation - 7515 Colshire Drive - McLean, VA 21102 - US - - Phone: +1 703 983 6547 - Fax: +1 703 983 7142 - EMail: kscott@mitre.org - - - Scott Burleigh - NASA Jet Propulsion Laboratory - 4800 Oak Grove Dr. - Pasadena, CA 91109-8099 - US - - Phone: +1 818 393 3353 - Fax: +1 818 354 1075 - EMail: Scott.Burleigh@jpl.nasa.gov - - - - - - - - - - -Scott & Burleigh Experimental [Page 49] -=0C -RFC 5050 Bundle Protocol Specification November 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78 and at www.rfc-editor.org/copyright.html, and - except as set forth therein, the authors retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org. - - - - - - - - - - - - -Scott & Burleigh Experimental [Page 50] -=0C diff -r 8b0d483af1e2 -r e62055127255 servlib/bundling/BundleDaemon.cc --- a/servlib/bundling/BundleDaemon.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/bundling/BundleDaemon.cc Sun Dec 13 21:46:12 2009 -0800 @@ -1320,10 +1320,12 @@ void BundleDaemon::handle_registration_removed(RegistrationRemovedEvent* event) { + Registration* registration =3D event->registration_; log_info("REGISTRATION_REMOVED %d %s", registration->regid(), registration->endpoint().c_str()); - =20 + + if (!reg_table_->del(registration->regid())) { log_err("error removing registration %d from table", registration->regid()); diff -r 8b0d483af1e2 -r e62055127255 servlib/cmd/DiscoveryCommand.cc --- a/servlib/cmd/DiscoveryCommand.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/cmd/DiscoveryCommand.cc Sun Dec 13 21:46:12 2009 -0800 @@ -30,21 +30,60 @@ DiscoveryCommand::DiscoveryCommand() : TclCommand("discovery") { - add_to_help("add " - "[ " - " " - "]", - "add discovery agent (address family can be ip or bt " - "[Bluetooth])"); - =20 - add_to_help("del ","remove discovery agent");=20 + add_to_help("add [ " + " = " + " ]", + "add a discovery agent\n" + " valid options:\n" + " \n" + " A string to define agent name\n" + " \n" + " The CLA type\n" + " bt\n" + " ip\n" + " bonjour\n" + " [ CLA specific options ]\n" + " \n" + " \n" + " \n" + " \n" + " \n" + " \n"); + + add_to_help("del ", + "remove discovery agent\n" + " valid options:\n" + " \n" + " A string to define agent name\n");=20 =20 add_to_help("announce " - " [ ]", - "announce the address of a local interface (convergence " - "layer)"); - add_to_help("remove ","remove announcement for local interface")= ; - add_to_help("list","list all discovery agents and announcements"); + " [ ]", + "announce the address of a local interface (convergence " + "layer)\n" + " valid options:\n" + " \n" + " The CLA name\n" + " \n" + " An agent name string\n" + " \n" + " The CLA type\n" + " bt\n" + " ip\n" + " \n" + " Periodic announcement interval\n" + " \n" + " [ CLA specific options ]\n" + " \n" + " \n"); + + add_to_help("remove ", + "remove announcement for local interface\n" + " valid options:\n" + " \n" + " The CLA name\n"); + + add_to_help("list", + "list all discovery agents and announcements\n"); } =20 int diff -r 8b0d483af1e2 -r e62055127255 servlib/cmd/InterfaceCommand.cc --- a/servlib/cmd/InterfaceCommand.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/cmd/InterfaceCommand.cc Sun Dec 13 21:46:12 2009 -0800 @@ -5,7 +5,7 @@ * you may not use this file except in compliance with the License. * You may obtain a copy of the License at *=20 - * http://www.apache.org/licenses/LICENSE-2.0 + * http://www.apache.org/licenses/LICENSE-2.0 *=20 * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, @@ -29,9 +29,43 @@ InterfaceCommand::InterfaceCommand() : TclCommand("interface")=20 { - add_to_help("add [?]", - "add an interface"); - add_to_help("del ", "delete an interface"); + add_to_help("add [arg1=3Dval1 arg=3Dval2 argN=3Dva= lN...]", + "add an interface\n" + " valid options:\n" + " \n" + " An interface name (string)\n" + " \n" + " The Convergence Layer Adapter (CLA)\n" + " udp\n" + " tcp\n" + " eth\n" + " :\n" + " Ethernet interface name (string://eth0)\n" + " bt\n" + " :\n" + " Bluetooth RFCOMM channel number (number)\n" + " serial\n" + " null\n" + " file\n" + " extcl\n" + " :\n" + " mtu \n" + " min_retry_interval \n" + " max_retry_interval \n" + " idle_close_time \n" + " potential_downtime \n" + " prevhop_hdr \n" + " cost \n" + " qlimit_bundles_high \n" + " qlimit_bytes_high \n" + " qlimit_bundles_low \n" + " qlimit_bytes_low \n" + " retry_interval \n"); + add_to_help("del ", "delete an interface" + "\n" + " valid options:\n" + " \n" + " An interface name (string)\n"); add_to_help("list", "list all of the interfaces"); } =20 @@ -41,58 +75,58 @@ (void)interp; // interface list if (strcasecmp("list", argv[1]) =3D=3D 0) { - // XXX/bowei -- seems to like to core - if (argc > 2) { - wrong_num_args(argc, argv, 1, 2, 2); - } + // XXX/bowei -- seems to like to core + if (argc > 2) { + wrong_num_args(argc, argv, 1, 2, 2); + } =20 - oasys::StringBuffer buf; - InterfaceTable::instance()->list(&buf); - set_result(buf.c_str()); + oasys::StringBuffer buf; + InterfaceTable::instance()->list(&buf); + set_result(buf.c_str()); =20 - return TCL_OK; + return TCL_OK; } =20 // interface add else if (strcasecmp(argv[1], "add") =3D=3D 0) { - if (argc < 4) { - wrong_num_args(argc, argv, 1, 4, INT_MAX); - return TCL_ERROR; - } - =20 - const char* name =3D argv[2]; - const char* proto =3D argv[3]; + if (argc < 4) { + wrong_num_args(argc, argv, 1, 4, INT_MAX); + return TCL_ERROR; + } +=09 + const char* name =3D argv[2]; + const char* proto =3D argv[3]; =20 - ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(proto); - if (!cl) { - resultf("can't find convergence layer for %s", proto); - return TCL_ERROR; - } + ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(proto); + if (!cl) { + resultf("can't find convergence layer for %s", proto); + return TCL_ERROR; + } =20 - // XXX/demmer return error string from here - if (! InterfaceTable::instance()->add(name, cl, proto, - argc - 4, argv + 4)) { - resultf("error adding interface %s", name); - return TCL_ERROR; - } - return TCL_OK; + // XXX/demmer return error string from here + if (! InterfaceTable::instance()->add(name, cl, proto, + argc - 4, argv + 4)) { + resultf("error adding interface %s", name); + return TCL_ERROR; + } + return TCL_OK; } =20 // interface del else if (strcasecmp(argv[1], "del") =3D=3D 0) { - if (argc !=3D 3) { - wrong_num_args(argc, argv, 2, 4, 4); - return TCL_ERROR; - } + if (argc !=3D 3) { + wrong_num_args(argc, argv, 2, 4, 4); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; - =20 - if (! InterfaceTable::instance()->del(name)) { - resultf("error removing interface %s", name); - return TCL_ERROR; - } + const char* name =3D argv[2]; +=09 + if (! InterfaceTable::instance()->del(name)) { + resultf("error removing interface %s", name); + return TCL_ERROR; + } =20 - return TCL_OK; + return TCL_OK; } =20 resultf("invalid interface subcommand %s", argv[1]); diff -r 8b0d483af1e2 -r e62055127255 servlib/cmd/LinkCommand.cc --- a/servlib/cmd/LinkCommand.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/cmd/LinkCommand.cc Sun Dec 13 21:46:12 2009 -0800 @@ -1,17 +1,17 @@ /* - * Copyright 2004-2006 Intel Corporation + * Copyright 2004-2006 Intel Corporation *=20 - * Licensed under the Apache License, Version 2.0 (the "License"); - * you may not use this file except in compliance with the License. - * You may obtain a copy of the License at + * Licensed under the Apache License, Version 2.0 (the "License"); + * you may not use this file except in compliance with the License. + * You may obtain a copy of the License at *=20 - * http://www.apache.org/licenses/LICENSE-2.0 + * http://www.apache.org/licenses/LICENSE-2.0 *=20 - * Unless required by applicable law or agreed to in writing, software - * distributed under the License is distributed on an "AS IS" BASIS, - * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or impl= ied. - * See the License for the specific language governing permissions and - * limitations under the License. + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied= . + * See the License for the specific language governing permissions and + * limitations under the License. */ =20 #ifdef HAVE_CONFIG_H @@ -32,355 +32,513 @@ namespace dtn { =20 LinkCommand::LinkCommand() - : TclCommand("link") + : TclCommand("link") { - add_to_help("add ", "add l= inks"); - add_to_help("open ", "open the link"); - add_to_help("close ", "close the link"); - add_to_help("delete ", "delete the link"); - add_to_help("set_available ",=20 - "hacky way to make the link available"); - add_to_help("state ", "return the state of a link"); - add_to_help("stats ", "dump link statistics"); - add_to_help("names", "print a list of existing link names"); - add_to_help("dump ", "print the list of existing links or " - "detailed info about a single link"); - add_to_help("reconfigure ...", - "configure link options after initialization " - "(not all options support this feature)"); - add_to_help("set_cl_defaults ...", - "configure convergence layer specific default options"); + add_to_help("add ...", + "add links" + "\n" + " valid options:\n" + " \n"=20 + " A string to define link name\n" + " \n" + " A string to define next hop name " + "if CLA type is file is a filesystem, if is eth is an Ethernet " + "HW Address or if is tcp or udp is an IP:PORT)\n" + " \n" + " The CLA type\n" + " udp\n" + " tcp\n" + " eth\n" + " bt\n" + " serial\n" + " null\n" + " file\n" + " extcl\n" + " \n" + " link type options\n"=20 + " ALLWAYSON\n"=20 + " ONDEMAND\n"=20 + " SCHEDULED\n"=20 + " OPPORTUNISTIC\n"=20 + " :\n" + " mtu \n" + " min_retry_interval \n" + " max_retry_interval \n" + " idle_close_time \n" + " potential_downtime \n" + " prevhop_hdr \n" + " cost \n" + " qlimit_bundles_high \n" + " qlimit_bytes_high \n" + " qlimit_bundles_low \n" + " qlimit_bytes_low \n" + " retry_interval \n"); + add_to_help("open ", "open the link" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("close ", "close the link" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("delete ", "delete the link" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("set_available ",=20 + "hacky way to make the link available" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("state ", "return the state of a link" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("stats ", "dump link statistics" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("names", "print a list of existing link names" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("dump ", "print the list of existing links or " + "detailed info about a single link" + "\n" + " valid options:\n" + " \n" + " A link name string\n"); + add_to_help("reconfigure ...", + "configure link options after initialization " + "\n" + " valid options:\n" + " \n" + " A link name string\n" + " :\n" + " mtu \n" + " min_retry_interval \n" + " max_retry_interval \n" + " idle_close_time \n" + " potential_downtime \n" + " prevhop_hdr \n" + " cost \n" + " qlimit_bundles_high \n" + " qlimit_bytes_high \n" + " qlimit_bundles_low \n" + " qlimit_bytes_low \n" + " retry_interval \n"); + add_to_help("set_cl_defaults ...", + "configure convergence layer specific default options" + "\n" + " valid options:\n" + " \n" + " The CLA type\n" + " udp\n" + " tcp\n" + " eth\n" + " bt\n" + " serial\n" + " null\n" + " file\n" + " extcl\n" + " :\n" + " mtu \n" + " min_retry_interval \n" + " max_retry_interval \n" + " idle_close_time \n" + " potential_downtime \n" + " prevhop_hdr \n" + " cost \n" + " qlimit_bundles_high \n" + " qlimit_bytes_high \n" + " qlimit_bundles_low \n" + " qlimit_bytes_low \n" + " retry_interval \n\n"); } +/* " **Note options for add, reconfigure and set_cl_defaults:\n\n" + " mtu is the MTU of the link, used to control\n " + " proactive fragmentation.\n\n" + " min_retry_interval is the minimum amount to \n" + " wait between attempts to re-open the link \n" + " in seconds). Default is set by the various\n " + " link types but can be overridden by \n" + " configuration parameters.\n\n" + " max_retry_interval is the Maximum amount to \n" + " wait between attempts to re-open the link (in\n " + " seconds). Default is set by the various Link \n" + " types but can be overridden by configuration \n" + " parameters.\n\n" + " idle_close_time is seconds of idle time \n" + " before the link is closed. Must be zero for \n" + " always on links (i.e. they are never closed). \n" + " Default is 30 seconds for on demand links, \n" + " zero for opportunistic links.\n\n" + " potential_downtime is a Conservative estimate \n" + " of the maximum amount of time that the link may \n" + " be down during 'normal' operation. Used by \n" + " routing algorithms to determine how long to leave \n" + " bundles queued on the down link before rerouting \n" + " them. Default is 30 seconds.\n\n" + " prevhop_hdr indicates whether or not to send \n" + " the previous hop header on this link. Default is \n" + " false.\n\n" + " cost is the abstract cost of the link, used \n" + " by routing algorithms. Default is 100.\n\n" + " qlimit_bundles_high is the high limits on the \n" + " number of bundles that should be queued on the \n" + " link. The high limits are used to indicate whether \n" + " or not more bundles can be queued onto the link to \n" + " effect backpressure from the convergence layers.\n\n" + " qlimit_bytes_high and qlimit_bytes_low is the \n" + " high or low limits on the number of bytes that \n" + " should be queued on the link. The high limits \n" + " are used to indicate whether or not more bundles \n" + " can be queued onto the link to effect backpressure \n" + " from the convergence layers. The low limits can \n" + " be used by the router to determine when to re-scan \n" + " the pending bundle lists\n\n" + " retry_interval is the seconds to wait between \n" + " attempts to re-open an unavailable link. Initially \n" + " set to min_retry_interval_, then doubles up to \n" + " max_retry_interval"); +*/ =20 int LinkCommand::exec(int argc, const char** argv, Tcl_Interp* interp) { - (void)interp; - =20 - if (argc < 2) { - resultf("need a link subcommand"); - return TCL_ERROR; - } + (void)interp; +=09 + if (argc < 2) { + resultf("need a link subcommand"); + return TCL_ERROR; + } =20 - const char* cmd =3D argv[1]; + const char* cmd =3D argv[1]; =20 - if (strcmp(cmd, "add") =3D=3D 0) { - // link add - if (argc < 6) { - wrong_num_args(argc, argv, 2, 6, INT_MAX); - return TCL_ERROR; - } - =20 - const char* name =3D argv[2]; - const char* nexthop =3D argv[3]; - const char* type_str =3D argv[4]; - const char* cl_str =3D argv[5]; + if (strcmp(cmd, "add") =3D=3D 0) { + // link add + if (argc < 6) { + wrong_num_args(argc, argv, 2, 6, INT_MAX); + return TCL_ERROR; + } + =09 + const char* name =3D argv[2]; + const char* nexthop =3D argv[3]; + const char* type_str =3D argv[4]; + const char* cl_str =3D argv[5]; =20 - // validate the link type, make sure there's no link of the - // same name, and validate the convergence layer - Link::link_type_t type =3D Link::str_to_link_type(type_str); - if (type =3D=3D Link::LINK_INVALID) { - resultf("invalid link type %s", type_str); - return TCL_ERROR; - } + // validate the link type, make sure there's no link of the + // same name, and validate the convergence layer + Link::link_type_t type =3D Link::str_to_link_type(type_str); + if (type =3D=3D Link::LINK_INVALID) { + resultf("invalid link type %s", type_str); + return TCL_ERROR; + } =20 - ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(cl_str); - if (!cl) { - resultf("invalid convergence layer %s", cl_str); - return TCL_ERROR; - } + ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(cl_str); + if (!cl) { + resultf("invalid convergence layer %s", cl_str); + return TCL_ERROR; + } =20 - // Create the link, parsing the cl-specific next hop string - // and other arguments - LinkRef link; - const char* invalid_arg =3D "(unknown)"; - link =3D Link::create_link(name, type, cl, nexthop, argc - 6, &arg= v[6], - &invalid_arg); - if (link =3D=3D NULL) { - resultf("invalid link option: %s", invalid_arg); - return TCL_ERROR; - } + // Create the link, parsing the cl-specific next hop string + // and other arguments + LinkRef link; + const char* invalid_arg =3D "(unknown)"; + link =3D Link::create_link(name, type, cl, nexthop, argc - 6, &argv[6], + &invalid_arg); + if (link =3D=3D NULL) { + resultf("invalid link option: %s", invalid_arg); + return TCL_ERROR; + } =20 - // Add the link to contact manager's table if it is not already - // present. The contact manager will post a LinkCreatedEvent to - // the daemon if the link is added successfully. - if (!BundleDaemon::instance()->contactmgr()->add_new_link(link)) { - // A link of that name already exists - link->delete_link(); - resultf("link name %s already exists, use different name", nam= e); - return TCL_ERROR; - } - return TCL_OK; + // Add the link to contact manager's table if it is not already + // present. The contact manager will post a LinkCreatedEvent to + // the daemon if the link is added successfully. + if (!BundleDaemon::instance()->contactmgr()->add_new_link(link)) { + // A link of that name already exists + link->delete_link(); + resultf("link name %s already exists, use different name", name); + return TCL_ERROR; + } + return TCL_OK; =20 - } else if (strcmp(cmd, "reconfigure") =3D=3D 0) { - // link set_option ... - if (argc < 4) { - wrong_num_args(argc, argv, 2, 4, INT_MAX); - return TCL_ERROR; - } + } else if (strcmp(cmd, "reconfigure") =3D=3D 0) { + // link set_option ... + if (argc < 4) { + wrong_num_args(argc, argv, 2, 4, INT_MAX); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; - =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - }=20 + const char* name =3D argv[2]; + =09 + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + }=20 =20 - argc -=3D 3; - argv +=3D 3; + argc -=3D 3; + argv +=3D 3; =20 - const char* invalid; - int count =3D link->parse_args(argc, argv, &invalid); - if (count =3D=3D -1) { - resultf("invalid link option: %s", invalid); - return TCL_ERROR; - } - argc -=3D count; - =20 - if (!link->reconfigure_link(argc, argv)) { - return TCL_ERROR; - } - =20 - return TCL_OK; - =20 - } else if (strcmp(cmd, "open") =3D=3D 0) { - // link open - if (argc !=3D 3) { - wrong_num_args(argc, argv, 2, 3, 3); - return TCL_ERROR; - } + const char* invalid; + int count =3D link->parse_args(argc, argv, &invalid); + if (count =3D=3D -1) { + resultf("invalid link option: %s", invalid); + return TCL_ERROR; + } + argc -=3D count; + =09 + if (!link->reconfigure_link(argc, argv)) { + return TCL_ERROR; + } + =09 + return TCL_OK; + =09 + } else if (strcmp(cmd, "open") =3D=3D 0) { + // link open + if (argc !=3D 3) { + wrong_num_args(argc, argv, 2, 3, 3); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; - =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + const char* name =3D argv[2]; + =09 + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - if (link->isopen()) { - resultf("link %s already open", name); - return TCL_OK; - } + if (link->isopen()) { + resultf("link %s already open", name); + return TCL_OK; + } =20 - // XXX/TODO should change all these to post_and_wait - BundleDaemon::post(new LinkStateChangeRequest(link, Link::OPEN, - ContactEvent::USER))= ; - =20 - } else if (strcmp(cmd, "close") =3D=3D 0) { - // link close - if (argc !=3D 3) { - wrong_num_args(argc, argv, 2, 3, 3); - return TCL_ERROR; - } + // XXX/TODO should change all these to post_and_wait + BundleDaemon::post(new LinkStateChangeRequest(link, Link::OPEN, + ContactEvent::USER)); + =09 + } else if (strcmp(cmd, "close") =3D=3D 0) { + // link close + if (argc !=3D 3) { + wrong_num_args(argc, argv, 2, 3, 3); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; - =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + const char* name =3D argv[2]; + =09 + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - if (! link->isopen() && ! link->isopening()) { - resultf("link %s already closed", name); - return TCL_OK; - } + if (! link->isopen() && ! link->isopening()) { + resultf("link %s already closed", name); + return TCL_OK; + } =20 - BundleDaemon::instance()->post( - new LinkStateChangeRequest(link, Link::CLOSED, - ContactEvent::USER)); + BundleDaemon::instance()->post( + new LinkStateChangeRequest(link, Link::CLOSED, + ContactEvent::USER)); =20 - return TCL_OK; + return TCL_OK; =20 - } else if (strcmp(cmd, "delete") =3D=3D 0) { - // link delete - if (argc !=3D 3) { - wrong_num_args(argc, argv, 2, 3, 3); - return TCL_ERROR; - } + } else if (strcmp(cmd, "delete") =3D=3D 0) { + // link delete + if (argc !=3D 3) { + wrong_num_args(argc, argv, 2, 3, 3); + return TCL_ERROR; + } =20 - const char * name =3D argv[2]; + const char * name =3D argv[2]; =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - BundleDaemon::instance()->post(new LinkDeleteRequest(link)); - return TCL_OK; + BundleDaemon::instance()->post(new LinkDeleteRequest(link)); + return TCL_OK; =20 - } else if (strcmp(cmd, "set_available") =3D=3D 0) { - // link set_available - if (argc !=3D 4) { - wrong_num_args(argc, argv, 2, 4, 4); - return TCL_ERROR; - } + } else if (strcmp(cmd, "set_available") =3D=3D 0) { + // link set_available + if (argc !=3D 4) { + wrong_num_args(argc, argv, 2, 4, 4); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; + const char* name =3D argv[2]; =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - int len =3D strlen(argv[3]); - bool set_available; + int len =3D strlen(argv[3]); + bool set_available; =20 - if (strncmp(argv[3], "1", len) =3D=3D 0) { - set_available =3D true; - } else if (strncmp(argv[3], "0", len) =3D=3D 0) { - set_available =3D false; - } else if (strncasecmp(argv[3], "true", len) =3D=3D 0) { - set_available =3D true; - } else if (strncasecmp(argv[3], "false", len) =3D=3D 0) { - set_available =3D false; - } else if (strncasecmp(argv[3], "on", len) =3D=3D 0) { - set_available =3D true; - } else if (strncasecmp(argv[3], "off", len) =3D=3D 0) { - set_available =3D false; - } else { - resultf("error converting argument %s to boolean value", argv[= 3]); - return TCL_ERROR; - } + if (strncmp(argv[3], "1", len) =3D=3D 0) { + set_available =3D true; + } else if (strncmp(argv[3], "0", len) =3D=3D 0) { + set_available =3D false; + } else if (strncasecmp(argv[3], "true", len) =3D=3D 0) { + set_available =3D true; + } else if (strncasecmp(argv[3], "false", len) =3D=3D 0) { + set_available =3D false; + } else if (strncasecmp(argv[3], "on", len) =3D=3D 0) { + set_available =3D true; + } else if (strncasecmp(argv[3], "off", len) =3D=3D 0) { + set_available =3D false; + } else { + resultf("error converting argument %s to boolean value", argv[3]); + return TCL_ERROR; + } =20 - if (set_available) { - if (link->state() !=3D Link::UNAVAILABLE) { - resultf("link %s already in state %s", - name, Link::state_to_str(link->state())); - return TCL_OK; - } + if (set_available) { + if (link->state() !=3D Link::UNAVAILABLE) { + resultf("link %s already in state %s", + name, Link::state_to_str(link->state())); + return TCL_OK; + } =20 - BundleDaemon::post( - new LinkStateChangeRequest(link, Link::AVAILABLE, - ContactEvent::USER)); - =20 - return TCL_OK; + BundleDaemon::post( + new LinkStateChangeRequest(link, Link::AVAILABLE, + ContactEvent::USER)); + =09 + return TCL_OK; =20 - } else { // ! set_available - if (link->state() !=3D Link::AVAILABLE) { - resultf("link %s can't be set unavailable in state %s", - name, Link::state_to_str(link->state())); - return TCL_OK; - } - =20 - BundleDaemon::post( - new LinkStateChangeRequest(link, Link::UNAVAILABLE, - ContactEvent::USER)); - =20 - return TCL_OK; - } - } - else if ((strcmp(cmd, "state") =3D=3D 0) || - (strcmp(cmd, "stats") =3D=3D 0)) - { - // link state - // link stats - if (argc !=3D 3) { - wrong_num_args(argc, argv, 2, 3, 3); - return TCL_ERROR; - } + } else { // ! set_available + if (link->state() !=3D Link::AVAILABLE) { + resultf("link %s can't be set unavailable in state %s", + name, Link::state_to_str(link->state())); + return TCL_OK; + } + =09 + BundleDaemon::post( + new LinkStateChangeRequest(link, Link::UNAVAILABLE, + ContactEvent::USER)); +=09 + return TCL_OK; + } + } + else if ((strcmp(cmd, "state") =3D=3D 0) || + (strcmp(cmd, "stats") =3D=3D 0)) + { + // link state + // link stats + if (argc !=3D 3) { + wrong_num_args(argc, argv, 2, 3, 3); + return TCL_ERROR; + } =20 - const char* name =3D argv[2]; + const char* name =3D argv[2]; =20 - LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link= (name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + LinkRef link =3D BundleDaemon::instance()->contactmgr()->find_link(name)= ; + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - if (strcmp(cmd, "state") =3D=3D 0) { - resultf("%s", Link::state_to_str(link->state())); - } else { - oasys::StringBuffer buf; - link->dump_stats(&buf); - set_result(buf.c_str()); - } - return TCL_OK; - } - else if (strcmp(cmd, "names") =3D=3D 0)=20 - { - // link names - if (argc !=3D 2) { - wrong_num_args(argc, argv, 2, 2, 2); - return TCL_ERROR; - } + if (strcmp(cmd, "state") =3D=3D 0) { + resultf("%s", Link::state_to_str(link->state())); + } else { + oasys::StringBuffer buf; + link->dump_stats(&buf); + set_result(buf.c_str()); + } + return TCL_OK; + } + else if (strcmp(cmd, "names") =3D=3D 0)=20 + { + // link names + if (argc !=3D 2) { + wrong_num_args(argc, argv, 2, 2, 2); + return TCL_ERROR; + } =20 - ContactManager* cm =3D BundleDaemon::instance()->contactmgr(); - oasys::ScopeLock l(cm->lock(), "LinkCommand::exec"); - =20 - const LinkSet* links =3D cm->links(); - for (LinkSet::const_iterator i =3D links->begin(); - i !=3D links->end(); ++i) - { - append_resultf("%s\n", (*i)->name()); - } - return TCL_OK; - } - else if (strcmp(cmd, "dump") =3D=3D 0)=20 - { - // link dump - if (argc =3D=3D 2) { - ContactManager* cm =3D BundleDaemon::instance()->contactmgr(); - oasys::ScopeLock l(cm->lock(), "LinkCommand::exec"); - =20 - const LinkSet* links =3D cm->links(); - for (LinkSet::const_iterator i =3D links->begin(); - i !=3D links->end(); ++i) - { - append_resultf("*%p\n", (*i).object()); - } - } else if (argc =3D=3D 3) { - const char* name =3D argv[2]; - =20 - LinkRef link =3D - BundleDaemon::instance()->contactmgr()->find_link(name); - if (link =3D=3D NULL) { - resultf("link %s doesn't exist", name); - return TCL_ERROR; - } + ContactManager* cm =3D BundleDaemon::instance()->contactmgr(); + oasys::ScopeLock l(cm->lock(), "LinkCommand::exec"); + =09 + const LinkSet* links =3D cm->links(); + for (LinkSet::const_iterator i =3D links->begin(); + i !=3D links->end(); ++i) + { + append_resultf("%s\n", (*i)->name()); + } + return TCL_OK; + } + else if (strcmp(cmd, "dump") =3D=3D 0)=20 + { + // link dump + if (argc =3D=3D 2) { + ContactManager* cm =3D BundleDaemon::instance()->contactmgr(); + oasys::ScopeLock l(cm->lock(), "LinkCommand::exec"); + =09 + const LinkSet* links =3D cm->links(); + for (LinkSet::const_iterator i =3D links->begin(); + i !=3D links->end(); ++i) + { + append_resultf("*%p\n", (*i).object()); + } + } else if (argc =3D=3D 3) { + const char* name =3D argv[2]; + =09 + LinkRef link =3D + BundleDaemon::instance()->contactmgr()->find_link(name); + if (link =3D=3D NULL) { + resultf("link %s doesn't exist", name); + return TCL_ERROR; + } =20 - oasys::StringBuffer buf; - link->dump(&buf); - set_result(buf.c_str()); - return TCL_OK; - } else { - wrong_num_args(argc, argv, 2, 2, 3); - return TCL_ERROR; - } - } - else if (strcmp(cmd, "set_cl_defaults") =3D=3D 0) - { - // link set_cl_defaults ... - if (argc < 4) { - wrong_num_args(argc, argv, 2, 4, INT_MAX); - return TCL_ERROR; - } + oasys::StringBuffer buf; + link->dump(&buf); + set_result(buf.c_str()); + return TCL_OK; + } else { + wrong_num_args(argc, argv, 2, 2, 3); + return TCL_ERROR; + } + } + else if (strcmp(cmd, "set_cl_defaults") =3D=3D 0) + { + // link set_cl_defaults ... + if (argc < 4) { + wrong_num_args(argc, argv, 2, 4, INT_MAX); + return TCL_ERROR; + } =20 - ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(argv[2]); - if (cl =3D=3D NULL) { - resultf("unknown convergence layer %s", argv[2]); - return TCL_ERROR; - } + ConvergenceLayer* cl =3D ConvergenceLayer::find_clayer(argv[2]); + if (cl =3D=3D NULL) { + resultf("unknown convergence layer %s", argv[2]); + return TCL_ERROR; + } =20 - const char* invalid; - if (!cl->set_link_defaults(argc - 3, &argv[3], &invalid)) { - resultf("invalid link option: %s", invalid); - return TCL_ERROR; - } - =20 - return TCL_OK; - } - else - { - resultf("unimplemented link subcommand %s", cmd); - return TCL_ERROR; - } - =20 - return TCL_OK; + const char* invalid; + if (!cl->set_link_defaults(argc - 3, &argv[3], &invalid)) { + resultf("invalid link option: %s", invalid); + return TCL_ERROR; + } + =09 + return TCL_OK; + } + else + { + resultf("unimplemented link subcommand %s", cmd); + return TCL_ERROR; + } +=09 + return TCL_OK; } =20 } // namespace dtn diff -r 8b0d483af1e2 -r e62055127255 servlib/cmd/RouteCommand.cc --- a/servlib/cmd/RouteCommand.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/cmd/RouteCommand.cc Sun Dec 13 21:46:12 2009 -0800 @@ -41,105 +41,162 @@ : TclCommand("route") { bind_var(new oasys::StringOpt("type", &BundleRouter::config_.type_,=20 - "type", "Which routing algorithm to use.= ")); + "type", "Which routing algorithm to use = " + "(default static).\n" + " valid options:\n" + " static\n" + " prophet\n" + " flood\n" + " dtlsr\n" + " tca_router\n" + " tca_gateway\n" + " external")); =20 bind_var(new oasys::BoolOpt("add_nexthop_routes", &BundleRouter::config_.add_nexthop_routes_= , - "Whether or not to automatically add route= s " - "for next hop links")); + "Whether or not to automatically add routes " + "for next hop links (default is true)\n" + " valid options: true or false\n")); =20 + add_to_help("add [opts]", "add a route"); + =20 + add_to_help("del ", "delete a route"); + =20 + add_to_help("dump", "dump all of the static routes"); + bind_var(new oasys::BoolOpt("open_discovered_links", &BundleRouter::config_.open_discovered_lin= ks_, - "Whether or not to automatically open " - "discovered opportunistic links")); + "Whether or not to automatically open " + "discovered opportunistic links (default is true)\n" + " valid options: true or false\n")); =20 bind_var(new oasys::IntOpt("default_priority", &BundleRouter::config_.default_priority_, - "priority", - "Default priority for new routes " - "(initially zero)")); + "priority", + "Default priority for new routes " + "(default 0)\n" + " valid options: number\n")); =20 bind_var(new oasys::IntOpt("max_route_to_chain", &BundleRouter::config_.max_route_to_chain_, - "length", - "Maximum number of route_to links to follow= ")); + "length", + "Maximum number of route_to links to follow " + "(default 10)\n" + " valid options: number\n")); =20 bind_var(new oasys::UIntOpt("subscription_timeout", &BundleRouter::config_.subscription_timeou= t_, - "timeout", - "Default timeout for upstream subscription= ")); + "timeout", + "Default timeout for upstream subscription " + "(default 600)\n" + " valid options: number\n")); =20 bind_var(new oasys::StringOpt("dtlsr_area", &DTLSRConfig::instance()->area_, - "area", "Administrative area for the loc= al node")); + "area", "Administrative area for the local= node " + "(default "")\n" + " valid options: string\n")); + =20 bind_var(new oasys::EnumOpt("dtlsr_weight_fn", DTLSRConfig::instance()->weight_opts_, (int*)&DTLSRConfig::instance()->weight_fn_= , - "fn", "Weight function for the graph")); + "fn", "Weight function for the graph " + "(default 10.0)\n" + " valid options: number\n")); =20 bind_var(new oasys::UIntOpt("dtlsr_weight_shift", &DTLSRConfig::instance()->weight_shift_, - "shift", "Scale the weight on down links")= ); + "shift", "Scale the weight on down links" + "Factor by which to age the cost of a link= " + "based on its uptime, " + "as a link's uptime goes to zero, the cost= " + "increases by 10x the original cost " + "(default 0)\n" + " valid options: number\n")); + =20 bind_var(new oasys::DoubleOpt("dtlsr_uptime_factor", - &DTLSRConfig::instance()->uptime_factor_= , - "pct", "Aging pct for cost of down links= ")); + &DTLSRConfig::instance()->uptime_factor_, + "pct", "Aging pct for cost of down links" + "(default 10.0)\n" + " valid options: number\n")); =20 bind_var(new oasys::BoolOpt("dtlsr_keep_down_links", &DTLSRConfig::instance()->keep_down_links_= , - "Whether or not to retain down links in th= e graph")); + "Whether or not to retain down links in th= e graph " + "(default is true)\n" + " valid options: true or false\n")); =20 bind_var(new oasys::UIntOpt("dtlsr_recompute_delay", &DTLSRConfig::instance()->recompute_delay_= , "seconds", - "Delay to compute routes after LSA arrives= ")); + "Delay to compute routes after LSA arrives= " + "(default 1)\n" + " valid options: number\n")); =20 - bind_var(new oasys::UIntOpt("dtlsr_aging_delay", + bind_var(new oasys::UIntOpt("dtlsr_aging_interval", &DTLSRConfig::instance()->aging_interval_, "seconds", - "Interval to locally recompute routes")); + "Interval to locally recompute routes " + "(default 5)\n" + " valid options: number\n")); =20 bind_var(new oasys::UIntOpt("dtlsr_lsa_interval", &DTLSRConfig::instance()->lsa_interval_, "seconds", - "Interval to periodically send LSAs")); + "Interval to periodically send LSAs " + "(default 3600)\n" + " valid options: number\n")); + + bind_var(new oasys::UIntOpt("dtlsr_min_lsa_interval", + &DTLSRConfig::instance()->min_lsa_interval_, + "seconds", + "Minimum interval to periodically send LSAs " + "(default 5)\n" + " valid options: number\n")); =20 bind_var(new oasys::UIntOpt("dtlsr_lsa_lifetime", &DTLSRConfig::instance()->lsa_lifetime_, "seconds", - "Lifetime of LSA bundles")); + "Lifetime of LSA bundles " + "(default 86400)\n" + " valid options: number\n")); =20 - add_to_help("add [opts]", "add a route"); - add_to_help("del ", "delete a route"); - add_to_help("dump", "dump all of the static routes"); - #if defined(XERCES_C_ENABLED) && defined(EXTERNAL_DP_ENABLED) bind_var(new oasys::UInt16Opt("server_port", - &ExternalRouter::server_port, - "port", - "UDP port for IPC with external router(s= )")); + &ExternalRouter::server_port, + "port", + "UDP port for IPC with external router(s) " + "(default 8001)\n" + " valid options: number\n")); =20 bind_var(new oasys::UInt16Opt("hello_interval", - &ExternalRouter::hello_interval, - "interval", - "seconds between hello messages")); + &ExternalRouter::hello_interval, + "interval", + "Seconds between hello messages with external router(s)" + "(default 30)\n" + " valid options: number\n")); =20 bind_var(new oasys::StringOpt("schema", &ExternalRouter::schema, - "file", - "The external router interface " - "message schema.")); + "file", + "The external router interface " + "message schema " + "(default /router.xsd)\n" + " valid options: string\n")); =20 bind_var(new oasys::BoolOpt("xml_server_validation", &ExternalRouter::server_validation, "Perform xml validation on plug-in " - "interface messages (default is true)")); + "interface messages (default is true)\n" + " valid options: true or false\n")); =20 bind_var(new oasys::BoolOpt("xml_client_validation", &ExternalRouter::client_validation, "Include meta-info in xml messages " "so plug-in routers" - "can perform validation (default is false)= ")); + "can perform validation (default is false)= \n" + " valid options: true or false\n")); #endif } =20 diff -r 8b0d483af1e2 -r e62055127255 servlib/cmd/StorageCommand.cc --- a/servlib/cmd/StorageCommand.cc Sat Dec 12 17:10:03 2009 +0000 +++ b/servlib/cmd/StorageCommand.cc Sun Dec 13 21:46:12 2009 -0800 @@ -31,65 +31,130 @@ inited_ =3D false; =20 bind_var(new oasys::StringOpt("type", &cfg->type_, - "type", "What storage system to use.")); + "type", "What storage system to use " + "(default is berkeleydb).\n" + " valid options:\n" + " berkeleydb\n" + " mysql\n" + " postgres\n" + " external\n" + " memorydb\n" + " filesysdb")); =20 + bind_var(new oasys::StringOpt("dbname", &cfg->dbname_, - "name", "The database name.")); + "name", "The database name (default " + "DB)\n" + " valid options: string")); + bind_var(new oasys::StringOpt("dbdir", &cfg->dbdir_, - "dir", "The database directory.")); + "dir", "The database directory (default " + "/var/dtn/db).\n" + " valid options: directory")); =20 bind_var(new oasys::BoolOpt("init_db", &cfg->init_, - "Same as the --init-db argument to dtnd.")= ); + "Same as the --init-db argument to dtnd. " + "Initialize the database on startup " + "(default false)\n" + " valid options: true or false")); + bind_var(new oasys::BoolOpt("tidy", &cfg->tidy_, - "Same as the --tidy argument to dtnd.")); + "Same as the --tidy argument to dtnd. " + "Cleans out the database and the " + "bundle directories (default false)\n" + " valid options: true or false")); + bind_var(new oasys::IntOpt("tidy_wait", &cfg->tidy_wait_, - "time", - "How long to wait before really doing " - "the tidy operation.")); + "time", + "How long to wait before really doing " + "the tidy operation (default 3)\n" + " valid options: number")); + + bind_var(new oasys::BoolOpt("leave_clean_file", &cfg->leave_clean_file= _, + "Leave a .ds_clean file on clean " + "shutdown (default true)\n" + " valid options: true or false")); =20 bind_var(new oasys::IntOpt("fs_fd_cache_size", &cfg->fs_fd_cache_size_= ,=20 - "num", "number of open fds to cache")); + "num", "number of open fds to cache " + "using Filesysyem DB. If > zero then " + "this # of open fds will be cached " + "(default 0)\n" + " valid options: number")); =20 bind_var(new oasys::BoolOpt("db_mpool", &cfg->db_mpool_, - "use mpool in Berkeley DB")); + "use mpool in Berkeley DB (default " + "true)" + " valid options: true or false")); + bind_var(new oasys::BoolOpt("db_log", &cfg->db_log_, - "use logging in Berkeley DB")); + "use logging in Berkeley DB (default " + "true)\n" + " valid options: true or false")); + bind_var(new oasys::BoolOpt("db_txn", &cfg->db_txn_, - "use transactions in Berkeley DB")); + "use transactions in Berkeley DB " + "(default true)\n" + " valid options: true or false")); + bind_var(new oasys::BoolOpt("db_sharefile", &cfg->db_sharefile_, - "use shared database file")); + "use shared database file (and a " + "lock) in Berkeley DB (default false)\n" + " valid options: true or false")); + bind_var(new oasys::IntOpt("db_max_tx", &cfg->db_max_tx_, - "num", "max # of active transactions in Ber= keley DB")); + "num", "max # of active transactions " + "in Berkeley DB (default 0)\n" + " valid options: number")); + bind_var(new oasys::IntOpt("db_max_locks", &cfg->db_max_locks_, - "num", "max # of active locks in Berkeley D= B")); + "num", "max # of active locks in " + "Berkeley DB (default 0)\n" + " valid options: number")); + bind_var(new oasys::IntOpt("db_max_lockers", &cfg->db_max_lockers_, - "num", "max # of active locking threads in = Berkeley DB")); + "num", "max # of active locking threads in " + "Berkeley DB (default 0)\n" + " valid options: number")); + bind_var(new oasys::IntOpt("db_max_lockedobjs", &cfg->db_max_lockedobj= s_, - "num", "max # of active locked objects in B= erkeley DB")); + "num", "max # of active locked objects in " + "Berkeley DB (default 0)\n" + " valid options: number")); + bind_var(new oasys::IntOpt("db_lockdetect", &cfg->db_lockdetect_, - "freq", "frequency to check for Berkeley DB= deadlocks " - "(zero disables locking)")); + "num", "frequency to check for Berkeley " + "DB deadlocks (default 5000 and " + "zero disables locking)\n" + " valid options: number")); =20 - bind_var(new oasys::StringOpt("payloaddir", &cfg->payload_dir_, "dir", - "directory for payloads while in transit= ")); + bind_var(new oasys::StringOpt("payloaddir", &cfg->payload_dir_, + "dir", "directory for payloads while in " + "transit (default is /var/dtn/bundles)\n" + " valid options: directory")); =20 bind_var(new oasys::UInt64Opt("payload_quota", - &cfg->payload_quota_, "bytes", - "storage quota for bundle payloads " - "(0 is unlimited)")); + &cfg->payload_quota_, + "bytes", "storage quota in bytes for bun= dle " + "payloads (default 0 - is unlimited)\n" + " valid options: number")); =20 bind_var(new oasys::UIntOpt("payload_fd_cache_size", - &cfg->payload_fd_cache_size_, "num", - "number of payload file descriptors to kee= p " - "open in a cache")); + &cfg->payload_fd_cache_size_, + "num", "number of payload file descriptors= to keep " + "open in a cache (default 32)\n" + " valid options: number")); =20 bind_var(new oasys::UInt16Opt("server_port", &cfg->server_port_, "port number", - "TCP port for IPC to external data store= ")); + "TCP port for IPC to external data " + "store on localhost (default 0)\n" + " valid options: number")); =20 - bind_var(new oasys::StringOpt("schema", &cfg->schema_, "pathname", - "File containing the XML schema for the = " - "external data store interface")); + bind_var(new oasys::StringOpt("schema", &cfg->schema_, + "pathname", "File containing the XML sch= ema for the " + "external/remote data store interface\n" + " valid options: filename")); =20 add_to_help("usage", "print the current storage usage"); } diff -r 8b0d483af1e2 -r e62055127255 servlib/conv_layers/ConvergenceLayer.c= c --- a/servlib/conv_layers/ConvergenceLayer.cc Sat Dec 12 17:10:03 2009 +000= 0 +++ b/servlib/conv_layers/ConvergenceLayer.cc Sun Dec 13 21:46:12 2009 -080= 0 @@ -65,9 +65,8 @@ add_clayer(new NORMConvergenceLayer()); #endif // XXX/demmer fixme - // add_clayer("file", new FileConvergenceLayer()); + //add_clayer("file", new FileConvergenceLayer()); } - //---------------------------------------------------------------------- CLVector::~CLVector() { --=-dYbAUotzJ4SaTPDyYLDr-- Received: from sabe.cs.wisc.edu (sabe.cs.wisc.edu [128.105.6.20]) by maillists.intel-research.net (8.13.8/8.13.8) with ESMTP id nB35gO6X009044 for ; Wed, 2 Dec 2009 21:42:25 -0800 Received: from brentons-mac-mini.local (pool-96-255-47-4.washdc.fios.verizon.net [96.255.47.4]) (authenticated bits=0) by sabe.cs.wisc.edu (8.14.1/8.14.1) with ESMTP id nB35gVUZ010653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Dec 2009 23:42:31 -0600 Message-ID: <4B174FC1.9090208@cs.wisc.edu> Date: Thu, 03 Dec 2009 00:42:25 -0500 From: Brenton Walker User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: dtn-users@mailman.dtnrg.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [dtn-users] Stable and development versions X-BeenThere: dtn-users@maillists.intel-research.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: dtn-users mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 05:42:25 -0000 Hi, Have people considered the possibility of splitting Reference Implementation development into stable and development branches? I know there are releases like 2.6.0, but that doesn't seem to be subject to bug fixes and minor improvements. Thanks, Brenton /not currently a contributor, but curious