idnits 2.17.1 draft-ietf-dtn-bibect-03.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 (February 18, 2020) is 1522 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 February 18, 2020 4 Expires: August 21, 2020 6 Bundle-in-Bundle Encapsulation 7 draft-ietf-dtn-bibect-03.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 21, 2020. 32 Copyright Notice 34 Copyright (c) 2020 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 Abstract 49 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 50 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence 51 layer" protocol that tunnels BP "bundles" through encapsulating 52 bundles. The services provided by the BIBE convergence-layer 53 protocol adapter encapsulate an outbound BP "bundle" in a BIBE 54 convergence-layer protocol data unit for transmission as the payload 55 of a bundle. Security measures applied to the encapsulating bundle 56 may augment those applied to the encapsulated bundle. The protocol 57 includes a mechanism for recovery from loss of an encapsulating 58 bundle, called "custody transfer". This mechanism is adapted from 59 the custody transfer procedures described in the experimental Bundle 60 Protocol specification developed by the Delay-Tolerant Networking 61 Research Group of the Internet Research Task Force and documented in 62 RFC 5050. 64 Table of Contents 66 1. Introduction...................................................2 67 2. Conventions used in this document..............................4 68 3. BIBE Design Elements...........................................4 69 3.1. BIBE Endpoints............................................4 70 3.2. BIBE Protocol Data Units..................................4 71 3.3. Custody Signals...........................................6 72 3.4. Custody Transfer Status Reports...........................8 73 4. BIBE Procedures................................................8 74 4.1. BPDU Transmission.........................................8 75 4.2. BPDU Reception............................................9 76 4.3. Retransmission Timer Expiration..........................10 77 4.4. Custody Signal Reception.................................10 78 5. Security Considerations.......................................11 79 6. IANA Considerations...........................................11 80 7. References....................................................11 81 7.1. Normative References.....................................11 82 7.2. Informative References...................................12 83 8. Acknowledgments...............................................12 84 Appendix A. For More Information.................................13 85 Appendix B. CDDL expression......................................14 87 1. Introduction 89 This document describes Bundle-in-Bundle Encapsulation (BIBE), a 90 Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [BP] 91 "convergence layer" protocol that tunnels BP "bundles" through 92 encapsulating bundles. 94 Conformance to the bundle-in-bundle encapsulation (BIBE) 95 specification is OPTIONAL for BP nodes. Each BP node that conforms 96 to the BIBE specification provides a BIBE convergence-layer adapter 97 (CLA) that is implemented by the administrative element of the BP 98 node's application agent. Like any convergence-layer adapter, the 99 BIBE CLA provides: 101 . A transmission service that sends an outbound bundle (from the 102 bundle protocol agent) to a peer CLA. In the case of BIBE, the 103 sending CLA and receiving peer CLA are both BP nodes. 104 . A reception service that delivers to the bundle protocol agent 105 an inbound bundle that was sent by a peer CLA (itself a BP 106 node) via the BIBE convergence layer protocol. 108 The BIBE CLA performs these services by: 110 . Encapsulating outbound bundles in BIBE protocol data units, 111 which take the form of Bundle Protocol administrative records 112 as described later. 113 . Requesting that the bundle protocol agent transmit bundles 114 whose payloads are BIBE protocol data units. 115 . Taking delivery of BIBE protocol data units that are the 116 payloads of bundles received by the bundle protocol agent. 117 . Delivering to the bundle protocol agent the bundles that are 118 encapsulated in delivered BIBE protocol data units. 120 Bundle-in-bundle encapsulation may have broad utility, but the 121 principal motivating use case is the deployment of "cross domain 122 solutions" in secure communications. Under some circumstances a 123 bundle may arrive at a node that is on the frontier of a sector of 124 network topology in which augmented security is required, from which 125 the bundle must egress at some other designated node. In that case, 126 the bundle may be encapsulated within a bundle to which the 127 requisite additional BP Security (BPSEC) [bpsec] extension block(s) 128 can be attached, whose source is the point of entry into the 129 insecure region (the "security source") and whose destination is the 130 point of egress from the insecure region (the "security 131 destination"). 133 Note that: 135 . If the payload of the encapsulating bundle is protected by a 136 Bundle Confidentiality Block (BCB), then the source and 137 destination of the encapsulated bundle are encrypted, providing 138 defense against traffic analysis that BPSEC alone cannot offer. 139 . Bundles whose payloads are BIBE protocol data units may 140 themselves be forwarded via a BIBE convergence-layer adapter, 141 enabling nested bundle encapsulation to arbitrary depth as 142 required by security policy. 143 . Moreover, in the event that no single point of egress from an 144 insecure region of network topology can be determined at the 145 moment a bundle is to be encapsulated, multiple copies of the 146 bundle may be encapsulated individually and forwarded to all 147 candidate points of egress. 149 The protocol includes a mechanism for recovery from loss of an 150 encapsulating bundle, called "custody transfer". This mechanism is 151 adapted from the custody transfer procedures described in the 152 experimental Bundle Protocol specification developed by the Delay- 153 Tolerant Networking Research Group of the Internet Research Task 154 Force and documented in RFC 5050 [RFC5050]. Custody transfer is a 155 convention by which the loss or corruption of BIBE encapsulating 156 bundles can be mitigated by the exchange of other bundles, which are 157 termed "custody signals". 159 2. Conventions used in this document 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in RFC-2119 [RFC2119]. 165 In this document, these words will appear with that interpretation 166 only when in ALL CAPS. Lower case uses of these words are not to be 167 interpreted as carrying RFC-2119 significance. 169 3. BIBE Design Elements 171 3.1. BIBE Endpoints 173 BIBE convergence-layer protocol endpoints, also known as BIBE 174 convergence-layer adapters (BCLAs), are implemented by the 175 administrative elements of the application agents of BP nodes that 176 conform to the BIBE protocol specification. The node of which a 177 given BCLA is one component is termed the BCLA's "local node". A BP 178 node that includes a BCLA is termed a "BIBE node". 180 3.2. BIBE Protocol Data Units 182 A BIBE Protocol Data Unit (BPDU) for which custody transfer is 183 requested is termed a "custodial BPDU". 185 Notionally, a BCLA is assumed to implement in some way, for each 186 BIBE node to which the local node issues custodial BPDUs, the 187 following two data resources: 189 1. A "custodial transmission count" (CTC). A CTC is a 190 monotonically increasing integer indicating the number of 191 custodial BPDUs that have been issued to this BIBE node by the 192 local node since instantiation of the local node. 193 2. A "custodial transmission database" (CTDB), a notional array of 194 "custodial transmission items" (CTIs). The CTDB contains one 195 CTI for each custodial BPDU issued to this BIBE node, by the 196 local node, for which (a) no custody disposition has yet been 197 received in any custody signal (as discussed later) and (b) the 198 bundle encapsulated in that BPDU has not yet been destroyed due 199 to, e.g., time-to-live expiration. Each CTI notionally 200 contains: 201 a. A reference to the bundle encapsulated in the 202 corresponding BPDU. 203 b. The "transmission ID" of the corresponding BPDU, as 204 discussed below. 205 c. A "retransmission time" indicating the time by which 206 custody disposition for the corresponding BDPU is 207 expected. 209 A BIBE protocol data unit is a Bundle Protocol administrative record 210 whose record type code is 3 (i.e., bit pattern 0011) and whose 211 representation conforms to the Bundle Protocol specification for 212 administrative record representation. The content of the record 213 SHALL be a BPDU message represented as follows. 215 Each BPDU message SHALL be represented as a CBOR array. The number 216 of elements in the array SHALL be 3. 218 The first item of the BPDU array SHALL be the "transmission ID" for 219 the BPDU, represented as a CBOR unsigned integer. The transmission 220 ID for a BPDU for which custody transfer is NOT requested SHALL be 221 zero. The transmission ID for a BPDU for which custody transfer IS 222 requested SHALL be the current value of the local node's custodial 223 transmission count, plus 1. 225 The second item of the BPDU array SHALL be the BPDU's retransmission 226 time (i.e., the time by which custody disposition for this BPDU is 227 expected), represented as a CBOR unsigned integer. Retransmission 228 time for a BPDU for which custody transfer is NOT requested SHALL be 229 zero. Retransmission time for a BPDU for which custody transfer IS 230 requested SHALL take the form of a "DTN Time" as defined in the 231 Bundle Protocol specification; determination of the value of 232 retransmission time is an implementation matter that is beyond the 233 scope of this specification and may be dynamically responsive to 234 changes in connectivity. 236 The third item of the BPDU array SHALL be a single BP bundle, termed 237 the "encapsulated bundle", represented as a CBOR byte string of 238 definite length. 240 3.3. Custody Signals 242 A "custody signal" is a Bundle Protocol administrative record whose 243 record type code is 4 (i.e., bit pattern 0100) and whose 244 representation conforms to the Bundle Protocol specification for 245 administrative record representation. The content of the record 246 shall be a Custody message represented as follows. 248 Each custody message SHALL be represented as a CBOR array. The 249 number of elements in the array SHALL be 2. 251 The first item of the custody signal content array SHALL be a 252 disposition code represented as a CBOR unsigned integer. Valid 253 disposition codes are defined as follows: 255 +---------+--------------------------------------------+ 257 | Value | Meaning | 259 +=========+============================================+ 261 | 0 | Custody accepted. | 263 +---------+--------------------------------------------+ 265 | 1 | No further information. | 267 +---------+--------------------------------------------+ 269 | 2 | Reserved for future use. | 271 +---------+--------------------------------------------+ 273 | 3 | Redundant (reception by a node that | 275 | | already has a copy of this bundle). | 277 +---------+--------------------------------------------+ 279 | 4 | Depleted storage. | 281 +---------+--------------------------------------------+ 282 | 5 | Destination endpoint ID unintelligible. | 284 +---------+--------------------------------------------+ 286 | 6 | No known route destination from here. | 288 +---------+--------------------------------------------+ 290 | 7 | No timely contact with next node on route. | 292 +---------+--------------------------------------------+ 294 | 8 | Block unintelligible. | 296 +---------+--------------------------------------------+ 298 | (other) | Reserved for future use. | 300 +---------+--------------------------------------------+ 302 Figure 1: Disposition Codes 304 The second item of the custody signal content array SHALL be a 305 "disposition scope report", represented as a CBOR array of definite 306 length. Each item of the disposition scope report array SHALL be a 307 "disposition scope sequence", represented as a CBOR array of two 308 elements. The first element of each disposition scope sequence 309 array SHALL be the first transmission ID in a sequence of 1 or more 310 consecutive transmission IDs corresponding to BPDUs to which the 311 custody signal's disposition is declared to apply; the second 312 element of each disposition scope sequence array SHALL be the number 313 of transmission IDs in that sequence. Both are represented as CBOR 314 unsigned integers. 316 A custody signal constitutes an assertion by the source of that 317 administrative record that the indicated disposition code applies to 318 all BPDUs identified by the transmission IDs enumerated in the 319 custody signal's disposition scope report. If the disposition code 320 is zero, then the source of the custody signal has accepted custody 321 of all bundles that were encapsulated in the indicated BPDUs. 322 Otherwise the source of the custody signal has refused custody of 323 all bundles that were encapsulated in the indicated BPDUs, for the 324 indicated reason. 326 3.4. Custody Transfer Status Reports 328 A "custody transfer status report" is a bundle status report with 329 the "reporting node attempted custody transfer" flag set to 1. 331 4. BIBE Procedures 333 4.1. BPDU Transmission 335 When a BCLA is requested by the bundle protocol agent to send a 336 bundle to the peer BCLA(s) included in the destination BP endpoint 337 identified by a specified BP endpoint ID: 339 . The BCLA SHALL generate, as defined in Section 6.2 of the 340 Bundle Protocol specification, a BPDU for which the third 341 element of the content array is the bundle that is to be 342 transmitted. The destination of the bundle whose payload is the 343 BPDU (termed the "encapsulating bundle") SHALL be the specified 344 destination BP endpoint. Selection of the values of the 345 parameters governing the forwarding of the encapsulating 346 bundle, other than the destination endpoint ID, is an 347 implementation matter. The parameter values governing the 348 forwarding of the BPDU's encapsulated bundle MAY be consulted 349 for this purpose. 350 . Note that any transmission request presented to a BCLA MAY 351 request that the transmission be subject to Custody Transfer, 352 provided that the destination EID of the request identifies a 353 singleton endpoint. 354 . If Custody Transfer is requested: 355 o The first element of the BPDU's content array MUST be the 356 BPDU's transmission ID, which SHALL be 1 more than the 357 current value of the BCLA's CTC for the node that is the 358 sole occupant of the BPDU's destination endpoint. 359 o The second element of the BPDU's content array MUST be the 360 BPDU's retransmission time as discussed in 3.2 above. 361 o The bundle protocol agent MUST add the retention constraint 362 "Custody accepted" to the encapsulated bundle. 363 o The BCLA MAY establish a retransmission timer for the 364 corresponding CTI. If a retransmission timer is 365 established, it MUST be set to expire at the 366 retransmission time indicated in the BPDU. 367 . Otherwise: 368 o The first two elements of the BPDU's content array MUST 369 both be zero. 370 o Upon completion of step 2 of Section 6.2 of the Bundle 371 Protocol specification (i.e., a request for transmission 372 of the encapsulating bundle has been presented to the 373 bundle protocol agent), the BCLA SHOULD notify the bundle 374 protocol agent that transmission of the encapsulated 375 bundle succeeded. 377 Note that the custody transfer retransmission timer mechanism 378 provides a means of recovering from loss of an encapsulating bundle 379 as indicated by non-arrival of a responding custody signal. 381 4.2. BPDU Reception 383 When a BCLA receives a BPDU from the bundle protocol agent (that is, 384 upon delivery of the payload of an encapsulating bundle): 386 . If Custody Transfer was requested for this BPDU (as indicated 387 by a non-zero value of transmission ID): 388 o If the encapsulated bundle has the same source node ID, 389 creation timestamp, and (if that bundle is a fragment) 390 fragment offset and payload length as another bundle that 391 is currently retained at the BCLA's local node, then 392 custody transfer redundancy MUST be handled as follows: 393 . The BCLA SHALL add the BPDU's transmission ID to the 394 disposition scope report of a pending outbound 395 custody signal, destined for the node that was the 396 source of the encapsulating bundle, whose disposition 397 is the reason code from Figure 1 for "Redundant 398 reception". 399 o Otherwise, if the BCLA determines that its local node can 400 neither deliver nor forward the encapsulated bundle for 401 any of the reasons listed in Figure 1, then custody 402 transfer has failed. Custody transfer failure SHALL be 403 handled as follows: 404 . The BCLA SHALL add the BPDU's transmission ID to the 405 disposition scope report of a pending outbound 406 custody signal, destined for the node that was the 407 source of the encapsulating bundle, whose disposition 408 is the reason code from Figure 1 that indicates the 409 reason for the custody transfer failure. 410 o Otherwise, custody transfer has succeeded: 411 . The BCLA SHALL add the BPDU's transmission ID to the 412 disposition scope report of a pending outbound 413 custody signal, destined for the node that was the 414 source of the encapsulating bundle, whose disposition 415 is zero (indicating that custody was accepted). 416 o In each of these three cases: 417 . The pending outbound custody signal MAY then be 418 issued immediately, but alternatively it MAY be 419 issued at some time in the future, possibly enabling 420 additional BPDUs' transmission IDs to be added to the 421 same disposition scope report. 422 . If Custody Transfer was NOT requested for this BPDU, or if 423 Custody Transfer was requested for this BPDU and custody 424 transfer succeeded, then the encapsulated bundle SHALL be 425 delivered from the BCLA to the bundle protocol agent, whereupon 426 reception of the encapsulated bundle SHALL be performed as 427 defined in section 5.6 of the Bundle Protocol specification in 428 the usual manner: the encapsulated bundle may be forwarded, 429 delivered, etc. 431 Note that the procedures by which pending outbound custody signals 432 are managed, disposition scope reports are aggregated, and custody 433 signal transmission is initiated are implementation matters that 434 are beyond the scope of this specification. Note, however, that 435 failure to deliver a custody signal prior to the earliest value of 436 retransmission time among all BPDUs enumerated in the custody 437 signal's disposition scope report may result in the unnecessary 438 re-forwarding of one or more encapsulated bundles. 440 4.3. Retransmission Timer Expiration 442 Upon expiration of a retransmission timer, the BCLA SHOULD remove 443 the corresponding CTI from the CTDB (destroying the associated 444 retransmission timer, if any) and notify the bundle protocol agent 445 that transmission failed for the encapsulated bundle referenced by 446 that CTI. Note that this notification may cause the encapsulated 447 bundle to be re-forwarded (possibly on a different route). 449 4.4. Custody Signal Reception 451 When a BCLA receives a custody signal from the bundle protocol agent 452 (that is, upon delivery of the payload of a custody-signal-bearing 453 bundle): 455 . If the custody signal's disposition is 0 (custody acceptance), 456 then for each transmission ID in the custody signal's 457 disposition scope report: 458 o The bundle protocol agent MUST remove the retention 459 constraint "Custody accepted" on the encapsulated bundle 460 referenced by the corresponding CTI. 461 o The corresponding CTI MUST be removed from the CTDB 462 (destroying the associated retransmission timer, if any). 463 o The BCLA SHOULD notify the bundle protocol agent that 464 transmission succeeded for the encapsulated bundle 465 referenced by the corresponding CTI. 467 . Otherwise (custody refusal), for each transmission ID in the 468 custody signal's disposition scope report: 469 o The corresponding CTI MUST be removed from the CTDB 470 (destroying the associated retransmission timer, if any). 471 o Any further action taken by the BCLA is implementation- 472 specific and may depend on the reason code cited for the 473 refusal. For example, if the custody signal's reason code 474 was "Depleted storage", the BCLA might choose to notify 475 the bundle protocol agent that transmission failed for the 476 encapsulated bundle referenced by the corresponding CTI. 477 If the reason code was "Redundant reception", on the other 478 hand, the BCLA might simply instruct the bundle protocol 479 agent to remove the retention constraint "Custody 480 accepted" on the encapsulated bundle referenced by the 481 corresponding CTI and to revise its algorithm for 482 computing retransmission time. 484 5. Security Considerations 486 An adversary on a DTN-based network that can delete bundles could 487 delete a BIBE custody signal in transit. This could result in 488 custody transfer failure and the possible re-forwarding of 489 encapsulated bundles, degrading network performance. 491 Alternatively, an adversary on a DTN-based network that can reorder 492 bundles could cause bundles to be delivered to a BCLA in an order 493 that complicates the efficient construction of disposition scope 494 reports in pending outbound custody signals. This could result in 495 inefficient custody transfer communications, again degrading network 496 performance. 498 Custody transfer in BIBE may be contraindicated in environments 499 characterized by such attacks. 501 6. IANA Considerations 503 The BIBE specification requires IANA registration of the new BIBE 504 administrative records (type codes 3 and 4) defined above. 506 7. References 508 7.1. Normative References 510 [BP] Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol 511 Version 7", draft-ietf-dtn-bpbis, February 2020. 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 7.2. Informative References 518 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 519 Specification", RFC 5050, November 2007. 521 8. Acknowledgments 523 This work is freely adapted from [RFC5050], which was an effort of 524 the Delay Tolerant Networking Research Group. The following DTNRG 525 participants contributed significant technical material and/or 526 inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh, 527 Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory, 528 Michael Demmer of the University of California at Berkeley, Robert 529 Durst, Keith Scott, and Susan Symington of The MITRE Corporation, 530 Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity 531 College Dublin, Peter Lovell and Howard Weiss of SPARTA, Inc., and 532 Manikantan Ramadas of Ohio University. 534 The custody transfer procedures defined in this specification are 535 adapted from the Aggregate Custody Signals draft specification 536 authored in 2010-2012 by Sebastian Kuzminsky and Andrew Jenkins, 537 then of the University of Colorado at Boulder. 539 Although the BIBE specification diverges in some ways from the 540 original Bundle-in-Bundle Encapsulation Internet Draft authored by 541 Susan Symington, Bob Durst, and Keith Scott of The MITRE Corporation 542 (draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of 543 that earlier document is gratefully acknowledged. 545 This document was prepared using 2-Word-v2.0.template.dot. 547 Appendix A. For More Information 549 Please refer comments to dtn@ietf.org. The Delay Tolerant Networking 550 Research Group (DTNRG) Web site is located at http://www.dtnrg.org. 552 Copyright (c) 2020 IETF Trust and the persons identified as authors 553 of the code. All rights reserved. 555 Redistribution and use in source and binary forms, with or without 556 modification, is permitted pursuant to, and subject to the license 557 terms contained in, the Simplified BSD License set forth in Section 558 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 559 (http://trustee.ietf.org/license-info). 561 Appendix B. CDDL expression 563 For informational purposes, Carsten Bormann has kindly provided an 564 expression of the Bundle Protocol specification in the CBOR Data 565 Definition Language (CDDL). Portions of CDDL expression that bear 566 on the custody transfer extension are presented below, somewhat 567 edited by the authors. Note that wherever the CDDL expression is in 568 disagreement with the textual representation of the BP specification 569 presented in the earlier sections of this document, the textual 570 representation rules. 572 admin-record-choice /= BIBE-PDU 574 BIBE-PDU = [3, [transmission-ID: uint, 576 retransmission-time: uint, 578 encapsulated-bundle: bytes, 580 admin-common]] 582 admin-record-choice /= custody-signal 584 custody-signal = [4, [disposition-code: uint, 586 disposition-scope-report, 588 admin-common]] 590 disposition-scope-report = *disposition-scope-sequence 592 disposition-scope-sequence = [first-transmission-ID: uint, 594 number-of-transmission-IDs: uint] 596 Authors' Address 598 Scott Burleigh 599 Jet Propulsion Laboratory, California Institute of Technology 600 4800 Oak Grove Dr. 601 Pasadena, CA 91109-8099 602 US 603 Phone: +1 818 393 3353 604 Email: Scott.Burleigh@jpl.nasa.gov