Subject: [dtn-interest] DTN Wiki
From: "Bush, Stephen F \(Research\)" <[email-masked]>
To: <[email-masked]>
Date: Fri, 22 Jul 2005 18:56:39 -0400
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

I'm interested in following the DTN work, particularly with regard to predictive routing, however, 
I did not notice a DTN meeting at ICWN'05.

Could someone add the following to the Wiki:

The Limits of Motion Prediction Support for Ad hoc Wireless Network Performance, Stephen F. Bush and Nathan Smith, The 2005 International Conference on Wireless Networks (ICWN-05) Monte Carlo Resort, Las Vegas, Nevada, USA, June 27-30, 2005. 
http://www.research.ge.com/~bushsf/pdfpapers/bush_worldacademy.pdf

Thanks,
Stephen F Bush (http://www.research.ge.com/~bushsf)

Date: Fri, 22 Jul 2005 15:28:51 -0700
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] internet drafts update
Sender: [email-masked]

A number of the Internet Drafts have been updated and are now
available on dtnrg.org:
http://www.dtnrg.org/wiki/Docs

    *      V. Cerf et. al., "Delay Tolerant Network Architecture",
draft-irtf-dtnrg-arch-03.txt, July 2005
    *      K. Scott, S. Burleigh, "Bundle Protocol Specification",
draft-irtf-dtnrg-bundle-spec-03.txt, July 2005
    *      S. Symington, S. Farrell, and H. Weiss, "Bundle Security
Protocol Specification", draft-irtf-dtnrg-bundle-security-00.txt, June
2005
    *      S. Burleigh et al, "Licklider Transmission Protocol"
          o     Motivation Document:
draft-irtf-dtnrg-ltp-motivation-01.txt, July 2005
          o     Main Spec: draft-irtf-dtnrg-ltp-03.txt, July 2005
          o     Extensions Document:
draft-irtf-dtnrg-ltp-extensions-01.txt, July 2005
    *      A. Lindgren and A. Doria, "Probabilistic Routing Protocol
for Intermittently Connected Networks",
draft-lindgren-dtnrg-prophet-01.txt, July 2005

Melissa

Melissa

Content-class: urn:content-classes:message
Date: Tue, 19 Jul 2005 19:16:26 -0700
From: "Fall, Kevin" <[email-masked]>
To: "Dimitrios Stiliadis" <[email-masked]>
Cc: "S. Keshav" <[email-masked]>, <[email-masked]>
Subject: [dtn-interest] announcement of WDTN (workshop on DTNs) at SIGCOMM 2005
Sender: [email-masked]

Greetings!

We invite you to participate in the first Workshop on Delay Tolerant
Networking (WDTN) to be held during SIGCOMM 2005 on Friday, August 26th
in Philadelphia.  Our Call pointed out that the Internet has a number of
significant problems when employed to fulfill service requirements or
when applied to some classes of networks for which it was not originally
designed.  For example, when disconnection and reconnection is common,
or link performance is highly variable or extreme, one or more of the
traditional Internet protocols do not work well. The goal of the
workshop is to explore physical networks that operate significantly
differently from wired, connected networks and the protocol
architectures used to deal with such situations, and techniques for
making applications tolerant to disruptions and/or high delays.

We think that the papers chosen for presentation fit well into the theme
of the Call. They fall naturally into three broad categories: routing,
movement/mobility, and new research directions. This grouping is
reflected in the three workshop sessions.

We hope that you will participate in the workshop and that you will
contribute to making it interesting, relevant, and the basis for a solid
research agenda in this exciting area.

For information and details about the SIGCOMM 2005 conference and WDTN
2005, see the conference web page at:
http://www.acm.org/sigs/sigcomm/sigcomm2005/.

We hope to see you there!

Sincerely,
Kevin Fall and S. Keshav
WDTN 2005 Co-chairs

Date: Wed, 20 Jul 2005 02:58:07 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] DTN related demo at MobiCom 2005
Sender: [email-masked]

Hi all,

I would just like to make you aware that there will be a DTN related demo
at the demo session of the MobiCom 2005 conference (to be held in Cologne,
Germany, Aug 28-Sept 2).

A group of students have implemented our PRoPHET routing protocol for
intermittently connected networks (the protocol described in the I-D
recently posted) on Lego MindStorms robots. The students have done a
really good job of showing the operation of the protocol in a visually
appealing way, putting much effort into making sure that people watching
can easily see what is happening in the various parts of the network, both
through audible and visual signals on the robots as well as control and
logging panels on laptops connected to the network that allow detailed
overview and control of everything that is happening.

Some more info about the project, including pictures and videos from
previous demo occasions can be found at:

http://prophet.azbean.com/

If you will be at MobiCom, we look forward to seeing you at the demo
session.

Best regards,

/Anders

Date: Tue, 19 Jul 2005 23:06:27 +0200 (MEST)
From: Anders Lindgren <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] New routing draft 
Sender: [email-masked]

All,

There is a new version of the draft below available at
http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-01.txt

Due to some bugs in our XML code some parts (equations) got lost when we
moved to the lated version of xml2rfc. Unfortunately it took a while
before someone noticed, but in this version it is fixed, and some other
minor changes has been made as well.

Anyway, this draft will be presented at the upcoming meeting at the Paris
IETF, so any comments and suggestions are most welcome.

/Anders

On Fri, 10 Jun 2005, Anders Lindgren wrote:

>
> All,  
>
> A new Internet-Draft for the PRoPHET probabilistic routing protocol for
> intermittently connected networks is available from the on-line
> Internet-Drafts directories at:
> http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-00.txt
> The I-D announcement can be found below. This is the first version of the
> draft, and all comments on it are most welcome and appreciated.
>
> /Anders
>
>
> -------------------
> Begin forwarded message:
>
> From: [email-masked]
> Date: 9 juni 2005 21.51.54 MET
> To: [email-masked]
> Subject: I-D ACTION:draft-lindgren-dtnrg-prophet-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Probabilistic Routing Protocol for Intermittently
>  		       	  Connected Networks
>  	Author(s)	: A. Lindgren, A. Doria
>  	Filename	: draft-lindgren-dtnrg-prophet-00.txt
>  	Pages		: 35
>  	Date		: 2005-6-9
>
>  This document describes 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 special cases of networks where
>    the Delay-Tolerant Network architecture[1] is applicable.  We define
>    PRoPHET, a Probabilistic Routing Protocol using History of Encounters
>    and Transitivity for intermittently connected networks.  The document
>    presents an architectural overview followed by the protocol
>    specification.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lindgren-dtnrg-prophet-00.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-lindgren-dtnrg-prophet-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
>  	"FILE /internet-drafts/draft-lindgren-dtnrg-prophet-00.txt".
>
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
>  	feature, insert the command "ENCODING mime" before the "FILE"
>  	command.  To decode the response(s), you will need "munpack" or
>  	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>  	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
>  	up into multiple messages), so check your local documentation on
>  	how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>  _______________________________________________
>  I-D-Announce mailing list
>  [email-masked]
>  https://www1.ietf.org/mailman/listinfo/i-d-announce
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Mon, 18 Jul 2005 17:41:53 -0700
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [dtn-interest] dtn architecture internet draft updated
Sender: [email-masked]

Hi,

The I-D for the DTN Architecture has been updated:

V. Cerf et. al., "Delay Tolerant Network Architecture",
draft-irtf-dtnrg-arch-03.txt, Jul 2005
http://www.dtnrg.org/docs/specs/draft-irtf-dtnrg-arch-03.txt

Melissa

Date: Mon, 18 Jul 2005 13:43:57 -0700
From: Melissa Ho <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked]
Subject: [dtn-interest] Bundle Security Protocol Specification
Sender: [email-masked]

The I-D for the security protocol specification is now available on
the Docs page of the dtnrg wiki (http://www.dtnrg.org):

S. Symington, S. Farrell, and H. Weiss, "Bundle Security Protocol
Specification", draft-irtf-dtnrg-bundle-security-00.txt, June 2005
http://www.dtnrg.org/docs/specs/draft-irtf-dtnrg-bundle-security-00.txt

Melissa

From: <[email-masked]>
To: [email-masked]
Date: Mon, 18 Jul 2005 14:13:21 -0500
Subject: [dtn-interest] Thomas L Vogl/CedarRapids/RockwellCollins is out of the office.
Sender: [email-masked]

I will be out of the office starting  07/18/2005 and will not return until
07/24/2005.

For UACO information contact Koji or for LSA contact Frank.

From: Dave Crocker <[email-masked]>
To: <[email-masked]>
Reply-To: Dave Crocker <[email-masked]>
Date: Mon, 18 Jul 2005 07:09:59 -0700
Subject: [dtn-interest] dtn-over-email
Sender: [email-masked]

>  I am planning to mainly use the DTN approach using email as the carrier
>  of information and data between nodes, both one to one and as a
>  mechanism for massive distribution.

If this has already been done, I apologize for missing it:

Perhaps there should be a specification to standardize DTN over email?

It would need to specify a MIME type, of course.  Perhaps application/dtn.

It probably should also specify some sort of addressing convention, to flag a 
standard address for the email/dtn gateway at each participating site.  Based on 
some other sub-addressing standards, perhaps a ABNF of:

    "dtn=" <mailbox> *("/" parameter) "@" <domain>

This allows multiple dtn servers on the same host.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

Date: Mon, 18 Jul 2005 07:52:28 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] turbo coding parameters
Sender: [email-masked]

Hello all,

I had a few questions regarding the use of turbo codes on deep space links. 
Firstly, what generator polynomials are generally used? What decoding 
algorithm is  used(LOGMAP, SOVA, LOGMAX?)What is the number of iterations 
during decoding?Finally, What are the block and constraint lengths used?

I am building a simulator to analyze a deep space link and need these final 
parameters to get it started.

Thanks You

Gautam

----------------------------------------------------------------------
Gautam Bhatia
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins CO - 80523
Tel:(970)-215-6316
Email: [email-masked]
----------------------------------------------------------------------

From: "Jose Manuel Diaz Rodriguez" <[email-masked]>
To: [email-masked]
Subject: RE: [dtn-interest] Use of the postal system as a transport for DTN messages
Date: Mon, 18 Jul 2005 10:11:36 +0000
Sender: [email-masked]

Hello.

Thank you for you answers.

I write from Madrid, Spain.
Although names are in Spanish, I'll try to give a translation.
My university is called UPM (Polythecnical University of Madrid). My school 
is called ETSIT (Telecommunication Engineering School).

For my graduation project, I'm collaborating with EHAS (Spanish-American 
Health Link), a non-profit institution, created by people at UPM and ISF, 
another NGO. More information can be found at http://www.ehas.org.

It would be great to work with more people, if you find it interesting.
As you said, Kevin, one of our first questions was which span a convergence 
layer like this would have. A graduation project at my school is about six 
months long, but I don't have full dedication to it, as I also work for a 
company not related to the project. Anyway, it seems that the convergence 
layer wouldn't require so much time; it could be complemented with some sort 
of appliance of DTN technology to some distributed applications developed by 
EHAS and currently based on email.

Regards,
José Manuel

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

From: =?ISO-8859-1?Q?Sten-Erik=20Bj=F6rling?= <[email-masked]>
To: <[email-masked]>
Subject: Re: [dtn-interest] Use of the postal system as a transport for DTN messages
Date: Sat, 16 Jul 2005 09:05:54 +0200
Organization: Enviro Data
Sender: [email-masked]

Hi,

I am planning to mainly use the DTN approach using email as the carrier
of information and data between nodes, both one to one and as a
mechanism for massive distribution. The approach that I will use is to
let the enclosed file to the message contain all the information to be
sent, a file that in itself contains all the meta-data controlling the
status of the information and the various blocks of information (InfoPack).

Since all the relevant information for the correct transfer of
information between in my case database systems are stored in a single
file that file can also be used in transfers using the standard
Internet, USB sticks and CD ROMs. By this the DTN system becomes one of
several transportation layers in the overall system and one can use
several different transport technologies simultaneously.

Since my effort is a commercial one I cannot be very open about the
structure and contents of the InfoPack but you can with a good effort
using XML create the structures needed for your own system. Just a
couple of notes though:

- The creation of the structures in the InfoPack will take more time and
effort than you might think in the beginning.
- The programming of the "packer" and "unpacker" at both the sender and
reciever will need good planning for the future abilities to expand and
being modified.
- One thing that is very often forgotten is the effort needed to connect
to the "data-supplying" systems like databases and manage them in a
matter that allows for expansion and simple modification. One must be
aware of that one is working with a process chain that not only contain
DTN elements but also database access and programming of useable client
interfaces.

Take care,

Stene

___

