| Internet-Draft | DTTP | September 2026 |
| bcht | Expires 10 March 2027 | [Page] |
Large-scale data transfers may be affected by bandwidth limitations and network instability, which can make network-based data transfer inefficient. DTTP provides an alternative data transfer method for such situations.¶
DTTP uses physical transportation to carry Storage Media containing the Payload. A physical vehicle is used as the Transmission Medium for transporting the Storage Media between the Sender and the Receiver.¶
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 10 March 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.¶
Traditional network transmission may be affected by network instability and ISP bandwidth limitations, resulting in packet loss and latency. These conditions may prevent a scheduled task or program from being completed within the required time.¶
In such cases, transporting Storage Media through a logistics service may be more appropriate.¶
Existing technical practice demonstrates that physically transporting Storage Media can be used as an alternative method for large-scale data transfer [AWS-Snowmobile]. DTTP builds on this approach by defining mechanisms for transport, verification, and state management.¶
DTTP provides an alternative to network-based data transfer when bandwidth limitations or network instability make network transmission inefficient. DTTP is responsible for data organization, integrity verification, and state management during and after the data transfer process.¶
DTTP does not address excessive latency or the inability to provide streaming data.¶
DTTP does not specify which logistics company is used by the Sender or which route a Carrier's vehicle takes.¶
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.¶
Sender: The entity that sends the Storage Media.¶
Receiver: The entity that receives the Storage Media.¶
Carrier: The entity that transports the Storage Media.¶
Storage Media: The hard drives transported by DTTP.¶
Shipping: A complete physical transportation process for Storage Media.¶
Transmission Medium: The physical vehicle used to transport Storage Media.¶
Payload: The data stored on Storage Media.¶
Manifest: A description of the shipment and its contents.¶
Integrity Verification: The mechanism used to verify the Payload stored on Storage Media by using SHA-256.¶
Acknowledgment: The action by which the Sender confirms transmission or the Receiver confirms receipt.¶
Cargo Manifest: The Manifest stored on a Transmission Medium.¶
If the term "Manifest" is used without qualification, it refers to a Manifest and not a Cargo Manifest.¶
The Sender MUST copy each Storage Media to a new Storage Media for backup.¶
The Sender MUST generate an Integrity Verification value for each Storage Media.¶
The Payload is divided among the Storage Media. Storage Media MAY be assigned to Transmission Media in any order. The Integrity Verification value of each Storage Media loaded onto each Transmission Medium MUST be recorded in the Manifest to provide the mapping between Storage Media and Transmission Media.¶
The Integrity Verification value generated for each Storage Media MUST be recorded individually in the Manifest.¶
For each Storage Media, the Sender MUST generate and record the SN (Serial Number), PN (Part Number), and the Integrity Verification value of the Payload stored on that Storage Media in the Manifest.¶
The Sender MUST copy the Manifest to a Cargo Manifest.¶
Finally, the Sender MUST transmit the Manifest via E-Mail and MUST store a Cargo Manifest separately on the Transmission Medium for delivery to the Receiver. The E-Mail transmission procedure is defined in the "Control Information Transmission" section.¶
Hard drives and Payload MAY be mixed during transportation. DTTP does not restrict the storage method or distribution of the Payload.¶
Both the Manifest and Cargo Manifest MUST contain the following fields:¶
The Manifest MUST identify which Storage Media are assigned to which Transmission Medium.¶
The Manifest MUST be sent as an E-Mail attachment.¶
The attachment MUST use XML format. The E-Mail body MUST contain the checksum of the Manifest, the current timestamp, and a UUID [RFC9562].¶
The Manifest and Cargo Manifest MUST contain the following fields:¶
The Manifest MUST NOT record the order of Storage Media. When multiple Transmission Media are used, a single Manifest MUST record all Storage Media.¶
When multiple vehicles are used, there MUST be multiple Cargo Manifests. Each Cargo Manifest MUST contain only the information for the Storage Media loaded onto its corresponding Transmission Medium.¶
The Sender MUST send the Manifest to the Receiver via E-Mail before Shipping.¶
If the transmission times out, the Sender MUST retransmit the Manifest until the Receiver sends an ACK E-Mail.¶
If, after Acknowledgment, a Storage Media cannot be opened, is damaged, or has an Integrity Verification value that does not match the value recorded in the Manifest, the Receiver MUST send an ARQ E-Mail.¶
During IN_TRANSIT, if the elapsed time exceeds the waiting interval agreed upon by the Sender and Receiver, the Sender MUST send a CTW (Continue to Wait) E-Mail.¶
The waiting interval for CTW MUST be agreed upon by the Sender and Receiver before Shipping.¶
CTW MUST only be used during IN_TRANSIT.¶
The Receiver MUST send an ACK E-Mail in response to a CTW E-Mail. If the CTW E-Mail transmission times out, the Sender MUST retransmit the CTW E-Mail until the Receiver sends an ACK E-Mail.¶
If no CTW E-Mail is received after the agreed waiting interval, the corresponding Payload transmission MUST be treated as a new Payload transmission.¶
The body of an ACK E-Mail MUST contain the string "ACK" and the UUID of the E-Mail file being acknowledged. If the ACK E-Mail requires reply confirmation, the SHA-256 value of the corresponding E-Mail body MUST be sent.¶
The body of an ARQ E-Mail MUST contain the string "ARQ" and the SN (Serial Number) and PN (Part Number) of the corresponding Storage Media.¶
The body of a CTW E-Mail MUST contain the string "CTW" and the corresponding Carrier UUID or Transmission Medium UUID.¶
The body of an EEC E-Mail MUST contain the string "EEC" and the UUID of the corresponding ACK file. The corrected content MUST be included as an attachment.¶
If multiple E-Mails are received, the attachment of the E-Mail that has already been acknowledged MUST be used. If multiple E-Mails have been acknowledged, the attachment of the acknowledged E-Mail whose body contains the latest timestamp MUST be used.¶
If the SHA-256 value included in the ACK E-Mail does not match the corresponding value, the Sender MUST send an EEC (Email Error Correction) E-Mail. If the transmission times out, the Sender MUST continue retransmission until the other party sends an ACK E-Mail.¶
DTTP uses E-Mail for control information transmission. Authentication, transport security, and other security properties of E-Mail itself are the responsibility of the E-Mail system.¶
When generating the Integrity Verification value for each Storage Media, the Sender MUST use SHA-256 [FIPS180-4].¶
After receiving the Storage Media, the Receiver MUST compare the Cargo Manifest with the Manifest and MUST use SHA-256 to generate an Integrity Verification value for the Payload on each Storage Media.¶
If damage, loss, or verification failure occurs, the Receiver MUST send an ARQ E-Mail, and the entire affected Storage Media MUST be re-Shipped.¶
This section defines the states of a single Storage Media.¶
The Storage Media is in the initial state and has not been copied, has not undergone Shipping, and has no generated Integrity Verification value.¶
The Storage Media is being copied to another Storage Media for backup.¶
The backup of the Storage Media has been completed, and the Integrity Verification value for the Payload on the Storage Media has been generated.¶
The Storage Media is being loaded onto the Transmission Medium.¶
The Storage Media has been loaded, but the Carrier's Transmission Medium has not yet officially departed.¶
The Transmission Medium has departed, and the Receiver has not yet received the Storage Media.¶
The Receiver has received the Storage Media and is verifying the Payload.¶
LOST or DAMAGE has been triggered and an ARQ E-Mail has been sent.¶
The corresponding Storage Media is missing when the Receiver compares the Manifest with the Cargo Manifest.¶
The Cargo Manifest, Manifest, and Storage Media Integrity Verification values do not match.¶
The Storage Media have been received, and all Storage Media have passed verification against the Cargo Manifest, Manifest, and Integrity Verification values.¶
The normal state transition sequence is:¶
NONE → BACKUP → CHECKSUM_VALUE → LOADED → SHIPMENT
→ IN_TRANSIT → ACKNOWLEDGE_RECEIPT → COMMIT
¶
After an error is detected during ACKNOWLEDGE_RECEIPT, the Storage Media enters LOST or DAMAGE. After the Receiver sends an ARQ E-Mail, the affected Storage Media enters RESHIPMENT. When the new Shipping begins, the Storage Media enters IN_TRANSIT.¶
CTW does not cause a state transition. CTW is used only during IN_TRANSIT.¶
After entering ACKNOWLEDGE_RECEIPT, the Receiver MUST compare the Cargo Manifest, Manifest, and Storage Media Integrity Verification values and MUST remove duplicate data.¶
If damage, loss, incorrect data, or duplicate data is detected, the Receiver MUST send an ARQ E-Mail. If the transmission times out, the Receiver MUST continue sending the ARQ E-Mail until the Sender sends an ACK E-Mail. The affected Storage Media MUST then be re-Shipped through the RESHIPMENT state.¶
During IN_TRANSIT, if the elapsed time exceeds the waiting interval agreed upon by the Sender and Receiver, the Sender MUST send a CTW E-Mail.¶
If the CTW E-Mail transmission times out, the Sender MUST retransmit the CTW E-Mail until the Receiver sends an ACK E-Mail.¶
If a Storage Media is stolen, replaced, or modified, the Sender and Receiver MUST handle the situation according to the Error Handling procedures.¶
For each Storage Media, SHA-256 MUST be used to generate the Integrity Verification value.¶
After receiving the Storage Media, the Receiver MUST compare the Cargo Manifest with the Manifest and MUST use SHA-256 to generate the corresponding Integrity Verification value for the Payload on each Storage Media and compare it with the recorded value.¶
DTTP can use SHA-256 to detect accidental damage that occurs during data transfer.¶
DTTP cannot guarantee the physical security of Storage Media during or after Shipping. DTTP also cannot guarantee economic loss or data loss caused by mistakes made by the Sender or Receiver.¶
This document has no IANA actions.¶
None.¶