idnits 2.17.1 draft-ietf-dtn-bibect-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2019) is 1912 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay-Tolerant Networking Working Group S. Burleigh 2 Internet Draft JPL, Calif. Inst. Of Technology 3 Intended status: Standards Track January 31, 2019 4 Expires: August 2019 6 Bundle-in-Bundle Encapsulation 7 draft-ietf-dtn-bibect-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 4, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 49 Abstract 51 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 52 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence 53 layer" protocol that tunnels BP "bundles" through encapsulating 54 bundles. The services provided by the BIBE convergence-layer 55 protocol adapter encapsulate an outbound BP "bundle" in a BIBE 56 convergence-layer protocol data unit for transmission as the payload 57 of a bundle. Security measures applied to the encapsulating bundle 58 may augment those applied to the encapsulated bundle. The protocol 59 includes a mechanism for recovery from loss of an encapsulating 60 bundle, called "custody transfer". This mechanism is adapted from 61 the custody transfer procedures described in the experimental Bundle 62 Protocol specification developed by the Delay-Tolerant Networking 63 Research group of the Internet Research Task Force and documented in 64 RFC 5050. 66 Table of Contents 68 1. Introduction...................................................2 69 2. Conventions used in this document..............................4 70 3. BIBE Design Elements...........................................4 71 3.1. BIBE Endpoints............................................4 72 3.2. BIBE Protocol Data Units..................................4 73 3.3. Custody Signals...........................................6 74 3.4. Custody Transfer Status Reports...........................7 75 4. BIBE Procedures................................................8 76 4.1. BPDU Transmission.........................................8 77 4.2. BPDU Reception............................................8 78 4.3. Retransmission Timer Expiration..........................10 79 4.4. Custody Signal Reception.................................10 80 5. Security Considerations.......................................11 81 6. IANA Considerations...........................................11 82 7. References....................................................11 83 7.1. Normative References.....................................11 84 7.2. Informative References...................................11 85 8. Acknowledgments...............................................11 86 Appendix A. For More Information.................................13 87 Appendix B. CDDL expression......................................14 89 1. Introduction 91 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 92 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC5050] 93 "convergence layer" protocol that tunnels BP "bundles" through 94 encapsulating bundles. 96 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 98 Conformance to the bundle-in-bundle encapsulation (BIBE) 99 specification is OPTIONAL for BP nodes. Each BP node that conforms 100 to the BIBE specification provides a BIBE convergence-layer adapter 101 (CLA) that is implemented within the administrative element of the 102 BP node's application agent. Like any convergence-layer adapter, 103 the BIBE CLA provides: 105 . A transmission service that sends an outbound bundle (from the 106 bundle protocol agent) to a peer CLA. In the case of BIBE, the 107 sending CLA and receiving peer CLA are both BP nodes. 108 . A reception service that delivers to the bundle protocol agent 109 an inbound bundle that was sent by a peer CLA (itself a BP 110 node) via the BIBE convergence layer protocol. 112 The BIBE CLA performs these services by: 114 . Encapsulating outbound bundles in BIBE protocol data units, 115 which take the form of Bundle Protocol administrative records 116 as described later. 117 . Requesting that the bundle protocol agent transmit bundles 118 whose payloads are BIBE protocol data units. 119 . Taking delivery of BIBE protocol data units that are the 120 payloads of bundles received by the bundle protocol agent. 121 . Delivering to the bundle protocol agent the bundles that are 122 encapsulated in delivered BIBE protocol data units. 124 Bundle-in-bundle encapsulation may have broad utility, but the 125 principal motivating use case is the deployment of "cross domain 126 solutions" in secure communications. Under some circumstances a 127 bundle may arrive at a node that is on the frontier of a sector of 128 network topology in which augmented security is required, from which 129 the bundle must egress at some other designated node. In that case, 130 the bundle may be encapsulated within a bundle to which the 131 requisite additional BP Security (BPSEC) [bpsec] extension block(s) 132 can be attached, whose source is the point of entry into the 133 insecure region (the "security source") and whose destination is the 134 point of egress from the insecure region (the "security 135 destination"). 137 Note that: 139 . If the payload of the encapsulating bundle is protected by a 140 Bundle Confidentiality Block (BCB), then the source and 141 destination of the encapsulated bundle are encrypted, providing 142 defense against traffic analysis that BPSEC alone cannot offer. 143 . Bundles whose payloads are BIBE protocol data units may 144 themselves be forwarded via a BIBE convergence-layer adapter, 146 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 148 enabling nested bundle encapsulation to arbitrary depth as 149 required by security policy. 150 . Moreover, in the event that no single point of egress from an 151 insecure region of network topology can be determined at the 152 moment a bundle is to be encapsulated, multiple copies of the 153 bundle may be encapsulated individually and forwarded to all 154 candidate points of egress. 156 The protocol includes a mechanism for recovery from loss of an 157 encapsulating bundle, called "custody transfer". This mechanism is 158 adapted from the custody transfer procedures described in the 159 experimental Bundle Protocol specification developed by the Delay- 160 Tolerant Networking Research group of the Internet Research Task 161 Force and documented in RFC 5050. Custody transfer is a convention 162 by which the loss or corruption of BIBE encapsulating bundles can be 163 mitigated by the exchange of other bundles, which are termed 164 "custody signals". 166 2. Conventions used in this document 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC-2119 [RFC2119]. 172 In this document, these words will appear with that interpretation 173 only when in ALL CAPS. Lower case uses of these words are not to be 174 interpreted as carrying RFC-2119 significance. 176 3. BIBE Design Elements 178 3.1. BIBE Endpoints 180 BIBE convergence-layer protocol endpoints, also known as BIBE 181 convergence-layer adapters (BCLAs), are the Administrative Elements 182 of Bundle Protocol nodes that conform to the BIBE protocol 183 specification. The node of which a given BCLA is one component is 184 termed the BCLA's "local node". 186 3.2. BIBE Protocol Data Units 188 Notionally, a BCLA is assumed to implement in some way, for each 189 neighboring node to which the local node issues BIBE Protocol Data 190 Units (BPDUs), the following two data resources: 192 1. A "custodial transmission count" (CTC). A CTC is a 193 monotonically increasing integer indicating the number of 194 "custodial" BPDUs - that is, BPDUs for which custody transfer 196 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 198 was requested - that have been issued to the neighboring node 199 by the local node since instantiation of the local node. 200 2. A "custodial transmission database" (CTDB), a notional array of 201 "custodial transmission items" (CTIs). The CTDB contains one 202 CTI for each custodial BPDU issued to the neighboring node, by 203 the local node, for which (a) no custody disposition has yet 204 been received in any custody signal (as discussed later) and 205 (b) the bundle encapsulated in that BPDU has not yet been 206 destroyed due to, e.g., time-to-live expiration. Each CTI 207 notionally contains: 208 a. A reference to the bundle encapsulated in the 209 corresponding BPDU. 210 b. The "transmission ID" of the corresponding BPDU, as 211 discussed below. 212 c. A "retransmission time" indicating the time by which 213 custody disposition for the corresponding BDPU is 214 expected. 216 A BIBE protocol data unit is a Bundle Protocol administrative record 217 whose record type code is 3 (i.e., bit pattern 0011), constructed as 218 follows. 220 Each BPDU SHALL be represented as a CBOR array. The number of 221 elements in the array SHALL be 3. 223 The first item of the BPDU array SHALL be the "transmission ID" for 224 the BPDU, represented as a CBOR unsigned integer. The transmission 225 ID for a BPDU for which custody transfer is NOT requested SHALL be 226 zero. The transmission ID for a BPDU for which custody transfer IS 227 requested SHALL be the current value of the local node's custodial 228 transmission count, plus 1. 230 The second item of the BPDU array SHALL be the BPDU's retransmission 231 time (i.e., the time by which custody disposition for this BPDU is 232 expected), represented as a CBOR unsigned integer. Retransmission 233 time for a BPDU for which custody transfer is NOT requested SHALL be 234 zero. Retransmission time for a BPDU for which custody transfer IS 235 requested SHALL take the form of a "DTN Time" as defined in the 236 Bundle Protocol specification; determination of the value of 237 retransmission time is an implementation matter that is beyond the 238 scope of this specification and may be dynamically responsive to 239 changes in connectivity. 241 The third item of the BPDU array SHALL be a single BP bundle, termed 242 the "encapsulated bundle", represented as a CBOR byte string of 243 definite length. 245 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 247 3.3. Custody Signals 249 A "custody signal" is a Bundle Protocol administrative record whose 250 record type code is 4 (i.e., bit pattern 0100) and whose content is 251 constructed as follows. 253 The content of each custody signal SHALL be represented as a CBOR 254 array. The number of elements in the array SHALL be 2. 256 The first item of the custody signal content array SHALL be a 257 disposition code represented as a CBOR unsigned integer. Valid 258 disposition codes are defined as follows: 260 +---------+--------------------------------------------+ 262 | Value | Meaning | 264 +=========+============================================+ 266 | 0 | Custody accepted. | 268 +---------+--------------------------------------------+ 270 | 1 | No further information. | 272 +---------+--------------------------------------------+ 274 | 2 | Reserved for future use. | 276 +---------+--------------------------------------------+ 278 | 3 | Redundant (reception by a node that | 280 | | already has a copy of this bundle). | 282 +---------+--------------------------------------------+ 284 | 4 | Depleted storage. | 286 +---------+--------------------------------------------+ 288 | 5 | Destination endpoint ID unintelligible. | 290 +---------+--------------------------------------------+ 292 | 6 | No known route destination from here. | 294 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 296 +---------+--------------------------------------------+ 298 | 7 | No timely contact with next node on route. | 300 +---------+--------------------------------------------+ 302 | 8 | Block unintelligible. | 304 +---------+--------------------------------------------+ 306 | (other) | Reserved for future use. | 308 +---------+--------------------------------------------+ 310 Figure 1: Disposition Codes 312 The second item of the custody signal content array SHALL be a 313 "disposition scope report", represented as a CBOR indefinite-length 314 array. Each item of the disposition scope report array SHALL be a 315 "disposition scope sequence", represented as a CBOR array of two 316 elements. The first element of each disposition scope sequence 317 array SHALL be the first transmission ID in a sequence of 1 or more 318 consecutive transmission IDs corresponding to BPDUs to which the 319 custody signal's disposition is declared to apply; the second 320 element of each disposition scope sequence array SHALL be the number 321 of transmission IDs in that sequence. Both are represented as CBOR 322 unsigned integers. 324 A custody signal constitutes an assertion by the source of that 325 administrative bundle that the indicated disposition code applies to 326 all BPDUs identified by the transmission IDs enumerated in the 327 custody signal's disposition scope report. If the disposition code 328 is zero, then the source of the custody signal has accepted custody 329 of all bundles that were encapsulated in the indicated BPDUs. 330 Otherwise the source of the custody signal has refused custody of 331 all bundles that were encapsulated in the indicated BPDUs, for the 332 indicated reason. 334 3.4. Custody Transfer Status Reports 336 A "custody transfer status report" is a bundle status report with 337 the "reporting node attempted custody transfer" flag set to 1. 339 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 341 4. BIBE Procedures 343 4.1. BPDU Transmission 345 When a BCLA is requested by the bundle protocol agent to send a 346 bundle to the peer BCLA(s) included in the BP endpoint identified by 347 a specified BP endpoint ID: 349 . The BCLA SHALL generate, as defined in Section 6.2 of the 350 Bundle Protocol specification (a work in progress), a BPDU for 351 which the third element of the content array is the bundle that 352 is to be transmitted. The destination of the bundle whose 353 payload is the BPDU (termed the "encapsulating bundle") SHALL 354 be the specified BP endpoint. Selection of the values of the 355 parameters governing the forwarding of the encapsulating 356 bundle, other than the destination endpoint ID, is an 357 implementation matter. The parameter values governing the 358 forwarding of the BPDU's encapsulated bundle MAY be consulted 359 for this purpose. 360 . Note that any transmission request presented to a BCLA MAY 361 request that the transmission be subject to Custody Transfer, 362 provided that the destination EID of the request identifies a 363 singleton endpoint. 364 . If Custody Transfer is requested: 365 o The first element of the BPDU's content array MUST be the 366 BPDU's transmission ID, which SHALL be 1 more than the 367 current value of the BCLA's CTC for the node that is the 368 sole occupant of the BPDU's destination endpoint. 369 o The second element of the BPDU's content array MUST be the 370 BPDU's retransmission time as discussed in 3.2 above. 371 o The bundle protocol agent MUST add the retention constraint 372 "Custody accepted" to the encapsulated bundle. 373 o The BCLA MAY establish a retransmission timer for the 374 encapsulated bundle. If a retransmission timer is 375 established, it MUST be set to expire at the BPDU's 376 retransmission time. 377 . Otherwise, the first two elements of the BPDU's content array 378 MUST both be zero. 380 Note that the custody transfer retransmission timer mechanism 381 provides a means of recovering from loss of an encapsulating bundle 382 as indicated by non-arrival of a responding custody signal. 384 4.2. BPDU Reception 386 When a BCLA receives a BPDU from the bundle protocol agent (that is, 387 upon delivery of the payload of an encapsulating bundle): 389 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 391 . If Custody Transfer was requested for this BPDU (as indicated 392 by a non-zero value of transmission ID): 393 o If the encapsulated bundle has the same source node ID, 394 creation timestamp, and (if that bundle is a fragment) 395 fragment offset and payload length as another bundle that 396 is currently retained at the BCLA's local node, then 397 custody transfer redundancy MUST be handled as follows: 398 . The BCLA SHALL add the BPDU's transmission ID to the 399 disposition scope report of a pending outbound 400 custody signal, destined for the node that was the 401 source of the encapsulating bundle, whose disposition 402 is the reason code from Figure 1 for "Redundant 403 reception". 404 o Otherwise, if the BCLA determines that its local node can 405 neither deliver nor forward the encapsulated bundle for 406 any of the reasons listed in Figure 1, then custody 407 transfer has failed. Custody transfer failure SHALL be 408 handled as follows: 409 . The BCLA SHALL add the BPDU's transmission ID to the 410 disposition scope report of a pending outbound 411 custody signal, destined for the node that was the 412 source of the encapsulating bundle, whose disposition 413 is the reason code from Figure 2 that indicates the 414 reason for the custody transfer failure. 415 o Otherwise, custody transfer has succeeded: 416 . The BCLA SHALL add the BPDU's transmission ID to the 417 disposition scope report of a pending outbound 418 custody signal, destined for the node that was the 419 source of the encapsulating bundle, whose disposition 420 is zero (indicating that custody was accepted). 421 o In each of these three cases: 422 . The pending outbound custody signal MAY then be 423 issued immediately, but alternatively it MAY be 424 issued at some time in the future, possibly enabling 425 additional BPDUs' transmission IDs to be added to the 426 same disposition scope report. 427 . If the "request reporting of custody transfer 428 attempted" flag in the encapsulating bundle's status 429 report request field is set to 1, and status 430 reporting is enabled, a custody transfer status 431 report whose reason code is the same as the pending 432 outbound custody signal's disposition SHOULD be 433 generated, destined for the report-to endpoint of the 434 encapsulating bundle. 435 . If Custody Transfer was NOT requested for this BPDU, or if 436 Custody Transfer was requested for this BPDU and custody 437 transfer succeeded, then the encapsulated bundle SHALL be 439 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 441 delivered from the convergence layer adapter to the bundle 442 protocol agent, whereupon bundle reception SHALL be performed 443 as defined in section 5.6 of the Bundle Protocol specification 444 (a work in progress) as usual: the encapsulated bundle may be 445 forwarded, delivered, etc. 447 Note that the manner in which pending outbound custody signals are 448 managed, disposition scope reports are aggregated, and custody 449 signal transmission is initiated is an implementation matter that 450 is beyond the scope of this specification. Note, however, that 451 failure to deliver a custody signal prior to the earliest value of 452 retransmission time among all BPDUs enumerated in the custody 453 signal's disposition scope report may result in unnecessary 454 retransmission of one or more BPDUs. 456 4.3. Retransmission Timer Expiration 458 Upon expiration of a retransmission timer, the BCLA SHOULD remove 459 the corresponding CTI from the CTDB (destroying the associated 460 retransmission timer, if any) and notify the bundle protocol agent 461 that custodial transmission of the indicated bundle failed. This 462 notification may cause the indicated bundle to be re-forwarded 463 (possibly on a different route). 465 4.4. Custody Signal Reception 467 When a BCLA receives a custody signal from the bundle protocol agent 468 (that is, upon delivery of the payload of a custody-signal-bearing 469 bundle): 471 . If the custody signal's disposition is 0 (custody acceptance), 472 then for each transmission ID in the custody signal's 473 disposition scope report: 474 o The bundle protocol agent MUST remove the retention 475 constraint "Custody accepted" on the bundle referenced by 476 the corresponding CTI. 477 o The corresponding CTI MUST be removed from the CTDB 478 (destroying the associated retransmission timer, if any). 479 . Otherwise (custody refusal), for each transmission ID in the 480 custody signal's disposition scope report: 481 o The corresponding CTI MUST be removed from the CTDB 482 (destroying the associated retransmission timer, if any). 483 o Any further action taken by the BCLA is implementation- 484 specific and may depend on the reason code cited for the 485 refusal. For example, if the custody signal's reason code 486 was "Depleted storage", the BCLA might choose to notify 487 the bundle protocol agent that custodial transmission of 489 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 491 the indicated bundle failed. If the reason code was 492 "Redundant reception", on the other hand, this might cause 493 the BCLA simply to instruct the bundle protocol agent to 494 remove the retention constraint "Custody accepted" on the 495 bundle referenced by the corresponding CTI and to revise 496 its algorithm for computing retransmission time. 498 5. Security Considerations 500 An adversary on a DTN-based network that can delete bundles could 501 delete a BIBE custody signal in transit. This could result in 502 unnecessary custodial retransmission, degrading network performance. 504 Alternatively, an adversary on a DTN-based network that can reorder 505 bundles could cause bundles to be delivered to a BCLA in an order 506 that complicates the efficient construction of disposition scope 507 reports in pending outbound custody signals. This could result in 508 inefficient custody transfer communications, again degrading network 509 performance. 511 Custody transfer in BIBE may be contraindicated in environments 512 characterized by such attacks. 514 6. IANA Considerations 516 The BIBE specification requires IANA registration of the new BIBE 517 administrative records (type codes 3 and 4) defined above. 519 7. References 521 7.1. Normative References 523 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 524 Requirement Levels", BCP 14, RFC 2119, March 1997. 526 7.2. Informative References 528 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 529 Specification", RFC 5050, November 2007. 531 8. Acknowledgments 533 This work is freely adapted from [RFC5050], which was an effort of 534 the Delay Tolerant Networking Research Group. The following DTNRG 535 participants contributed significant technical material and/or 536 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 537 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 539 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 541 Michael Demmer of the University of California at Berkeley, Robert 542 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 543 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 544 College Dublin, Peter Lovell and Howard Weiss of SPARTA, Inc., and 545 Manikantan Ramadas of Ohio University. 547 The custody transfer procedures defined in this specification are 548 adapted from the Aggregate Custody Signals draft specification 549 authored in 2010-2012 by Sebastian Kuzminsky and Andrew Jenkins, 550 then of the University of Colorado at Boulder. 552 Although the BIBE specification diverges in some ways from the 553 original Bundle-in-Bundle Encapsulation Internet Draft authored by 554 Susan Symington, Bob Durst, and Keith Scott of The MITRE Corporation 555 (draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of 556 that earlier document is gratefully acknowledged. 558 This document was prepared using 2-Word-v2.0.template.dot. 560 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 562 Appendix A. For More Information 564 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 565 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 567 Copyright (c) 2019 IETF Trust and the persons identified as authors 568 of the code. All rights reserved. 570 Redistribution and use in source and binary forms, with or without 571 modification, is permitted pursuant to, and subject to the license 572 terms contained in, the Simplified BSD License set forth in Section 573 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 574 (http://trustee.ietf.org/license-info). 576 Internet-Draft Bundle-in-Bundle Encapsulation January 20199 578 Appendix B. CDDL expression 580 For informational purposes, Carsten Bormann has kindly provided an 581 expression of the Bundle Protocol specification in the CBOR Data 582 Definition Language (CDDL). Portions of CDDL expression that bear 583 on the custody transfer extension are presented below, somewhat 584 edited by the authors. Note that wherever the CDDL expression is in 585 disagreement with the textual representation of the BP specification 586 presented in the earlier sections of this document, the textual 587 representation rules. 589 admin-record-choice /= BIBE-PDU 591 BIBE-PDU = [3, [transmission-ID: uint, 593 retransmission-time: uint, 595 encapsulated-bundle: bytes, 597 admin-common]] 599 admin-record-choice /= custody-signal 601 custody-signal = [4, [disposition-code: uint, 603 disposition-scope-report, 605 admin-common]] 607 disposition-scope-report = *disposition-scope-sequence 609 disposition-scope-sequence = [first-transmission-ID: uint, 611 number-of-transmission-IDs: uint] 613 Authors' Address 615 Scott Burleigh 616 Jet Propulsion Laboratory, California Institute of Technology 617 4800 Oak Grove Dr. 618 Pasadena, CA 91109-8099 619 US 620 Phone: +1 818 393 3353 621 Email: Scott.Burleigh@jpl.nasa.gov