>Hello.
>
>I've recently begun my graduation project in Telecommunications Engineering.
>I plan to focus my work on the application of the postal system (or other 
>means of delivering mobile storage devices, such as USB keys or CDs) as a 
>transport for messages in a DTN network, which is particularly useful for 
>certain distributed applications being developed at my university for use in 
>developing countries.

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] draft for updated DTN Architecture Internet Draft
Date: Fri, 15 Jul 2005 23:06:18 -0700
From: "Fall, Kevin" <[email-masked]>
To: "Symington,Susan F." <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C589CC.7EBE97E4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks.  I have made another pass on this document, and am very close to
submitting it as the next I-D (due before Monday!).  Please see
attached.  If there are any remaining comments, I will need them
sometime this weekend.

Cheers,
- Kevin

> -----Original Message-----
> From: Symington,Susan F. [mailto:[email-masked]]
> Sent: Wednesday, July 13, 2005 1:19 PM
> To: Fall, Kevin; [email-masked]
> Subject: RE: [dtn-interest] draft for updated DTN Architecture
Internet
> Draft
>=20
> Kevin,
>=20
> I am almost all the way through the DTN Architecture document. Here
are
> my comments. I wanted to give them to you now so you can get started
on
> them. If I have any more, I will send them tomorrow.
>=20
> -susan
>=20
> O. The terminology of the architecture document needs to be updated to
> reflect the new terminology of the bundle protocol spec. There is a
> looseness that needs to be tightened.  For example, the word "sender"
is
> used when "Source" should be used, etc.
>=20
> 1. In the introduction, you say that DTN has a basic security model
that
> is "optionally enabled". Our intention is that the security model be
> recommended for implementation but optionally used.  Best to be clear
> about this.
>=20
> 2. Section 3.1.  It says that bundles may contain report-to endpoint
IDS
> "to direct diagnostic output to an entity other than the sender". I
> think this contradicts the bundle protocol, which stipulates that the
> report-to endpoint (section 4.2 of the BP spec) "must be either the ID
> of an endpoint of which the node is a member or else the null
endpoint".
> So according to the bundle protocol, the bundles directed to the
> report-to endpoint will be sent to the source and also possibly to
other
> nodes. In order to be sent to other nodes, a multicast endpoint ID
must
> be used.
>=20
> 3. Section 3.3 In answer to your question, yes, I think bindings
should
> be renamed registrations.
>=20
> 4. Section 3.3.1.  Need the word "one" in "A single EID may refer to
> more than ONE DTN node, as..."
>=20
> 5. Section 3.3.1. In answer to your question, no, I don't think you
> should rename this late-or lazy-mapping.
>=20
> 6. last paragraph of section 3.4: need an "is" in "as it IS likely to
be
> at least as hard..."
>=20
> 7. Section 3.6.1 Requests. This section is a bit out of date with
> respect to the current Delivery options that can be requested for a
> bundle. Here are the necessary changes:
>=20
> - There is no longer a Secured Delivery Request in the bundle
protocol.
> But there are three security-related delivery options that can be
> requested when using the Bundle Security Protocol: confidentiality,
> authentication, and error-detection (section 2.1 of the Bundle
Security
> Protocol).
>=20
> There are now two additional delivery options in the bundle security
> protocol:
>=20
> Report when bundle received, and
> Report when bundle deleted
>=20
> 8. Section 3.6.2 Indicators.  This section is also a bit out of date
> with respect to the bundle protocol. I guess it is meant to be a
> description of both the types of Bundle Status Reports that can be
sent
> in the BP and also the Custodial signals. I'm not sure. The
terminology
> used here is so different from that in the bundle protocol it's hard
for
> me to tell what's missing and extra, but here is what I think are the
> necessary changes:
>=20
> - I think that by a "custody transfer ACK Indication" you mean a
custody
> signal. This however can either be a signal for success or for
failure.
>=20
> - There is no such thing as a Time Expired Error Indicator.  I don't
> believe there is any signal with that or a similar purpose.
>=20
> - There is no such thing as an Unknown/Invalid EID Indicator.
>=20
> - There is no such thing as a Policy Violation Indicator.
>=20
> - You best clean up the terminology and rename the "Dropped Indicator"
> to be "Deleted Indicator" or something, because the bundle protocol
> makes a very specific distinction between a bundle that is discarded
> versus one that is deleted.
>=20
> - there is also an indicator that the Bundle was received at a node,
but
> this isn't mentioned in the architecture document.
>=20
> 9. Section 3.7 says that the BP is designed with a basic header and a
> set of optional extension headers. Actually, the BP defines two
> mandatory headers that must be found in every bundle.
>=20
> 10. Section 3.7 says that if the report-to EID isn't present, reports
> are sent to the source EID.  The way the BP is now written, the
> report-to EID must be present; it may be the null endpoint ID (in
which
> case the reports will not be sent anywhere), but it must be present.
If
> reports are to go to the source, the source must be listed explicitly
in
> the report-to EID.
>=20
> 11. Section 3.7. The Request options listed need to be corrected as
> discussed earlier.
>=20
> 12. Section 3.10, last paragraph.  It says "When a bundle is forwarded
> that contains the Custodial Delivery optoin, a Custody Transfer ACK
> indicator is sent to the bundle layer to the Current Custodian ..."
>=20
> This is not true. When custody of a bundle is accepted (not when a
> bundle is forwarded) , a "succeeded" custody signal is sent to the
> current custodian.
>=20
> 13. Section 3.10, last paragraph goes on to say "...the Current
> Custodian EID is updated to contain one of the forwarding nodes's
> (unicast) EIDs before the bundle is forwarded."
>=20
> My comment is that I think this is the way it should be, but right now
> the Bundle Protocol allows the Current Custodian EID to be updated to
> contain a _multicast_ EID that includes the forwarding node.  I have
> argued, unsucessfully, that the BP should limit the current custodian
> field to only holding unicast EIDs for now, and that in a multicast
> extension document we could allow the Current Custodian EIDs to be
> multicast under some specific circumstances.
>=20
> 14. Section 3.11 Time Stamps and Time Synchronization
>=20
> According to this section, when an application expresses its desire to
> receive data for a particular EID, this binding is only maintained for
a
> finite period of time, specified by the application.  Is this true?  I
> don't see any parameter in the Register.Request for the application to
> specifiy the time.
>=20
> 15. Section 4.2. "Custody ACK Indicators" should be replaced by
> "succeeded" custody signals.
>=20
>=20
> *****************************************************************
> Susan Symington
> The MITRE Corporation
> [email-masked]
> 703-983-7209 (voice)
> 703-983-7142 (fax)
> ******************************************************************
>=20
>=20
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]] On Behalf Of Fall,
Kevin
> >Sent: Monday, July 11, 2005 12:32 AM
> >To: [email-masked]
> >Subject: [dtn-interest] draft for updated DTN Architecture
> >Internet Draft
> >
> >
> >Hi folks--
> >
> >Well, I have finally put together a document which I intend to submit
> >later this week as an update to draft-irtf-dtnrg-arch-02.txt.  This
> >would be good, as the current one has actually expired.
> >
> >The document has to be in by Jul 18 to be admitted as an I-D before
the
> >next IETF meeting, so I would like to receive any comments you folks
> >have prior to July 16.
> >
> >As you look through the attachment, you will notice several
> >places where
> >'XXX' appears.  In general, the intention is to delete the material
> >surrounded by this mark, although there might be a couple of places
> >where it instead brings up an issue to consider.
> >
> >So, anyhow, please let me know if you have comments/concerns as
quickly
> >as possible so I can address them prior to the cutoff date.
> >
> >Cheers,
> >- Kevin
> >

------_=_NextPart_001_01C589CC.7EBE97E4
Content-Type: text/plain;
	name="draft-irtf-dtnrg-arch-03b.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-arch-03b.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-arch-03b.txt"

------_=_NextPart_001_01C589CC.7EBE97E4--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] Use of the postal system as a transport for DTN messages
Date: Fri, 15 Jul 2005 20:26:04 -0700
From: "Fall, Kevin" <[email-masked]>
To: =?iso-8859-1?Q?Jos=E9_Manuel_D=EDaz_Rodr=EDguez?= <[email-masked]>, <[email-masked]>
Sender: [email-masked]

I think it would be great to get some more folks working on this.

We have talked with Randy Wang somewhat regularly, but at least for the moment the actual software is different.

I personally think that writing the convergence layer will be much less time consuming than actually deploying the thing, measuring it, and showing the sorts of results you obtain.  Is that a thing you are interested in doing?

(also, I am curious... where are you writing from?)

Cheers,
- K

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of José Manuel Díaz Rodríguez
> Sent: Friday, July 15, 2005 12:02 PM
> To: [email-masked]
> Subject: [dtn-interest] Use of the postal system as a transport for DTN
> messages
> 
> Hello.
> 
> I've recently begun my graduation project in Telecommunications
> Engineering.
> I plan to focus my work on the application of the postal system (or other
> means of delivering mobile storage devices, such as USB keys or CDs) as a
> transport for messages in a DTN network, which is particularly useful for
> certain distributed applications being developed at my university for use
> in
> developing countries.
> 
> I've read the paper "Postmanet: Turning the Postal System into a Generic
> Digital Communication Mechanism" by Randolph Y. Wang et al., which
> explains
> the main reasons for such an approach.
> 
> My first question is whether current efforts are being conducted in this
> area by members of the DTN initiative. If so, maybe I can concentrate in
> other aspects of the subject, just for the sake of preventing duplicate
> work. If not, I could develop a convergence layer for DTN usage of the
> postal system by extending current classes, studying ways for automatic
> generation and processing of storage media, and contribute my work to
> future
> versions of the DTN software prototype.
> 
> Another issue related to postal usage is routing techniques to take
> advantage of the coexistence of a low latency low bandwidth network, such
> as
> a modest digital communication network, and a high latency high bandwidth
> means of communication, like the carriage of storage media over the postal
> system. In such a scenario, a DTN router should use the former for small
> messages, like control messages, and the latter for larger messages and
> multimedia content delivery. My second question is whether there is active
> work being done for the inclusion of such routing mechanisms in the DTN
> prototype, or, on the contrary, there is space for such an initiative by
> new
> developers.
> 
> Thank you very much for your help.
> 
> Regards,
> José Manuel Díaz Rodríguez
> 
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today - it's FREE!
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "José Manuel Díaz Rodríguez" <[email-masked]>
To: [email-masked]
Date: Fri, 15 Jul 2005 19:01:31 +0000
Subject: [dtn-interest] Use of the postal system as a transport for DTN messages
Sender: [email-masked]

Hello.

I've recently begun my graduation project in Telecommunications Engineering.
I plan to focus my work on the application of the postal system (or other 
means of delivering mobile storage devices, such as USB keys or CDs) as a 
transport for messages in a DTN network, which is particularly useful for 
certain distributed applications being developed at my university for use in 
developing countries.

I've read the paper "Postmanet: Turning the Postal System into a Generic 
Digital Communication Mechanism" by Randolph Y. Wang et al., which explains 
the main reasons for such an approach.

My first question is whether current efforts are being conducted in this 
area by members of the DTN initiative. If so, maybe I can concentrate in 
other aspects of the subject, just for the sake of preventing duplicate 
work. If not, I could develop a convergence layer for DTN usage of the 
postal system by extending current classes, studying ways for automatic 
generation and processing of storage media, and contribute my work to future 
versions of the DTN software prototype.

Another issue related to postal usage is routing techniques to take 
advantage of the coexistence of a low latency low bandwidth network, such as 
a modest digital communication network, and a high latency high bandwidth 
means of communication, like the carriage of storage media over the postal 
system. In such a scenario, a DTN router should use the former for small 
messages, like control messages, and the latter for larger messages and 
multimedia content delivery. My second question is whether there is active 
work being done for the inclusion of such routing mechanisms in the DTN 
prototype, or, on the contrary, there is space for such an initiative by new 
developers.

Thank you very much for your help.

Regards,
José Manuel Díaz Rodríguez

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] turbo code programs
Date: Thu, 14 Jul 2005 11:54:20 -0700
From: "Fall, Kevin" <[email-masked]>
To: "gtmbht" <[email-masked]>, <[email-masked]>, "Leigh Torgerson" <[email-masked]>
Sender: [email-masked]

Check out:

http://citeseer.ist.psu.edu/566143.html

this is more in the realm of tornado codes, but will probably be of
interest to you.

- K

