One document matched: draft-irtf-dtnrg-bundle-spec-00.txt
Delay Tolerant Networking Research Group K. Scott
Internet Draft The MITRE Corporation
<draft-irtf-dtnrg-bundle-spec-00.txt> S. Burleigh
March 2003 Jet Propulsion Laboratory
Expires: September 2003
Bundle Protocol Specification
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
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
document are to be interpreted as described in RFC-2119 [1].
K. Scott and S. Burleigh Expires - September 2003 [Page 1]
Internet Draft Bundle Protocol Specification March 2003
Table of Contents
1. Introduction.........................................2
2. Service Description..................................4
2.1 Definitions..........................................4
2.2 Services at the User Interface.......................4
2.3 Summary of Primitives................................4
2.4 Summary of Parameters................................5
2.5 Bundling Service Primitives..........................6
3. Bundle Message Format...............................11
3.1 General Bundle Header Format........................15
3.2 Tuples..............................................15
3.3 Primary and Variable-Length Immutable Portion Headers16
3.4 Current Custodian Header............................19
3.5 Bundle Status Report Header.........................20
3.6 Bundle Payload Header...............................21
3.7 Subsequent Bundle Payload Header....................21
3.8 Authentication Header...............................22
3.9 16-bit Extended Offset Header.......................23
3.10 Rules Governing the Appearance and Order of Headers.23
4. Bundle Processing...................................24
4.1 Bundles received from applications via the API......24
4.2 Bundles received from other bundle agents...........24
4.3 Bundle Fragmentation and Reassembly.................27
Security Considerations.........................................28
Informative References..........................................28
Acknowledgements................................................29
Author's Addresses..............................................29
1. Introduction
Delay Tolerant Networking (DTN) 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, the DTN protocols, also known
as bundle protocols, sit at the application layer of the constituent
internets, forming a store-and-forward overlay network. Key
capabilities of the bundling protocols include:
o Custody-based reliability
o Ability to cope with intermittent connectivity
o Ability to take advantage of scheduled and opportunistic
connectivity (in addition to 'always-up' connectivity)
o Late binding of names to addresses
K. Scott and S. Burleigh Expires - August 2003 [Page 2]
Internet Draft Bundle Protocol Specification March 2003
For descriptions of these capabilities and rationale for the DTN
architecture, see [2]. [3] contains a tutorial-level overview of
DTN concepts.
The bundle protocols sit at the application layer of the constituent
internets as shown in Figure 1. Bundling 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 known as a
convergence layer. Figure 1 shows three distinct transport and
network protocols (denoted T1/N1, T2,N2, and T3/N3).
+-----------+ +-----------+
| BundleApp | | BundleApp |
+---------v-| +->>>>>>>>>>v-+ +->>>>>>>>>>v-+ +-^---------+
| Bundle v | | ^ Bundle v | | ^ Bundle v | | ^ Bundle |
+---------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 bundling protocol sits at the application layer of the
Internet model.
This document describes the format of the messages (called bundles)
passed between entities participating in bundle communications. The
entities are referred to as bundle nodes or bundle agents. This
document does not address:
o The mechanisms bundle agents use to transport data through a
specific Internet, called convergence layers, or the bundle
agent to convergence layer API.
o The bundle routing algorithm or mechanisms for populating the
routing or forwarding information bases of bundle nodes.
K. Scott and S. Burleigh Expires - August 2003 [Page 3]
Internet Draft Bundle Protocol Specification March 2003
2. Service Description
2.1 Definitions
Communications Endpoint ID û A Communications Endpoint ID or
'Communications endpoint' corresponds to a 'tuple' in [2]. A
communications endpoint is identified by a DTN region identifier and
an administrative part that is opaque to the bundle system outside
the destination region.
Passive bundle reception û A bundle application is said to be in a
period of passive bundle reception if it expects the bundle agent to
asynchronously notify it of new bundles. This assumes that the
application has registered a Communications Endpoint ID and a
callback mechanism with a bundle agent.
Send token binding, registration token binding û A token passed from
a bundle application to the bundle agent when sending a bundle /
registering to receive bundles. This token is used to associate an
opaque token returned by the bundle agent with a specific bundle /
registration.
2.2 Services at the User Interface
2.2.1 The bundling protocol SHALL provide the following services to
bundling applications:
a) sending a bundle to an identified communications endpoint;
b) canceling a previously submitted request to send a bundle
c) beginning a period of passive bundle reception;
d) ending a period of passive bundle reception;
e) actively requesting delivery of a bundle.
2.3 Summary of Primitives
2.3.1 The bundling service SHALL consume the following request
primitives:
a) Send.request;
b) Cancel.request
c) Register.request;
d) Deregister.request;
e) Poll.request;
K. Scott and S. Burleigh Expires - August 2003 [Page 4]
Internet Draft Bundle Protocol Specification March 2003
2.3.2 The Bundling service SHALL deliver the following indication
primitives:
a) Bundle.indication;
b) SendError.indication
c) SendToken.indication
d) RegistrationToken.indication
2.4 Summary of Parameters
NOTE û The availability and use of parameters for each primitive
are indicated in section 2.5, where optional parameters are
identified with square brackets [thus]. The following definitions
apply.
2.4.1 Destination Communications endpoint ID
The destination communications endpoint ID parameter identifies the
communications endpoint to which the bundle is to be sent. One can
think of a DTN communications endpoint as an application, but in
general the definition is meant to be broader. For example, elements
of a sensor network might register with a local bundle agent to
receive information about certain topics of interest. A
communications endpoint could thus refer to a process running on a
general-purpose processor, a special-purpose hardware device, an
object in an object-oriented operating system, etc.
2.4.2 Source Communications endpoint ID
The source communications endpoint ID parameter shall uniquely
identify the communications endpoint from which the bundle was sent.
2.4.3 Reply Communications endpoint ID
The reply communications endpoint ID parameter shall identify the
communications endpoint to which any bundle status reports pertaining
to the bundle, including end-to-end acknowledgments, should be sent.
2.4.4 Class of Service Parameter
The class of service parameter shall indicate which class of standard
procedures shall be followed when transmitting and delivering the
bundle. Its value shall be one of the following:
o Bulk
o Normal
o Expedited
K. Scott and S. Burleigh Expires - August 2003 [Page 5]
Internet Draft Bundle Protocol Specification March 2003
2.4.5 Delivery Options Parameter
The delivery options parameter shall indicate what optional
procedures shall additionally be followed when transmitting and
delivering the bundle. Its value shall be a combination of zero or
more of the following:
o Custody transfer
o Return receipt
o Delivery record received
o Delivery record custody taken
o Security requirements
- Confidentiality
- Integrity
- Authentication
2.4.6 Lifespan parameter
The lifespan parameter shall indicate the length of time, following
initial transmission of a bundle, after which bundling agents shall
no longer store or forward the bundle. The sum of the bundle's
transmission time and lifespan is its delivery deadline, the moment
at which it will be deleted from the DTN network if it has not
already been delivered to its destination communications endpoint.
2.4.7 Application Data Unit Parameter
The application data unit parameter shall indicate the location (in
memory or non-volatile storage, a local implementation matter) of the
application data conveyed by the bundle.
2.4.8 Delivery Failure Action Parameter
The delivery failure action parameter shall indicate what action is
to be taken when a bundle arrives for delivery at a moment when its
destination communications endpoint is not currently in a period of
passive bundle reception. Its value shall be one of the following:
o Defer delivery until the entity either actively requests
delivery of the bundle or else begins a period of passive
bundle reception.
o Abort delivery of the bundle.
o Execute a specified procedure, where the expression of the
procedure to be executed is a matter of local implementation.
2.5 Bundling Service Primitives
K. Scott and S. Burleigh Expires - August 2003 [Page 6]
Internet Draft Bundle Protocol Specification March 2003
2.5.1 SEND.REQUEST
The Send.request primitive shall be used by the application to
request transmission of an application data unit from the source
communications endpoint to a destination communications endpoint.
Semantics: Send.request shall provide parameters as follows:
Send.request( source communications endpoint ID,
destination communications endpoint ID,
reply communications endpoint ID,
class of service,
delivery options,
lifespan,
send token binding,
application data unit)
When Generated: Send.request is generated by the source Bundling
application at any time.
Effect on Receipt: Receipt of Send.request shall cause the Bundling
agent to initiate bundle transmission procedures. In addition, the
agent will generate a SendToken.indication for the application. The
SendToken.indication returns to the application the send token
binding and a token that the application can later use to refer to
this bundle.
Additional Comments: None.
2.5.2 CANCELBUNDLE.REQUEST
The CancelBundle.request primitive shall be used by the application
to request that a bundle previously sent via a Send.request be
cancelled.
Semantics: CancelBundle.request shall provide parameters as follows:
Cancel.request ( send token )
When Generated: CancelBundle.request MAY be generated by the
application after sending a bundle via the Send.request and after
receiving a reference token for the bundle via a
SendToken.indication. A CancelBundle.request should be sent if the
application no longer wished to send the bundle referenced by the
send token.
Effect on Receipt: Receipt of CancelBundle.request shall cause the
Bundling agent to cease attempts to transmit the given bundle. If
the bundle agent is the current custodian, then retransmission
resources, including any retransmission timers, associated with the
bundle will be released.
K. Scott and S. Burleigh Expires - August 2003 [Page 7]
Internet Draft Bundle Protocol Specification March 2003
Additional Comments: None.
2.5.3 REGISTER.REQUEST
The Register.request primitive shall be used to notify the Bundling
agent of the start of a period of passive bundle reception.
Semantics: Register.request shall provide parameters as follows:
Register.request( delivery failure action,
registration token binding,
destination communications endpoint ID)
When Generated: Register.request is generated by any Bundling
application at any time when not currently in a period of passive
bundle reception.
Effect on Receipt: Receipt of Register.request shall cause the
Bundling agent to deliver to the Bundling application any bundles
destined for the application that (a) arrived in the past and were
deferred or (b) arrive during the new period of passive bundle
reception. Receipt of Register.request will also cause the agent to
deliver a RegisterToken.indication to the application. The
RegisterToken.indication contains a token that the application can
use to refer to this registration.
Additional Comments: There are currently no provisions for multipoint
delivery of bundles. Bundle agents MAY prohibit multiple
applications from registering for passive bundle reception with the
same destination communications endpoint ID. The behavior of the
bundle agent when multiple applications register with the same
communications endpoint ID is undefined. The registration token
binding is currently unused but included in anticipation of being
useful for multipoint delivery.
2.5.4 DEREGISTER.REQUEST
The Deregister.request primitive shall be used to notify the Bundling
agent of the end of a period of passive bundle reception.
Semantics: Deregister.request shall provide parameters as follows:
Deregister.request(destination communications endpoint id)
When Generated: Deregister.request is generated by any Bundling
application at any time when the application is currently in a period
of passive bundle reception.
K. Scott and S. Burleigh Expires - August 2003 [Page 8]
Internet Draft Bundle Protocol Specification March 2003
Effect on Receipt: Receipt of Deregister.request shall cause the
Bundling agent to dispatch any subsequently arriving bundles destined
for the application in accord with the delivery failure action
specified by the most recent Register.request primitive issued by
this application.
Additional Comments: None.
2.5.5 POLL.REQUEST
The Poll.request primitive shall be used to request immediate
delivery of a bundle.
Semantics: Poll.request shall provide parameters as follows:
Poll.request(destination communications endpoint id)
When Generated: Poll.request is generated by any Bundling application
at any time when not currently in a period of passive bundle
reception.
Effect on Receipt: Receipt of Poll.request shall cause the Bundling
Agent to deliver to the Bundling application the least recently
received bundle, destined for the communications endpoint ID, for
which delivery was deferred.
Additional Comments: There are currently no provisions for multipoint
bundle delivery. If multiple distinct applications poll for delivery
of bundles using the same communications endpoint ID, each
application may receive some subset of the bundles that the agent has
received destined for that ID.
2.5.6 BUNDLE.INDICATION
The Bundle.indication primitive shall be used to deliver the content
of a bundle to the bundle's destination communications endpoint.
Semantics: Bundle.indication shall provide parameters as follows:
Bundle.indication ( source communications endpoint ID,
destination communications endpoint ID,
reply communications endpoint ID,
class of service,
delivery options,
lifespan,
application data unit)
When Generated: Bundle.indication shall be generated on receipt of a
Poll.request primitive from a Bundling application or on arrival of a
bundle destined for the application at a time when the application is
in a period of passive bundle reception.
K. Scott and S. Burleigh Expires - August 2003 [Page 9]
Internet Draft Bundle Protocol Specification March 2003
Effect on Receipt: The effect on receipt of Bundle.indication by a
Bundling application is undefined.
Additional Comments: None.
2.5.7 SENDERROR.INDICATION
The SendError.indication primitive shall be used to deliver
information about bundles that the agent cannot accept from the
application.
Semantics: SendError.indication shall provide parameters as follows:
SendError.indication ( source communications endpoint ID,
destination communications endpoint ID,
reply communications endpoint ID,
class of service,
delivery options,
lifespan,
application data unit)
When Generated: SendError.indication shall be generated when a bundle
sent by an application cannot be accepted by the agent.
Effect on Receipt: The effect on receipt of SendError.indication by a
Bundling application is undefined.
Additional Comments: None.
2.5.8 SENDTOKEN.INDICATION
The SendToken.indication primitive shall be used to deliver a token
to the application that it can use to refer to a particular bundle
sent via s Send.request primitive.
Semantics: SendToken.indication shall provide parameters as follows:
SendToken.indication ( send token binding,
send token)
When Generated: SendToken.indication shall be generated when a bundle
is accepted by the agent for transmission. The send token binding
parameter is the same as that supplied with the Send.indication, and
the send token can be supplied to refer to the particular bundle.
Effect on Receipt: The effect on receipt of SendToken.indication by a
Bundling application is undefined.
Additional Comments: None.
K. Scott and S. Burleigh Expires - August 2003 [Page 10]
Internet Draft Bundle Protocol Specification March 2003
2.5.9 REGISTRATIONTOKEN.INDICATION
The RegistrationToken.indication primitive shall be used to deliver a
token to the application that it can use to refer to a particular
registration invoked with the Register.request primitive.
Semantics: RegistrationToken.indication shall provide parameters as
follows:
RegistrationToken.indication ( registration token binding,
registration token)
When Generated: RegistrationToken.indication shall be generated when
a registration.request primitive is serviced by the agent.
Effect on Receipt: The effect on receipt of
RegistrationToken.indication by a Bundling application is undefined.
Additional Comments: The Registration.indication is currently unused.
It is expected that it will be useful when multipoint delivery is
implemented.
3. Bundle Message Format
The DTN protocols use a chained header format reminiscent of IPv6
headers. Each bundle header consists of at least a primary bundle
header and a variable-length Immutable Portion (VLIP) header. Other
header types can be chained after the VLIP to support additional
functionality such as authentication, bundle segmentation, etc.
This section describes the format of the different bundle headers.
Rules for processing bundle headers appear in section 4 of this
document.
The currently defined headers are:
Table 1: Bundle Header Types
+--------------------+------+---------------------------------------+
| Header | Type | Comment |
+====================+======+=======================================+
| | 0x00 | Reserved |
+--------------------+------+---------------------------------------+
| Primary bundle | 0x01 | Must appear before any other bundle |
| header | | header. |
+--------------------+------+---------------------------------------+
| Variable Length | 0x02 | (VLIP) contains source, destination, |
| Immutable Portion | | and reply-to tuples. |
+--------------------+------+---------------------------------------+
K. Scott and S. Burleigh Expires - August 2003 [Page 11]
Internet Draft Bundle Protocol Specification March 2003
| Current Custodian | 0x03 | Indicates current bundle custodian. |
| | | Present only if the custody transfer |
| | | service is requested. |
+--------------------+------+---------------------------------------+
| Bundle Status | 0x04 | Used to report bundle receipt, |
| Report | | forwarding, and custody actions. |
+--------------------+------+---------------------------------------+
| Bundle Payload | 0x05 | Identifies actual bundle content. |
+--------------------+------+---------------------------------------+
| Subsequent Bundle | 0x06 | Used when more than one bundle is |
| Payload Header | | transmitted under a single primary |
| | | header. |
+--------------------+------+---------------------------------------+
| Authentication | 0x07 | Content depends on the type of |
| | | authentication used. |
+--------------------+------+---------------------------------------+
| 16-bit Extended | 0x08 | Provides extended reference |
| Offset | | capabilities when the combination of |
| | | source, dest, and reply-to tuples in |
| | | the VLIP precludes their reference |
| | | by -byte offsets. |
+--------------------+------+---------------------------------------+
| Bundle Fragment | 0x09 | This bundle is a fragment of a |
| | | larger one.
+--------------------+------+---------------------------------------+
| All other values reserved for future use. |
+--------------------+------+---------------------------------------+
The format of the various headers is shown in Figure 2 below.
Primary Bundle Header
+----------------+----------------+----------------+----------------+
| Version | Next Header | Destination | Source |
+----------------+----------------+----------------+----------------+
| Reply-To | Cur. Custodian | COS Flags | Authentication |
+----------------+----------------+----------------+----------------+
| |
+ Creation Timestemp (8 bytes) +
| |
+---------------------------------+---------------------------------+
| Expiration Time |
+----------------+----------------+---------------------------------+
K. Scott and S. Burleigh Expires - August 2003 [Page 12]
Internet Draft Bundle Protocol Specification March 2003
Variable Length Immutable Portion Header
+----------------+----------------+----------------+----------------+
| Next Header | Total Length | Destination Tuple (variable) |
+----------------+----------------+ |
/ /
/ /
+----------------+----------------+----------------+----------------+
| Source Tuple (variable) |
/ /
/ /
+----------------+----------------+----------------+----------------+
| Reply-To Tuple (variable) |
/ /
/ /
+----------------+----------------+----------------+----------------+
Current Custodian Header
+----------------+----------------+----------------+----------------+
| Next Header | Current custodian tuple (variable) |
+----------------+----------------+----------------+----------------+
Bundle Status Report Header for bundle 'X'
+----------------+----------------+----------------+----------------+
| Next Header | Length | Status Flags | Fragment
+----------------+----------------+----------------+----------------+
offset (4 bytes, if present) | Fragment
+--------------------------------------------------+----------------+
length (4 bytes, if present) | Copy of |
+--------------------------------------------------+ |
| X's Creation Timestamp (8 bytes) |
+ +----------------+
| | Time of
+----------------+----------------+----------------+ |
| Receipt of Bundle 'X' (8 Bytes, if present)
+ +----------------+
| | Time of |
+----------------+----------------+----------------+ |
| Forwarding of Bundle 'X' (8 bytes, if present) |
+ +-----------------
| | Copy of X's |
+--------------------------------------------------+ |
| Source Tuple (variable) |
+-------------------------------------------------------------------+
K. Scott and S. Burleigh Expires - August 2003 [Page 13]
Internet Draft Bundle Protocol Specification March 2003
Bundle Payload Header
+----------------+----------------+----------------+----------------+
| Next Header | Length of bundle payload (4 bytes)
+----------------+----------------+----------------+----------------+
| |
+----------------+ |
| Bundle Payload (variable) |
| |
/ /
/ /
| |
+-------------------------------------------------------------------+
Bundle Fragment Header
+----------------+----------------+----------------+----------------+
| Next Header | Length of original bundle payload (4 bytes)
+----------------+----------------+----------------+----------------+
| Offset of this bundle fragment (4 bytes)
+----------------+--------------------------------------------------+
|
-----------------+
Subsequent Bundle Payload Header
+----------------+----------------+----------------+----------------+
| Next Header | Length of subsequent bundle payload (4 bytes)
+----------------+----------------+----------------+----------------+
| Creation Timestamp (8 bytes) |
+----------------+ |
| |
+ +--------------------------------------------------+
| | |
+----------------+ |
| Bundle Payload (variable) +
+ |
/ /
/ /
| |
+-------------------------------------------------------------------+
K. Scott and S. Burleigh Expires - August 2003 [Page 14]
Internet Draft Bundle Protocol Specification March 2003
16-bit Extended Offset Header
+----------------+----------------+----------------+----------------+
| Next Header | Destination | Source
+----------------+----------------+----------------+----------------+
| Reply-To | Cur. Custodian
+----------------+----------------+----------------+----------------+
|
+----------------+
Authentication
+----------------+----------------+----------------+----------------+
| Next Header | Length | Auth. information (variable)
+----------------+----------------+----------------+----------------+
Figure 2: Bundle header formats.
3.1 General Bundle Header Format
In most cases a bundle header begins with a one-octet next header
type field. This field identifies the type of the header following
the one the field is part of. The exception to this rule is the
primary bundle header, which must appear before any other bundle sub-
headers. The primary bundle header begins with a 1-byte version
field that identifies the version of the bundling protocols used to
create the current bundle, followed by a 1-byte next header type
field.
All multi-byte fields are transmitted in network byte order. Note
that the class of service in the primary bundle header is not a
single two-byte field but instead the functional concatenation of two
one-byte fields.
3.2 Tuples
Communicating entities in the DTN are referred to via name tuples. A
name tuple contains a routing part that identifies the entity's DTN
region, and an administrative part that identifies the entity within
that region. The routing part of a DTN name tuple must be globally
parsable throughout the DTN. The administrative part is opaque
outside of the destination region, but must be parsable anywhere in
the destination region. Note that the administrative part of a DTN
name tuple may include information about a specific machine as well
as a specific application or process on that machine.
The representation of a tuple contains a 1-byte length subfield
indicating the total length of the tuple, including the length
subfield, followed by the routing and administrative parts of the
K. Scott and S. Burleigh Expires - August 2003 [Page 15]
Internet Draft Bundle Protocol Specification March 2003
tuple. Note that in Figure 1 above, the length fields of tuples are
explicitly shown.
3.3 Primary and Variable-Length Immutable Portion Headers
The primary bundle header together with the variable length Immutable
Portion header contains the basic information needed to route bundles
to their destinations. The main goal in separating the primary
bundle header from the variable length Immutable Portion header is to
make processing simpler.
Section 3.3.1 describes the fields of the primary bundle header, and
section 3.3.2 the fields of the variable-length Immutable Portion
header. The processing rules for the primary and variable-length
Immutable Portion headers are described in sections 4.2 (Bundle
Routing) and 4.3 (Current Custodian Header Fields).
3.3.1 Primary Bundle Header
The field of the primary bundle header are:
Version. A 1-byte field indicating the version of the bundling
protocol that generated this header.
Next Header Type. The Next Header Type field is a 1-byte field
that indicates the type of the header that immediately follows
this one. Header types are listed in Table 1 above.
Destination Tuple Offset. This 1-byte field contains the offset of
the beginning of the destination name tuple, in bytes, from
the beginning of the primary bundle header. The format of a
tuple is described in section 3.3.2.1.
Source Tuple Offset. A 1-byte field containing the offset of the
beginning of the source name tuple, in bytes, from the
beginning of the primary bundle header. If the source and
destination tuples are the same, then the source tuple offset
may equal the destination tuple offset. In this case the
length of the source tuple in the VLIP header (described
below) will be 1 (i.e. the length will include only the 1-byte
length field).
Reply-To Tuple Offset. A 1-byte field containing the offset of the
beginning of the reply-to name tuple, in bytes, from the
beginning of the primary bundle header. Note that if the
reply-to tuple is the same as the source tuple (that is, the
source wants replies sent to it), then the reply-to offset may
be the same as the source offset. In this case the length of
the reply-to tuple in the VLIP header (described below) will
K. Scott and S. Burleigh Expires - August 2003 [Page 16]
Internet Draft Bundle Protocol Specification March 2003
be 1 (i.e. the length will include only the 1-byte length and
no tuple).
Current custodian Tuple Offset. A 1-byte field containing the offset
of the beginning of the current custodian name tuple, in
bytes, from the beginning of the primary bundle header.
Bundles requiring custodial delivery must contain a current
custodian header, and the current custodian tuple offset
points to the current custodian tuple in that header, even if
the current custodian is the source.
Class of Service. The class of service is the concatenation of two 1-
byte fields that contains a number of class-of-service related
parameters and flags. The COS consists of a 1-bit custody
switch followed by four (4) bits of priority, three (3) bits
of delivery record request flags, and an 8-bit 'authentication
present & type' field. If the custody bit is 1 then the
sender requests custodial transfer of the bundle. The four-
bit priority field indicates the bundle's priority, with
higher values being of higher priority. The priorities are
strict in that all bundles with higher priorities should be
transmitted before any bundles of lower priorities. The
interpretation of the delivery record request flags is as
follows.
Table 2: Delivery Record Request Flag Meanings
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 000 | No delivery records requested. |
+---------+--------------------------------------------+
| 001 | Request custody transfer reporting |
+---------+--------------------------------------------+
| 010 | Request reporting of bundle reception. |
+---------+--------------------------------------------+
| 100 | Request end-to-end return receipt. |
+---------+--------------------------------------------+
The Authentication Present (&Type) field indicates whether or not
bundle authentication is present and, if so, the authentication type.
The values for this field are:
K. Scott and S. Burleigh Expires - August 2003 [Page 17]
Internet Draft Bundle Protocol Specification March 2003
Table 3: Authentication Values in the Primary Bundle Header
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x00 | No bundle authentication present. |
+---------+--------------------------------------------+
| 0x01 | Authentication with DSA. |
+---------+--------------------------------------------+
| 0x02 | Authentication with DES-MAC |
+---------+--------------------------------------------+
| 0x03 | Authentication with other |
+---------+--------------------------------------------+
| All | Reserved. |
| Others | |
+---------+--------------------------------------------+
Creation Timestamp. The creation timestamp is an 8-byte field
containing the time the bundle was first accepted for
transmission by the source bundle agent, formatted as an NTP
timestamp.
Expiration Time. The four-byte expiration time field indicates the
time at which the bundle's data will no longer be useful,
encoded as the number of seconds past the creation timestamp.
When the current time is greater than the creation timestamp
plus the expiration time, bundles may be discarded.
The reason that the creation timestamp has higher granularity than
the expiration time is because the creation timestamp together with
the source tuple make up the bundle identifier, which must be unique
to every bundle in the system.
3.3.2 Variable Length Immutable Portion (VLIP) Header
The variable length Immutable Portion header follows the primary
bundle header if all of the source, destination, reply-to, and
current custodian offsets can be accommodated by the primary bundle
header's one-byte offset fields. If any of the offsets cannot be
accommodated by the primary bundle header's 1-byte offset fields,
then a 16-bit Extended Offset Header will separate the primary bundle
header from the VLIP. If the 16-bit Extended Offset Header is
present, the source, destination, reply-to, and current custodian
offsets in the primary bundle header must all be zero.
The fields of the variable length immutable portion header are:
K. Scott and S. Burleigh Expires - August 2003 [Page 18]
Internet Draft Bundle Protocol Specification March 2003
Next Header Type. The Next Header Type field is a 1-byte field
that indicates the type of the header that immediately follows
this one. Header types are listed in Table 1 above.
Total Length. A 1-byte field indicating the total length, in bytes,
of the Variable Length Immutable Portion header, including the
next header type field. If the sum of the dest, source, and
reply-to tuples is too long for the total length field of the
variable-length Immutable Portion header then the tuples are
split into multiple VLIPHes. In this case a 16-bit extended
offset header will be required after the primary bundle header
to convey the offsets of the various tuples.
Destination Tuple. The destination tuple indicates the intended
recipient(s) of the bundle. The format of a tuple is described
in section 3.3.2.1.
Source Tuple. The source tuple indicates the sender of the bundle.
The format of a tuple is described in section 3.3.2.1.
Reply-To Tuple. The reply-to tuple identifies the communicating
entity that is to receive bundle status reports associated
with the current bundle. Messages that are sent to the reply-
to tuple include any bundle status reports requested in this
bundle's class of service field and any end-to-end error
messages associated with the bundle. The format of a tuple is
described in section 3.3.2.1.
The combination of the source tuple and the creation timestamp
constitute the bundle identifier, or bundleID. BundleIDs are used by
the network to differentiate bundles, and must therefore be unique
throughout a DTN. Thus a source may not send two bundles with the
same creation timestamp.
3.4 Current Custodian Header
Custody transfer provides a means of reliable bundle transfer. The
rationale behind custody transfers is discussed in detail in [2].
The rules for processing custodial bundles are described in section
4.5 below.
The fields of the current custodian header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Current Custodian Tuple. The DTN name tuple of the bundle agent
that is the current custodian of the bundle.
K. Scott and S. Burleigh Expires - August 2003 [Page 19]
Internet Draft Bundle Protocol Specification March 2003
3.5 Bundle Status Report Header
This section describes the fields in a bundle status report header.
Rules for processing delivery record requests are described in
section 4.3.
The fields in a bundle status report header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Length. A 1-byte field indicating the total length, in bytes, of the
Bundle Status Report Header, including the next header type
field.
Status Flags. A 1-byte field containing the following flags:
Table 4: Status Flags for Bundle Status Report Headers
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0x01 | Reporting node correctly received bundle. |
+---------+--------------------------------------------+
| 0x02 | Reporting node took custody of bundle. |
+---------+--------------------------------------------+
| 0x04 | Reporting node has forwarded the bundle. |
+---------+--------------------------------------------+
| 0x08 | Reserved for future use.
+---------+--------------------------------------------+
| 0x10 | Time of receipt (TOR) field present. |
+---------+--------------------------------------------+
| 0x20 | Time of forward (TOR) field present. |
+---------+--------------------------------------------+
| 0x40 | Report is for a bundle fragment; fragment |
| | offset and length fields are present. |
+---------+--------------------------------------------+
| 0x80 | Reserved for future use. |
+---------+--------------------------------------------+
Send Timestamp For Reported Bundle. A copy of the send timestamp of
the bundle that caused the status report to be generated.
Time of Receipt (if present). If the TOR present bit is set in the
status flags, then a timestamp indicating the time at which
K. Scott and S. Burleigh Expires - August 2003 [Page 20]
Internet Draft Bundle Protocol Specification March 2003
the bundle was received by the reporting node is included
here. The timestamp is 8 bytes long, formatted as an NTP
timestamp.
Time of Forward (if present). If the TOF present bit is set in the
status flags, then a timestamp indicating the time at which
the bundle was first forwarded by the reporting node is
included here. The timestamp is 8 bytes long, formatted as an
NTP timestamp.
Reported Bundle's Source Tuple. The source tuple of the bundle that
caused the status report to be generated.
The combination of the reported bundle's send timestamp and source
tuple constitute the bundle identifier. This uniquely identifies the
bundle to the reportee.
Discussion of delivery record requests and bundle status reports
appears in section 4.3 below.
3.6 Bundle Payload Header
The fields of the bundle payload header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Length. A 4-byte field indicating the total length, in bytes, of the
Bundle Payload (data-carrying portion of the bundle). This
length does NOT include the lengths of the header elements of
this bundle payload header.
Payload. The bundle payload. This is the application data.
3.7 Subsequent Bundle Payload Header
It may be desirable to combine several payloads to the same
destination, provided that the information in their primary,
variable-length immutable portion, current custodian, and
authentication headers are compatible. The subsequent bundle payload
header provides a mechanism to include additional bundle payloads
after the primary payload.
To be compatible, the following must be true of all bundles combined
under a single primary bundle header:
o They all have the same version, source, destination, reply-to (if
any), and current custodian (if any).
o Their 'custody required' bits must be the same.
K. Scott and S. Burleigh Expires - August 2003 [Page 21]
Internet Draft Bundle Protocol Specification March 2003
o Their priorities must be the same.
o Compatibility of various authentication methods is currently
undefined. Bundles that are not using authentication (i.e. the
"Authentication Present & Type" field in their primary bundle
headers are all 0x00) are compatible.
o The difference between the maximum and minimum expiration times
(in absolute seconds) must be less than a TBD value.
If multiple compatible bundles are combined under a single primary
bundle header, a single expiration time must be chosen to cover them
all. In this case, the expiration time in the primary bundle header
is set to the maximum of the expiration times of the constituent
bundle payloads. Note that because the expiration time is expressed
as a delta from the send timestamp, the various expiration times must
be added to the 'seconds' portions of their send timestamps. This
yields a list of bundle expiration times in absolute seconds.
3.7.1 The fields of the Subsequent bundle payload header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Length. A 4-byte field indicating the total length, in bytes, of the
Bundle Payload (data-carrying portion of the bundle). This
length does NOT include the lengths of the header elements of
this bundle payload header.
Creation Timestamp. The creation timestamp of this payload, an 8-
byte object formatted as an NTP timestamp. This is necessary
because the combination of the creation timestamp and the
source tuple uniquely identify a bundle.
Payload. The bundle payload. This is the user data.
3.8 Authentication Header
The fields of the authentication header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Length. The length of the authentication header depends on the
algorithm used, but can be determined from the algorithm type.
Authentication. Authentication is achieved by the source generating
a hash over the immutable portion header and the immutable
payload then running the hash through a signature algorithm û
K. Scott and S. Burleigh Expires - August 2003 [Page 22]
Internet Draft Bundle Protocol Specification March 2003
e.g., sign using sender's private key. Authentication when
the bundle agent is physically separated from the bundle
applications using it is an open question
3.9 16-bit Extended Offset Header
The 16-bit extended offset header immediately follows the primary
bundle header whenever any of the destination, source, or reply-to
tuple offsets are greater than the 1-byte offset fields in the
primary bundle header allow (i.e. 255). Recall that the tuple
offsets are defined as the indices of the starts of the various
tuples relative to the beginning of the primary bundle header.
The fields of the 16-bit Extended Offset Header are:
Next Header Type. The Next Header Type field is a 1-byte field that
indicates the type of the header that immediately follows this
one. Header types are listed in Table 1 above.
Destination Tuple Offset. The byte offset of the beginning of the
destination name tuple, in bytes, from the beginning of the
primary bundle header. The format of a tuple is described in
section 3.3.2.1. This is a 16-bit field.
Source Tuple Offset. The byte offset of the beginning of the
source name tuple, in bytes, from the beginning of the primary
bundle header. This is a 16-bit field.
Reply-To Tuple Offset. The byte offset of the beginning of the
reply-to name tuple, in bytes, from the beginning of the
primary bundle header. This is a 16-bit field. Note that if
the reply-to tuple is the same as the source tuple (that is,
the source wants replies sent to it), then the reply-to offset
may be the same as the source offset. In this case the length
of the reply-to tuple in the variable-length Immutable Portion
header (described 3.3.2.1) will be 1 (i.e. the length will
include only the 1-byte length and no tuple).
3.10 Rules Governing the Appearance and Order of Headers
The following rules apply to the order and presence of DTN headers:
o The primary bundle header must appear first, followed by either
the 16-bit extended offset header (if present) or the variable
length Immutable Portion header.
o The only headers allowed after a bundle payload header are
subsequent bundle payload headers and (possibly) their
associated authentication headers. In cases where a subsequent
bundle payload requires authorization, the payload's
authorization header will immediately precede the payload. A
K. Scott and S. Burleigh Expires - August 2003 [Page 23]
Internet Draft Bundle Protocol Specification March 2003
bundle payload header must appear before any subsequent bundle
payload headers.
o Rules regarding the order of appearance of other header types
have not yet been established, though we expect to formulate
such rules soon.
4. Bundle Processing
There are currently no provisions for multipoint delivery of bundles.
4.1 Bundles received from applications via the API
Step 1: Permissions checking. Bundle agents MAY enforce policy that
restricts the permissions of applications. Such policy could,
for example, limit the rate at which particular applications are
allowed to inject traffic, or limit the CoS options that
particular applications are allowed to use. Bundles that do not
meet the policy criteria MAY be silently dropped by the bundle
agent, though some indication SHOULD be provided to the
application via the API.
Step 2: If the bundle is accepted for transmission, then processing
proceeds from Step 3 of section 4.2.
4.2 Bundles received from other bundle agents
The steps in processing bundles received from other bundle agents
are:
Step 1: Bundle Authentication: The bundle must first be
authenticated as described in section 3.13 of [2]. The purpose
of this authentication is to protect the bundle transmission
infrastructure, not to provide security services to the bundle
per se. If the authentication fails then the bundle is silently
discarded.
Step 2: Generate a bundle status report, if requested. If the bundle
class of service requests that a bundle status report be
generated when the bundle is received, a bundle status report
SHOULD be generated. For bundles requesting only bundle receipt
notification, the bundle status report can be immediately queued
for transmission to the bundle's reply-to address. If the bundle
requests custody transfer reporting, a single bundle status
report MAY be generated after the agent decides whether or not to
take custody of the bundle.
K. Scott and S. Burleigh Expires - August 2003 [Page 24]
Internet Draft Bundle Protocol Specification March 2003
Step 3: Local bundle delivery processing. The steps described here
are carried out ONLY if the bundle's destination tuple matches
one of the bundle agent's interfaces.
Step 3a: Reassembly. If the received bundle contains a fragmentation
header, it MUST be combined with the rest of the fragments that
make up the entire original bundle before the content can be
further processed.
Step 3b: Processing custody acknowledgements. A custody
acknowledgement is a bundle status report directed to the current
agent indicating that a downstream agent has taken custody of the
bundle. Custody acknowledgements may be for entire bundles or
for fragments of bundles. This bundle agent must examine the
bundle status report and the saved state associated with the
bundle to determine how much of the bundle is acknowledged by the
report. If the report covers only a portion of a bundle, the
bundle agent SHOULD mark that piece of the bundle as being
acknowledged. The bundle agent SHOULD maintain the
retransmission timer for any pieces of the bundle NOT covered by
the status report. When status reports have been received taking
custody of the entire bundle, the bundle agent SHOULD stop any
retransmission timers and free all retransmission resources
associated with the bundle.
Step 3c: If an application has registered with the bundle agent with
the bundle's destination communication endpoint ID and is in a
period of passive bundle reception, the bundle SHALL be delivered
to the application.
Step 3d: If the bundle class of service requests that and end-to-end
return receipt be sent, such a receipt SHOULD be generated once
the bundle has been delivered to the application. Note that this
return receipt only states that the bundle has been delivered to
the application, not that the application has processed the
content.
Step 4: Bundle forwarding.
Step 4a: Test for bundle expiration. If the bundle has expired then
it SHOULD be silently discarded. A bundle has expired if the
current time is greater than the bundle's creation time plus its
lifetime as specified in the primary bundle header.
Step 4b: Custody transfer processing. If the bundle class of service
requests custodial transfer, the bundle agent has to decide
whether or not to take custody of the bundle. The decision as to
whether or not to take custody of a bundle may involve both
resource and policy considerations. If the agent elects to NOT
K. Scott and S. Burleigh Expires - August 2003 [Page 25]
Internet Draft Bundle Protocol Specification March 2003
take custody of the bundle, it SHOULD forward the bundle as if it
did not request custodial service. In particular, if the bundle
agent does not take custody of the bundle then it MUST NOT modify
the bundle's current custodian header.
If the bundle requests custodial transfer and the agent elects to
take custody of the bundle, then it MUST take the following
actions:
o If the bundle requests custody transfer reporting, a bundle
status report indicating that the current agent is taking
custody of the bundle SHOULD be generated. This report MAY
be combined with a record of the bundle's reception, if
such a report was not already generated and queued for
transmission above. It is important to note that this
bundle status report is addressed to the bundle's 'REPLY-
TO' address; the bundle status report effecting the
custodial acknowledgement is handled below.
If the received bundle is a fragment (i.e. it contains a
fragment header) the bundle status report MUST contain the
Fragment flag and the fragment offset and fragment length
fields.
o The agent generates a bundle status report for the bundle,
destined for the bundle's current custodian. This is the
custodial acknowledgment that allows the previous custodian
to release resources associated with the bundle. The
bundle status report MUST contain the status flag
indicating that the bundle agent has taken custody of the
bundle. The status report MUST be sent with the CoS flag
requesting custodial delivery set.
If the received bundle is a fragment (i.e. it contains a
fragment header) the bundle status report MUST contain the
Fragment flag and the fragment offset and fragment length
fields.
o The bundle agent then modifies the bundle's current
custodian header, setting itself as the bundle's current
custodian.
o The bundle agent MUST keep a copy of the bundle, and this
copy SHOULD be in persistent storage if at all possible.
o The bundle agent MUST set a retransmission timer so that
the bundle will be retransmitted if a custody
acknowledgement is not received. The value of the
retransmission timer is up to the bundle agent.
K. Scott and S. Burleigh Expires - August 2003 [Page 26]
Internet Draft Bundle Protocol Specification March 2003
o After the above, the normal bundle forwarding processing is
resumed.
Step 4c: Determine next hop for bundle.
o If the bundle agent does NOT have an interface in the
bundle's destination region, then it MUST determine the
bundle's next hop using ONLY the bundle's destination
region. The information in the bundle's endpoint
identifier is NOT used at this time. In this case, the
agent consults a region routing table to determine the next
hop bundle agent to which the bundle will be transmitted.
The agent then schedules the bundle for transmission.
o If the bundle agent contains an interface in the bundle's
destination region, then the bundle's next hop depends on
whether the region is a DIRECT or an INDIRECT region.
For DIRECT regions, the bundle can be transmitted directly
to the communications entity specified in the
administrative part of the bundle's destination tuple.
For INDIRECT regions, the bundle agent consults a separate
routing table to determine the 'care-of' host to which the
bundle should be transmitted.
Step 5: Forward the bundle. At this point the bundle agent can
schedule the bundle for transmission via an appropriate
convergence layer.
4.3 Bundle Fragmentation and Reassembly
It may be necessary for bundle agents to break bundles into smaller
units in order to forward them. This might be the case, for example,
if the next hop destination is available only via intermittent
contacts, and no upcoming contact is long enough to support sending
the entire bundle. The process of breaking bundles into smaller
units is called fragmentation. Reassembly of bundle fragments occurs
at the ultimate destination.
4.3.1 Bundle Fragmentation
Bundle fragments are themselves bundles, and are individually
routable. When breaking a bundle into fragments, the following WILL
be true:
o All fragments will contain the same headers as the original
bundle. In particular, the creation timestamps of all bundle
K. Scott and S. Burleigh Expires - August 2003 [Page 27]
Internet Draft Bundle Protocol Specification March 2003
fragments MUST be the same as that of the original bundle.
Recall that the pair (source tuple, creation timestamp) is
unique for each bundle. This allows the destination to
associate the bundle fragments with a single reconstructed
bundle. The payload headers of the fragments MUST be modified
to reflect the actual lengths of the fragments.
o In addition to the original headers, each fragment MUST contain
a fragment header identifying the original bundle's length and
the fragment's position and length within the original bundle.
Note that if a bundle fragment is further fragmented, the
original bundle length from the fragment header is used in
subsequent fragments. That is, there is only one 'level' of
fragmentation (as in IP fragmentation).
After fragmentation, the fragments are individually forwarded.
4.3.2 Bundle Reassembly
Each bundle fragment contains a fragment header. The fragment header
contains the original bundle's length as well as the fragment's
offset within the original bundle. The fragment's bundle payload
header contains the length of the current fragment. This information
is enough for the receiving bundle agent to reconstruct the original
bundle from the fragments.
Security Considerations
Section 3.13 of [2] describes the general methods for protecting the
DTN infrastructure. In summary, bundle applications must present
credentials to bundle agents before the agents will accept bundles
from the applications. Agents sign all bundles they transmit, and
receiving bundle agents discard any bundles whose signatures are not
valid.
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, March 2003.
[3] F. Warthman, "Delay-Tolerant Networks (DTNs): A Tutorial",
Wartham Associates, Available from http://www.dtnrg.org
K. Scott and S. Burleigh Expires - August 2003 [Page 28]
Internet Draft Bundle Protocol Specification March 2003
Acknowledgements
The authors gratefully acknowledge the contributions of Dr. Vint Cerf
of Worldcom, Dr. Kevin Fall of Intel Corporation, Adrian Hooke and
Leigh Torgerson of the Jet Propulsion Laboratory, and Howard Weiss of
SPARTA, Inc.
Author's Addresses
Dr. Keith L. Scott Scott C. Burleigh
The MITRE Corporation Jet Propulsion Laboratory
1820 Dolley Madison Blvd. 4800 Oak Grove Drive
M/S H300 M/S: 179-206
McLean, VA 22102 Pasadena, CA 91109-8099
Telephone +1 (703) 883-6547 Telephone +1 (818) 393-3353
FAX +1 (703) 883-7142 FAX +1 (818) 354-1075
Email kscott@mitre.org Email Scott.Burleigh@jpl.nasa.gov
Intellectual Property Notices
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 implementors or users of this
specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its
attention any copyrights, patents or patent applications, or
other proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
K. Scott and S. Burleigh Expires - August 2003 [Page 29]
Internet Draft Bundle Protocol Specification March 2003
Copyright
"Copyright (C) The Internet Society (2003). All Rights
Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or
otherwise explain it or assist in its implmentation may be
prepared, copied, published and distributed, in whole or in
part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may
not be modified in any way, such as by removing the copyright
notice or references to the Internet Society or other Internet
organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or
assigns.
This document and the information contained herein is provided
on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
K. Scott and S. Burleigh Expires - August 2003 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-23 23:29:29 |