< draft-ietf-dtn-bpbis-13.txt   draft-ietf-dtn-bpbis-14.txt >
Delay-Tolerant Networking Working Group S. Burleigh Delay-Tolerant Networking Working Group S. Burleigh
Internet Draft JPL, Calif. Inst. Of Technology Internet Draft JPL, Calif. Inst. Of Technology
Intended status: Standards Track K. Fall Obsoletes: 5050 and 6255 (if approved) K. Fall
Expires: October 2019 Nefeli Networks, Inc. Intended status: Standards Track Roland Computing Services
E. Birrane Expires: February 5, 2020 E. Birrane
APL, Johns Hopkins University APL, Johns Hopkins University
April 23, 2019 August 4, 2019
Bundle Protocol Version 7 Bundle Protocol Version 7
draft-ietf-dtn-bpbis-13.txt draft-ietf-dtn-bpbis-14.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 25, 2019. This Internet-Draft will expire on February 5, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Abstract Abstract
This Internet Draft presents a specification for Bundle Protocol, This Internet Draft presents a specification for Bundle Protocol,
adapted from the experimental Bundle Protocol specification adapted from the experimental Bundle Protocol specification
developed by the Delay-Tolerant Networking Research group of the developed by the Delay-Tolerant Networking Research group of the
Internet Research Task Force and documented in RFC 5050. Internet Research Task Force and documented in RFC 5050.
It obsoletes RFC 5050 and RFC 6255.
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Conventions used in this document..............................5 2. Conventions used in this document..............................5
3. Service Description............................................5 3. Service Description............................................6
3.1. Definitions...............................................5 3.1. Definitions...............................................6
3.2. Discussion of BP concepts.................................9 3.2. Discussion of BP concepts.................................9
3.3. Services Offered by Bundle Protocol Agents...............12 3.3. Services Offered by Bundle Protocol Agents...............12
4. Bundle Format.................................................12 4. Bundle Format.................................................13
4.1. BP Fundamental Data Structures...........................13 4.1. BP Fundamental Data Structures...........................13
4.1.1. CRC Type............................................13 4.1.1. CRC Type............................................13
4.1.2. CRC.................................................13 4.1.2. CRC.................................................14
4.1.3. Bundle Processing Control Flags.....................13 4.1.3. Bundle Processing Control Flags.....................14
4.1.4. Block Processing Control Flags......................15 4.1.4. Block Processing Control Flags......................15
4.1.5. Identifiers.........................................16 4.1.5. Identifiers.........................................16
4.1.5.1. Endpoint ID....................................16 4.1.5.1. Endpoint ID....................................16
4.1.5.2. Node ID........................................17 4.1.5.2. Node ID........................................17
4.1.6. DTN Time............................................17 4.1.6. DTN Time............................................18
4.1.7. Creation Timestamp..................................17 4.1.7. Creation Timestamp..................................20
4.1.8. Block-type-specific Data............................18 4.1.8. Block-type-specific Data............................20
4.2. Bundle Representation....................................18 4.2. Bundle Representation....................................20
4.2.1. Bundle..............................................18 4.2.1. Bundle..............................................20
4.2.2. Primary Bundle Block................................18 4.2.2. Primary Bundle Block................................21
4.2.3. Canonical Bundle Block Format.......................20 4.2.3. Canonical Bundle Block Format.......................23
4.3. Extension Blocks.........................................21 4.3. Extension Blocks.........................................23
4.3.1. Previous Node.......................................22 4.3.1. Previous Node.......................................24
4.3.2. Bundle Age..........................................22 4.3.2. Bundle Age..........................................25
4.3.3. Hop Count...........................................23 4.3.3. Hop Count...........................................25
5. Bundle Processing.............................................23 5. Bundle Processing.............................................26
5.1. Generation of Administrative Records.....................23 5.1. Generation of Administrative Records.....................26
5.2. Bundle Transmission......................................24 5.2. Bundle Transmission......................................27
5.3. Bundle Dispatching.......................................24 5.3. Bundle Dispatching.......................................27
5.4. Bundle Forwarding........................................25 5.4. Bundle Forwarding........................................27
5.4.1. Forwarding Contraindicated..........................26 5.4.1. Forwarding Contraindicated..........................29
5.4.2. Forwarding Failed...................................27 5.4.2. Forwarding Failed...................................29
5.5. Bundle Expiration........................................27 5.5. Bundle Expiration........................................30
5.6. Bundle Reception.........................................27 5.6. Bundle Reception.........................................30
5.7. Local Bundle Delivery....................................28 5.7. Local Bundle Delivery....................................31
5.8. Bundle Fragmentation.....................................29 5.8. Bundle Fragmentation.....................................32
5.9. Application Data Unit Reassembly.........................30 5.9. Application Data Unit Reassembly.........................33
5.10. Bundle Deletion.........................................31 5.10. Bundle Deletion.........................................34
5.11. Discarding a Bundle.....................................31 5.11. Discarding a Bundle.....................................34
5.12. Canceling a Transmission................................31 5.12. Canceling a Transmission................................34
6. Administrative Record Processing..............................31 6. Administrative Record Processing..............................34
6.1. Administrative Records...................................31 6.1. Administrative Records...................................34
6.1.1. Bundle Status Reports...............................32 6.1.1. Bundle Status Reports...............................35
6.2. Generation of Administrative Records.....................35 6.2. Generation of Administrative Records.....................38
7. Services Required of the Convergence Layer....................35 7. Services Required of the Convergence Layer....................38
7.1. The Convergence Layer....................................35 7.1. The Convergence Layer....................................38
7.2. Summary of Convergence Layer Services....................35 7.2. Summary of Convergence Layer Services....................38
8. Implementation Status.........................................36 8. Implementation Status.........................................39
9. Security Considerations.......................................37 9. Security Considerations.......................................40
10. IANA Considerations..........................................39 10. IANA Considerations..........................................42
11. References...................................................40 10.1. Bundle Block Types......................................42
11.1. Normative References....................................40 10.2. Primary Bundle Protocol Version.........................43
11.2. Informative References..................................40 10.3. Bundle Processing Control Flags.........................44
12. Acknowledgments..............................................41 10.4. Block Processing Control Flags..........................45
13. Significant Changes from RFC 5050............................41 10.5. Bundle Status Report Reason Codes.......................46
Appendix A. For More Information.................................42 10.6. URI scheme types........................................47
Appendix B. CDDL expression......................................43 10.7. New URI scheme "dtn"....................................48
11. References...................................................50
11.1. Normative References....................................50
11.2. Informative References..................................51
12. Acknowledgments..............................................51
13. Significant Changes from RFC 5050............................52
Appendix A. For More Information.................................53
Appendix B. CDDL expression......................................54
1. Introduction 1. Introduction
Since the publication of the Bundle Protocol Specification Since the publication of the Bundle Protocol Specification
(Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN) (Experimental RFC 5050) in 2007, the Delay-Tolerant Networking (DTN)
Bundle Protocol has been implemented in multiple programming Bundle Protocol has been implemented in multiple programming
languages and deployed to a wide variety of computing platforms. languages and deployed to a wide variety of computing platforms.
This implementation and deployment experience has identified This implementation and deployment experience has identified
opportunities for making the protocol simpler, more capable, and opportunities for making the protocol simpler, more capable, and
easier to use. The present document, standardizing the Bundle easier to use. The present document, standardizing the Bundle
Protocol (BP), is adapted from RFC 5050 in that context. Protocol (BP), is adapted from RFC 5050 in that context and
obsoletes RFC 5050 for that reason. Significant changes from the
Bundle Protocol specification defined in RFC 5050 are listed in
section 13. In addition, those registry rules defined for RFC 5050
in RFC 6255 that are relevant to the current document have been
transcribed into section 10, with modifications as necessary;
therefore the rules defined in RFC 6255 are now relevant only to RFC
5050, so in obsoleting RFC 5050 we also obsolete RFC 6255.
This document describes version 7 of BP. This document describes version 7 of BP.
Delay Tolerant Networking is a network architecture providing Delay Tolerant Networking is a network architecture providing
communications in and/or through highly stressed environments. communications in and/or through highly stressed environments.
Stressed networking environments include those with intermittent Stressed networking environments include those with intermittent
connectivity, large and/or variable delays, and high bit error connectivity, large and/or variable delays, and high bit error
rates. To provide its services, BP may be viewed as sitting at the rates. To provide its services, BP may be viewed as sitting at the
application layer of some number of constituent networks, forming a application layer of some number of constituent networks, forming a
store-carry-forward overlay network. Key capabilities of BP store-carry-forward overlay network. Key capabilities of BP
skipping to change at page 5, line 24 skipping to change at page 5, line 45
bases of bundle nodes. bases of bundle nodes.
. The mechanisms for securing bundles en route. . The mechanisms for securing bundles en route.
. The mechanisms for managing bundle nodes. . The mechanisms for managing bundle nodes.
Note that implementations of the specification presented in this Note that implementations of the specification presented in this
document will not be interoperable with implementations of RFC 5050. document will not be interoperable with implementations of RFC 5050.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC-2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
In this document, these words will appear with that interpretation capitals, as shown here.
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Service Description 3. Service Description
3.1. Definitions 3.1. Definitions
Bundle - A bundle is a protocol data unit of BP, so named because Bundle - A bundle is a protocol data unit of BP, so named because
negotiation of the parameters of a data exchange may be impractical negotiation of the parameters of a data exchange may be impractical
in a delay-tolerant network: it is often better practice to "bundle" in a delay-tolerant network: it is often better practice to "bundle"
with a unit of data all metadata that might be needed in order to with a unit of application data all metadata that might be needed in
make the data immediately usable when delivered to applications. order to make the data immediately usable when delivered to the
Each bundle comprises a sequence of two or more "blocks" of protocol application. Each bundle comprises a sequence of two or more
data, which serve various purposes. "blocks" of protocol data, which serve various purposes.
Block - A bundle protocol block is one of the protocol data Block - A bundle protocol block is one of the protocol data
structures that together constitute a well-formed bundle. structures that together constitute a well-formed bundle.
Application Data Unit (ADU) - An application data unit is the unit
of data whose conveyance to the bundle's destination is the purpose
for the transmission of some bundle that is not a fragment (as
defined below).
Bundle payload - A bundle payload (or simply "payload") is the Bundle payload - A bundle payload (or simply "payload") is the
application data whose conveyance to the bundle's destination is the content of the bundle's payload block. The terms "bundle content",
purpose for the transmission of a given bundle; it is the content of "bundle payload", and "payload" are used interchangeably in this
the bundle's payload block. The terms "bundle content", "bundle document. For a bundle that is not a fragment (as defined below),
payload", and "payload" are used interchangeably in this document. the payload is an application data unit.
Partial payload - A partial payload is a payload that comprises Partial payload - A partial payload is a payload that comprises
either the first N bytes or the last N bytes of some other payload either the first N bytes or the last N bytes of some other payload
of length M, such that 0 < N < M. Note that every partial payload of length M, such that 0 < N < M. Note that every partial payload
is a payload and therefore can be further subdivided into partial is a payload and therefore can be further subdivided into partial
payloads. payloads.
Fragment - A fragment is a bundle whose payload block contains a Fragment - A fragment is a bundle whose payload block contains a
partial payload. partial payload.
skipping to change at page 11, line 18 skipping to change at page 12, line 5
asserted source node ID is the null endpoint ID are termed asserted source node ID is the null endpoint ID are termed
"anonymous" bundles. "anonymous" bundles.
Any number of transmissions may be concurrently undertaken by the Any number of transmissions may be concurrently undertaken by the
bundle protocol agent of a given node. bundle protocol agent of a given node.
When the bundle protocol agent of a node determines that a bundle When the bundle protocol agent of a node determines that a bundle
must be forwarded to a node (either to a node that is a member of must be forwarded to a node (either to a node that is a member of
the bundle's destination endpoint or to some intermediate forwarding the bundle's destination endpoint or to some intermediate forwarding
node) in the course of completing the successful transmission of node) in the course of completing the successful transmission of
that bundle, it invokes the services of one or more CLAs in a that bundle, the bundle protocol agent invokes the services of one
sustained effort to cause a copy of the bundle to be received by or more CLAs in a sustained effort to cause a copy of the bundle to
that node. be received by that node.
Upon reception, the processing of a bundle that has been received by Upon reception, the processing of a bundle that has been received by
a given node depends on whether or not the receiving node is a given node depends on whether or not the receiving node is
registered in the bundle's destination endpoint. If it is, and if registered in the bundle's destination endpoint. If it is, and if
the payload of the bundle is non-fragmentary (possibly as a result the payload of the bundle is non-fragmentary (possibly as a result
of successful payload reassembly from fragmentary payloads, of successful payload reassembly from fragmentary payloads,
including the original payload of the newly received bundle), then including the original payload of the newly received bundle), then
the bundle is normally delivered to the node's application agent the bundle is normally delivered to the node's application agent
subject to the registration characterizing the node's membership in subject to the registration characterizing the node's membership in
the destination endpoint. the destination endpoint.
skipping to change at page 13, line 13 skipping to change at page 13, line 47
specification. specification.
4.1. BP Fundamental Data Structures 4.1. BP Fundamental Data Structures
4.1.1. CRC Type 4.1.1. CRC Type
CRC type is an unsigned integer type code for which the following CRC type is an unsigned integer type code for which the following
values (and no others) are valid: values (and no others) are valid:
. 0 indicates "no CRC is present." . 0 indicates "no CRC is present."
. 1 indicates "a standard X-25 CRC-16 is present." . 1 indicates "a standard X-25 CRC-16 is present." [CRC16]
. 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present." . 2 indicates "a standard CRC32C (Castagnoli) CRC-32 is present."
[CRC32C]
CRC type SHALL be represented as a CBOR unsigned integer. CRC type SHALL be represented as a CBOR unsigned integer.
For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143]. For examples of CRC32C CRCs, see Appendix A.4 of [RFC7143].
4.1.2. CRC 4.1.2. CRC
CRC SHALL be omitted from a block if and only if the block's CRC CRC SHALL be omitted from a block if and only if the block's CRC
type code is zero. type code is zero.
skipping to change at page 14, line 38 skipping to change at page 15, line 29
the control flag values as follows: the control flag values as follows:
. Bit 0 (the high-order bit, 0x8000): reserved. . Bit 0 (the high-order bit, 0x8000): reserved.
. Bit 1 (0x4000): reserved. . Bit 1 (0x4000): reserved.
. Bit 2 (0x2000): reserved. . Bit 2 (0x2000): reserved.
. Bit 3(0x1000): bundle deletion status reports are requested. . Bit 3(0x1000): bundle deletion status reports are requested.
. Bit 4(0x0800): bundle delivery status reports are requested. . Bit 4(0x0800): bundle delivery status reports are requested.
. Bit 5(0x0400): bundle forwarding status reports are requested. . Bit 5(0x0400): bundle forwarding status reports are requested.
. Bit 6(0x0200): reserved. . Bit 6(0x0200): reserved.
. Bit 7(0x0100): bundle reception status reports are requested. . Bit 7(0x0100): bundle reception status reports are requested.
. Bit 8(0x0080): bundle contains a Manifest block. . Bit 8(0x0080): reserved.
. Bit 9(0x0040): status time is requested in all status reports. . Bit 9(0x0040): status time is requested in all status reports.
. Bit 10(0x0020): user application acknowledgement is requested. . Bit 10(0x0020): user application acknowledgement is requested.
. Bit 11(0x0010): reserved. . Bit 11(0x0010): reserved.
. Bit 12(0x0008): reserved. . Bit 12(0x0008): reserved.
. Bit 13(0x0004): bundle must not be fragmented. . Bit 13(0x0004): bundle must not be fragmented.
. Bit 14(0x0002): payload is an administrative record. . Bit 14(0x0002): payload is an administrative record.
. Bit 15 (the low-order bit, 0x0001: bundle is a fragment. . Bit 15 (the low-order bit, 0x0001: bundle is a fragment.
Note: bit 8 is reserved with the intention of using it to indicate
the presence of a Manifest extension block, not yet defined.
4.1.4. Block Processing Control Flags 4.1.4. Block Processing Control Flags
The block processing control flags assert properties of canonical The block processing control flags assert properties of canonical
bundle blocks. They are conveyed in the header of the block to bundle blocks. They are conveyed in the header of the block to
which they pertain. which they pertain.
The following properties are asserted by the block processing The following properties are asserted by the block processing
control flags: control flags:
. This block must be replicated in every fragment. (Boolean) . This block must be replicated in every fragment. (Boolean)
skipping to change at page 17, line 33 skipping to change at page 18, line 19
MAY be used to identify that node. A "node ID" is an EID that MAY be used to identify that node. A "node ID" is an EID that
is used in this way. is used in this way.
. A node's membership in a given singleton endpoint MUST be . A node's membership in a given singleton endpoint MUST be
sustained at least until the nominal operation of the Bundle sustained at least until the nominal operation of the Bundle
Protocol no longer depends on the identification of that node Protocol no longer depends on the identification of that node
using that endpoint's ID. using that endpoint's ID.
4.1.6. DTN Time 4.1.6. DTN Time
A DTN time is an unsigned integer indicating an interval of Unix A DTN time is an unsigned integer indicating an interval of Unix
epoch time that has elapsed since the start of the year 2000 on the epoch time [EPOCH] that has elapsed since the start of the year 2000
Coordinated Universal Time (UTC) scale [UTC], which is Unix epoch on the Coordinated Universal Time (UTC) scale [UTC], which is Unix
timestamp 946684800. (Note that the DTN time that equates to the epoch timestamp 946684800. (Note that the DTN time that equates to
current time as reported by the POSIX time() function can be derived the current time as reported by the UNIX time() function can be
by subtracting 946684800 from that reported time value.) Each DTN derived by subtracting 946684800 from that reported time value.)
time SHALL be represented as a CBOR unsigned integer item. Each DTN time SHALL be represented as a CBOR unsigned integer item.
Note: The choice of Unix epoch time as the scale on which time
values in DTN are expressed may need some explanation.
The computation of time intervals is integral to several DTN
protocol procedures. Inconsistency in the results of these
computations would result in inconsistent performance of those
procedures and would compromise the operation of the protocol.
So the key qualities sought in selecting the time scale to be used
for expressing DTN times were these: (a) the broadest possible
access to the value of the current time on the selected time scale,
enabling all nodes of the network to perform protocol procedures in
the same way using the same information, and (b) ease of time
interval computation.
UTC was an obvious candidate but fell short on both counts. First,
millions of devices can readily query the current UTC time, thanks
to NTP, but spacecraft operating beyond Earth orbit cannot. There
is currently no adaptation of NTP that operates over the long and
variable signal propagation delays between vehicles in deep space.
Moreover, computing the number of actual elapsed seconds between two
UTC times is non-trivial because UTC times include leap seconds. As
an illustration of the issue, consider the passage of UTC and TAI
time at a ground station antenna that began transmitting data at
8Kbps around midnight December 31, 2016 (UTC), when a leap second
was added (*):
UTC TAI Total bytes sent
t1 2016-12-31 23:59:58 2017-01-01 00:00:34 0
t2 2016-12-31 23:59:59 2017-01-01 00:00:35 1000
t3 2016-12-31 23:59:60* 2017-01-01 00:00:36 2000
t4 2017-01-01 00:00:00 2017-01-01 00:00:37 3000
t5 2017-01-01 00:00:01 2017-01-01 00:00:38 4000
Suppose we must compute the volume of data transmitted in the
interval between t1 and t5. If we use TAI time values, the elapsed
time interval is 4 seconds (00:00:38 minus 00:00:34); at 8Kbps, the
computed transmission volume is 4000 bytes, which is correct. If we
instead use UTC time values as stated, without special compensation
for the insertion of the leap second, the elapsed time interval is 3
seconds (00:00:01 minus 23:59:58); the computed transmission volume
is then 3000 bytes, which is incorrect.
TAI, then, would be an ideal time scale for DTN, as the interval in
seconds between two TAI times can be computed by simply subtracting
one from the other; there is no need to consult a table of leap
seconds each time a time interval is computed. Unfortunately the
current value of TAI, as tracked by atomic clocks on Earth and
carefully managed by the International Bureau of Weights and
Measures, is likewise not directly accessible to spacecraft.
Unix epoch time is the next best option. Like TAI, Unix epoch time
is simply a count of seconds elapsed since a standard epoch. Unlike
TAI, the current value of Unix epoch time is provided by virtually
all operating systems on which BP is likely to run.
Implementers of Bundle Protocol need to be aware that the difference
between DTN time and UTC time will increase with the passing years
as additional leap seconds are inserted into UTC. Converting DTN
time to the correct corresponding UTC time, in the event that such
conversion is needed, will require an understanding of the leap
second adjustments made to UTC over time; for software written in C,
the widely supported gmtime() function provides this service.
Implementers also need to be aware that DTN time values conveyed in
CBOR representation in bundles can conceivably exceed (2**32 - 1).
4.1.7. Creation Timestamp 4.1.7. Creation Timestamp
Each creation timestamp SHALL be represented as a CBOR array item Each creation timestamp SHALL be represented as a CBOR array item
comprising a 2-tuple. comprising a 2-tuple.
The first item of the array SHALL be a DTN time. The first item of the array SHALL be a DTN time.
The second item of the array SHALL be the creation timestamp's The second item of the array SHALL be the creation timestamp's
sequence number, represented as a CBOR unsigned integer. sequence number, represented as a CBOR unsigned integer.
skipping to change at page 18, line 46 skipping to change at page 21, line 11
blocks are explicitly stated in block headers as noted below. Block blocks are explicitly stated in block headers as noted below. Block
numbering is unrelated to the order in which blocks are sequenced in numbering is unrelated to the order in which blocks are sequenced in
the bundle. The block number of the payload block is always 1. the bundle. The block number of the payload block is always 1.
4.2.2. Primary Bundle Block 4.2.2. Primary Bundle Block
The primary bundle block contains the basic information needed to The primary bundle block contains the basic information needed to
forward bundles to their destinations. forward bundles to their destinations.
Each primary block SHALL be represented as a CBOR array; the number Each primary block SHALL be represented as a CBOR array; the number
of elements in the array SHALL be 8 (if the bundle is not a fragment of elements in the array SHALL be 9 (if the bundle is not a
and CRC type is zero) or 9 (if the bundle is not a fragment and CRC fragment) or 11 (if the bundle is a fragment).
type is non-zero) or 10 (if the bundle is a fragment and CRC type is
zero) or 11 (if the bundle is a fragment and CRC-type is non-zero). The primary block of each bundle SHALL be immutable. The values of
all fields in the primary block must remain unchanged from the time
the block is created to the time it is delivered.
The fields of the primary bundle block SHALL be as follows, listed The fields of the primary bundle block SHALL be as follows, listed
in the order in which they MUST appear: in the order in which they MUST appear:
Version: An unsigned integer value indicating the version of the Version: An unsigned integer value indicating the version of the
bundle protocol that constructed this block. The present document bundle protocol that constructed this block. The present document
describes version 7 of the bundle protocol. Version number SHALL be describes version 7 of the bundle protocol. Version number SHALL be
represented as a CBOR unsigned integer item. represented as a CBOR unsigned integer item.
Bundle Processing Control Flags: The Bundle Processing Control Flags Bundle Processing Control Flags: The Bundle Processing Control Flags
skipping to change at page 20, line 11 skipping to change at page 22, line 24
bundle creation timestamp serves to identify a single transmission bundle creation timestamp serves to identify a single transmission
request, enabling it to be acknowledged by the receiving application request, enabling it to be acknowledged by the receiving application
(provided the source node ID is not the null endpoint ID). (provided the source node ID is not the null endpoint ID).
Lifetime: The lifetime field is an unsigned integer that indicates Lifetime: The lifetime field is an unsigned integer that indicates
the time at which the bundle's payload will no longer be useful, the time at which the bundle's payload will no longer be useful,
encoded as a number of microseconds past the creation time. (For encoded as a number of microseconds past the creation time. (For
high-rate deployments with very brief disruptions, fine-grained high-rate deployments with very brief disruptions, fine-grained
expression of bundle lifetime may be useful.) When a bundle's age expression of bundle lifetime may be useful.) When a bundle's age
exceeds its lifetime, bundle nodes need no longer retain or forward exceeds its lifetime, bundle nodes need no longer retain or forward
the bundle; the bundle SHOULD be deleted from the network. Bundle the bundle; the bundle SHOULD be deleted from the network. For
lifetime SHALL be represented as a CBOR unsigned integer item. bundles originating at nodes that lack accurate clocks, it is
recommended that bundle age be obtained from the Bundle Age
extension block (see 4.3.2 below) rather than from the difference
between current time and bundle creation time. Bundle lifetime
SHALL be represented as a CBOR unsigned integer item.
Fragment offset: If and only if the Bundle Processing Control Flags Fragment offset: If and only if the Bundle Processing Control Flags
of this Primary block indicate that the bundle is a fragment, of this Primary block indicate that the bundle is a fragment,
fragment offset SHALL be present in the primary block. Fragment fragment offset SHALL be present in the primary block. Fragment
offset SHALL be represented as a CBOR unsigned integer indicating offset SHALL be represented as a CBOR unsigned integer indicating
the offset from the start of the original application data unit at the offset from the start of the original application data unit at
which the bytes comprising the payload of this bundle were located. which the bytes comprising the payload of this bundle were located.
Total Application Data Unit Length: If and only if the Bundle Total Application Data Unit Length: If and only if the Bundle
Processing Control Flags of this Primary block indicate that the Processing Control Flags of this Primary block indicate that the
bundle is a fragment, total application data unit length SHALL be bundle is a fragment, total application data unit length SHALL be
present in the primary block. Total application data unit length present in the primary block. Total application data unit length
SHALL be represented as a CBOR unsigned integer indicating the total SHALL be represented as a CBOR unsigned integer indicating the total
length of the original application data unit of which this bundle's length of the original application data unit of which this bundle's
payload is a part. payload is a part.
CRC: If and only if the value of the CRC type field of this Primary CRC: A CRC SHALL be present in the primary block. The length and
block is non-zero, a CRC SHALL be present in the primary block. The nature of the CRC SHALL be as indicated by the CRC type. The CRC
length and nature of the CRC SHALL be as indicated by the CRC type. SHALL be computed over the concatenation of all bytes (including
The CRC SHALL be computed over the concatenation of all bytes CBOR "break" characters) of the primary block including the CRC
(including CBOR "break" characters) of the primary block including field itself, which for this purpose SHALL be temporarily populated
the CRC field itself, which for this purpose SHALL be temporarily with the value zero.
populated with the value zero.
4.2.3. Canonical Bundle Block Format 4.2.3. Canonical Bundle Block Format
Every block other than the primary block (all such blocks are termed Every block other than the primary block (all such blocks are termed
"canonical" blocks) SHALL be represented as a CBOR array; the number "canonical" blocks) SHALL be represented as a CBOR array; the number
of elements in the array SHALL be 5 (if CRC type is zero) or 6 of elements in the array SHALL be 5 (if CRC type is zero) or 6
(otherwise). (otherwise).
The fields of every canonical block SHALL be as follows, listed in The fields of every canonical block SHALL be as follows, listed in
the order in which they MUST appear: the order in which they MUST appear:
skipping to change at page 21, line 43 skipping to change at page 24, line 13
blocks. Because not all extension blocks are defined in the Bundle blocks. Because not all extension blocks are defined in the Bundle
Protocol specification (the present document), not all nodes Protocol specification (the present document), not all nodes
conforming to this specification will necessarily instantiate Bundle conforming to this specification will necessarily instantiate Bundle
Protocol implementations that include procedures for processing Protocol implementations that include procedures for processing
(that is, recognizing, parsing, acting on, and/or producing) all (that is, recognizing, parsing, acting on, and/or producing) all
extension blocks. It is therefore possible for a node to receive a extension blocks. It is therefore possible for a node to receive a
bundle that includes extension blocks that the node cannot process. bundle that includes extension blocks that the node cannot process.
The values of the block processing control flags indicate the action The values of the block processing control flags indicate the action
to be taken by the bundle protocol agent when this is the case. to be taken by the bundle protocol agent when this is the case.
The following extension blocks are defined in other DTN protocol Extension block types 2 and 3 are reserved for the Block Integrity
specification documents as noted: Block and Block Confidentiality Block as defined in the Bundle
Security Protocol specification [BPSEC].
. Block Integrity Block (block type 2) and Block Confidentiality The following extension block types are reserved for extension
Block (block type 3) are defined in the Bundle Security blocks for which a need is anticipated but for which no definitions
Protocol specification (work in progress). yet exist:
. Manifest Block (block type 4) is defined in the Manifest
Extension Block specification (work in progress). The manifest . Block type 4 is reserved for the anticipated Manifest Block.
block identifies the blocks that were present in the bundle at Note: it is anticipated that the manifest block will identify
the time it was created. The bundle MUST contain one (1) the blocks that were present in the bundle at the time it was
created, implying that the bundle MUST contain one (1)
occurrence of this type of block if the value of the "manifest" occurrence of this type of block if the value of the "manifest"
flag in the bundle processing control flags is 1; otherwise the flag in the bundle processing control flags is 1, but otherwise
bundle MUST NOT contain any Manifest block. the bundle MUST NOT contain any Manifest block.
. The Flow Label Block (block type 6) is defined in the Flow . Block type 5 is reserved for the anticipated Metadata Block.
Label Extension Block specification (work in progress). The Note: the structure and function of the anticipated Metadata
flow label block is intended to govern transmission of the Block are currently undefined.
bundle by convergence-layer adapters. . Block type 6 is reserved for the anticipated Data Label Block.
Note: it is anticipated that the data label block will provide
additional information that can assist nodes in making
forwarding decisions.
The following extension blocks are defined in the current document. The following extension blocks are defined in the current document.
4.3.1. Previous Node 4.3.1. Previous Node
The Previous Node block, block type 7, identifies the node that The Previous Node block, block type 7, identifies the node that
forwarded this bundle to the local node (i.e., to the node at which forwarded this bundle to the local node (i.e., to the node at which
the bundle currently resides); its block-type-specific data is the the bundle currently resides); its block-type-specific data is the
node ID of that forwarder node which SHALL take the form of a node node ID of that forwarder node which SHALL take the form of a node
ID represented as described in Section 4.1.5.2. above. If the local ID represented as described in Section 4.1.5.2. above. If the local
skipping to change at page 23, line 9 skipping to change at page 25, line 30
bundle's creation time is zero, then the bundle MUST contain exactly bundle's creation time is zero, then the bundle MUST contain exactly
one (1) occurrence of this type of block; otherwise, the bundle MAY one (1) occurrence of this type of block; otherwise, the bundle MAY
contain at most one (1) occurrence of this type of block. A bundle contain at most one (1) occurrence of this type of block. A bundle
MUST NOT contain multiple occurrences of the bundle age block, as MUST NOT contain multiple occurrences of the bundle age block, as
this could result in processing anomalies. this could result in processing anomalies.
4.3.3. Hop Count 4.3.3. Hop Count
The Hop Count block, block type 9, contains two unsigned integers, The Hop Count block, block type 9, contains two unsigned integers,
hop limit and hop count. A "hop" is here defined as an occasion on hop limit and hop count. A "hop" is here defined as an occasion on
which a bundle was forwarded from one node to another node. The hop which a bundle was forwarded from one node to another node. Hop
limit value SHOULD NOT be changed at any time after creation of the limit MUST be in the range 1 through 255. The hop limit value SHOULD
Hop Count block; the hop count value SHOULD initially be zero and NOT be changed at any time after creation of the Hop Count block;
SHOULD be increased by 1 on each hop. the hop count value SHOULD initially be zero and SHOULD be increased
by 1 on each hop.
The hop count block is mainly intended as a safety mechanism, a The hop count block is mainly intended as a safety mechanism, a
means of identifying bundles for removal from the network that can means of identifying bundles for removal from the network that can
never be delivered due to a persistent forwarding error. When a never be delivered due to a persistent forwarding error. When a
bundle's hop count exceeds its hop limit, the bundle SHOULD be bundle's hop count exceeds its hop limit, the bundle SHOULD be
deleted for the reason "hop limit exceeded", following the bundle deleted for the reason "hop limit exceeded", following the bundle
deletion procedure defined in Section 5.10. . Procedures for deletion procedure defined in Section 5.10. . Procedures for
determining the appropriate hop limit for a block are beyond the determining the appropriate hop limit for a block are beyond the
scope of this specification. The block-type-specific data in a hop scope of this specification. The block-type-specific data in a hop
count block SHALL be represented as a CBOR array comprising a 2- count block SHALL be represented as a CBOR array comprising a 2-
skipping to change at page 24, line 5 skipping to change at page 26, line 29
"generate" an administrative record (such as a bundle status "generate" an administrative record (such as a bundle status
report), the bundle protocol agent itself is responsible for causing report), the bundle protocol agent itself is responsible for causing
a new bundle to be transmitted, conveying that record. In concept, a new bundle to be transmitted, conveying that record. In concept,
the bundle protocol agent discharges this responsibility by the bundle protocol agent discharges this responsibility by
directing the administrative element of the node's application agent directing the administrative element of the node's application agent
to construct the record and request its transmission as detailed in to construct the record and request its transmission as detailed in
Section 6 below. In practice, the manner in which administrative Section 6 below. In practice, the manner in which administrative
record generation is accomplished is an implementation matter, record generation is accomplished is an implementation matter,
provided the constraints noted in Section 6 are observed. provided the constraints noted in Section 6 are observed.
Under some circumstances, the requesting of status reports could Note that requesting status reports for any single bundle might
easily result in the generation of (1 + (2 *(N-1))) status report
bundles, where N is the number of nodes on the path from the
bundle's source to its destination, inclusive. That is, the
requesting of status reports for large numbers of bundles could
result in an unacceptable increase in the bundle traffic in the result in an unacceptable increase in the bundle traffic in the
network. For this reason, the generation of status reports MUST be network. For this reason, the generation of status reports MUST be
disabled by default and enabled only when the risk of excessive disabled by default and enabled only when the risk of excessive
network traffic is deemed acceptable. network traffic is deemed acceptable.
When the generation of status reports is enabled, the decision on When the generation of status reports is enabled, the decision on
whether or not to generate a requested status report is left to the whether or not to generate a requested status report is left to the
discretion of the bundle protocol agent. Mechanisms that could discretion of the bundle protocol agent. Mechanisms that could
assist in making such decisions, such as pre-placed agreements assist in making such decisions, such as pre-placed agreements
authorizing the generation of status reports under specified authorizing the generation of status reports under specified
skipping to change at page 24, line 51 skipping to change at page 27, line 32
Step 2: Processing proceeds from Step 1 of Section 5.4. Step 2: Processing proceeds from Step 1 of Section 5.4.
5.3. Bundle Dispatching 5.3. Bundle Dispatching
The steps in dispatching a bundle are: The steps in dispatching a bundle are:
Step 1: If the bundle's destination endpoint is an endpoint of which Step 1: If the bundle's destination endpoint is an endpoint of which
the node is a member, the bundle delivery procedure defined in the node is a member, the bundle delivery procedure defined in
Section 5.7 MUST be followed and for the purposes of all subsequent Section 5.7 MUST be followed and for the purposes of all subsequent
processing of this bundle at this node the node's membership in the processing of this bundle at this node the node's membership in the
bundle's destination endpoint SHALL be disavowed. bundle's destination endpoint SHALL be disavowed; specifically, even
though the node is a member of the bundle's destination endpoint,
the node SHALL NOT undertake to forward the bundle to itself in the
course of performing the procedure described in Section 5.4.
Step 2: Processing proceeds from Step 1 of Section 5.4. Step 2: Processing proceeds from Step 1 of Section 5.4.
5.4. Bundle Forwarding 5.4. Bundle Forwarding
The steps in forwarding a bundle are: The steps in forwarding a bundle are:
Step 1: The retention constraint "Forward pending" MUST be added to Step 1: The retention constraint "Forward pending" MUST be added to
the bundle, and the bundle's "Dispatch pending" retention constraint the bundle, and the bundle's "Dispatch pending" retention constraint
MUST be removed. MUST be removed.
skipping to change at page 25, line 42 skipping to change at page 28, line 28
will enable the node to send the bundle to those nodes. The will enable the node to send the bundle to those nodes. The
manner in which specific appropriate convergence layer adapters manner in which specific appropriate convergence layer adapters
are selected is beyond the scope of this document. If the agent are selected is beyond the scope of this document. If the agent
finds it impossible to select any appropriate convergence layer finds it impossible to select any appropriate convergence layer
adapter(s) to use in forwarding this bundle, then forwarding is adapter(s) to use in forwarding this bundle, then forwarding is
contraindicated. contraindicated.
Step 3: If forwarding of the bundle is determined to be Step 3: If forwarding of the bundle is determined to be
contraindicated for any of the reasons listed in Figure 4, then the contraindicated for any of the reasons listed in Figure 4, then the
Forwarding Contraindicated procedure defined in Section 5.4.1 MUST Forwarding Contraindicated procedure defined in Section 5.4.1 MUST
be followed; the remaining steps of Section 5 are skipped at this be followed; the remaining steps of Section 5.4 are skipped at this
time. time.
Step 4: For each node selected for forwarding, the bundle protocol Step 4: For each node selected for forwarding, the bundle protocol
agent MUST invoke the services of the selected convergence layer agent MUST invoke the services of the selected convergence layer
adapter(s) in order to effect the sending of the bundle to that adapter(s) in order to effect the sending of the bundle to that
node. Determining the time at which the bundle protocol agent node. Determining the time at which the bundle protocol agent
invokes convergence layer adapter services is a BPA implementation invokes convergence layer adapter services is a BPA implementation
matter. Determining the time at which each convergence layer matter. Determining the time at which each convergence layer
adapter subsequently responds to this service invocation by sending adapter subsequently responds to this service invocation by sending
the bundle is a convergence-layer adapter implementation matter. the bundle is a convergence-layer adapter implementation matter.
Note that: Note that:
. If the bundle contains a flow label extension block (to be . If the bundle contains a data label extension block (to be
defined in a future document) then that flow label value MAY defined in a future document) then that data label value MAY
identify procedures for determining the order in which identify procedures for determining the order in which
convergence layer adapters must send bundles, e.g., considering convergence layer adapters must send bundles, e.g., considering
bundle source when determining the order in which bundles are bundle source when determining the order in which bundles are
sent. The definition of such procedures is beyond the scope of sent. The definition of such procedures is beyond the scope of
this specification. this specification.
. If the bundle has a bundle age block, as defined in 4.3.2. . If the bundle has a bundle age block, as defined in 4.3.2.
above, then at the last possible moment before the CLA above, then at the last possible moment before the CLA
initiates conveyance of the bundle node via the CL protocol the initiates conveyance of the bundle node via the CL protocol the
bundle age value MUST be increased by the difference between bundle age value MUST be increased by the difference between
the current time and the time at which the bundle was received the current time and the time at which the bundle was received
skipping to change at page 28, line 5 skipping to change at page 30, line 39
Step 1: The retention constraint "Dispatch pending" MUST be added to Step 1: The retention constraint "Dispatch pending" MUST be added to
the bundle. the bundle.
Step 2: If the "request reporting of bundle reception" flag in the Step 2: If the "request reporting of bundle reception" flag in the
bundle's status report request field is set to 1, and status bundle's status report request field is set to 1, and status
reporting is enabled, then a bundle reception status report with reporting is enabled, then a bundle reception status report with
reason code "No additional information" SHOULD be generated, reason code "No additional information" SHOULD be generated,
destined for the bundle's report-to endpoint ID. destined for the bundle's report-to endpoint ID.
Step 3: For each block in the bundle that is an extension block that Step 3: If any block of the bundle is malformed according to this
specification, or if any block has an attached CRC and the CRC
computed for this block upon reception differs from that attached
CRC, then the bundle protocol agent MUST delete the bundle for the
reason "Block unintelligible". The bundle deletion procedure
defined in Section 5.10 MUST be followed and all remaining steps of
the bundle reception procedure MUST be skipped.
Step 4: For each block in the bundle that is an extension block that
the bundle protocol agent cannot process: the bundle protocol agent cannot process:
. If the block processing flags in that block indicate that a . If the block processing flags in that block indicate that a
status report is requested in this event, and status reporting status report is requested in this event, and status reporting
is enabled, then a bundle reception status report with reason is enabled, then a bundle reception status report with reason
code "Block unintelligible" SHOULD be generated, destined for code "Block unintelligible" SHOULD be generated, destined for
the bundle's report-to endpoint ID. the bundle's report-to endpoint ID.
. If the block processing flags in that block indicate that the . If the block processing flags in that block indicate that the
bundle must be deleted in this event, then the bundle protocol bundle must be deleted in this event, then the bundle protocol
agent MUST delete the bundle for the reason "Block agent MUST delete the bundle for the reason "Block
skipping to change at page 28, line 27 skipping to change at page 31, line 21
Section 5.10 MUST be followed and all remaining steps of the Section 5.10 MUST be followed and all remaining steps of the
bundle reception procedure MUST be skipped. bundle reception procedure MUST be skipped.
. If the block processing flags in that block do NOT indicate . If the block processing flags in that block do NOT indicate
that the bundle must be deleted in this event but do indicate that the bundle must be deleted in this event but do indicate
that the block must be discarded, then the bundle protocol that the block must be discarded, then the bundle protocol
agent MUST remove this block from the bundle. agent MUST remove this block from the bundle.
. If the block processing flags in that block indicate neither . If the block processing flags in that block indicate neither
that the bundle must be deleted nor that that the block must be that the bundle must be deleted nor that that the block must be
discarded, then processing continues with the next extension discarded, then processing continues with the next extension
block that the bundle protocol agent cannot process, if any; block that the bundle protocol agent cannot process, if any;
otherwise, processing proceeds from step 4. otherwise, processing proceeds from step 5.
Step 4: Processing proceeds from Step 1 of Section 5.3. Step 5: Processing proceeds from Step 1 of Section 5.3.
5.7. Local Bundle Delivery 5.7. Local Bundle Delivery
The steps in processing a bundle that is destined for an endpoint of The steps in processing a bundle that is destined for an endpoint of
which this node is a member are: which this node is a member are:
Step 1: If the received bundle is a fragment, the application data Step 1: If the received bundle is a fragment, the application data
unit reassembly procedure described in Section 5.9 MUST be followed. unit reassembly procedure described in Section 5.9 MUST be followed.
If this procedure results in reassembly of the entire original If this procedure results in reassembly of the entire original
application data unit, processing of this bundle (whose fragmentary application data unit, processing of this bundle (whose fragmentary
skipping to change at page 34, line 34 skipping to change at page 37, line 34
+---------+--------------------------------------------+ +---------+--------------------------------------------+
| 8 | Block unintelligible. | | 8 | Block unintelligible. |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
| 9 | Hop limit exceeded. | | 9 | Hop limit exceeded. |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
| 10 | Traffic pared (e.g., status reports). |
+---------+--------------------------------------------+
| (other) | Reserved for future use. | | (other) | Reserved for future use. |
+---------+--------------------------------------------+ +---------+--------------------------------------------+
Figure 4: Status Report Reason Codes Figure 4: Status Report Reason Codes
The third item of the bundle status report array SHALL be the source The third item of the bundle status report array SHALL be the source
node ID identifying the source of the bundle whose status is being node ID identifying the source of the bundle whose status is being
reported, represented as described in Section 4.1.5.2. above. reported, represented as described in Section 4.1.5.2. above.
skipping to change at page 35, line 47 skipping to change at page 38, line 50
defined minimal set of services to the bundle protocol agent. This defined minimal set of services to the bundle protocol agent. This
convergence layer service specification enumerates those services. convergence layer service specification enumerates those services.
7.2. Summary of Convergence Layer Services 7.2. Summary of Convergence Layer Services
Each convergence layer protocol adapter is expected to provide the Each convergence layer protocol adapter is expected to provide the
following services to the bundle protocol agent: following services to the bundle protocol agent:
. sending a bundle to a bundle node that is reachable via the . sending a bundle to a bundle node that is reachable via the
convergence layer protocol; convergence layer protocol;
. notifying the bundle protocol agent when it has concluded its
data sending procedures with regard to a bundle;
. delivering to the bundle protocol agent a bundle that was sent . delivering to the bundle protocol agent a bundle that was sent
by a bundle node via the convergence layer protocol. by a bundle node via the convergence layer protocol.
The convergence layer service interface specified here is neither The convergence layer service interface specified here is neither
exhaustive nor exclusive. That is, supplementary DTN protocol exhaustive nor exclusive. That is, supplementary DTN protocol
specifications (including, but not restricted to, the Bundle specifications (including, but not restricted to, the Bundle
Security Protocol [BPSEC]) may expect convergence layer adapters Security Protocol [BPSEC]) may expect convergence layer adapters
that serve BP implementations conforming to those protocols to that serve BP implementations conforming to those protocols to
provide additional services such as reporting on the transmission provide additional services such as reporting on the transmission
and/or reception progress of individual bundles (at completion and/or reception progress of individual bundles (at completion
skipping to change at page 38, line 9 skipping to change at page 41, line 12
Because the security mechanisms are extension blocks that are Because the security mechanisms are extension blocks that are
themselves inserted into the bundle, the integrity and themselves inserted into the bundle, the integrity and
confidentiality of bundle blocks are protected while the bundle is confidentiality of bundle blocks are protected while the bundle is
at rest, awaiting transmission at the next forwarding opportunity, at rest, awaiting transmission at the next forwarding opportunity,
as well as in transit. as well as in transit.
Additionally, convergence-layer protocols that ensure authenticity Additionally, convergence-layer protocols that ensure authenticity
of communication between adjacent nodes in BP network topology of communication between adjacent nodes in BP network topology
SHOULD be used where available, to minimize the ability of SHOULD be used where available, to minimize the ability of
unauthenticated nodes to introduce inauthentic traffic into the unauthenticated nodes to introduce inauthentic traffic into the
network. network. Convergence-layer protocols that ensure confidentiality of
communication between adjacent nodes in BP network topology SHOULD
also be used where available, to minimize exposure of the bundle's
primary block and other clear-text blocks, thereby offering some
defense against traffic analysis.
Note that, while the primary block must remain in the clear for Note that, while the primary block must remain in the clear for
routing purposes, the Bundle Protocol can be protected against routing purposes, the Bundle Protocol can be protected against
traffic analysis to some extent by using bundle-in-bundle traffic analysis to some extent by using bundle-in-bundle
encapsulation to tunnel bundles to a safe forward distribution encapsulation to tunnel bundles to a safe forward distribution
point: the encapsulated bundle forms the payload of an encapsulating point: the encapsulated bundle forms the payload of an encapsulating
bundle, and that payload block may be encrypted by a BCB. bundle, and that payload block may be encrypted by a BCB.
Note that the generation of bundle status reports is disabled by Note that the generation of bundle status reports is disabled by
default because malicious initiation of bundle status reporting default because malicious initiation of bundle status reporting
could result in the transmission of extremely large numbers of could result in the transmission of extremely large numbers of
bundle, effecting a denial of service attack. bundles, effecting a denial of service attack.
The bpsec extensions accommodate an open-ended range of The bpsec extensions accommodate an open-ended range of
ciphersuites; different ciphersuites may be utilized to protect ciphersuites; different ciphersuites may be utilized to protect
different blocks. One possible variation is to sign and/or encrypt different blocks. One possible variation is to sign and/or encrypt
blocks in symmetric keys securely formed by Diffie-Hellman blocks using symmetric keys securely formed by Diffie-Hellman
procedures (such as EKDH) using the public and private keys of the procedures (such as EKDH) using the public and private keys of the
sending and receiving nodes. For this purpose, the key distribution sending and receiving nodes. For this purpose, the key distribution
problem reduces to the problem of trustworthy delay-tolerant problem reduces to the problem of trustworthy delay-tolerant
distribution of public keys, a current research topic. distribution of public keys, a current research topic.
Bundle security MUST NOT be invalidated by forwarding nodes even Bundle security MUST NOT be invalidated by forwarding nodes even
though they themselves might not use the Bundle Security Protocol. though they themselves might not use the Bundle Security Protocol.
In particular, while blocks MAY be added to bundles transiting In particular, while blocks MAY be added to bundles transiting
intermediate nodes, removal of blocks with the "Discard block if it intermediate nodes, removal of blocks with the "Discard block if it
skipping to change at page 39, line 15 skipping to change at page 42, line 23
the first path segment on which the resulting overhead is the first path segment on which the resulting overhead is
acceptable and on all subsequent path segments. acceptable and on all subsequent path segments.
. If any segment of the end-to-end path of a bundle will traverse . If any segment of the end-to-end path of a bundle will traverse
the Internet or any other potentially insecure communication the Internet or any other potentially insecure communication
environment, then the payload block SHOULD be encrypted by a environment, then the payload block SHOULD be encrypted by a
BCB on this path segment and all subsequent segments of the BCB on this path segment and all subsequent segments of the
end-to-end path. end-to-end path.
10. IANA Considerations 10. IANA Considerations
This document defines the following additional Bundle Protocol block The Bundle Protocol includes fields requiring registries managed by
types, for which values are to be assigned from the Bundle IANA.
Administrative Record Types namespace [RFC6255]:
Value Name Meaning Reference 10.1. Bundle Block Types
----- ------------- ----------------------------- ---------- The Bundle Protocol has a Bundle Block Type code field (Section
4.2.3). An IANA registry has been set up as follows.
7 Previous node Identifies sender This document The registration policy for this registry is:
8 Bundle age Bundle age in seconds This document 0-191: Specification Required.
9 Hop count #prior transmission attempts This document 192-255: Private or experimental use. No assignment by IANA.
This document also defines a new URI scheme type field - an unsigned The Value range is: unsigned 8-bit integer.
integer of undefined length - for which IANA is to create and
maintain a new registry named "URI scheme type values". Initial Bundle Block Type Registry
+--------------+---------------------------------+---------------+
| Value | Description | Reference |
+--------------+---------------------------------+---------------+
| 0 | Reserved | This document |
| 1 | Bundle Payload Block | section 4.2.3 |
| 2 | Block Integrity Block | [BPSEC] |
| 3 | Block Confidentiality Block | [BPSEC] |
| 4-6 | Reserved | section 4.3 |
| 7 | Previous node (proximate sender)| section 4.3.1 |
| 8 | Bundle age (in seconds) | section 4.3.2 |
| 9 | Hop count (#prior xmit attempts)| section 4.3.3 |
| 10-191 | Unassigned | |
| 192-255 | Private and/or Experimental Use | This document |
+--------------+---------------------------------+---------------+
IANA is requested to add values 2-9, as noted above, to the existing
registry.
The value "0" was not defined in any document or in the ad hoc
registry. As per consensus by the DTNRG research group, it is
reserved per this document.
10.2. Primary Bundle Protocol Version
The Bundle Protocol has a version field (Section 4.2.2). An IANA
registry has been set up as follows.
The registration policy for this registry is: RFC Required.
The value range is: unsigned 8-bit integer.
Primary Bundle Protocol Version Registry
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| 0-5 | Reserved | This document |
| 6 | Assigned | [RFC5050] |
| 7 | Assigned | section 4.2.2 |
| 8-255 | Unassigned | |
+-------+-------------+---------------+
The value "0-5" was not defined in any document or in the ad hoc
registry. As per consensus by the DTNRG research group, it is
reserved per this document.
10.3. Bundle Processing Control Flags
The Bundle Protocol has a Bundle Processing Control Flags field
(Section 4.1.3) for which IANA is requested to create and maintain a
new registry named "BPv7 Bundle Processing Control Flags". Initial
values for this registry are given below.
The registration policy for this registry is: Specification
Required.
The value range is: variable length. Maximum number of flag bit
positions: 16.
Bundle Processing Control Flags Registry
+--------------------+----------------------------------+----------+
| Bit Position | Description | Reference|
| (right to left) | | |
+--------------------+----------------------------------+----------+
| 0 | Bundle is a fragment | 4.1.3 |
| 1 | Application data unit is an | 4.1.3 |
| | administrative record | |
| 2 | Bundle must not be fragmented | 4.1.3 |
| 3 | reserved | 4.1.3 |
| 4 | reserved | 4.1.3 |
| 5 | Acknowledgement by application | 4.1.3 |
| | is requested | |
| 6 | Status time requested in reports | 4.1.3 |
| 7 | Reserved | 4.1.3 |
| 8 | Request reporting of bundle | 4.1.3 |
| | reception | |
| 9 | Reserved | 4.1.3 |
| 10 | Request reporting of bundle | 4.1.3 |
| | forwarding | |
| 11 | Request reporting of bundle | 4.1.3 |
| | delivery | |
| 12 | Request reporting of bundle | 4.1.3 |
| | deletion | |
| 13-15 | Unassigned | |
+--------------------+----------------------------------+----------+
10.4. Block Processing Control Flags
The Bundle Protocol has a Block Processing Control Flags field
(Section 4.1.4) for which IANA is requested to create and maintain a
new registry named "BPv7 Block Processing Control Flags". Initial
values for this registry are given below.
The registration policy for this registry is: Specification
Required.
The value range is: variable length. Maximum number of flag bit
positions: 8.
Block Processing Control Flags Registry
+--------------------+----------------------------------+----------+
| Bit Position | Description | Reference|
| (right to left) | | |
+--------------------+----------------------------------+----------+
| 0 | Block must be replicated in | 4.1.4 |
| | every fragment | |
| 1 | Discard block if it can't be | 4.1.4 |
| | processed | |
| 2 | Transmit status report if block | 4.1.4 |
| | can't be processed | |
| 3 | Delete bundle if block can't be | 4.1.4 |
| | processed | |
| 4-7 | Reserved | |
+--------------------+----------------------------------+----------+
10.5. Bundle Status Report Reason Codes
The Bundle Protocol has a Bundle Status Report Reason Codes field
(Section 6.1.1) for which IANA is requested to create and maintain a
new registry named "BPv7 Bundle Status Report Reason Codes".
Initial values for this registry are given below.
The registration policy for this registry is: Specification
Required.
The value range is: unsigned 8-bit integer.
Bundle Status Report Reason Codes Registry
+-------+-------------------------------------------+--------------+
| Value | Description | Reference |
+-------+-------------------------------------------+--------------+
| 0 | No additional information | 6.1.1 |
| 1 | Lifetime expired | 6.1.1 |
| 2 | Forwarded over unidirectional link | 6.1.1 |
| 3 | Transmission canceled | 6.1.1 |
| 4 | Depleted storage | 6.1.1 |
| 5 | Destination endpoint ID unintelligible | 6.1.1 |
| 6 | No known route to destination from here | 6.1.1 |
| 7 | No timely contact with next node on route | 6.1.1 |
| 8 | Block unintelligible | 6.1.1 |
| 9 | Hop limit exceeded | 6.1.1 |
| 8 | Traffic pared | 6.1.1 |
| 9-254 | Unassigned | |
| 255 | Reserved | |
+-------+-------------------------------------------+--------------+
10.6. URI scheme types
The Bundle Protocol has a URI scheme type field - an unsigned
integer of undefined length - for which IANA is requested to create
and maintain a new registry named "URI scheme type values". Initial
values for the Bundle Protocol URI scheme type registry are given values for the Bundle Protocol URI scheme type registry are given
below; future assignments are to be made through Expert Review. below.
The registration policy for this registry is: RFC Required.
The value range is: unsigned 8-bit integer.
Each assignment consists of a URI scheme type name and its Each assignment consists of a URI scheme type name and its
associated value. associated value.
Value URI Scheme Type Name Reference Bundle Block Type Registry
----- ------------------------ ------------------------------- +--------------+-----------------------------+-------------------+
0 Reserved | Value | Description | Reference |
1 dtn RFC5050, Section 4.4 +--------------+-----------------------------+-------------------+
2 ipn RFC6260, Section 4 | 0 | Reserved | |
3-254 Unassigned | 1 | dtn | section 10.7 |
| 2 | ipn | RFC6260, Section 4|
255 Reserved | 3-254 | Unassigned | |
--------------------------------------------------------------- | 255 | reserved | |
+--------------+-----------------------------+-------------------+
10.7. New URI scheme "dtn"
IANA is requested to register a URI scheme with the string "dtn" as
the scheme name, as follows:
URI scheme name: "dtn"
Status: provisional
URI scheme syntax:
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234].
dtn-uri = "dtn:" dtn-hier-part
dtn-hier-part = "//" node-name name-delim demux ; a path-rootless
node-name = 1*VCHAR
name-delim = "/"
demux = *VCHAR
None of the reserved characters defined in the generic URI syntax
are used as delimiters within URIs of the DTN scheme.
URI scheme semantics: URIs of the DTN scheme are used as endpoint
identifiers in the Delay-Tolerant Networking (DTN) Bundle Protocol
(BP) as described in Section 4.1.5.1.
Encoding considerations: URIs of the DTN scheme are encoded
exclusively in US-ASCII characters.
Applications and/or protocols that use this URI scheme name: the
Delay-Tolerant Networking (DTN) Bundle Protocol (BP).
Interoperability considerations: as noted above, URIs of the DTN
scheme are encoded exclusively in US-ASCII characters.
Security considerations:
. Reliability and consistency: none of the BP endpoints
identified by the URIs of the DTN scheme are guaranteed to be
reachable at any time, and the identity of the processing
entities operating on those endpoints is never guaranteed by
the Bundle Protocol itself. Bundle authentication as defined by
the Bundle Security Protocol is required for this purpose.
. Malicious construction: malicious construction of a conformant
DTN-scheme URI is limited to the malicious selection of node
names and the malicious selection of demux strings. That is, a
maliciously constructed DTN-scheme URI could be used to direct
a bundle to an endpoint that might be damaged by the arrival of
that bundle or, alternatively, to declare a false source for a
bundle and thereby cause incorrect processing at a node that
receives the bundle. In both cases (and indeed in all bundle
processing), the node that receives a bundle should verify its
authenticity and validity before operating on it in any way.
. Back-end transcoding: the limited expressiveness of URIs of the
DTN scheme effectively eliminates the possibility of threat due
to errors in back-end transcoding.
. Rare IP address formats: not relevant, as IP addresses do not
appear anywhere in conformant DTN-scheme URIs.
. Sensitive information: because DTN-scheme URIs are used only to
represent the identities of Bundle Protocol endpoints, the risk
of disclosure of sensitive information due to interception of
these URIs is minimal. Examination of DTN-scheme URIs could be
used to support traffic analysis; where traffic analysis is a
plausible danger, bundles should be conveyed by secure
convergence-layer protocols that do not expose endpoint IDs.
. Semantic attacks: the simplicity of DTN-scheme URI syntax
minimizes the possibility of misinterpretation of a URI by a
human user.
Contact:
Scott Burleigh
Jet Propulsion Laboratory,
California Institute of Technology
scott.c.burleigh@jpl.nasa.gov
+1 (800) 393-3353
Author/Change controller:
Scott Burleigh
Jet Propulsion Laboratory,
California Institute of Technology
scott.c.burleigh@jpl.nasa.gov
11. References 11. References
11.1. Normative References 11.1. Normative References
[CRC]Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization of [BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work
Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE In Progress, October 2015.
Transact. on Communications, Vol. 41, No. 6, June 1993..
[CRC16] ITU-T Recommendation X.25, p. 9, section 2.2.7.4,
International Telecommunications Union, October 1996.
[CRC32C] Castagnoli, G., Brauer, S., and M. Herrmann, "Optimization
of Cyclic Redundancy-Check Codes with 24 and 32 Parity Bits", IEEE
Transact. on Communications, Vol. 41, No. 6, June 1993.
[EPOCH] Thompson, K. and D. M. Ritchie, "UNIX Programmer's Manual,
Fifth Edition", Bell Telephone Laboratories Inc., June 1974.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object [RFC7049] Borman, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, October 2013. Representation (CBOR)", RFC 7049, October 2013.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66,
January 2005. January 2005.
[URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and [URIREG] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and
Registration Procedures for URI Schemes", RFC 7595, BCP 35, June Registration Procedures for URI Schemes", RFC 7595, BCP 35, June
2015. 2015.
11.2. Informative References 11.2. Informative References
[ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC [ARCH] V. Cerf et al., "Delay-Tolerant Network Architecture", RFC
4838, April 2007. 4838, April 2007.
[BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In [BIBE] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work In
Progress, June 2017. Progress, June 2017.
[BPSEC] Birrane, E., "Bundle Security Protocol Specification", Work
In Progress, October 2015.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC6255] Blanchet, M., "Delay-Tolerant Networking Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
IANA Registries", RFC 6255, May 2011. Specification", RFC 5050, November 2007.
[RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
"Internet Small Computer System Interface (iSCSI) Protocol "Internet Small Computer System Interface (iSCSI) Protocol
(Consolidated)", RFC 7143, April 2014. (Consolidated)", RFC 7143, April 2014.
[SIGC] Fall, K., "A Delay-Tolerant Network Architecture for [SIGC] Fall, K., "A Delay-Tolerant Network Architecture for
Challenged Internets", SIGCOMM 2003. Challenged Internets", SIGCOMM 2003.
[UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC: [UTC] Arias, E. and B. Guinot, "Coordinated universal time UTC:
historical background and perspectives" in "Journees systemes de historical background and perspectives" in "Journees systemes de
skipping to change at page 41, line 22 skipping to change at page 51, line 44
12. Acknowledgments 12. Acknowledgments
This work is freely adapted from RFC 5050, which was an effort of This work is freely adapted from RFC 5050, which was an effort of
the Delay Tolerant Networking Research Group. The following DTNRG the Delay Tolerant Networking Research Group. The following DTNRG
participants contributed significant technical material and/or participants contributed significant technical material and/or
inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh,
Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory,
Michael Demmer of the University of California at Berkeley, Robert Michael Demmer of the University of California at Berkeley, Robert
Durst, Keith Scott, and Susan Symington of The MITRE Corporation, Durst, Keith Scott, and Susan Symington of The MITRE Corporation,
Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity
College Dublin, Peter Lovell of SPARTA, Inc., Manikantan Ramadas of College Dublin, Howard Weiss and Peter Lovell of SPARTA, Inc., and
Ohio University, and Howard Weiss of SPARTA, Inc. Manikantan Ramadas of Ohio University.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
13. Significant Changes from RFC 5050 13. Significant Changes from RFC 5050
Points on which this draft significantly differs from RFC 5050 Points on which this draft significantly differs from RFC 5050
include the following: include the following:
. Clarify the difference between transmission and forwarding. . Clarify the difference between transmission and forwarding.
. Migrate custody transfer to the bundle-in-bundle encapsulation . Migrate custody transfer to the bundle-in-bundle encapsulation
specification [BIBE]. specification [BIBE].
. Introduce the concept of "node ID" as functionally distinct . Introduce the concept of "node ID" as functionally distinct
from endpoint ID, while having the same syntax. from endpoint ID, while having the same syntax.
. Restructure primary block, making it immutable. Add optional . Restructure primary block, making it immutable. Add optional
CRC. CRC.
. Add optional CRCs to non-primary blocks. . Add optional CRCs to non-primary blocks.
. Add block ID number to canonical block format (to support . Add block ID number to canonical block format (to support
streamlined BSP). BPSEC).
. Add bundle age extension block, defined in this specification. . Add definition of bundle age extension block.
. Add previous node extension block, defined in this . Add definition of previous node extension block.
specification. . Add definition of hop count extension block.
. Add flow label extension block, *not* defined in this . Remove Quality of Service markings.
specification. . Change from SDNVs to CBOR representation.
. Add manifest extension block, *not* defined in this
specification.
. Add hop count extension block, defined in this specification.
. Migrate Quality of Service markings to a new QoS extension
block, *not* defined in this specification.
Appendix A. For More Information Appendix A. For More Information
Please refer comments to dtn@ietf.org. DTN Working Group documents Please refer comments to dtn@ietf.org. DTN Working Group documents
are located at https://datatracker.ietf.org/wg/dtn/documents. The are located at https://datatracker.ietf.org/wg/dtn/documents. The
original Delay Tolerant Networking Research Group (DTNRG) Web site original Delay Tolerant Networking Research Group (DTNRG) Web site
is located at https://irtf.org/concluded/dtnrg. is located at https://irtf.org/concluded/dtnrg.
Copyright (c) 2019 IETF Trust and the persons identified as authors Copyright (c) 2019 IETF Trust and the persons identified as authors
of the code. All rights reserved. of the code. All rights reserved.
skipping to change at page 47, line 31 skipping to change at page 58, line 21
extension-block = $extension-block-structure .within canonical- extension-block = $extension-block-structure .within canonical-
block-structure block-structure
; Generic shared structure of all non-primary blocks ; Generic shared structure of all non-primary blocks
extension-block-use<CodeValue, BlockData> = [ extension-block-use<CodeValue, BlockData> = [
block-type-code: CodeValue, block-type-code: CodeValue,
block-number: (uint .ne 0), block-number: (uint .gt 1),
block-control-flags, block-control-flags,
crc-type, crc-type,
BlockData, BlockData,
? crc-value ? crc-value
] ]
skipping to change at page 48, line 4 skipping to change at page 58, line 37
BlockData, BlockData,
? crc-value ? crc-value
] ]
; Payload block type ; Payload block type
payload-block = payload-block-structure .within canonical-block- payload-block = payload-block-structure .within canonical-block-
structure structure
payload-block-structure = [ payload-block-structure = [
block-type-code: 1, block-type-code: 1,
block-number: 0, block-number: 1,
block-control-flags, block-control-flags,
crc-type, crc-type,
$payload-block-data, $payload-block-data,
? crc-value ? crc-value
] ]
skipping to change at page 51, line 4 skipping to change at page 61, line 14
Authors' Addresses Authors' Addresses
Scott Burleigh Scott Burleigh
Jet Propulsion Laboratory, California Institute of Technology Jet Propulsion Laboratory, California Institute of Technology
4800 Oak Grove Dr. 4800 Oak Grove Dr.
Pasadena, CA 91109-8099 Pasadena, CA 91109-8099
US US
Phone: +1 818 393 3353 Phone: +1 818 393 3353
Email: Scott.C.Burleigh@jpl.nasa.gov Email: Scott.C.Burleigh@jpl.nasa.gov
Kevin Fall Kevin Fall
Nefeli Networks, Inc. Roland Computing Services
2150 Shattuck Ave. 3871 Piedmont Ave. Suite 8
Berkeley, CA 94704 Oakland, CA 94611
US US
Email: kfall@kfall.com Email: kfall+rcs@kfall.com
Edward J. Birrane Edward J. Birrane
Johns Hopkins University Applied Physics Laboratory Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd 11100 Johns Hopkins Rd
Laurel, MD 20723 Laurel, MD 20723
US US
Phone: +1 443 778 7423 Phone: +1 443 778 7423
Email: Edward.Birrane@jhuapl.edu Email: Edward.Birrane@jhuapl.edu
 End of changes. 68 change blocks. 
170 lines changed or deleted 638 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/