> -----Original Message-----
> From: [email-masked] [mailto:dtn-interest-
> [email-masked]] On Behalf Of gtmbht
> Sent: Thursday, July 14, 2005 11:22 AM
> To: [email-masked]; Leigh Torgerson
> Subject: RE: [dtn-interest] turbo code programs
> 
> Hello Mr. Torgerson,
> 
> Unfortunately, this is the turbo code that I have been working with
for
> about
> two weeks and it takes forever to decode large packets. Anyway, thank
you
> for
> the help. Please let me know if you happen to come across some other
> modules.
> 
> Cheers
> 
> P.S. : This code is in MATLAB. Do you think if I were to convert it to
> C/C++,
> it would run a lot faster? - because right now it takes about 3-4 mins
to
> decode a packet of size 15KB.
> 
> Gautam
> >===== Original Message From Leigh Torgerson <[email-masked]>
> =====
> >Take a look at
> >http://www.ee.vt.edu/~yufei/turbo.html
> >
> >See if that helps!
> >
> >Leigh
> >
> >
> >At 11:16 PM -0600 7/13/05, gtmbht wrote:
> >>Hello all,
> >>
> >>Can someone please direct me to some programs that can simulate
turbo
> code
> >>encoding and decoding? I have tried googling but cant find anything.
> >>
> >>Thank You
> >>
> >>Gautam
> >>
>
>>----------------------------------------------------------------------
> >>Gautam Bhatia
> >>Department of Electrical and Computer Engineering
> >>Colorado State University
> >>Fort Collins CO - 80523
> >>Tel:(970)-215-6316
> >>Email: [email-masked]
>
>>----------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>dtn-interest mailing list
> >>[email-masked]
> >>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> >
> >
> >--
> >--------------------------------------------------------------------
> >J. Leigh Torgerson                           [email-masked]
> >Jet Propulsion Laboratory - Communications Systems Research Sec. 331
> >NASA Space Communications Protocol Standards (SCPS) Project CTM
> >(818) 393-0695                                   (818) 393-4643 fax
> >--------------------------------------------------------------------
> 
> ----------------------------------------------------------------------
> Gautam Bhatia
> Department of Electrical and Computer Engineering
> Colorado State University
> Fort Collins CO - 80523
> Tel:(970)-215-6316
> Email: [email-masked]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 14 Jul 2005 14:29:37 -0400
From: Matthew MacLeod <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] turbo code programs
OpenPGP: id=9CE4648B; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9CE4648B
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFBF405C9845803486B0074F6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

gtmbht wrote:
> P.S. : This code is in MATLAB. Do you think if I were to convert it to C/C++, 
> it would run a lot faster? - because right now it takes about 3-4 mins to 
> decode a packet of size 15KB.

>From a quick glance this code looks to be very "for" loop-heavy, which
Matlab is notoriously slow at handling. Converting it to C/C++ would
likely show a fair bit of improvement.

-- 
Matthew MacLeod
[email-masked]
"Only amateurs attack machines; professionals target people. And any
solutions will have to target the people problem, not the math problem." -
Bruce Schneier

--------------enigFBF405C9845803486B0074F6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigFBF405C9845803486B0074F6--

Date: Thu, 14 Jul 2005 12:22:28 -0600
From: gtmbht <[email-masked]>
To: [email-masked], Leigh Torgerson <[email-masked]>
Subject: RE: [dtn-interest] turbo code programs
Sender: [email-masked]

Hello Mr. Torgerson,

Unfortunately, this is the turbo code that I have been working with for about 
two weeks and it takes forever to decode large packets. Anyway, thank you for 
the help. Please let me know if you happen to come across some other modules.

Cheers

P.S. : This code is in MATLAB. Do you think if I were to convert it to C/C++, 
it would run a lot faster? - because right now it takes about 3-4 mins to 
decode a packet of size 15KB.

Gautam
>===== Original Message From Leigh Torgerson <[email-masked]> =====
>Take a look at
>http://www.ee.vt.edu/~yufei/turbo.html
>
>See if that helps!
>
>Leigh
>
>
>At 11:16 PM -0600 7/13/05, gtmbht wrote:
>>Hello all,
>>
>>Can someone please direct me to some programs that can simulate turbo code
>>encoding and decoding? I have tried googling but cant find anything.
>>
>>Thank You
>>
>>Gautam
>>
>>----------------------------------------------------------------------
>>Gautam Bhatia
>>Department of Electrical and Computer Engineering
>>Colorado State University
>>Fort Collins CO - 80523
>>Tel:(970)-215-6316
>>Email: [email-masked]
>>----------------------------------------------------------------------
>>
>>_______________________________________________
>>dtn-interest mailing list
>>[email-masked]
>>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>
>
>--
>--------------------------------------------------------------------
>J. Leigh Torgerson                           [email-masked]
>Jet Propulsion Laboratory - Communications Systems Research Sec. 331
>NASA Space Communications Protocol Standards (SCPS) Project CTM
>(818) 393-0695                                   (818) 393-4643 fax
>--------------------------------------------------------------------

----------------------------------------------------------------------
Gautam Bhatia
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins CO - 80523
Tel:(970)-215-6316
Email: [email-masked]
----------------------------------------------------------------------

Date: Thu, 14 Jul 2005 09:31:35 -0700
To: gtmbht <[email-masked]>, [email-masked]
From: Leigh Torgerson <[email-masked]>
Subject: Re: [dtn-interest] turbo code programs
Sender: [email-masked]

Take a look at
http://www.ee.vt.edu/~yufei/turbo.html

See if that helps!

Leigh

At 11:16 PM -0600 7/13/05, gtmbht wrote:
>Hello all,
>
>Can someone please direct me to some programs that can simulate turbo code
>encoding and decoding? I have tried googling but cant find anything.
>
>Thank You
>
>Gautam
>
>----------------------------------------------------------------------
>Gautam Bhatia
>Department of Electrical and Computer Engineering
>Colorado State University
>Fort Collins CO - 80523
>Tel:(970)-215-6316
>Email: [email-masked]
>----------------------------------------------------------------------
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

-- 
--------------------------------------------------------------------
J. Leigh Torgerson                           [email-masked]
Jet Propulsion Laboratory - Communications Systems Research Sec. 331
NASA Space Communications Protocol Standards (SCPS) Project CTM
(818) 393-0695                                   (818) 393-4643 fax
--------------------------------------------------------------------

Date: Wed, 13 Jul 2005 23:16:01 -0600
From: gtmbht <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] turbo code programs
Sender: [email-masked]

Hello all,

Can someone please direct me to some programs that can simulate turbo code 
encoding and decoding? I have tried googling but cant find anything.

Thank You

Gautam

----------------------------------------------------------------------
Gautam Bhatia
Department of Electrical and Computer Engineering
Colorado State University
Fort Collins CO - 80523
Tel:(970)-215-6316
Email: [email-masked]
----------------------------------------------------------------------

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] draft for updated DTN Architecture Internet Draft
Date: Wed, 13 Jul 2005 16:18:58 -0400
From: "Symington,Susan F." <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Kevin,

I am almost all the way through the DTN Architecture document. Here are
my comments. I wanted to give them to you now so you can get started on
them. If I have any more, I will send them tomorrow.

-susan

O. The terminology of the architecture document needs to be updated to
reflect the new terminology of the bundle protocol spec. There is a
looseness that needs to be tightened.  For example, the word "sender" is
used when "Source" should be used, etc.

1. In the introduction, you say that DTN has a basic security model that
is "optionally enabled". Our intention is that the security model be
recommended for implementation but optionally used.  Best to be clear
about this.

2. Section 3.1.  It says that bundles may contain report-to endpoint IDS
"to direct diagnostic output to an entity other than the sender". I
think this contradicts the bundle protocol, which stipulates that the
report-to endpoint (section 4.2 of the BP spec) "must be either the ID
of an endpoint of which the node is a member or else the null endpoint".
So according to the bundle protocol, the bundles directed to the
report-to endpoint will be sent to the source and also possibly to other
nodes. In order to be sent to other nodes, a multicast endpoint ID must
be used.

3. Section 3.3 In answer to your question, yes, I think bindings should
be renamed registrations.

4. Section 3.3.1.  Need the word "one" in "A single EID may refer to
more than ONE DTN node, as..."

5. Section 3.3.1. In answer to your question, no, I don't think you
should rename this late-or lazy-mapping.

6. last paragraph of section 3.4: need an "is" in "as it IS likely to be
at least as hard..."

7. Section 3.6.1 Requests. This section is a bit out of date with
respect to the current Delivery options that can be requested for a
bundle. Here are the necessary changes:

- There is no longer a Secured Delivery Request in the bundle protocol.
But there are three security-related delivery options that can be
requested when using the Bundle Security Protocol: confidentiality,
authentication, and error-detection (section 2.1 of the Bundle Security
Protocol). 

There are now two additional delivery options in the bundle security
protocol:

Report when bundle received, and
Report when bundle deleted

8. Section 3.6.2 Indicators.  This section is also a bit out of date
with respect to the bundle protocol. I guess it is meant to be a
description of both the types of Bundle Status Reports that can be sent
in the BP and also the Custodial signals. I'm not sure. The terminology
used here is so different from that in the bundle protocol it's hard for
me to tell what's missing and extra, but here is what I think are the
necessary changes:

- I think that by a "custody transfer ACK Indication" you mean a custody
signal. This however can either be a signal for success or for failure.

- There is no such thing as a Time Expired Error Indicator.  I don't
believe there is any signal with that or a similar purpose.

- There is no such thing as an Unknown/Invalid EID Indicator.

- There is no such thing as a Policy Violation Indicator.

- You best clean up the terminology and rename the "Dropped Indicator"
to be "Deleted Indicator" or something, because the bundle protocol
makes a very specific distinction between a bundle that is discarded
versus one that is deleted.

- there is also an indicator that the Bundle was received at a node, but
this isn't mentioned in the architecture document.

9. Section 3.7 says that the BP is designed with a basic header and a
set of optional extension headers. Actually, the BP defines two
mandatory headers that must be found in every bundle.

10. Section 3.7 says that if the report-to EID isn't present, reports
are sent to the source EID.  The way the BP is now written, the
report-to EID must be present; it may be the null endpoint ID (in which
case the reports will not be sent anywhere), but it must be present. If
reports are to go to the source, the source must be listed explicitly in
the report-to EID.

11. Section 3.7. The Request options listed need to be corrected as
discussed earlier.

12. Section 3.10, last paragraph.  It says "When a bundle is forwarded
that contains the Custodial Delivery optoin, a Custody Transfer ACK
indicator is sent to the bundle layer to the Current Custodian ..."

This is not true. When custody of a bundle is accepted (not when a
bundle is forwarded) , a "succeeded" custody signal is sent to the
current custodian.

13. Section 3.10, last paragraph goes on to say "...the Current
Custodian EID is updated to contain one of the forwarding nodes's
(unicast) EIDs before the bundle is forwarded."

My comment is that I think this is the way it should be, but right now
the Bundle Protocol allows the Current Custodian EID to be updated to
contain a _multicast_ EID that includes the forwarding node.  I have
argued, unsucessfully, that the BP should limit the current custodian
field to only holding unicast EIDs for now, and that in a multicast
extension document we could allow the Current Custodian EIDs to be
multicast under some specific circumstances.

14. Section 3.11 Time Stamps and Time Synchronization

According to this section, when an application expresses its desire to
receive data for a particular EID, this binding is only maintained for a
finite period of time, specified by the application.  Is this true?  I
don't see any parameter in the Register.Request for the application to
specifiy the time.

15. Section 4.2. "Custody ACK Indicators" should be replaced by
"succeeded" custody signals.

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Fall, Kevin
>Sent: Monday, July 11, 2005 12:32 AM
>To: [email-masked]
>Subject: [dtn-interest] draft for updated DTN Architecture 
>Internet Draft
>
>
>Hi folks--
>
>Well, I have finally put together a document which I intend to submit
>later this week as an update to draft-irtf-dtnrg-arch-02.txt.  This
>would be good, as the current one has actually expired.
>
>The document has to be in by Jul 18 to be admitted as an I-D before the
>next IETF meeting, so I would like to receive any comments you folks
>have prior to July 16.
>
>As you look through the attachment, you will notice several 
>places where
>'XXX' appears.  In general, the intention is to delete the material
>surrounded by this mark, although there might be a couple of places
>where it instead brings up an issue to consider.
>
>So, anyhow, please let me know if you have comments/concerns as quickly
>as possible so I can address them prior to the cutoff date.
>
>Cheers,
>- Kevin
>

From: =?ISO-8859-1?Q?Sten-Erik=20Bj=F6rling?= <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] Work in progress - OmnIES
Date: Mon, 11 Jul 2005 18:21:46 +0200
Organization: Enviro Data
Sender: [email-masked]

Hi all,

This is my first entry in this mail-list and I have been requested by a
member of this list to enclose information on different project /
products / solutions underway that is planned to include DTN support in
the future.

A document has been creating describing a toolbox that I am developing
named OmnIES and the future interfaces to DTN networks.

In this document is described one scenario of how to use the technology
- distribution of qualified distance learning materials and other
competence resources to a large number of autonomous clients and
installations.

Other usages of this technology could be handling of measurement data
from many different measurement sites where each one will contain local
intelligence, mechanisms for data massaging and feedback structures for
the staff entering / monitoring the measurement streams.

Both of the above mentioned scenarios demand advanced interfaces to work
properly and also local storage structures capable enough to handle a
multitude of data-types and volumes of data. This is where the OmnIES
toolsets comes in - especially in future incarnations of the systems
that will share the same interfaces between web-based systems and
autonomous workstations.

If you have any interest in this document then please inform me and I
will send it to you off-list.

Stene

___

Sten-Erik Björling
Enviro Data
Varvsgatan 47
S#972 33  LULEÅ
Sweden

