Delay-Tolerant Networking Working Group Scott Burleigh
Internet Draft IPNGROUP
Intended status: Standards Track Alberto Montilla
Expires: September 14, 2025 Spatiam Corporation
Joshua Deaton
SAIC
Carlo Caini
University of Bologna
March 13, 2025
Bundle-in-Bundle Encapsulation
draft-ietf-dtn-bibect-05.txt
Status of this Memo
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 14, 2025.
Copyright Notice
Copyright (c) 2025 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
(http://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
Burleigh, et al Expires September 2025 [Page 1]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
This document describes Bundle-in-Bundle Encapsulation (BIBE), a
Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence
layer" protocol that tunnels BP "bundles" through encapsulating
bundles. The services provided by the BIBE convergence-layer
protocol adapter encapsulate an outbound BP "bundle" in a BIBE
convergence-layer protocol data unit for transmission as the payload
of a bundle. Security measures applied to the encapsulating bundle
may augment those applied to the encapsulated bundle. The protocol
includes a mechanism for recovery from loss of an encapsulating
bundle, called Bundle Retransmission Methods (BRM). This mechanism
is adapted from the custody transfer procedures described in the
experimental Bundle Protocol (version 6) specification developed by
the Delay-Tolerant Networking Research Group of the Internet
Research Task Force and documented in RFC 5050.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................4
3. BIBE Design Elements...........................................5
3.1. BIBE Endpoints............................................5
3.2. BIBE Protocol Data Units..................................5
3.3. BRM Signals...............................................6
4. BIBE Procedures................................................8
4.1. BPDU Transmission.........................................8
4.2. BPDU Reception............................................9
4.3. Retransmission Timer Expiration..........................11
4.4. BRM Signal Reception.....................................11
5. Security Considerations.......................................12
6. IANA Considerations...........................................12
7. References....................................................12
7.1. Normative References.....................................12
7.2. Informative References...................................12
8. Acknowledgments...............................................12
Appendix A. CDDL expression......................................14
1. Introduction
This document describes Bundle-in-Bundle Encapsulation (BIBE), a
Delay-Tolerant Networking (DTN) Bundle Protocol (BP) [RFC9171]
Burleigh, et al Expires September 2025 [Page 2]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
"convergence layer" protocol that tunnels BP "bundles" through
encapsulating bundles.
Conformance to the bundle-in-bundle encapsulation (BIBE)
specification is OPTIONAL for BP nodes. Each BP node that conforms
to the BIBE specification provides a BIBE convergence-layer adapter
(CLA) that is implemented by the administrative element of the BP
node's application agent. Like any convergence-layer adapter, the
BIBE CLA provides:
. A transmission service that sends an outbound bundle (from the
bundle protocol agent) to a peer CLA. In the case of BIBE, the
sending CLA and receiving peer CLA are both BP nodes.
. A reception service that delivers to the bundle protocol agent
an inbound bundle that was sent by a peer CLA (itself a BP
node) via the BIBE convergence layer protocol.
The BIBE CLA performs these services by:
. Encapsulating outbound bundles in BIBE protocol data units,
which take the form of Bundle Protocol administrative records
as described later.
. Requesting that the bundle protocol agent transmit bundles
whose payloads are BIBE protocol data units.
. Taking delivery of BIBE protocol data units that are the
payloads of bundles received by the bundle protocol agent.
. Delivering to the bundle protocol agent the bundles that are
encapsulated in delivered BIBE protocol data units.
Bundle-in-bundle encapsulation may have broad utility, but the
principal motivating use case is the deployment of "cross domain
solutions" in DTN networks. Under some circumstances a bundle may
arrive at a node that is on the frontier of a sector of network
topology in which any of the below scenarios may be present,
. Augmented security is required, from which the bundle must
egress at some other designated node. In that case, the bundle
may be encapsulated within a bundle to which the requisite
additional BP Security (BPSEC) [RFC9172] extension block(s) can
be attached, whose source is the point of entry into the
insecure region (the "security source") and whose destination
is the point of egress from the insecure region (the "security
destination").
. Bundles conforming to Bundle Protocol Version 6 [RFC5050] may
need to traverse a network using Bundle Protocol Version 7
[RFC9171]. In that case, the incoming bundle (BPv6) may be
Burleigh, et al Expires September 2025 [Page 3]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
encapsulated within a bundle (BPv7) which is forwarded through
the BPv7 based network.
. Application of other per-domain policies, including forwarding,
recovery of lost data, and quality of service. In that case,
the node encapsulating incoming bundles within a new bundle can
apply different policies without modifying the parameters of
the encapsulated bundle. This may be especially useful in
service provider networks defining their policies at the edge
of a network.
Note that:
. If the payload of the encapsulating bundle is protected by a
Bundle Confidentiality Block (BCB), then the source and
destination of the encapsulated bundle are encrypted, providing
defense against traffic analysis that BPSEC alone cannot offer.
. Bundles whose payloads are BIBE protocol data units may
themselves be forwarded via a BIBE convergence-layer adapter,
enabling nested bundle encapsulation to arbitrary depth as
required by security policy.
. Moreover, in the event that no single point of egress from an
insecure region of network topology can be determined at the
moment a bundle is to be encapsulated, multiple copies of the
bundle may be encapsulated individually and forwarded to all
candidate points of egress.
The protocol includes a mechanism for recovery from loss of an
encapsulating bundle, called Bundle Retransmission Method (BRM).
This mechanism is adapted from the custody transfer procedures
described in the experimental Bundle Protocol (version 6)
specification developed by the Delay-Tolerant Networking Research
Group of the Internet Research Task Force and documented in RFC 5050
[RFC5050]. BRM is a convention by which the loss or corruption of
BIBE encapsulating bundles can be mitigated by the exchange of other
bundles, which are termed "BRM signals".
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
Burleigh, et al Expires September 2025 [Page 4]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
3. BIBE Design Elements
3.1. BIBE Endpoints
BIBE convergence-layer protocol endpoints, also known as BIBE
convergence-layer adapters (BCLAs), are implemented by the
administrative elements of the application agents of BP nodes that
conform to the BIBE protocol specification. The node of which a
given BCLA is one component is termed the BCLA's "local node". A BP
node that includes a BCLA is termed a "BIBE node".
3.2. BIBE Protocol Data Units
A BIBE protocol data unit (BPDU) is a Bundle Protocol administrative
record whose record type code is 64443, whose representation
conforms to the Bundle Protocol specification for administrative
record representation, and whose content SHALL be a BPDU message
represented as described later.
A BIBE Protocol Data Unit (BPDU) for which BRM is requested is
termed a "BRM BPDU". The action taken by a BCLA upon delivery of a
BRM BPDU is termed the "disposition" of that BPDU; the disposition
of a BRM BPDU SHALL be either acceptance or refusal.
Notionally, a BCLA is assumed to implement in some way, for each
BIBE node to which the local node issues BRM BPDUs, the following
two data resources:
1. A "BRM transmission count" (BRMTC). A BRMTC is a monotonically
increasing integer indicating the number of BRM BPDUs that have
been issued to this BIBE node by the local node since
instantiation of the local node.
2. A "BRM transmission database" (BRMDB), a notional array of "BRM
transmission items" (BRMTIs). The BRMDB contains one BRMTI for
each BRM BPDU issued to this BIBE node, by the local node, for
which (a) no BRM disposition signal has yet been received in
any BRM signal (as discussed later), and (b) the bundle
encapsulated in that BPDU has not yet been destroyed due to,
e.g., time-to-live expiration, and (c) "retransmission time"
(discussed below) either is in the future or is zero. Each
BRMTI notionally contains:
a. A reference to the bundle encapsulated in the
corresponding BPDU.
b. The "transmission ID" of the corresponding BPDU, as
discussed below.
Burleigh, et al Expires September 2025 [Page 5]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
c. A The BPDU's "retransmission time," indicating the time by
which BRM disposition for the corresponding BDPU is
expected.
The BRMDB itself being notional, normative language prescribing
operations on the BRMDB is necessarily notional as well. Technical
operations on the BRMDB are an implementation matter.
The BPDU messages that constitute the content of BIBE protocol data
unit administrative records are represented as follows.
Each BPDU message SHALL be represented as a CBOR array. The number
of elements in the array SHALL be 3.
The first item of the BPDU array SHALL be the "transmission ID" for
the BPDU, represented as a CBOR unsigned integer. The transmission
ID for a BPDU for which BRM is NOT requested SHALL be zero. The
transmission ID for a BPDU for which BRM IS requested SHALL be the
current value of the local node's BRM transmission count for the
BIBE node to which the BPDU is to be issued, plus 1.
The second item of the BPDU array SHALL be the BPDU's retransmission
time (i.e., the time by which BRM disposition for this BPDU is
expected), represented as a CBOR unsigned integer. Retransmission
time for a BPDU for which BRM is NOT requested SHALL be zero.
Retransmission time for a BPDU for which BRM IS requested SHALL take
the form of a "DTN Time" as defined in the Bundle Protocol
specification; determination of the value of retransmission time is
an implementation matter that is beyond the scope of this
specification and may be dynamically responsive to changes in
connectivity.
The third item of the BPDU array SHALL be a single BP bundle, termed
the "encapsulated bundle", represented as a CBOR byte string of
definite length.
3.3. BRM Signals
A "BRM signal" is a Bundle Protocol administrative record whose
record type code is 64444 and whose representation conforms to the
Bundle Protocol specification for administrative record
representation. The content of the record shall be a BRM message
represented as follows.
Each BRM message SHALL be represented as a CBOR array. The number of
elements in the array SHALL be 2.
Burleigh, et al Expires September 2025 [Page 6]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
The first item of the BRM message content array SHALL be a BRM
disposition code represented as a CBOR unsigned integer. Valid
disposition codes are defined as follows:
+---------+--------------------------------------------+
| Value | Meaning |
+=========+============================================+
| 0 | Bundle Retransmission Method accepted. |
+---------+--------------------------------------------+
| 1 | No further information. |
+---------+--------------------------------------------+
| 2 | Reserved for future use. |
+---------+--------------------------------------------+
| 3 | Redundant (reception by a node that |
| | already has a copy of this bundle). |
+---------+--------------------------------------------+
| 4 | Depleted storage. |
+---------+--------------------------------------------+
| 5 | Destination endpoint ID unintelligible. |
+---------+--------------------------------------------+
| 6 | No known route destination from here. |
+---------+--------------------------------------------+
| 7 | No timely contact with next node on route. |
+---------+--------------------------------------------+
| 8 | Block unintelligible. |
+---------+--------------------------------------------+
Burleigh, et al Expires September 2025 [Page 7]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
| (other) | Reserved for future use. |
+---------+--------------------------------------------+
Figure 1: Disposition Codes
Disposition code 0 indicates that the disposition of the BPDU at the
BCLA that issued the BRM signal was acceptance. All other
disposition codes indicate that BRM was refused and, additionally,
indicate the reason for refusal.
The second item of the BRM message content array SHALL be a
"disposition scope report" (or, simply, "scope report"), represented
as a CBOR array of definite length. Each item of the disposition
scope report array SHALL be a "disposition scope sequence" (or,
simply, "scope sequence"), represented as a CBOR array of two
elements. The first element of each disposition scope sequence
array SHALL be the first transmission ID in a sequence of 1 or more
consecutive transmission IDs corresponding to BPDUs to which the BRM
signal's disposition is declared to apply; the second element of
each disposition scope sequence array SHALL be the number of
transmission IDs in that sequence. Both are represented as CBOR
unsigned integers.
A BRM signal constitutes an assertion by the source of that
administrative record that the indicated disposition code applies to
all BPDUs identified by the transmission IDs enumerated in the BRM
signal's disposition scope report. If the disposition code is zero,
then the source of the BRM signal has accepted BRM for all bundles
that were encapsulated in the indicated BPDUs. Otherwise the source
of the BRM signal has refused BRM for all bundles that were
encapsulated in the indicated BPDUs, for the indicated reason.
4. BIBE Procedures
4.1. BPDU Transmission
When a BCLA is requested by the bundle protocol agent to send a
bundle to the peer BCLA(s) included in the destination BP endpoint
identified by a specified BP endpoint ID:
. The BCLA SHALL generate, as defined in Section 6.2 of the
Bundle Protocol specification, a BPDU for which the third
element of the content array is the bundle that is to be
transmitted. The destination of the bundle whose payload is the
BPDU (termed the "encapsulating bundle") SHALL be the specified
destination BP endpoint. Selection of the values of the
Burleigh, et al Expires September 2025 [Page 8]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
parameters governing the forwarding of the encapsulating
bundle, other than the destination endpoint ID, is an
implementation matter. The parameter values governing the
forwarding of the BPDU's encapsulated bundle MAY be consulted
for this purpose.
. Note that any transmission request presented to a BCLA MAY
request that the transmission be subject to BRM, provided that
the destination EID of the request identifies a singleton
endpoint.
. If BRM is requested:
o The first element of the BPDU's content array MUST be the
BPDU's transmission ID, which SHALL be 1 more than the
current value of the BCLA's CTC for the node that is the
sole occupant of the BPDU's destination endpoint.
o The second element of the BPDU's content array MUST be the
BPDU's retransmission time as discussed in 3.2 above.
o The bundle protocol agent MUST add the retention constraint
"BRM accepted" to the encapsulated bundle.
o The BCLA MAY establish a retransmission timer for the
corresponding BRMTI. If a retransmission timer is
established, it MUST be set to expire at the
retransmission time indicated in the BPDU.
. Otherwise:
o The first two elements of the BPDU's content array MUST
both be zero.
o Upon completion of step 2 of Section 6.2 of the Bundle
Protocol specification (i.e., a request for transmission
of the encapsulating bundle has been presented to the
bundle protocol agent), the BCLA SHOULD notify the bundle
protocol agent that transmission of the encapsulated
bundle succeeded.
Note that the BRM retransmission timer mechanism provides a means of
recovering from loss of an encapsulating bundle as indicated by non-
arrival of a responding BRM signal.
4.2. BPDU Reception
When a BCLA receives a BPDU from the bundle protocol agent (that is,
upon delivery of the payload of an encapsulating bundle):
. If BRM was requested for this BPDU (as indicated by a non-zero
value of transmission ID):
o If the encapsulated bundle has the same source node ID,
creation timestamp, and (if that bundle is a fragment)
fragment offset and payload length as another bundle that
Burleigh, et al Expires September 2025 [Page 9]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
is currently retained at the BCLA's local node, then BRM
redundancy MUST be handled as follows:
. The BCLA SHALL add the BPDU's transmission ID to the
disposition scope report of a pending outbound BRM
signal, destined for the node that was the source of
the encapsulating bundle, whose disposition code is
the reason disposition code from Figure 1 for
"Redundant reception".
o Otherwise, if the BCLA determines that its local node can
neither deliver nor forward the encapsulated bundle for
any of the reasons listed in Figure 1, then BRM has
failed. BRM failure SHALL be handled as follows:
. The BCLA SHALL add the BPDU's transmission ID to the
disposition scope report of a pending outbound BRM
signal, destined for the node that was the source of
the encapsulating bundle, whose disposition code is
the reason disposition code from Figure 1 that
indicates the reason for the BRM failure.
o Otherwise, BRM has succeeded:
. The BCLA SHALL add the BPDU's transmission ID to the
disposition scope report of a pending outbound BRM
signal, destined for the node that was the source of
the encapsulating bundle, whose disposition code is
zero (indicating that BRM was accepted).
o In each of these three cases:
. The pending outbound BRM signal MAY then be issued
immediately, but alternatively it MAY be issued at
some time in the future, possibly enabling additional
BPDUs' transmission IDs to be added to the same
disposition scope report.
. If BRM was NOT requested for this BPDU, or if BRM was requested
for this BPDU and BRM succeededwas accepted, then the
encapsulated bundle SHALL be delivered from the BCLA to the
bundle protocol agent, whereupon reception of the encapsulated
bundle SHALL be performed as defined in Section 5.6 of the
Bundle Protocol specification in the usual manner: the
encapsulated bundle may be forwarded, delivered, etc.
Note that the procedures by which pending outbound BRM signals are
managed, disposition scope reports are aggregated, and BRM signal
transmission is initiated are implementation matters that are
beyond the scope of this specification. Note, however, that
failure to deliver a BRM signal prior to the earliest value of
retransmission time among all BPDUs enumerated in the BRM signal's
disposition scope report may result in the unnecessary re-
forwarding of one or more encapsulated bundles.
Burleigh, et al Expires September 2025 [Page 10]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
4.3. Retransmission Timer Expiration
Upon expiration of a retransmission timer, the BCLA SHOULD MUST
remove the corresponding BRMTI from the BRMDB (destroying the
associated retransmission timer, if any) and notify the bundle
protocol agent that transmission failed for the encapsulated bundle
referenced by that BRMTI. Note that this notification may cause the
encapsulated bundle to be re-forwarded (possibly on a different
route).
4.4. BRM Signal Reception
When a BCLA receives a BRM signal from the bundle protocol agent
(that is, upon delivery of the payload of a BRM-signal-bearing
bundle):
. If the BRM signal's disposition code is 0 (BRM acceptance),
then for each transmission ID in the BRM signal's disposition
scope report:
o The bundle protocol agent MUST remove the retention
constraint "BRM accepted" on the encapsulated bundle
referenced by the corresponding BRMTI.
o The corresponding BRMTI MUST be removed from the BRMDB
(destroying the associated retransmission timer, if any).
o The BCLA SHOULD notify the bundle protocol agent that
transmission succeeded for the encapsulated bundle
referenced by the corresponding BRMTI.
. Otherwise (BRM refusal), for each transmission ID in the BRM
signal's disposition scope report:
o The corresponding BRMTI MUST be removed from the BRMDB
(destroying the associated retransmission timer, if any).
o Any further action taken by the BCLA is implementation-
specific and may depend on the reason disposition code
citing the reasoned for the refusal. For example, if the
BRM signal's reason disposition code was "Depleted
storage", the BCLA might choose to notify the bundle
protocol agent that transmission failed for the
encapsulated bundle referenced by the corresponding BRMTI.
If the reason disposition code was "Redundant reception",
on the other hand, the BCLA might simply instruct the
bundle protocol agent to remove the retention constraint
"BRM accepted" on the encapsulated bundle referenced by
the corresponding BRMTI and to revise its algorithm for
computing retransmission time.
Burleigh, et al Expires September 2025 [Page 11]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
5. Security Considerations
An adversary on a DTN-based network that can delete bundles could
delete a BRM signal in transit. This could result in BRM failure
and the possible re-forwarding of encapsulated bundles, degrading
network performance.
Alternatively, an adversary on a DTN-based network that can reorder
bundles could cause bundles to be delivered to a BCLA in an order
that complicates the efficient construction of disposition scope
reports in pending outbound BRM signals. This could result in
inefficient BRM communications, again degrading network performance.
BIBE's Bundle Retransmission Method may be contraindicated in
environments characterized by such attacks.
6. IANA Considerations
The BIBE specification requires IANA registration of the new BIBE
administrative records (type codes 64443 and 64444) defined above.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC9171] Burleigh, S., Fall, K., and Birrane, E., "Bundle Protocol
Version 7", RFC 9171, January 2022.
[RFC9172] Birrane, E. and McKeever, K., "Bundle Protocol Security
(BPSec)", RFC 9172, January 2022.
7.2. Informative References
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
8. Acknowledgments
This work is freely adapted from [RFC5050], which was an effort of
the Delay Tolerant Networking Research Group. The following DTNRG
participants contributed significant technical material and/or
inputs to that document: Dr. Vinton Cerf of Google, Scott Burleigh,
Adrian Hooke, and Leigh Torgerson of the Jet Propulsion Laboratory,
Michael Demmer of the University of California at Berkeley, Robert
Burleigh, et al Expires September 2025 [Page 12]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
Durst, Keith Scott, and Susan Symington of The MITRE Corporation,
Kevin Fall of Carnegie Mellon University, Stephen Farrell of Trinity
College Dublin, Peter Lovell and Howard Weiss of SPARTA, Inc., and
Manikantan Ramadas of Ohio University.
The BRM procedures defined in this specification are adapted from
the Aggregate Custody Signals draft specification authored in 2010-
2012 by Sebastian Kuzminsky and Andrew Jenkins, then of the
University of Colorado at Boulder.
Although the BIBE specification diverges in some ways from the
original Bundle-in-Bundle Encapsulation Internet Draft authored by
Susan Symington, Bob Durst, and Keith Scott of The MITRE Corporation
(draft-irtf-dtnrg-bundle-encapsulation-06, 2009), the influence of
that earlier document is gratefully acknowledged.
This document was prepared using 2-Word-v2.0.template.dot.
Burleigh, et al Expires September 2025 [Page 13]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
Appendix A. CDDL expression
For informational purposes, Carsten Bormann has kindly provided an
expression of the Bundle Protocol specification in the CBOR Data
Definition Language (CDDL). Portions of CDDL expression that bear
on the BRM extension are presented below, somewhat edited by the
authors. Note that wherever the CDDL expression is in disagreement
with the textual representation of the BP specification presented in
the earlier sections of this document, the textual representation
rules.
admin-record-choice /= BIBE-PDU
BIBE-PDU = [64443, [transmission-ID: uint,
retransmission-time: uint,
encapsulated-bundle: bytes,
admin-common]]
admin-record-choice /= BRM-signal
BRM-signal = [64444, [disposition-code: uint,
disposition-scope-report,
admin-common]]
disposition-scope-report = *disposition-scope-sequence
disposition-scope-sequence = [first-transmission-ID: uint,
number-of-transmission-IDs: uint]
Authors' Address
Scott Burleigh
IPNGROUP
1435 Woodhurst Blvd.
McLean, VA 22102
US
Email: sburleig.sb@gmail.com
Burleigh, et al Expires September 2025 [Page 14]
Internet-Draft Bundle-in-Bundle Encapsulation 2025
Alberto Montilla
Spatiam Corporation
1200 Conroe Dr.
Allen, TX 75013
US
Email: a.montilla@spatiam.com
Joshua Deaton
Science Applications International Corporation - SAIC
300 Diamond Drive
Huntsville, AL 35806
US
E-mail: joshua.e.deaton@nasa.gov
Carlo Caini
University of Bologna
Dipartimento di Ingegneria dell'Energia Elettrica e
dell'Informazione "Guglielmo Marconi"
Viale del Risorgimento 2, Bologna
Italy
E-mail: carlo.caini@unibo.it
Burleigh, et al Expires September 2025 [Page 15]