| Internet-Draft | BPv7 TREB | October 2026 |
| Koo | Expires 9 April 2027 | [Page] |
This document defines a Traceroute Extension Block (TREB) for Bundle Protocol Version 7 (BPv7). Each participating node along a bundle's path appends a hop-record containing its Node ID, the node it received the bundle from, the next hop it selected, the time of the recorded event, and link characteristics. The same block, copied into bundle status reports, returns traceroute data to the source. The mechanism is opt-in and intended for designated diagnostic bundles on scheduled, bandwidth-constrained paths. Each forwarding report returns one hop-record, and the delivery report returns the full recorded path and also records its own return path, giving a round-trip trace. Status report generation remains governed by RFC 9171.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
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."¶
This Internet-Draft will expire on 9 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Network diagnostic tools are essential for operational networks. In DTN, particularly space communications, operators need visibility into:¶
Bundle Status Reports (BSRs) [RFC9171] can provide some of this information, but path reconstruction from BSRs requires every intermediate node to generate a forwarding report, each report identifies only the reporting node, and the reports carry no link detail. The mechanism defined here records the path in the bundle itself. The delivery report (or a deletion report) returns the full recorded path and records its own return path, giving a round-trip trace; each forwarding report carries only the reporting node's own hop-record, so total report volume grows linearly with path length. Appendix B quantifies the report volume.¶
radiate-time separates the time spent waiting for a contact; further separation of transmission and propagation delay is out of scope of this document (Section 3.3).¶
The TREB is independent of the extension blocks defined in [RFC9171]; it neither requires nor replaces them. Those blocks travel with the bundle toward its destination, whereas the TREB returns per-hop information to the departure node. The relationships are as follows.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the terms Bundle Protocol Agent (BPA), Endpoint Identifier (EID), Node ID, extension block, administrative record, and bundle status report as defined in [RFC9171]. CDDL [RFC8610] is used to describe CBOR [RFC8949] structures; the rules "eid" and "dtn-time" are those of Appendix B of [RFC9171].¶
This document requests a block type code, TBD1, from the "Bundle Block Types" registry (Section 8.1). For experimentation before assignment, implementations MAY use a value from the range 192-255, which Section 9.1 of [RFC9171] makes available for private and/or experimental use. The examples in this document use 194.¶
The block-type-specific data of a TREB is a CBOR byte string containing:¶
treb-data = [
traceroute-id: uint .ge 1, ; unique per departure node
record-limit: 1..255, ; max hop-records per direction
hop-records: [* hop-record],
? report-value: record-position / hop-count ; report copies only
]
record-position = uint ; forwarding report: position of
; the record; 0..record-limit
hop-count = uint ; delivery/deletion report: hop
; count of the Hop Count Block;
; 0 if absent
hop-record = [
self-node-id: eid, ; Node ID of the recording node
prev-node-id: eid, ; node the bundle was received from;
; dtn:none = unknown or none
next-node-id: eid, ; Node ID of the selected next hop
event-type: 0..255, ; Section 8.2
event-time: dtn-time, ; 0 = unknown/withheld
radiate-time: dtn-time, ; planned; 0 = unknown/withheld
link-info ; Link characteristics
]
link-info = [
type: 0..255, ; Section 8.3
speed: uint, ; kbps, rounded up; 0 = unknown
distance: uint, ; km, rounded up; 0 = unknown
cl: -32768..32767, ; SAND CL Type; 0 = unknown
congestion: 0..100 ; percent, rounded up; 0 = unknown
]
¶
report-value SHALL be present in a report copy and SHALL NOT be present in a traced bundle; a TREB is therefore encoded as a 3-element array in a traced bundle and as a 4-element array in a report copy (Section 4.7). Its meaning depends on the report type:¶
See Appendix A.2 for a worked example.¶
DTN time (Section 4.2.6 of [RFC9171]), according to the recording node's clock, at which the node recorded the event: for departure and forwarding, the time at which the node, having selected the next hop, queues the bundle for transmission; for delivery and deletion, the time of delivery or deletion. 0 means unknown or withheld.¶
The difference between a record's radiate-time and the event-time of the following record includes transmission and propagation delays, which this specification does not separate; the time at which the reporting node asserted that it forwarded the bundle is given by the status time of a forwarding report (Section 6.1.1 of [RFC9171]). Comparing times of different nodes assumes synchronized clocks, which [RFC9171] does not require. Analysis of propagation delay is out of scope of this document.¶
The block processing control flags (Section 4.2.4 of [RFC9171]) of a TREB SHALL be set as follows:¶
These settings ensure that nodes that do not support this specification forward the TREB unchanged.¶
This section is informative. It summarizes the processing specified in the rest of Section 4; in case of conflict, the text of those sections takes precedence.¶
hr = hop-record; RC = report copy; rv = report-value
hr3 = return record by C (event-type 0), hr4 by B (Sections 4.4, 4.7)
delivery BSR, rv = 2 (RC extended on its return path)
<== RC [hr0 ... hr4] =========+<== RC [hr0 ... hr3] =======+
| |
<= fwd BSR: RC [hr1], rv = 1 =+ |
| |
TREB [hr0] | TREB [hr0, hr1] |
+-------+ +-------+ +-------+
| A |-------------------->| B |------------------->| C |
+-------+ +-------+ +-------+
hr0 hr1, hr4 hr2, hr3
departure intermediate destination
Legend: RC = report copy; Tmr = treb-completion-timeout timer
+----------+
| IDLE |
+----+-----+
| Start traceroute:
| traceroute-id := previous + 1;
| create TREB, append departure record;
| queue carrier bundle; start Tmr
V
+----------+ Rcv forwarding RC:
| | place record at report-value
| WAIT_RPT |------------------------------+
| |<-----------------------------+
+--+----+--+
| |
Rcv delivery or | | Tmr expires
deletion RC: +--+ +------+
place records from | |
position 0; | |
stop Tmr | |
V V
+----------+ +-----------+
| COMPLETE | | TIMED_OUT |
+-----+----+ +-----+-----+
| |
+------+-------+
| Evaluate trace (Section 4.8):
| gaps, overflow,
| transparent nodes
V
+----------+ Rcv RC with this
| CLOSED | traceroute-id: ignore
+----------+
Legend: RC = report copy; rv = report-value
Bundle with TREB received
|
+-- ADU is an administrative record? --yes--> delivery/deletion
| RC: append return
| record unless full
| or declined;
| forwarding RC:
| forward unchanged
| (Section 4.4)
| no
+-- Process TREB (local policy)? ------no---> forward TREB
| unchanged
| (transparent node)
| yes
+-- Destination? ----------------------yes--> create delivery
| record; append if
| TREB not full;
| deliver
| no |
V V
Select next hop; Delivery report?
create forwarding record yes: RC = all
| records (+ own if
+-- TREB full? --yes--> leave TREB TREB full),
| unchanged rv = hop count;
| no | on queuing the
V | report, append own
Append record | return record
| | (event-type 0)
+<------------------------+
V
Queue for transmission <--- re-queued: replace own record
|
V
Forwarded
|
V
Forwarding report?
yes: RC = [own record], rv = position
(record-limit if TREB was full)
At any time, if the bundle is deleted and a deletion report is
generated: create deletion record; RC = all records + deletion
record, rv = hop count; on queuing the report, append own return
record (event-type 0).
A departure node MAY add a TREB to any bundle it sources, other than a bundle whose payload is an administrative record. It SHALL set traceroute-id (Section 3.3), set record-limit (a value based on expected network diameter; 32 is suggested), and set hop-records to an empty array; report-value is absent. It SHALL append the first hop-record (event-type 0) when queuing the bundle for transmission, as specified in Section 4.3. hop-records[0] therefore always describes the departure node.¶
The source node ID, destination, and report-to EID of a traced bundle SHALL NOT be the null endpoint (Section 4.2.3 of [RFC9171] and Section 4.2.5.1.1 of [RFC9171]).¶
A traceroute carrier bundle is a bundle created specifically to gather path information. For a traceroute carrier bundle:¶
A Hop Count Block SHOULD be included.¶
Note: The hop count, returned as report-value in delivery and deletion reports, lets the departure node determine how many hops were made by nodes that do not support or do not process the TREB, including consecutive ones that the trace alone cannot reveal (Section 4.8.3).¶
Alternatively, the destination application MAY return the delivered treb-data to the departure node in the payload of an ordinary bundle (Section 4.5). This provides delivery results even where status reporting is disabled, but does not report deletions or intermediate progress.¶
A participating node creates its hop-record, and appends it to the TREB unless the TREB is full (see below), when the event it records occurs: for event-types 0 and 1, when the node has decided to process the TREB, has selected the next hop, and queues the bundle for transmission to it; for event-type 2, at delivery; for event-type 3, at deletion.¶
If a bundle, whether a traced bundle or a report bundle, is removed from a transmission queue and queued again, for example after a failed transmission attempt or a change of next hop, the node SHALL replace the hop-record it appended for the earlier queuing with a new one. A node thus contributes at most one hop-record to each transmitted bundle.¶
Before appending, the node SHALL compare with record-limit the number of hop-records in the TREB of a traced bundle, or the number of return records in a report copy (Section 4.4). If that number is equal to or greater than record-limit, the TREB is full: the node SHALL NOT modify the TREB of the bundle and SHALL otherwise process and forward the bundle normally. The node still creates its hop-record, which it includes in any report copy it generates (Section 4.7).¶
An intermediate node MAY decline to process the TREB of a traced bundle (for example, due to policy, trust in the source, topology-disclosure restrictions, or resource constraints). A node that declines, i.e., a transparent node, SHALL forward the TREB unchanged and SHALL NOT remove it. A node that processes the TREB SHALL create a hop-record with event-type 1 and append it as specified in Section 4.3.¶
A TREB in a bundle whose "ADU is an administrative record" bundle processing control flag is set is a report copy. Because the primary block is immutable (Section 4.3.1 of [RFC9171]), every node can make this distinction. Report copies are handled as follows:¶
No node adds a TREB to a bundle whose payload is an administrative record (Section 4.2), and the node that delivers a report bundle does not append a record.¶
When delivering a traced bundle, a participating node SHALL create a hop-record with event-type 2, with next-node-id equal to self-node-id, and append it as specified in Section 4.3. The BPA MAY make the resulting treb-data available to the application registered at the destination endpoint, so that it can be returned to the departure node (Section 4.2.1). The interface for doing so is implementation-specific.¶
When a participating node deletes a traced bundle and generates a deletion status report for it, the node SHALL create a hop-record with event-type 3 and next-node-id equal to self-node-id and include it in the report copy (Section 4.7). The reason for deletion is conveyed by the status report's reason code.¶
Nodes supporting this specification SHOULD enable status reporting for traced bundles, subject to local policy. This does not change the default of Section 5.1 of [RFC9171]: enabling remains an operator decision, and the bounded size of report copies (Section 7.3) is intended to make the risk of excessive traffic acceptable for traced bundles.¶
When a participating node generates a bundle status report for a traced bundle, the report bundle SHALL carry exactly one TREB, the report copy, whose traceroute-id and record-limit are copied from the traced bundle's TREB, whose hop-records are set as follows, and to which report-value is added as the last element:¶
A node that generates a delivery or deletion report copy SHALL, when it queues the report bundle for transmission to its next hop, create a hop-record with event-type 0 describing that queuing, as a departure node does for a traced bundle, and append it to the report copy as specified in Section 4.3. This record is the first return record; it describes the first hop of the return path, which would otherwise not be recorded. No such record is created if the report is delivered locally.¶
A report copy therefore contains at most record-limit + 1 hop-records when generated. Up to record-limit return records may then be appended (Section 4.4), so a report copy contains at most 2 x record-limit + 1 hop-records when it arrives.¶
A node MAY omit the report copy, for example when the report-to EID does not identify the bundle's source node, or under the mitigations in Section 7.3.¶
The departure node correlates report copies with the traceroute by traceroute-id, checked against the subject bundle identification in each status report (Section 3.3). It places the hop-record of a forwarding report at position report-value, and the hop-records of a delivery or deletion report at positions 0, 1, and so on, of the reconstructed trace, up to and including the first hop-record with event-type 2 or 3 (the turnaround record). The hop-records that follow the turnaround record are return records; in the order received, they describe the path of the report bundle toward the report-to endpoint and are not placed at positions. Consecutive records are linked by next-node-id and the following record's self-node-id, and by prev-node-id and the preceding record's self-node-id. None of this requires synchronized clocks.¶
Traceroutes are independent of one another. A node may be the departure node of several traceroutes at the same time, and may forward a traced bundle of another departure node while its own traceroutes are in progress. Every report copy carries the traceroute-id and is checked against the subject bundle identification, so report copies of different traceroutes are never confused. This also holds when a traced bundle is carried inside another traced bundle (Section 4.10): the two TREBs belong to different bundles and are processed and reported separately. A report copy that matches no traceroute in progress, for example one received after the departure node has restarted, SHALL be ignored.¶
Positions 0 to record-limit - 1 are filled as above. A record whose position would be record-limit or higher was created after the TREB had become full (overflow). Overflow records are not ordered by position; the departure node orders them by chaining, starting from the next-node-id of the record at position record-limit - 1. A forwarding report with report-value equal to record-limit, or a delivery or deletion report whose turnaround record is at position record-limit, indicates that overflow occurred; a larger record-limit can then be used for subsequent probes. Appendix A.2 gives worked examples.¶
Figure 4 summarizes this procedure; it is informative, and the text above takes precedence.¶
Legend: RC = report copy; rv = report-value; L = record-limit
slot[0..L-1] = positions; OVF = set of overflow records
RET = return records (after the turnaround record)
Hr = hop count reported in a delivery/deletion RC
(local variable; no block is modified)
Rcv RC (same traceroute-id; subject bundle matches)
|
+-- Forwarding report? ---yes--+
| |
| no (delivery or deletion) V
| rv < L ? --yes--> slot[rv] := record
V |
for i = 0, 1, ... over the no (rv = L: overflow)
records of the RC up to and |
including the turnaround +----------> add record to OVF
record (event-type 2 or 3):
i < L ? --yes--> slot[i] := record
|
no
+-------------> add record to OVF
|
records after the turnaround record --> add to RET, in order
|
rv > 0 ? --yes--> record Hr := rv
|
V
... repeat for each RC until completion (Figure 2) ...
|
V
1. Path := slot[0], slot[1], ... in order; then OVF records
ordered by chaining from the next-node-id of the
last record in slot[L-1]
2. Empty slot k before the -> report of the node at position k
last filled slot missing (lost or not generated)
3. slot[k].next-node-id -> transparent node(s) after
!= slot[k+1].self-node-id slot[k]; the first is
slot[k].next-node-id, the
last slot[k+1].prev-node-id
4. OVF not empty or an -> overflow; use a larger
RC with rv = L record-limit next time
5. Hr known: Hr - (number of records with event-type 0 or 1,
including OVF, excluding RET) = hops made by
transparent nodes
6. Return path := RET in order; if the last next-node-id is not
this node, the return path was partly traced
More than one record for a position: The departure node can receive more than one record for the same position.¶
Completion occurs at the first delivery or deletion report (Section 5); a departure node that expects reports from several branches MAY instead keep the traceroute open until treb-completion-timeout.¶
A traceroute completes successfully when the departure node receives a delivery report whose report copy contains a hop-record with event-type 2, or the destination application returns the treb-data.¶
With forwarding reports, the departure node can distinguish two kinds of gap in the reconstructed trace:¶
A delivery or deletion report fills all empty positions up to the reporting node. Among overflow records and return records only the chaining test is available. If the next-node-id of the last return record is not the node that received the report, the return path was only partly traced (transparent nodes, or record-limit reached).¶
The chaining test identifies the first node of a segment of transparent nodes (record k's next-node-id) and, where prev-node-id is known, its last node (record k+1's prev-node-id), but not how many nodes the segment contains. In a delivery or deletion report, report-value (the hop count) minus the number of records with event-type 0 or 1 in the reconstructed trace, including overflow records but excluding return records, gives the number of hops made by transparent nodes, provided every node updates the Hop Count Block as specified in [RFC9171]. A delivery report whose report-value exceeds the hop limit set by the departure node indicates a node that did not enforce the hop limit.¶
With bit 0 of the block processing control flags set to 0 (Section 3.4), Section 5.8 of [RFC9171] places the TREB only in the fragment whose offset is zero, so exactly one TREB survives reassembly and its hop-records remain a single ordered sequence. Hop-records are appended only to that fragment.¶
Only the fragment that carries the TREB is a traced bundle; the trace describes the path of that fragment, and other fragments may take other paths. A status report for a fragment without a TREB contains no report copy and is not used in path reconstruction (Section 4.8). Delivery takes place after reassembly, in the bundle that holds the fragment with offset zero and therefore the TREB (Section 5.9 of [RFC9171]). If reassembly does not complete, no delivery report is generated, and the traceroute ends by deletion or timeout (Section 4.8.2).¶
The purpose of the TREB is to show whether a bundle reached its destination and, if not, where along the path it stopped. Bundle-in-Bundle Encapsulation (BIBE) [I-D.ietf-dtn-bibe] acts as a convergence layer that tunnels a bundle between an encapsulator and a decapsulator as the payload of an encapsulating bundle. Nodes inside the tunnel process only the encapsulating bundle, so the TREB of the encapsulated bundle is processed only at the encapsulator and the decapsulator, and the tunnel appears in the trace as a single hop: the encapsulator's hop-record names the decapsulator as next-node-id, with link-info describing the tunnel as a whole. As on any single hop, the hop count of the encapsulated bundle advances once across the tunnel, so the chaining and hop count tests (Section 4.8.3) remain consistent, and nodes inside the tunnel are not counted as transparent nodes.¶
If the encapsulated bundle does not emerge from the tunnel, the departure node learns from the encapsulator's forwarding report that the bundle entered the tunnel toward the decapsulator. Diagnosing the tunnel is the responsibility of the encapsulator and is out of scope of this document. If the encapsulator eventually deletes the encapsulated bundle, its deletion report reaches the departure node as usual (Section 4.6). No change to BIBE is required.¶
A participating node MAY withhold prev-node-id by using the null endpoint, and event-time, radiate-time, and any element of link-info by using the value 0; for example:¶
link-info = [0, 0, 0, 0, 0] ; All fields withheld¶
A value of 0 in these fields SHALL NOT be treated as an error. This supports deployments spanning administrative domains with different disclosure policies. A node that must not disclose its identity declines to process the TREB (Section 4.4).¶
The following managed parameter is part of the local configuration (Management Information Base) of a departure node. It does not appear in any bundle.¶
| Parameter | Description | Units |
|---|---|---|
| treb-completion-timeout | Maximum time, measured by the departure node from when it queues the traced bundle (Section 4.2), during which it processes report copies for that bundle. | milliseconds |
This interval requires only a local timer, not synchronized or absolute time, so it also applies to a departure node without an accurate clock (creation time 0); how the interval is measured is implementation-specific.¶
When treb-completion-timeout expires, the departure node SHALL complete the traceroute (Section 4.8) using only the report copies received up to that time, and SHALL ignore report copies for that bundle received afterwards.¶
A traceroute also completes, before treb-completion-timeout expires, when a delivery or deletion report copy is received (Section 4.8), unless the departure node keeps it open until the timeout as permitted for custody transfer (Section 1.2) and for bundles that took several paths (Section 4.8); report copies for that traceroute received after completion are ignored. See Figure 2.¶
A bundle cannot be recalled once sent; a traced bundle may therefore remain in the network until its lifetime expires, and reports may still arrive after the timeout. To obtain a deletion report for a bundle whose lifetime expires, the departure node SHOULD set the bundle's lifetime so that it expires early enough for that report to arrive before treb-completion-timeout.¶
[RFC Editor: please remove this section before publication, as well as the reference to RFC 7942.]¶
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
No implementations are listed in this revision. Implementation reports, including measured overhead, will be added in a future revision.¶
The TREB reveals node identities, path, link characteristics, congestion, and timing. Operators SHOULD restrict TREB processing to authorized sources, and nodes MAY decline to participate or withhold fields (Section 4.11). Confidentiality can be provided by a Block Confidentiality Block (BCB) [RFC9172]: hop by hop for the TREB of a traced bundle and of a delivery or deletion report copy, and by the reporting node for a forwarding report copy (Section 7.2).¶
Like the Previous Node, Hop Count, and Bundle Age blocks [RFC9171], the TREB of a traced bundle, and of a delivery or deletion report copy on its return path, is modified at each participating node. It is therefore handled in the same way: end-to-end integrity or confidentiality of the TREB is not possible. A Block Integrity Block (BIB) or BCB targeting the TREB can protect it only until it is next modified: the security operation has to be accepted, according to security policy, at or before the next participating node [RFC9172]. Appending a hop-record changes only the TREB; BIBs and BCBs targeting other blocks are unaffected. As with the values of those blocks, TREB field values, including traceroute-id (sequential after a random first value), are predictable and can be forged by an on-path node; the TREB relies on the same protection practice.¶
Hop-records are unauthenticated end to end and SHALL be treated as diagnostic data only; they MUST NOT be used as input to routing or access-control decisions. A forwarding report copy is not modified after creation (Section 4.4); the reporting node MAY add a BIB or BCB targeting it, for example using the security contexts of [RFC9173].¶
prev-node-id allows the next hop claimed by one node to be compared with the previous node observed by the following node. A mismatch that is not explained by transparent nodes indicates an error or tampering, but it does not show which of the two nodes is responsible, and prev-node-id is itself unauthenticated. Conversely, a consistent chain does not prove that the recorded nodes forwarded the bundle: an on-path node can forge records that are consistent with one another.¶
The TREB does not by itself cause additional bundles to be generated; reports are generated only as requested and permitted under [RFC9171]. However, report copies increase the size of reports. Because the report-to EID is not authenticated in BPv7, a spoofed diagnostic bundle could direct larger reports to a third party. This specification bounds the increase: a forwarding report carries exactly one hop-record, and a delivery or deletion report carries at most record-limit + 1 hop-records from the traced bundle and at most record-limit return records (at most 511 in total). Nodes SHOULD rate-limit report copy generation and MAY omit the report copy when the report-to EID does not identify the bundle's source node (Section 4.7).¶
TREB growth is bounded by record-limit. Implementations SHOULD rate-limit TREB processing and MAY decline to process TREBs under resource pressure.¶
IANA is requested to register the following in the "Bundle Block Types" registry, from the range currently unassigned below 192:¶
| Bundle Protocol Version | Value | Description | Reference |
|---|---|---|---|
| 7 | TBD1 | Traceroute Extension Block | This document |
IANA is requested to create a registry titled "TREB Event Type Codes" in the "Bundle Protocol" registry group. Values are unsigned integers 0-255. Registration procedures [RFC8126]: 0-191 Specification Required; 192-255 Private or Experimental Use. Initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | departure | This document |
| 1 | forwarding | This document |
| 2 | delivery | This document |
| 3 | deletion | This document |
| 4-191 | Unassigned | |
| 192-255 | Private or Experimental Use | This document |
IANA is requested to create a registry titled "TREB Link Type Codes" in the "Bundle Protocol" registry group. Values are unsigned integers 0-255. Registration procedures [RFC8126]: 0-191 Specification Required; 192-255 Private or Experimental Use. Initial values:¶
| Value | Description | Reference |
|---|---|---|
| 0 | unknown or withheld | This document |
| 1 | RF | This document |
| 2 | optical | This document |
| 3 | terrestrial / Internet | This document |
| 4 | inter-satellite link | This document |
| 5-191 | Unassigned | |
| 192-255 | Private or Experimental Use | This document |
No registry is created for convergence layer types (Section 3.3) or for congestion, which is a numeric value.¶
Examples use the experimental block type value 194 and "ipn" Node IDs.¶
This example follows a traceroute carrier bundle over three nodes and shows, at each node, the complete bundle and the bundle status report (BSR) it generates. Forwarding, delivery, and deletion reports and status times are requested. The encodings were generated programmatically; sizes are of the complete encoded bundles. Times are DTN times in milliseconds.¶
Earth Ground Station (ipn:1.0) departure | RF, 2,000 kbps, 385,000 km, cl 3 (LTP), congestion 12% v Lunar Orbiter (ipn:2.0) intermediate | RF, 256 kbps, 250 km, cl -1, congestion 47% v Lunar Lander (ipn:3.0) destination¶
Notation: ipn:N.S stands for [2, [N, S]] and dtn:none for [1, 0]; << >> denotes CBOR-encoded data in a byte string. Primary-block flags 458820 (0x70044) = must not be fragmented, status time requested, and forwarding, delivery, and deletion reports requested; 2 = ADU is an administrative record. cl 3 is the "SAND CL Types" value for LTP; cl -1 is a private value of that registry, used here to denote another convergence layer on the orbiter-lander link.¶
Bundle as queued for ipn:2.0 (172 bytes):¶
[_
; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
[7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
86400000, h'F419'],
; Hop Count Block: limit 16, count 0
[10, 3, 0, 0, << [16, 0] >>],
; TREB (traced bundle: 3 elements, no report-value)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]]
]] >> ],
; payload block
[1, 1, 0, 0,
'This bundle is the host of traceroute extension block.']
]
¶
Bundle as queued for ipn:3.0 (217 bytes). Only the Hop Count Block and the TREB have changed:¶
[_
; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
[7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
86400000, h'F419'],
; Hop Count Block: limit 16, count 1
[10, 3, 0, 0, << [16, 1] >>],
; TREB (traced bundle: 3 elements, no report-value)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]]
]] >> ],
; payload block
[1, 1, 0, 0,
'This bundle is the host of traceroute extension block.']
]
¶
Forwarding report (142 bytes; 83 bytes without the report copy). The orbiter queued the bundle at 841307665784 (event-time), but its next contact with the lander was planned to begin 10 minutes later, which it records as radiate-time 841308265784. The BSR asserts forwarding at that time:¶
[_
; primary block: admin record flag; (BSR) to ipn:1.0 from ipn:2.0
[7, 2, 1, ipn:1.0, ipn:2.0, dtn:none, [841308265784, 0],
86400000, h'6B60'],
; TREB (report copy: 4 elements, report-value 1)
[194, 2, 0, 0, << [17, 32, [
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]]
], 1] >> ],
; admin record payload block: bundle status report (forwarded)
[1, 1, 0, 0, << [1, [
[[false], [true, 841308265784], [false], [false]],
0, ipn:1.1, [841307664384, 0]]] >>]
]
¶
Bundle as delivered (250 bytes):¶
[_
; primary block (identical at every hop): to ipn:3.1 from ipn:1.1
[7, 458820, 1, ipn:3.1, ipn:1.1, ipn:1.0, [841307664384, 0],
86400000, h'F419'],
; Hop Count Block: limit 16, count 2
[10, 3, 0, 0, << [16, 2] >>],
; TREB (traced bundle: 3 elements, no report-value)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.0, ipn:3.0, 2, 841308265804, 0,
[0, 0, 0, 0, 0]]
]] >> ],
; payload block
[1, 1, 0, 0,
'This bundle is the host of traceroute extension block.']
]
¶
Delivery report as queued by the lander for ipn:2.0 (261 bytes; 83 bytes without the report copy). When queuing the report bundle, the lander appends its own return record (event-type 0), describing the first hop of the return path (Section 4.7):¶
[_
; primary block: admin record flag; (BSR) to ipn:1.0 from ipn:3.0
[7, 2, 1, ipn:1.0, ipn:3.0, dtn:none, [841308265804, 0],
86400000, h'AF24'],
; TREB (report copy: 4 elements, report-value 2)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.0, ipn:3.0, 2, 841308265804, 0,
[0, 0, 0, 0, 0]],
[ipn:3.0, dtn:none, ipn:2.0, 0, 841308265809,
841308265809, [1, 128, 250, -1, 3]]
], 2] >> ],
; admin record payload block: bundle status report (delivered)
[1, 1, 0, 0, << [1, [
[[false], [false], [true, 841308265804], [false]],
0, ipn:1.1, [841307664384, 0]]] >>]
]
¶
The delivery report carries the full trace (Section 4.7), so that the path is complete even when forwarding reports are lost or not generated.¶
The delivery report travels back through the orbiter. Its report copy contains a record with event-type 2 and one return record, fewer than record-limit (32), so the orbiter appends a second return record when queuing the report bundle for ipn:1.0 (Section 4.4). The forwarding report above is not modified. Delivery report as queued by the orbiter for ipn:1.0 (309 bytes; only the TREB has changed):¶
[_
; primary block (unchanged): (BSR) to ipn:1.0 from ipn:3.0
[7, 2, 1, ipn:1.0, ipn:3.0, dtn:none, [841308265804, 0],
86400000, h'AF24'],
; TREB (report copy with two return records, report-value 2)
[194, 2, 0, 0, << [17, 32, [
[ipn:1.0, dtn:none, ipn:2.0, 0, 841307664484,
841307664484, [1, 2000, 385000, 3, 12]],
[ipn:2.0, ipn:1.0, ipn:3.0, 1, 841307665784,
841308265784, [1, 256, 250, -1, 47]],
[ipn:3.0, ipn:2.0, ipn:3.0, 2, 841308265804, 0,
[0, 0, 0, 0, 0]],
[ipn:3.0, dtn:none, ipn:2.0, 0, 841308265809,
841308265809, [1, 128, 250, -1, 3]],
[ipn:2.0, ipn:3.0, ipn:1.0, 1, 841308265844,
841308265844, [1, 10000, 385000, 3, 46]]
], 2] >> ],
; admin record payload block: bundle status report (delivered)
[1, 1, 0, 0, << [1, [
[[false], [false], [true, 841308265804], [false]],
0, ipn:1.1, [841307664384, 0]]] >>]
]
¶
The departure node places the forwarding report's record at position 1 (its report-value) and the delivery report's records at positions 0 to 2, up to the turnaround record, obtaining ipn:1.0 -> ipn:2.0 -> ipn:3.0. The delivery report's report-value 2 is the hop count; two records at these positions have event-type 0 or 1, so every hop was made by a participating node. The fourth and fifth records are return records: the report returned via ipn:3.0 -> ipn:2.0 -> ipn:1.0, with link information for both hops, and because the next-node-id of the last one is the departure node, the return path is complete.¶
This example shows how report-value is set and how the departure node uses it. The path is A -> B -> C -> D. Forwarding, delivery, and deletion reports are requested. For brevity, a hop-record is written as its self-node-id and next-node-id only.¶
The traced bundle carries no report-value; each participating node appends one record.¶
Queued at A: [A->B] Queued at B: [A->B, B->C] Queued at C: [A->B, B->C, C->D] Delivered at D: [A->B, B->C, C->D, D->D]¶
Each forwarding report carries only the reporting node's record. Its report-value is the number of records the TREB held before that node appended its own, i.e., the position of that record. The delivery report carries the full trace; its report-value is the hop count (3: A, B, and C each forwarded the bundle once). D appends its own return record D->C when queuing the report, and C and B append theirs on the way back; the forwarding reports are not modified.¶
Report from Type report-value hop-records
----------- ---------- ------------ ----------------------
B forwarding 1 (position) [B->C]
C forwarding 2 (position) [C->D]
D delivery 3 (hops) [A->B, B->C, C->D, D->D]
D's report copy as received at A (return records by D, C, B):
[A->B, B->C, C->D, D->D,
D->C, C->B, B->A]
¶
Node A, the departure node, already holds its own record.¶
The departure node keeps a table of positions. It writes each forwarding report's record at report-value and the delivery report's records from position 0. The order in which reports arrive does not matter. Records after the turnaround record D->D are return records and are not placed at positions. Three records at positions have event-type 0 or 1 (A, B, C), equal to the hop count 3, so no hop was made by a transparent node.¶
Position: 0 1 2 3 From A: A->B From C: C->D From B: B->C From D: A->B B->C C->D D->D return: D->C, C->B, B->A Result: A->B B->C C->D D->D Return path: D -> C -> B -> A¶
Suppose the traced bundle is lost after C and no delivery report arrives.¶
Case 1: B's forwarding report is lost (B participated).¶
Position: 0 1 2 Result: A->B -- C->D¶
Position 1 is empty. Because C's record is at position 2, some node appended the record at position 1, but its report was not received (lost, or not generated). A->B indicates that this node was B.¶
Case 2: B does not participate (transparent node).¶
Traced bundle after C: [A->B, C->D] (C's record is at 1) C's forwarding report: report-value 1, [C->D] Position: 0 1 Result: A->B C->D¶
A->B does not chain to C->D: B forwarded the bundle without participating. The departure node learns B's identity from A's next-node-id and from C's prev-node-id, but nothing else about B.¶
Now let record-limit be 2 on the same path A -> B -> C -> D. The TREB becomes full at B; C and D do not modify it.¶
Queued at A: [A->B]
Queued at B: [A->B, B->C] (full)
Queued at C: [A->B, B->C] (unchanged)
Delivered at D: [A->B, B->C] (unchanged)
Report from Type report-value hop-records
----------- ---------- ------------ ----------------------
B forwarding 1 (position) [B->C]
C forwarding 2 (overflow) [C->D]
D delivery 3 (hops) [A->B, B->C, D->D]
D's report copy as received at A (return records by D and C):
[A->B, B->C, D->D,
D->C, C->B]
¶
Positions 0 and 1 hold A->B and B->C. C->D (report-value 2) and D->D (third record of D's report copy, position 2) are overflow records. Chaining from B->C gives C->D and then D->D:¶
Position: 0 1 overflow (by chaining) Result: A->B B->C C->D D->D¶
C's report-value equals record-limit, and the turnaround record of D's report copy is at position record-limit; either shows that overflow occurred. record-limit applies separately to the return path, so D and C still append their return records D->C and C->B. B does not append, because the report copy already holds record-limit return records; since the next-node-id of the last return record (C->B) is not A, the departure node knows that the return path was only partly traced.¶
| Distance (km) | link-info [1, d, 0, 10] | Bytes |
|---|---|---|
| 400,000 (Moon) | 84 01 1A 00 06 1A 80 00 0A | 9 |
| 225,000,000 (Mars, mean) | 84 01 1A 0D 69 3A 40 00 0A | 9 |
| 4,500,000,000 (Neptune) | 84 01 1B 00 00 00 01 0C 38 8D 00 00 0A | 13 |
Distances up to 4,294,967,295 km use the same 5-byte CBOR unsigned integer encoding; only a link longer than that adds 4 bytes, and only to the hop-record describing that link.¶
With small "ipn" node numbers, a hop-record is typically 41-48 bytes, depending on the encoded values, of which 18 bytes are event-time and radiate-time (9 bytes each); a delivery or deletion record is about 33 bytes. Using 47 bytes as a representative record size, a TREB with N hop-records occupies approximately 13 + 47N bytes including the canonical block header. For comparison, the TREB of Appendix A.1.3 is 136 bytes: 13 bytes of block header and array overhead, two records of 45 bytes, and a delivery record of 33 bytes. A report copy adds report-value (1 byte for positions up to 23).¶
Total status report bytes returned to the departure node for a path of N participating nodes. Each bundle status report bundle without a report copy is taken to be 83 bytes, the encoded size of the reports in Appendix A.1 (status time requested, DTN time available, CRC-16 on the primary block); it is 74 bytes without status time and 57 bytes for a source without a clock. About 27 of the 83 bytes are the three DTN time values (creation time, status time, and subject creation time), 9 bytes each. A report copy adds 14 bytes of overhead and 47 bytes per hop-record. On a symmetric path, the delivery report also collects N - 1 return records (Section 4.4), which are included in the last two columns. All columns use the record size of this document, and each of the first three columns counts N - 1 forwarding reports and one delivery report.¶
| N | Plain BSRs: forwarding + delivery (no path detail) | -00 (accumulated trace in each forwarding report) | This document: forwarding + delivery | Of which: the delivery report |
|---|---|---|---|---|
| 2 | 166 | 335 | 382 | 238 |
| 3 | 249 | 573 | 620 | 332 |
| 5 | 415 | 1,190 | 1,096 | 520 |
| 8 | 664 | 2,468 | 1,810 | 802 |
| 16 | 1,328 | 7,944 | 3,714 | 1,554 |
| 32 | 2,656 | 27,920 | 7,522 | 3,058 |
| 255 | 21,165 | 1,558,815 | 60,596 | 24,020 |
N = 255 is the largest hop limit of the Hop Count Block (Section 4.4.3 of [RFC9171]) and the largest record-limit (Section 3.2), so it bounds the path length for which reports are complete when the hop limit is enforced.¶
Accumulating the trace in every forwarding report (as in -00) grows as O(N^2) (bounded by record-limit); single-record forwarding reports and return records grow as O(N). The delivery report, which carries the whole path in both directions, accounts for about 40% of the total for N of 8 or more. Forwarding reports add about 61 bytes per hop compared with plain bundle status reports, in exchange for per-hop timing, link, and congestion information that bundle status reports do not carry.¶
[RFC Editor: please remove this section before publication.]¶
The author thanks the CCSDS SIS-DTN Working Group for input on DTN diagnostic requirements, and Nicholas Perry for a detailed review of -00.¶