EMail: [email-masked]
Mobile: +46-70-655 28 66
Fax: +46-920-171 20
Skype: stenerikbjorling
AIM: [email-masked]
MSN, Hotmail: [email-masked]

___

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] draft for updated DTN Architecture Internet Draft
Date: Mon, 11 Jul 2005 12:04:26 -0400
From: "Symington,Susan F." <[email-masked]>
To: "Fall, Kevin" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Kevin,

I haven't yet had a chance to read over the whole document, but I did
look at the security section (3.13) and with regard to it, I have three
suggestions:

1. In the 4th paragraph, change the word "optionally" to "recommended"
(in accordance with RFC 2119). It is our intention that security SHOULD
be deployed; not simply that it merely MAY be deployed. 

2. In last line of 5th paragraph, put a space between the two words that
are now merged as "eachother".

3. Reference the DTN Security Bundle Protocol draft that has already
been submitted:

Symington, S., Farrell, S. and H. Weiss, "Bundle Security Protocol
Specification", draft-irtf-dtnrg-bundle-security-00.txt , May 2005.

I'll get back to you with other comments when I get a chance to look
over the rest of the document.

-susan

*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Fall, Kevin
>Sent: Monday, July 11, 2005 12:32 AM
>To: [email-masked]
>Subject: [dtn-interest] draft for updated DTN Architecture 
>Internet Draft
>
>
>Hi folks--
>
>Well, I have finally put together a document which I intend to submit
>later this week as an update to draft-irtf-dtnrg-arch-02.txt.  This
>would be good, as the current one has actually expired.
>
>The document has to be in by Jul 18 to be admitted as an I-D before the
>next IETF meeting, so I would like to receive any comments you folks
>have prior to July 16.
>
>As you look through the attachment, you will notice several 
>places where
>'XXX' appears.  In general, the intention is to delete the material
>surrounded by this mark, although there might be a couple of places
>where it instead brings up an issue to consider.
>
>So, anyhow, please let me know if you have comments/concerns as quickly
>as possible so I can address them prior to the cutoff date.
>
>Cheers,
>- Kevin
>

Content-class: urn:content-classes:message
Date: Mon, 11 Jul 2005 09:33:31 -0400
From: "Scott,Keith L." <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] draft-irtf-dtnrg-bundle-spec-03.txt
Sender: [email-masked]

Below is draft 3 of the bundle protocol specification,
draft-irtf-dtnrg-bundle-spec-03.txt
 
  --keith

Internet Draft      Bundle Protocol Specification          July 2005 

   Delay Tolerant Networking Research Group                    K. Scott 
   Internet Draft                                 The MITRE Corporation 
   <draft-irtf-dtnrg-bundle-spec-03.txt>                                
   July 2005                                                S. Burleigh 
   Expires: January 2006                      Jet Propulsion Laboratory 

    
                       Bundle Protocol Specification 

Status of this Memo 
    
   By submitting this Internet-Draft, we certify that any applicable 
   patent or other IPR claims of which we am aware have been disclosed, 
   and any of which we become aware will be disclosed, in accordance 
   with RFC 3668.  
        
   This document is an Internet-Draft and is in full conformance with 
   Sections 5 and 6 of RFC3667 and Section 5 of RFC3668.  
        
   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  document  was  produced  within  the  IRTF's  Delay  Tolerant 
   Networking Research Group (DTNRG).  See http://www.dtnrg.org for more

   information.  
 
Abstract 
    
   This document describes the end-to-end protocol, header formats, and 
   abstract service description for the exchange of messages (bundles) 
   in Delay Tolerant Networking (DTN).   
 
Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 

K. Scott and S. Burleigh      Expires - January 2006       [Page 1] 
Internet Draft      Bundle Protocol Specification          July 2005 

   document are to be interpreted as described in RFC-2119 [1]. 
 
Table of Contents 
    
   1.       Introduction .....................................3 
   2.       Service Description ..............................5 
   2.1      Definitions.......................................5 
   2.2      Services offered by bundle protocol agents........8 
   2.3      Summary of Primitives.............................8 
   2.3.1    Requests..........................................8 
   2.3.2    Indications.......................................9 
   2.4      Summary of Parameters.............................9 
   2.4.1    Destination endpoint ID...........................9 
   2.4.2    Source endpoint ID................................9 
   2.4.3    Report-to endpoint ID.............................9 
   2.4.4    Priority..........................................9 
   2.4.5    Delivery Options.................................10 
   2.4.6    Lifespan.........................................10 
   2.4.7    Transmission Token...............................10 
   2.4.8    Application Data Unit............................10 
   2.4.9    Registration Token...............................10 
   2.4.10   Delivery Failure Action..........................10 
   2.4.11   Bundle creation time.............................11 
   2.5      Bundle Protocol Service Primitives...............11 
   2.5.1    TRANSMIT.REQUEST.................................11 
   2.5.2    CANCEL.REQUEST...................................11 
   2.5.3    REGISTER.REQUEST.................................12 
   2.5.4    START-DELIVERY.REQUEST...........................13 
   2.5.5    STOP-DELIVERY.REQUEST............................13 
   2.5.6    CHANGE-REGISTRATION.REQUEST......................13 
   2.5.7    DEREGISTER.REQUEST...............................14 
   2.5.8    POLL.REQUEST ....................................14 
   2.5.9    DATA.INDICATION..................................15 
   2.5.10   TRANSMITERROR.INDICATION.........................15 
   2.5.11   TRANSMISSION.INDICATION..........................15 
   2.5.12   REGISTRATION.INDICATION..........................16 
   3.       Bundle Format....................................16 
   3.1      Canonical Bundle Header Format...................16 
   3.2      Header Processing Flags..........................17 
   3.3      Bundle Processing Flags..........................17 
   3.4      Self-Delimiting Numeric Values (SDNV)............17 
   3.5      Endpoint IDs ....................................18 
   3.6      Formats of Mandatory Bundle Headers..............20 
   3.6.1    Primary Bundle Header............................22 
   3.6.2    Bundle Payload Header............................25 
   4.       Bundle Processing................................25 
   4.1      Generation of administrative records.............25 
   4.2      Bundle transmission requests.....................26 
   4.3      Bundle dispatching...............................27 
   4.4      Bundle forwarding................................27 
   4.4.1    Forwarding Contraindicated ......................28 

K. Scott and S. Burleigh      Expires - January 2006       [Page 2] 
Internet Draft      Bundle Protocol Specification          July 2005 

   4.4.2    Forwarding Failed................................28 
   4.5      Bundle expiration................................29 
   4.6      Bundle reception.................................29 
   4.7      Local bundle delivery............................30 
   4.8      Bundle Fragmentation.............................31 
   4.9      Application Data Unit Reassembly.................31 
   4.10     Custody transfer.................................32 
   4.10.1   Custody acceptance...............................32 
   4.10.2   Custody release..................................33 
   4.11     Custody transfer success.........................33 
   4.12     Custody transfer failure.........................33 
   4.13     Bundle deletion..................................33 
   4.14     Discarding a bundle .............................34 
   5.       Administrative record processing.................34 
   5.1      Administrative records...........................34 
   5.1.1    Bundle Status Reports............................34 
   5.1.2    Custody Signals..................................38 
   5.2      Generation of administrative records.............40 
   5.3      Reception of custody signals.....................41 
   6.       Services Required of the Convergence Layer.......41 
   6.1      The Convergence Layer............................41 
   6.2      Summary of Convergence Layer Services............41 
   6.3      Summary of Primitives............................42 
   6.3.1    Requests.........................................42 
   6.3.2    Indications......................................42 
   6.4      Summary of Parameters............................42 
   6.4.1    Receiving Endpoint ID............................42 
   6.4.2    Bundle...........................................42 
   6.4.3    Bundle length....................................42 
   6.4.4    Send result......................................42 
   6.5      Convergence Layer Service Primitives.............42 
   6.5.1    SEND.REQUEST ....................................42 
   6.5.2    SEND-REPORT.INDICATION...........................42 
   6.5.3    BUNDLE.INDICATION................................42 

1. Introduction 
    
   This  document  describes  version  4  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 

K. Scott and S. Burleigh      Expires - January 2006       [Page 3] 
Internet Draft      Bundle Protocol Specification          July 2005 

        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 [2].  [3] contains a tutorial-level overview of DTN

   concepts. 
    
   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). 
    
   +-----------+                                         +-----------+  
   |   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. 

 
K. Scott and S. Burleigh      Expires - January 2006       [Page 4] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
2. Service Description 
    
2.1 Definitions 
    
   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.  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 content is 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 service interface 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 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.  

 
K. Scott and S. Burleigh      Expires - January 2006       [Page 5] 
Internet Draft      Bundle Protocol Specification          July 2005 

   Application agent - The application agent (AA) of a node is the node 
   component that utilizes the BP service interface, presenting requests

   and receiving indications, 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.5 below).   In the most familiar case a 
   bundle endpoint comprises a single bundle node (and in fact some 
   endpoints are not permitted to comprise multiple nodes, as discussed 
   below), but in general this definition too is meant to be broader.  
   For example, the motes 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

 
K. Scott and S. Burleigh      Expires - January 2006       [Page 6] 
Internet Draft      Bundle Protocol Specification          July 2005 

   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 an endpoint that is not permitted to 
   contain more than one node (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.5 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 single registration

   must at any time be in one of two states (discussed later): Active, 
   Passive.  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. 
    
   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, then the 
   bundle is "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 a Data.indication service 
   primitive containing the bundle's payload has been issued 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. 
    
   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 or issuance of a service 

K. Scott and S. Burleigh      Expires - January 2006       [Page 7] 
Internet Draft      Bundle Protocol Specification          July 2005 

   interface indication.  "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 set 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 is released when either 
   (a) notification is received that some other node has accepted 
   custody of the same bundle or (b) the bundle is explicitly deleted 
   for some reason, such as lifetime expiration.  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 an endpoint whose membership includes at least one of the 
   bundle's custodial nodes.  
    
2.2 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: 
       
      a) transmitting a bundle to an identified bundle endpoint; 
      b) canceling a transmission; 
      c) switching a registration between active and passive state; 
      d) polling a registration that is in passive state; 
      e) delivering a received bundle. 
    
2.3 Summary of Primitives 
    
   The list of primitives specified here is neither exhaustive or 
   exclusive.   That is, supplementary DTN protocol specifications 
   (including, but not restricted to, the Bundle Security Protocol) may 
   expect BP implementations conforming to those protocols to offer 
   additional primitives. 
    
2.3.1 Requests 

 
K. Scott and S. Burleigh      Expires - January 2006       [Page 8] 
Internet Draft      Bundle Protocol Specification          July 2005 

   The bundle protocol is expected to consume the following request 
   primitives: 
    
      a) Transmit.request; 
      b) Cancel.request 
      c) Register.request; 
      d) Start_delivery.request; 
      e) Stop_delivery.request; 
      f) Change_registration.request; 
      g) Deregister.request; 
      h) Poll.request; 
    
2.3.2 Indications 
    
   The bundle protocol is expected to issue the following indication 
   primitives: 
    
      a) Data.indication; 
      b) TransmitError.indication 
      c) Transmission.indication 
      d) Registration.indication 
    
2.4 Summary of Parameters 
    
   NOTE  -  The availability and use of parameters for each primitive 
   are indicated in section 2.5.  The following definitions apply. 
    
2.4.1 Destination endpoint ID 
    
   The destination endpoint ID parameter identifies the bundle endpoint 
   containing the nodes at which the bundle is to be delivered.   
    
2.4.2 Source endpoint ID 
    
   The source endpoint ID parameter identifies the bundle endpoint 
   containing the node from which the bundle was initially transmitted. 
    
2.4.3 Report-to endpoint ID 
    
   The report-to endpoint ID parameter identifies the bundle endpoint to

   which any bundle status reports pertaining to the bundle should be 
   transmitted. 
    
2.4.4 Priority 
    
   The priority parameter indicates the urgency with which the bundle is

   to be forwarded and delivered.  Its value is one of the following: 
      o Bulk 
      o Normal 
      o Expedited 

 
K. Scott and S. Burleigh      Expires - January 2006       [Page 9] 
Internet Draft      Bundle Protocol Specification          July 2005 

2.4.5 Delivery Options 
    
   The delivery options parameter indicates what optional procedures 
   must be followed when forwarding and delivering the bundle.  Its 
   value is a combination of zero or more of the following: 
      o Custody transfer required 
      o Report when bundle received 
      o Report when bundle custody accepted 
      o Report when bundle forwarded 
      o Report when bundle delivered (a.k.a. return receipt requested) 
      o Report when bundle deleted 
    
2.4.6 Lifespan 
    
   The lifespan parameter indicates the length of time, following the 
   initial transmission of a bundle, after which bundle nodes need no 
   longer retain or forward the bundle.  The sum of the bundle's 
   creation time and lifespan is its delivery deadline, the moment at 
   which it is expected to be deleted from the DTN network if it has not

   already been delivered at all nodes in the minimum reception set of 
   its destination endpoint. 
    
2.4.7 Transmission Token 
    
   The transmission token parameter identifies a transmission, enabling 
   it to be distinguished from all other transmissions. 
    
2.4.8 Application Data Unit 
    
   The application data unit parameter indicates the location (in memory

   or non-volatile storage, a local implementation matter) of the 
   application data conveyed by the bundle. 
    
2.4.9 Registration Token 
    
   The registration token parameter identifies a registration, enabling 
   it to be distinguished from all other registrations. 
    
2.4.10 
       Delivery Failure Action 
    
   The delivery failure action parameter indicates what action is to be 
   taken when a bundle that is deliverable subject to the registration 
   is received at a time when the registration is in the Passive state.

   Its value is one of the following: 
      o Defer delivery of the bundle subject to this registration until 
        (a) this bundle is the least recently received of all bundles 
        currently deliverable subject to this registration and (b) 
        either the registration is polled or else the registration is 
        in active state. 
      o Abandon delivery of the bundle subject to this registration. 
      o Defer delivery as above and, in addition, immediately execute a 

K. Scott and S. Burleigh      Expires - January 2006      [Page 10] 
Internet Draft      Bundle Protocol Specification          July 2005 

        specified procedure, where the expression of the procedure to 
        be executed is a matter of local implementation. 
    
2.4.11 
      Bundle creation time 
    
   The bundle creation time indicates the time, at 1-second granularity,

   at which the Transmit.request primitive was received that resulted in

   the creation of this bundle.  This is the time that appears in the 
   high-order 4 bytes of the Creation Timestamp discussed in 3.6.1 
   below. 
    
2.5 Bundle Protocol Service Primitives 
    
   The list of parameters specified here for each BP primitive is 
   neither exhaustive or exclusive.  That is, supplementary DTN protocol

   specifications (including, but not restricted to, the Bundle Security

   Protocol) may expect BP implementations conforming to those protocols

   to provide additional parameters with specified primitives. 
    
2.5.1 TRANSMIT.REQUEST 
    
   The Transmit.request primitive requests transmission of a bundle to a

   destination endpoint. 
    
   Semantics: Transmit.request provides parameters as follows: 
      Transmit.request(source endpoint ID, 
                     destination endpoint ID, 
                     report-to endpoint ID, 
                     priority, 
                     delivery options, 
                     lifespan, 
                     application data unit, 
                     transmission token) 
    
   When Presented: Transmit.request may be presented at any time. 
    
   Effect on Receipt: Receipt of Transmit.request causes the BPA to 
   follow the transmission request procedure described in section 4.2; 
   this will normally result in issuance of a Transmission.indication.  
   That indication will include the transmission token provided with the

   Transmit.request primitive, enabling the AA to monitor and control 
   the state of the transmission. 
    
   Additional Comments: None. 
    
2.5.2 CANCEL.REQUEST 
    
   The Cancel.request primitive requests that a bundle transmission 
   previously initiated in response to a Transmit.request be canceled. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 11] 
Internet Draft      Bundle Protocol Specification          July 2005 

   Semantics: Cancel.request provides parameters as follows: 
      Cancel.request (  transmission token) 
    
   When Presented: Cancel.request for a given transmission may be 
   presented   at   any   time   after   the   BPA   has   issued   a 
   Transmission.indication indicating initiation of that transmission.  
   A Cancel.request should be presented if the AA determines that the 
   referenced transmission must be terminated for some reason. 
    
   Effect on Receipt: Receipt of Cancel.request causes the BPA to delete

   the bundle created upon initiation of the indicated transmission for 
   the reason "transmission canceled": the bundle deletion procedure 
   defined in 4.13 must be followed. 
    
   Additional  Comments:  If  the  subject  bundle  has  already  been 
   discarded, the request has no effect. 
    
2.5.3 REGISTER.REQUEST 
    
   The Register.request primitive requests that the node be declared a 
   member of a specified endpoint and that received bundles destined for

   that endpoint be delivered, under specified conditions. 
    
   Semantics: Register.request provides parameters as follows: 
      Register.request( delivery failure action, 
                        registration token, 
                        destination endpoint ID) 
    
   When Presented: Register.request may be presented at any time. 
    
   Effect on Receipt: Receipt of Register.request causes the BPA to 
   initiate   a   registration,   resulting   in   issuance   of   a 
   Registration.indication.  The indication includes the registration 
   token provided with the Register.request primitive, enabling the AA 
   to monitor and control the state of the registration.  The indicated 
   registration is initially in the Passive state.  Whenever the 
   registration is in the Passive state, the indicated delivery failure 
   action is to be performed whenever the node receives a bundle that is

   deliverable subject to this registration. 
    
   Additional Comments: Multiple nodes may be registered - in fact, a 
   single node may be registered multiple times - at the same endpoint.

   Where this is the case, the delivery rules specified for each 
   individual registration must be observed with regard to bundle 
   delivery subject to that registration. 
    
   Implementations may require that an expiration time additionally be 
   specified when Register.request is presented, to enable conservation 
   of resources by automatic termination of registrations as their 
   timers expire. 

 
K. Scott and S. Burleigh      Expires - January 2006      [Page 12] 
Internet Draft      Bundle Protocol Specification          July 2005 

2.5.4 START-DELIVERY.REQUEST 
    
   The Start-delivery.request primitive requests that the state of the 
   specified registration be changed from Passive to Active. 
    
   Semantics: Start-delivery.request provides parameters as follows: 
      Start-delivery.request( registration token) 
    
   When Presented: Start_delivery.request may be presented at any time 
   when the indicated registration is in the Passive state. 
    
   Effect on Receipt: Receipt of Start-delivery.request causes the state

   of the registration to change from Passive to Active.  While the 
   state of a registration is Active, reception of a bundle that is 
   deliverable subject to this registration causes the bundle to be 
   delivered automatically as soon as it is the least recently received 
   bundle that is currently deliverable subject to the registration. 
    
   Additional Comments: None. 
    
2.5.5 STOP-DELIVERY.REQUEST 
    
   The Stop-delivery.request primitive requests that the state of the 
   specified registration be changed from Active to Passive. 
 
   Semantics: Stop-delivery.request provides parameters as follows: 
      Stop-delivery.request( registration token) 
    
   When Presented: Stop-delivery.request may be presented at any time 
   when the indicated registration is in the Active state. 
    
   Effect on Receipt: Receipt of Stop-delivery.request causes the state 
   of the registration to change from Active to Passive.  While the 
   state of a registration is Passive, reception of a bundle that is 
   deliverable subject to this registration causes delivery of the 
   bundle to be abandoned or deferred in accord with the registration's 
   current delivery failure action; in the latter case it also causes 
   the current user-specified delivery failure action, if any, to be 
   performed. 
    
   Additional Comments: None. 
    
2.5.6 CHANGE-REGISTRATION.REQUEST 
    
   The Change-registration.request primitive amends the measures to be 
   taken when a bundle that is deliverable subject to the specified 
   registration is received by the associated node at a time when the 
   registration is in the Passive state. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 13] 
Internet Draft      Bundle Protocol Specification          July 2005 

   Semantics:  Change-registration.request  provides  parameters   as 
   follows: 
      Change-registration.request(  registration token, 
                                    delivery failure action) 
    
   When Presented: Change-registration.request may be presented at any 
   time. 
    
   Effect on Receipt: Receipt of Change-registration.request causes the 
   indicated registration's current delivery failure action to be 
   superseded such that, from this time onward, the indicated delivery 
   failure action is invoked whenever a bundle that is deliverable 
   subject to this registration is received at a time when the 
   registration is in the Passive state. 
    
   Additional Comments: None. 
 
2.5.7 DEREGISTER.REQUEST 
    
   The  Deregister.request  primitive  requests  that  a  registration 
   previously initiated in response to a Register.request be terminated.

   Semantics: Deregister.request provides parameters as follows: 
      Deregister.request(  registration token) 
    
   When Presented: Deregister.request may be presented at any time. 
    
   Effect on Receipt: Receipt of Deregister.request terminates the 
   indicated registration, causing the node no longer to be a member of 
   the endpoint with which the indicated registration is associated.  At

   this time all delivery of bundles subject to this registration is 
   abandoned. 
    
   Additional  Comments:  Implementations  are  free  to  recover  any 
   resources allocated to the delivery of bundles subject to the 
   terminated registration. 
    
2.5.8 POLL.REQUEST 
    
   The Poll.request primitive explicitly requests delivery of a bundle 
   whose delivery was deferred. 
    
   Semantics: Poll.request provides parameters as follows: 
      Poll.request(  registration token) 
    
   When Presented: Poll.request may be presented at any time when the 
   indicated registration is in the Passive state. 
    
   Effect on Receipt: Receipt of Poll.request causes immediate delivery 
   of the least recently received bundle that is deliverable subject to 
   the indicated registration. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 14] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   Additional Comments: None. 
 
2.5.9 DATA.INDICATION 
    
   The Data.indication primitive effects the delivery of a bundle. 
    
   Semantics: Data.indication provides parameters as follows: 
      Data.indication(  source endpoint ID, 
                        destination endpoint ID, 
                        report-to endpoint ID, 
                        priority, 
                        delivery options, 
                        lifespan, 
                        application data unit) 
    
   When  Issued:  Data.indication  is  issued  whenever  a  bundle  is 
   delivered. 
    
   Effect on Receipt: The effect on receipt of a Data.indication whose 
   application data unit is a custody signal causes the custody signal 
   reception procedures detailed in section 5.3 to be followed.  Beyond 
   this, the effect on receipt of Data.indication is undefined. 
    
   Additional Comments: As noted above, delivery of a bundle subject to 
   a registration may be initiated either in response to a Poll.request 
   primitive (when the registration is in the Passive state) or 
   automatically upon delivery of all previously received deliverable 
   bundles (when the registration is in the Active state). 
    
2.5.10 
       TRANSMITERROR.INDICATION 
    
   The TransmitError.indication primitive delivers information about 
   bundle transmission requests that are rejected. 
    
   Semantics: TransmitError.indication provides parameters as follows: 
      TransmitError.indication(  transmission token) 
    
   When   Issued:   TransmitError.indication   is   issued   when   a 
   Transmit.request primitive is rejected. 
    
   Effect on Receipt: The effect on receipt of TransmitError.indication 
   is undefined. 
    
   Additional Comments: None. 
    
2.5.11 
       TRANSMISSION.INDICATION 
    
   The Transmission.indication primitive notifies the application agent 
   that a bundle transmission has been initiated in response to a 
   particular Transmit.request primitive. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 15] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   Semantics: Transmission.indication provides parameters as follows: 
      Transmission.indication (  transmission token) 
    
   When Issued: Transmission.indication is issued when a requested 
   bundle transmission is initiated.  The transmission token parameter 
   is the same as that supplied with the antecedent Transmit.request 
   primitive. 
    
   Effect on Receipt: The effect on receipt of Transmission.indication 
   is undefined. 
    
   Additional Comments: None. 
    
2.5.12 
       REGISTRATION.INDICATION 
    
   The Registration.indication primitive notifies the application agent 
   that a registration has been initiated in response to a particular 
   Register.request primitive. 
    
   Semantics: Registration.indication provides parameters as follows: 
      Registration.indication (  registration token) 
    
   When Issued: RegistrationToken.indication is issued when a requested 
   registration is initiated.  The registration token parameter is the 
   same as that supplied with the antecedent Register.request primitive.

   Effect    on    Receipt:    The    effect    on    receipt    of 
   RegistrationToken.indication is undefined. 
    
   Additional Comments: None. 
    
3. Bundle Format 
    
   Each bundle is a concatenated sequence of at least two bundle header 
   structures.  The first header in the sequence must be a primary 
   bundle header.  Additional bundle protocol headers of other types may

   follow the primary header to support extensions to the Bundle 
   Protocol, such as the Bundle Security Protocol.  The last header in 
   the sequence must be a payload header.  No bundle may have more than 
   one primary bundle header, and no bundle may have more than one 
   payload header. 
    
3.1 Canonical Bundle Header Format 
    
   Every bundle header of every type other than the primary bundle 
   header comprises the following elements, in this order: 
      o Header type code, expressed as an 8-bit unsigned binary 
        integer. 
      o Header processing control flags, a set of eight bit-flag 
        values. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 16] 
Internet Draft      Bundle Protocol Specification          July 2005 

      o Header data length, an unsigned integer expressed as an SDNV 
        (explained below). 
      o Header-type-specific data fields, whose format and order are 
        type-specific and whose aggregate length in octets is the value 
        of the header data length field.  All multi-byte header-type-
        specific data fields are represented in network byte order. 
 
3.2 Header Processing Flags 
    
   The following Boolean processing control flags are present in the 
   header processing control flags byte of every bundle header other 
   than the primary bundle header of each bundle: 
    
   00000001 -  Header must be replicated in every fragment. 
   00000010 -  Transmit status report if header can't be processed. 
   00000100 -  Discard bundle if header can't be processed. 
   00001000 -  Reserved for future use. 
   00010000 -  Reserved for future use. 
   00100000 -  Reserved for future use. 
   01000000 -  Reserved for future use. 
   10000000 -  Reserved for future use. 
 
3.3 Bundle Processing Flags 
    
   The following Boolean processing control flags are present only in 
   the bundle processing control flags byte of the primary bundle header

   of each bundle: 
    
   00000001 -  Bundle is a fragment. 
   00000010 -  Application data unit is an administrative record. 
   00000100 -  Bundle must not be fragmented. 
   00001000 -  Reserved for future use. 
   00010000 -  Reserved for future use. 
   00100000 -  Reserved for future use. 
   01000000 -  Reserved for future use. 
   10000000 -  Reserved for future use. 
    
3.4 Self-Delimiting Numeric Values (SDNV) 
    
   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 [ASN1] scheme for encoding 
   Object Identifier Arcs.  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

 
K. Scott and S. Burleigh      Expires - January 2006      [Page 17] 
Internet Draft      Bundle Protocol Specification          July 2005 

   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 
            {100 1010 1} {0 011 1100}  
            = 10010101 00111100 
    
   0x1234 : 0001 0010 0011 0100 
          =    1 0010 0011 0100  
            is encoded as 
            {10 1 0010 0} {0 011 0100} 
            = 10100100 00110100   
             
   0x4234 : 0100 0010 0011 0100 
          =  100 0010 0011 0100  
            is encoded as 
            {1000000 1} {1 00 0010 0} {0 011 0100} 
            = 10000001 10000100 00110100 
             
   0x7F   : 0111 1111 
          =  111 1111  
            is encoded as 
            {0 111 1111} 
            = 01111111 
    
   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/8-th of the bitwise length of the value to be 
   encoded.  In order to encode an 64-bit numeric value, an SDNV field 
   of 9 octets is required.  128 bits of overhead would be consumed in 
   encoding a 1024-bit RSA encryption key directly in an SDNV. 
    
   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 headers yields the smallest bundle header 
   sizes without sacrificing scalability. 
    
3.5 Endpoint IDs 
    
   The destinations of bundles are bundle endpoints, identified by text 
   strings termed "endpoint IDs" (see section 2.1).  Each endpoint ID 

K. Scott and S. Burleigh      Expires - January 2006      [Page 18] 
Internet Draft      Bundle Protocol Specification          July 2005 

   conveyed in any bundle header takes the form of a Uniform Resource 
   Identifier (URI; see RFC 3986).  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 headers 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 headers of a given bundle are 
   conveyed in the "dictionary" byte array in the bundle's primary 
   header.  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 header are endpoint ID references, and other bundle headers 
   may contain endpoint ID references as well.  Each endpoint ID is an 
   ordered pair of 16-bit unsigned integers: 
     
      o The offset, within the dictionary, of the first character of 
        the referenced endpoint ID's scheme name. 
    
      o The offset, within the dictionary, of the first character of 
        the referenced endpoint ID's SSP. 
 
   This encoding enables a degree of header 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.  Two schemes are defined by the present document: 
    
     o The base scheme "bp0", whose SSPs are all of this form: 

            //<host identifier>[:<port number>][/<application tag>] 
    
        <host identifier> may be either a DNS name or the dotted string 
        representation of an IP address.  <application tag>, where 
        present,  may  be  any  ASCII  string.  The  convergence-layer 
        protocol  to  use  in  forwarding  a  bundle  to  an  endpoint 
        identified by an endpoint ID conforming to this scheme is 
        determined by consulting a forwarding information base, as is 
        the port number on which to exercise that protocol (except 
        where the port number is explicitly declared in the SSP).  An 
        endpoint identified by a "bp0" endpoint ID may contain at most 

K. Scott and S. Burleigh      Expires - January 2006      [Page 19] 
Internet Draft      Bundle Protocol Specification          July 2005 

        one node.  

     o The "none" scheme, which is used only in the null endpoint ID 
        "none:.".  The forwarding of a bundle to the null endpoint is 
        never contraindicated, and the minimum reception set for the 
        null endpoint is the empty set.  
    
   Note that, although the endpoint IDs conveyed in bundle headers 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) in Transmit.request and Data.indication 
   primitives.  
    
3.6 Formats of Mandatory Bundle Headers 
    
   This section describes the formats of the two mandatory headers found

   in every bundle.  Rules for processing these headers appear in 
   section 4 of this document. 
    
   Note that the list of BP headers specified here is neither exhaustive

   or exclusive.  That is, supplementary DTN protocol specifications 
   (including, but not restricted to, the Bundle Security Protocol) may 
   require  that  BP  implementations  conforming  to  those  protocols 
   construct and process additional headers. 
 
                     Table 1: Mandatory Bundle Header Types 
+--------------------+------+---------------------------------------+ 
|       Header       | Type |              Comment                  | 
+====================+======+=======================================+ 
+--------------------+------+---------------------------------------+ 
|  Bundle Payload    | 0x01 |  Contains bundle content.             | 
+--------------------+------+---------------------------------------+ 
|               All other values reserved for future use.           | 
+--------------------+------+---------------------------------------+ 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 20] 
Internet Draft      Bundle Protocol Specification          July 2005 

   The format of the two mandatory headers is shown in Figure 2 below. 
    
Primary Bundle Header 
+----------------+----------------+----------------+----------------+ 
|    Version     |  Proc. Flags   |   COS Flags    |Header 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 (8 bytes)                   + 
|                                                                   | 
+---------------------------------+---------------------------------+ 
|                             Lifetime                              | 
+----------------+----------------+----------------+----------------+ 
|                        Dictionary length (**)                     | 
+----------------+----------------+----------------+----------------+ 
|                  Dictionary byte array (variable)                 | 
+----------------+----------------+---------------------------------+ 
|                      [Fragment offset (***)]                      | 
+----------------+----------------+---------------------------------+ 
|              [Total application data unit length (****)]          | 
+----------------+----------------+---------------------------------+ 

    
Bundle Payload Header 
+----------------+----------------+----------------+----------------+ 
|  Header type   |  Proc. Flags   |        Header length(*****)     | 
+----------------+----------------+----------------+----------------+ 
|                                                                   | 
|                     Bundle Payload (variable)                     | 
|                                                                   | 
/                                                                   / 
/                                                                   / 
|                                                                   | 
+-------------------------------------------------------------------+ 
    
                 Figure 2:   Bundle header formats. 
   Notes: 
    
   (*)  The header length field of the Primary Bundle Header is an SDNV 
   and is therefore variable-length.  A one-octet SDNV is shown here for

   convenience in representation. 
    
   (**)  The dictionary length field of the Primary Bundle Header is an 

K. Scott and S. Burleigh      Expires - January 2006      [Page 21] 
Internet Draft      Bundle Protocol Specification          July 2005 

   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 Header is 
   present only if the Fragment flag in the header'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 Header is present only if the Fragment flag in the header'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 header length field of the Payload Header is an SDNV and

   is therefore variable-length.  A two-octet SDNV is shown here for 
   convenience in representation. 
    
3.6.1 Primary Bundle Header 
    
   The primary bundle header contains the basic information needed to 
   route bundles to their destinations.  The fields of the primary 
   bundle header are: 
    
   Version.  A 1-byte field indicating the version of the bundle 
          protocol that constructed this header.  The present document 
          describes version 0x04 of the bundle protocol. 
    
   Bundle Processing Control Flags.  The Bundle Processing Control Flags

          field is a 1-byte field that contains the bundle processing 
          control flags discussed in section 3.3 above. 
    
   Class of Service Flags.  The COS Flags byte consists of a 1-bit 
          custody transfer required switch followed by two (2) bits of 
          priority and five (5) bits of delivery record request flags.  
          If the custody transfer required switch is 1 then the sending 
          node requests that the receiving node accept custody of the 
          bundle.  The two-bit priority field indicates the bundle's 
          priority, with higher values being of higher priority: 00 = 
          bulk, 01 = normal, 10 = expedited, 11 is reserved for future 
          use.  The interpretation of the delivery record request flags 
          is as follows. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 22] 
Internet Draft      Bundle Protocol Specification          July 2005 

         Table 2: Delivery Record Request Flag Meanings 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  00000  |  No delivery records requested.            | 
         +---------+--------------------------------------------+ 
         |  00001  |  Request reporting of bundle reception.    | 
         +---------+--------------------------------------------+ 
         |  00010  |  Request custody acceptance reporting.     | 
         +---------+--------------------------------------------+ 
         |  00100  |  Request reporting of bundle forwarding.   | 
         +---------+--------------------------------------------+ 
         |  01000  |  Request reporting of bundle delivery.     | 
         +---------+--------------------------------------------+ 
         |  10000  |  Request reporting of bundle deletion.     | 
         +---------+--------------------------------------------+ 
    
   Header Length.  The Header Length field is an SDNV that contains the 
          aggregate length of all remaining fields of the header. 
    
   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. 
    
   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. 
    
   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 header identifies an endpoint whose membership 

K. Scott and S. Burleigh      Expires - January 2006      [Page 23] 
Internet Draft      Bundle Protocol Specification          July 2005 

          includes the node that most recently accepted custody of the 
          bundle upon forwarding this bundle header.  The Custodian 
          Scheme Offset field contains the offset within the dictionary 
          byte array of the scheme name of the current custodian 
          endpoint ID. 
    
   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 an 8-byte field that, 
          together with the source endpoint ID and (if applicable) the 
          fragment offset, serves to identify the bundle.  The high-
          order four bytes of the timestamp are the bundle's creation 
          time, a time value - expressed in seconds since the start of 
          the year 2000 - containing the time that the application data 
          unit of which this bundle's payload is a part (possibly all) 
          was received for initial transmission by the source node's 
          bundle protocol agent.  The low-order four bytes of the 
          timestamp are the latest value (as of the time the ADU was 
          received) of a monotonically increasing positive integer 
          counter managed by the source node's bundle protocol agent 
          that is reset to zero whenever the current time advances by 
          one second. 
    
   Lifetime.   The four-byte lifetime field 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, 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 Header 
          together with, potentially, other endpoint IDs referenced by 
          fields in other TBD DTN protocol headers.  Its length is given

          by the value of the Dictionary Length field. 
    
   Fragment Offset.  If the Bundle Processing Control Flags of this 
          Primary header 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 
          header. 
    
   Total Application Data Unit Length.  If the Bundle Processing Control

          Flags of this Primary header indicate that the bundle is a 

K. Scott and S. Burleigh      Expires - January 2006      [Page 24] 
Internet Draft      Bundle Protocol Specification          July 2005 

          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 header. 
 
3.6.2 Bundle Payload Header 
    
   The fields of the bundle payload header are: 
    
   Header Type.  The Header Type field is a 1-byte field that indicates 
          the type of the header.  Header types are listed in Table 1 
          above. 
    
   Header Processing Control Flags.  The Header Processing Control Flags

          field is a 1-byte field that contains the header processing 
          control flags discussed in section 3.2 above. 
    
   Header Length.  The Header Length field is an SDNV that contains the 
          aggregate length of all remaining fields of the header - which

          is to say, the length of the bundle's payload. 
 
   Payload.  The application data carried by this bundle. 
    
4. Bundle Processing 
    
   The bundle processing procedures mandated in this section are neither

   exhaustive or exclusive.   That is, supplementary DTN protocol 
   specifications (including, but not restricted to, the Bundle Security

   Protocol) 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. 
    
4.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 5 below; in practice, the manner 
   in which administrative record generation is accomplished is an 
   implementation matter, provided the constraints noted in section 5 
   are observed.   

K. Scott and S. Burleigh      Expires - January 2006      [Page 25] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   Notes on administrative record terminology: 
    
   a. A "bundle reception status report" is a bundle status report with 
   the "reporting node received bundle" flag set to 1. 
    
   b. A "custody acceptance status report" is a bundle status report 
   with the "reporting node accepted custody of bundle" flag set to 1. 
    
   c. A "bundle forwarding status report" is a bundle status report with

   the "reporting node forwarded the bundle" flag set to 1. 
    
   d. A "bundle delivery status report" is a bundle status report with 
   the "reporting node delivered the bundle" flag set to 1. 
    
   e. A "bundle deletion status report" is a bundle status report with 
   the "reporting node deleted the bundle" flag set to 1. 
    
   f. A "Succeeded" custody signal is a custody signal with the "custody

   transfer succeeded" flag set to 1.    
    
   g. A "Failed" custody signal is a custody signal with the "custody 
   transfer succeeded" flag set to zero. 
    
   h. The "current custodian" of a bundle is the endpoint identified by 
   the current custodian endpoint ID in the bundle's primary header.  
    
4.2 Bundle transmission requests 
    
   The steps in processing a Transmit.request primitive are: 
    
   Step 1: The source endpoint ID provided with the request must be 
      either the ID of an endpoint of which the node is a member or else

      the null endpoint ID "none:."; the same is true of the report-to 
      endpoint ID provided with the request.  If the request fails to 
      satisfy this condition or any implementation-specific transmission

      request policy that is in effect, a TransmitError.indication must 
      be  issued  to  the  application  agent  and  processing  of  the 
      Transmit.request must terminate.  Otherwise, transmission of the 
      bundle is initiated and processing proceeds from Step 2. 
    
   Step 2: A Transmission.indication must be issued to the application 
      agent. 
    
   Step 3: An outbound bundle must be created per the parameters of the 
      Transmit.request primitive, with current custodian endpoint ID set

      to the null endpoint ID "none:." and with the retention constraint

      "Dispatch pending". 
    
   Step 4: Processing proceeds from Step 1 of section 4.3. 

 
K. Scott and S. Burleigh      Expires - January 2006      [Page 26] 
Internet Draft      Bundle Protocol Specification          July 2005 

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

      must be followed. 
    
   Step 2: Processing proceeds from Step 1 of section 4.4. 
    
4.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 
      Table 5.  In particular: 
    
     o The bundle protocol agent must determine which endpoint 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 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 an 
        endpoint  to  forward  the  bundle  to,  then  forwarding  is 
        contraindicated  for  the  reason  "destination  endpoint  ID 
        unintelligible". 
    
     o Provided the bundle protocol agent succeeded in selecting an 
        endpoint 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 the 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 for the reason "destination 
        endpoint ID unintelligible". 
    
   Step  3:  If  forwarding  of  the  bundle  is  determined  to  be 
      contraindicated for any of the reasons listed in Table 5, then the

      Forwarding Contraindicated procedure defined in 4.4.1 must be 
      followed; the remaining steps of section 4 are skipped at this 

K. Scott and S. Burleigh      Expires - January 2006      [Page 27] 
Internet Draft      Bundle Protocol Specification          July 2005 

      time.  Otherwise, (a) if the bundle's custody transfer required 
      switch (in the class of service field) is set to 1 then the 
      custody transfer procedure defined in section 4.10 must be 
      followed; (b) processing proceeds from Step 4. 
    
   Step 4: 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 of the minimum reception group 
      of the selected endpoint.  Determining the time at which the 
      bundle is to be sent by each convergence layer adapter is an 
      implementation matter. 
    
   Step 5: 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: 
    
      o  If the "request reporting of bundle forwarding" flag in the 
          bundle's class of service field is set to 1, then a bundle 
          forwarding status report must be generated, destined for the 
          bundle's report-to endpoint ID. 
    
      o  The bundle's "Forward pending" retention constraint must be 
          removed. 
    
4.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 required switch (in the class of 
      service field) is set to 1 then the custody transfer procedure 
      defined in section 4.10 must be followed; (b) when - at some 
      future time - the forwarding of this bundle ceases to be 
      contraindicated, processing proceeds from Step 3 of 4.4. 
    
4.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 required switch (in the 
      class of service field) is set to 1, the bundle protocol agent 
      must generate a "Failed" custody signal for the bundle, destined 
      for the bundle's current custodian; the custody signal must 

K. Scott and S. Burleigh      Expires - January 2006      [Page 28] 
Internet Draft      Bundle Protocol Specification          July 2005 

      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. 
    
4.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 
   header.  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 4.13 must be followed. 
    
4.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 class of service field is set to 1, then a bundle 
      reception  status  report  with  reason  code  "No  additional 
      information" must be generated, destined for the bundle's report-
      to endpoint ID. 
    
   Step 3: If any header in the bundle cannot be processed: 
    
      o  If the header processing flags in the header indicate that a 
          status report must be generated in this event, then a bundle 
          reception   status   report   with   reason   code   "Header 
          unintelligible" must be generated, destined for the bundle's 
          report-to endpoint ID. 
     
     o  If the header processing flags in that header indicate that 
          the bundle must be discarded in this event, then the bundle 
          protocol agent must delete the bundle for the reason "Header 
          unintelligible": the bundle deletion procedure defined in 4.13

          must be followed.  Otherwise, processing proceeds from Step 4.

   Step 4: If the bundle's custody transfer required switch (in the 
      class of service field) is set to 1 and the bundle has the same 
      source endpoint ID, creation timestamp, and fragment offset as 

K. Scott and S. Burleigh      Expires - January 2006      [Page 29] 
Internet Draft      Bundle Protocol Specification          July 2005 

      another bundle that (a) has not been discarded and (b) currently 
      has the retention constraint "Custody accepted", then the bundle 
      protocol agent must generate a "Failed" custody signal for this 
      bundle with reason code "Redundant reception", destined for this 
      bundle's current custodian, and must also remove this bundle's 
      "Dispatch pending" retention constraint.  Otherwise, processing 
      proceeds from Step 5. 
    
   Step 5: Processing proceeds from Step 1 of section 4.3. 
    
4.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 4.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: For each of the node's current registrations whose endpoint 
      ID matches the destination endpoint ID of the bundle: 
    
      o  If the registration is in the Active state, then the bundle 
          must be delivered subject to this registration - that is, a 
          Data.indication primitive containing the bundle's payload must

          be issued to the application agent - as soon as all previously

          received bundles deliverable subject to this registration have

          been delivered. 
    
     o  If the registration is in the Passive state, then the 
          registration's delivery failure action must be taken (see 
          2.4.10 above). 
 
   Step 3: If the "request reporting of bundle delivery" flag in the 
      bundle's class of service field is set to 1, then a bundle 
      delivery status report must be generated, destined for the 
      bundle's report-to endpoint ID, as soon as the bundle has been 
      delivered subject to at least one registration.  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. 
 
   Step 4: If the bundle's custody transfer required switch (in the 
      class of service field) is set to 1, the bundle protocol agent 
      must generate a "Succeeded" custody signal for the bundle, 
      destined for the bundle's current custodian.  The reason code in 

K. Scott and S. Burleigh      Expires - January 2006      [Page 30] 
Internet Draft      Bundle Protocol Specification          July 2005 

      the signal must be "Delivery to application by non-custodian". 
 
4.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 header'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 
        a 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 header processing flags of each header 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 
        header. 
      
      o All fragments must contain the same headers as the original 
        bundle, except that (a) the primary headers of the fragments 
        will differ from that of the fragmented bundle as noted above, 
        (b) the payload headers of fragments will differ from that of 
        the  fragmented  bundle,  and  (c)  any  header  whose  header 
        processing flags do NOT indicate that the header must be 
        replicated in every fragment should be replicated only in the 
        fragment whose fragment offset is zero.  
   
4.9 Application Data Unit Reassembly 

 
K. Scott and S. Burleigh      Expires - January 2006      [Page 31] 
Internet Draft      Bundle Protocol Specification          July 2005 

  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 header, 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. 
    
4.10 Custody transfer 
    
  The decision as to whether or not to accept custody of a bundle is an 
  implementation matter which may involve both resource and policy 
  considerations; however, if the node is not currently a member of any 
  endpoint (i.e., the node is not registered under any endpoint ID) 
  then custody must be refused.   If the bundle protocol agent elects 
  to accept custody of the bundle, then it must follow the custody 
  acceptance procedure defined in 4.10.1. 
    
4.10.1 
       Custody acceptance 
    
   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, a custody acceptance status 
   report must 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 4.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 
   reason code in the signal must be "Acceptance of custody". 
    
   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 
   endpoints in which the node is registered.  This may entail 
   appending that endpoint ID's null-terminated scheme name and SSP to 

K. Scott and S. Burleigh      Expires - January 2006      [Page 32] 
Internet Draft      Bundle Protocol Specification          July 2005 

   the dictionary byte array in the bundle's primary header. 
    
   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 
   4.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. 
    
4.10.2 
       Custody release 
    
   When custody of a bundle is released, 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. 
    
4.11 Custody transfer success 
    
   Upon receipt of a "Succeeded" custody signal at a node that is a 
   custodial node of the bundle identified in the custody signal, 
   custody of the node is released in accord with the procedures 
   described in 4.10.2. 
   
4.12 Custody transfer failure 
    
   Upon receipt of a "Failed" custody signal at a node that is a 
   custodial node of the bundle identified in the custody signal, the 
   action taken by the bundle protocol agent is implementation-dependent

   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 4.4).  
   Receipt of a "Failed" custody signal with the "Redundant reception" 
   reason code, on the other hand, might cause the bundle protocol agent

   to handle the failure in the same way as a custody transfer success 
   (4.11) and to revise its algorithm for computing countdown intervals 
   for custody transfer timers. 
   
4.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, then: 
    
      o  Custody of the node is released in accord with the procedures 
          described in 4.10.2. 

 
K. Scott and S. Burleigh      Expires - January 2006      [Page 33] 
Internet Draft      Bundle Protocol Specification          July 2005 

      o  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 class of service field is set to 1, then a bundle 
      deletion status report citing the reason for deletion must be 
      generated, destined for the bundle's report-to endpoint ID. 
    
   Step 2: All of the bundle's retention constraints must be removed. 
   
4.14 Discarding a bundle 
    
   As soon as a bundle has no remaining retention constraints it may be 
   discarded. 
 
5. Administrative record processing 
    
5.1 Administrative records 
    
   Two types of administrative records have been defined to date: bundle

   status reports and custody signals. 
    
   Every administrative record consists of an eight-bit record type 
   code, followed by record content in type-specific format.  Record 
   type codes are defined as follows: 
    
         Table 4: Administrative Record Type Codes 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  0x01   |  Bundle status report.                     | 
         +---------+--------------------------------------------+ 
         |  0x02   |  Custody signal.                         | 
         +---------+--------------------------------------------+ 
         | (other) |  Reserved for future use.                  | 
         +---------+--------------------------------------------+ 
    
   The contents of the various types of administrative records are 
   described below. 
    
5.1.1 Bundle Status Reports 
    
   The  transmission  of  'bundle  status  reports'  under  specified 
   conditions is an option that can be invoked when a Transmit.request 
   primitive is presented.  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. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 34] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   Status reports have the following format. 
    
   Bundle Status Report for bundle 'X': 
    
+----------------+----------------+----------------+----------------+ 
|  Status Flags  |  Reason code   |       Fragment offset (*) (if      
+----------------+----------------+----------------+----------------+ 
    present)     |      Fragment length (**) (if present)           | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+        Time of receipt of bundle X (8 bytes, if present)          + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+       Time of forwarding of bundle X (8 bytes, if present)        + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+        Time of delivery of bundle X (8 bytes, if present)         + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+        Time of deletion of bundle X (8 bytes, if present)         + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+           Copy of bundle X's Creation Timestamp (8 bytes)         + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|      Length of X's source endpoint ID (***)      |   Source        
+----------------+---------------------------------+                + 
                     endpoint ID of bundle X (variable)             | 
+----------------+----------------+----------------+----------------+ 
    
   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 source endpoint ID length field is an SDNV and is 
   therefore variable-length.  A three-octet SDNV is shown here for 
   convenience in representation. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 35] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   The fields in a bundle status report are: 
    
   Status Flags.  A 1-byte field containing the following flags: 
    
         Table 4: Status Flags for Bundle Status Reports 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  0x01   |  Reporting node received bundle.           | 
         +---------+--------------------------------------------+ 
         |  0x02   |  Reporting node accepted custody of bundle.| 
         +---------+--------------------------------------------+ 
         |  0x04   |  Reporting node forwarded the bundle.      | 
         +---------+--------------------------------------------+ 
         |  0x08   |  Reporting node delivered the bundle.      | 
         +---------+--------------------------------------------+ 
         |  0x10   |  Reporting node deleted the bundle.        | 
         +---------+--------------------------------------------+ 
         |  0x20   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x40   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x80   |  Report is for a fragment; fragment        | 
         |         |  offset and length fields are present.     | 
         +---------+--------------------------------------------+ 
    
   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) may define 
          additional reason codes.  Status report reason codes are 
          defined as follows: 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 36] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
         Table 5: Status Report Reason Codes 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  0x00   |  No additional information.                | 
         +---------+--------------------------------------------+ 
         |  0x01   |  Lifetime expired.                         | 
         +---------+--------------------------------------------+ 
         |  0x02   |  Header unintelligible.                    | 
         +---------+--------------------------------------------+ 
         |  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.| 
         +---------+--------------------------------------------+ 
         | (other) |  Reserved for future use.                  | 
         +---------+--------------------------------------------+ 
    
   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 or custody-
          accepted bit is set in the status flags, then a timestamp 
          indicating the time at which the indicated event occurred at 
          the reporting endpoint is included here.  The timestamp is 8 
          bytes long, formatted as a POSIX timespec. 
    
   Time of Forward (if present).  If the bundle-forwarded bit is set in 
          the status flags, then a timestamp indicating the time at 
          which the bundle was first forwarded at the reporting endpoint

          is included here.  The timestamp is 8 bytes long, formatted as

          a POSIX timespec. 
 
   Time of Delivery (if present).  If the bundle-delivered bit is set in

          the status flags, then a timestamp indicating the time at 
          which the bundle was first delivered at the reporting endpoint

          is included here.  The timestamp is 8 bytes long, formatted as

          a POSIX timespec. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 37] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   Time of Deletion (if present).  If the bundle-deleted bit is set in 
          the status flags, then a timestamp indicating the time at 
          which the bundle was deleted at the reporting endpoint is 
          included here.  The timestamp is 8 bytes long, formatted as a 
          POSIX timespec. 
    
   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. 
   
5.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 Flags  |  Reason code   |       Fragment offset (*) (if      
+----------------+----------------+----------------+----------------+ 
    present)     |      Fragment length (**) (if present)           | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+                      Time of signal (8 bytes)                     + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|                                                                    
+           Copy of bundle X's Creation Timestamp (8 bytes)         + 
                                                                    | 
+----------------+----------------+----------------+----------------+ 
|      Length of X's source endpoint ID (***)      |   Source        
+----------------+---------------------------------+                + 
                     endpoint ID of bundle X (variable)             | 
+----------------+----------------+----------------+----------------+ 
    
   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. 

K. Scott and S. Burleigh      Expires - January 2006      [Page 38] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
   (**)  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 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 Flags.  A 1-byte field containing the following flags: 
    
         Table 6: Status Flags for Custody Signals 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  0x01   |  Custody transfer succeeded.               | 
         +---------+--------------------------------------------+ 
         |  0x02   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x04   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x08   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x10   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x20   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x40   |  Unused.                                   | 
         +---------+--------------------------------------------+ 
         |  0x80   |  Signal pertains to a fragment; fragment   | 
         |         |  offset and length fields are present.     | 
         +---------+--------------------------------------------+ 
    
   Reason code.  A 1-byte field explaining the value of the "Custody 
   transfer succeeded" flag in the status flags byte.  Reason codes are 
   defined as follows: 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 39] 
Internet Draft      Bundle Protocol Specification          July 2005 

    
         Table 7: Custody Signal Reason Codes 
    
         +---------+--------------------------------------------+ 
         |  Value  |                  Meaning                   | 
         +=========+============================================+ 
         |  0x00   |  No additional information.                | 
         +---------+--------------------------------------------+ 
         |  0x01   |  Acceptance of custody.                    | 
         +---------+--------------------------------------------+ 
         |  0x02   |  Delivery to application by non-custodian. | 
         +---------+--------------------------------------------+ 
         |  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.| 
         +---------+--------------------------------------------+ 
         | (other) |  Reserved for future use.                  | 
         +---------+--------------------------------------------+ 
    
   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 timestamp indicating the time at which the signal 
          was issued.  The timestamp is 8 bytes long, formatted as a 
          POSIX timespec. 
    
   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. 
    
  Source Endpoint ID text.  The text of the source endpoint ID of the 
          bundle to which the signal applies. 
    
5.2 Generation of administrative records 
    
   Whenever the application agent's administrative element is directed 

K. Scott and S. Burleigh      Expires - January 2006      [Page 40] 
Internet Draft      Bundle Protocol Specification          July 2005 

   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 Transmit.request primitive, requesting transmission of the

      administrative record, must be presented to the bundle protocol 
      agent. 
 
5.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 4.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 4.12. 
    
6. Services Required of the Convergence Layer 
    
6.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  point-to-point 
   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.     
    
6.2 Summary of Convergence Layer Services 
    
   Each convergence layer protocol adapter is expected to provide the 
   following services to the bundle protocol agent: 
    
      a) sending a bundle to all bundle nodes in the minimum reception 
        set of the endpoint identified by a specified endpoint ID that 
        are reachable via the convergence layer protocol; 
    
      b) delivering to the bundle protocol agent a bundle that was sent 

K. Scott and S. Burleigh      Expires - January 2006      [Page 41] 
Internet Draft      Bundle Protocol Specification          July 2005 

        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) may expect convergence layer adapters which serve BP 
   implementations conforming to those protocols to offer additional 
   primitives and/or provide additional parameters with the listed 
   primitives. 
    
6.3 Summary of Primitives 
    
6.3.1 Requests 
    
   The convergence layer service is expected to consume the following 
   request primitives: 
    
      a) Send.request 
    
6.3.2 Indications 
    
   The convergence layer service is expected to deliver the following 
   indication primitives: 
    
      a) Send-Report.indication 
      b) Bundle.indication 
    
6.4 Summary of Parameters 
    
   NOTE  -  The availability and use of parameters for each primitive 
   are indicated in section 6.5.  The following definitions apply. 
    
6.4.1 Receiving Endpoint ID 
    
   The  receiving  endpoint  ID  parameter  identifies  the  endpoint 
   containing the node(s) to which a bundle is to be sent.  Note: this 
   endpoint is not necessarily the final destination of the bundle.  
    
6.4.2 Bundle 
    
   The bundle parameter indicates the location of a bundle, in the 
   format described in section 3, that has been conveyed or is to be 
   conveyed by the convergence layer protocol. 
    
6.4.3 Bundle length 
    
   The bundle length parameter indicates the length of a bundle that has

   been conveyed or is to be conveyed by the convergence layer protocol.

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 42] 
Internet Draft      Bundle Protocol Specification          July 2005 

6.4.4 Send result 
    
   The send result parameter indicates in an implementation-specific 
   manner the results of processing a Send.request. 
    
6.5 Convergence Layer Service Primitives 
    
6.5.1 SEND.REQUEST 
    
   The Send.request primitive requests the sending of a bundle to the 
   nodes in the minimum reception set of a neighboring endpoint. 
    
   Semantics: Send.request provides parameters as follows: 
      Send.request(  receiving endpoint ID, 
                     bundle length, 
                     bundle) 
    
   When Presented: Send.request may be presented by the bundle protocol 
   agent at any time. 
    
   Effect on Receipt: Receipt of Send.request is expected to cause the 
   convergence  layer  protocol  adapter  to  initiate  data  sending 
   procedures; the manner in which it does so may depend on the scheme 
   name in the receiving endpoint ID.  In addition, the convergence 
   layer adapter is expected to issue a Send-Report.indication to the 
   bundle protocol agent when it has concluded those procedures. 
    
   Additional Comments:  None. 
    
6.5.2 SEND-REPORT.INDICATION 
    
   The Send-Report.indication primitive reports to the bundle protocol 
   agent on the results of processing a Send.request primitive. 
    
   Semantics: Send-Report.indication provides parameters as follows: 
      Send-Report.indication  (  receiving endpoint ID, 
                     bundle length, 
                     bundle, 
                     send result) 
    
   When Issued: Send-Report.indication is expected to be issued upon the

   conclusion of the data sending procedures initiated in response to a 
   Send.request primitive. 
    
   Effect on Receipt: The effect on receipt of Send-Report.indication is

   undefined. 
    
   Additional Comments: None. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 43] 
Internet Draft      Bundle Protocol Specification          July 2005 

6.5.3 BUNDLE.INDICATION 
    
   The Bundle.indication primitive delivers a received bundle to the 
   bundle protocol agent. 
    
   Semantics: Bundle.indication provides parameters as follows: 
      Bundle.indication (  bundle length, 
                     bundle) 
    
   When Issued: Bundle.indication is expected to be issued on arrival of

   a bundle sent from a remote node. 
    
   Effect on Receipt: Receipt of Bundle.indication causes the bundle 
   protocol agent to process the received bundle as described in section

   4.6. 
    
   Additional Comments: None. 
    
Security Considerations 
    
   Security in the bundle protocol is the subject of the Bundle Security

   Protocol specification [5].   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. 
    
IANA Considerations 
    
   The new Uniform Resource Identifier schemes "bp0" and "none", defined

   by the Bundle Protocol, will need to be documented. 
    
Informative References 
    
   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
       Levels", BCP 14, RFC 2119, March 1997 
    
   [2] V. Cerf, et. al., "Delay-Tolerant Network Architecture," work in 
       progress, draft-irtf-dtnrg-arch-02.txt, July 2004 
    
   [3] F.  Warthman,  "Delay-Tolerant  Networks  (DTNs):  A  Tutorial", 
       Warthman Associates, available from http://www.dtnrg.org 
    
   [4] Mills, D., "Network Time Protocol (Version 3) Specification, 
       Implementation and Analysis", RFC 1305, March 1992 
    
   [5] S. Symington, et. al., "Bundle Security Protocol Specification," 
       work in progress, draft-irtf-dtnrg-bundle-security-00.txt, May 
       2005 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 44] 
Internet Draft      Bundle Protocol Specification          July 2005 

Acknowledgements 
 
   The authors gratefully acknowledge the contributions of Dr. Vint Cerf

   of MCI, Dr. Kevin Fall and Michael Demmer of Intel Corporation, 
   Adrian Hooke and Leigh Torgerson of the Jet Propulsion Laboratory, 
   Howard Weiss of SPARTA, Inc., Dr. Stephen Farrell of Trinity College 
   Dublin,  and  Robert  Durst  and  Susan  Symington  of  The  MITRE 
   Corporation. 
    
Author's Addresses 
    
Dr. Keith L. Scott             Scott C. Burleigh 
The MITRE Corporation          Jet Propulsion Laboratory 
7515 Colshire Drive            4800 Oak Grove Drive 
McLean, VA 22102                M/S: 179-206 
Telephone  +1  (703)  883-6547 Pasadena, CA 91109-8099 
FAX +1 (703) 883-7142          Telephone +1 (818) 393-3353 
Email [email-masked]         FAX +1 (818) 354-1075 
                                Email [email-masked]  
    
   Please refer comments to [email-masked].  The Delay 
   Tolerant Networking Research Group (DTNRG) web site is located at 
   http://www.dtnrg.org.  
 
Copyright Notice  
 
   Copyright (C) The Internet Society (2005).  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.   
        
Disclaimer  
 
   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 

K. Scott and S. Burleigh      Expires - January 2006      [Page 45] 
Internet Draft      Bundle Protocol Specification          July 2005 

   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- 
   [email-masked]. 
        
Release Statement  
        
By submitting this Internet-Draft, the authors accept the provisions of 
Section 4 of RFC 3667. 

 
 
K. Scott and S. Burleigh      Expires - January 2006      [Page 46] 

Content-class: urn:content-classes:message
Date: Sun, 10 Jul 2005 21:32:16 -0700
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>
Subject: [dtn-interest] draft for updated DTN Architecture Internet Draft
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C585D1.876DDBDD
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi folks--

Well, I have finally put together a document which I intend to submit
later this week as an update to draft-irtf-dtnrg-arch-02.txt.  This
would be good, as the current one has actually expired.

The document has to be in by Jul 18 to be admitted as an I-D before the
next IETF meeting, so I would like to receive any comments you folks
have prior to July 16.

As you look through the attachment, you will notice several places where
'XXX' appears.  In general, the intention is to delete the material
surrounded by this mark, although there might be a couple of places
where it instead brings up an issue to consider.

So, anyhow, please let me know if you have comments/concerns as quickly
as possible so I can address them prior to the cutoff date.

Cheers,
- Kevin

------_=_NextPart_001_01C585D1.876DDBDD
Content-Type: text/plain;
	name="draft_irtf_dtnrg_arch_071005.txt"
Content-Transfer-Encoding: base64
Content-Description: draft_irtf_dtnrg_arch_071005.txt
Content-Disposition: attachment;
	filename="draft_irtf_dtnrg_arch_071005.txt"

------_=_NextPart_001_01C585D1.876DDBDD--

Date: Fri, 8 Jul 2005 15:13:27 -0700
From: Joshua Schoolcraft <[email-masked]>
Reply-To: Joshua Schoolcraft <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Configure / compile under updated FC3?
Sender: [email-masked]

Hello,

I'm trying to compile DTN2 in Fedora Core 3, but I run into an issue
with ./configure:

checking compilation target... native
checking whether to compile with debugging... yes
checking whether to compile with memory debugging... no
checking whether to compile with optimization... no
checking whether to build and link using static tcl and db libraries... no
checking for a C compiler (trying gcc gcc-3.3 gcc-3.2 gcc-2.96 gcc296
gcc-2.95 gcc295)...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for a C++ compiler (trying g++ g++-3.3 g++-3.2 g++-2.96
g++296 g++-2.95 g++295)...
checking for g++... no
checking for g++-3.3... no
checking for g++-3.2... no
checking for g++-2.96... no
checking for g++296... no
checking for g++-2.95... no
checking for g++295... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking for gawk... gawk
checking for a BSD-compatible install... /usr/bin/install -c
checking whether make sets $(MAKE)... yes
checking for ranlib... ranlib
checking for the version of the gcc compiler... 3.4.3
checking whether gcc accepts -Wno-long-double (Apple OSX only)... no
checking whether std::string::reserve() is broken... yes
configure: error: broken std::string::reserve() -- upgrade your compiler

The installation of Fedora Core 3 was updated with yum recently, and
gcc is version 3.4.3-22.  Does anyone know how to deal with this?  A
Google search for broken std::string::reserve() didn't turn up much.

Thanks,
Josh