]> bcht

bcht1145@163.com

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.

Introduction 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 . 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.

Conventions and Definitions 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 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.

Protocol Overview

Before Shipping 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.

Loading During loading, the Sender MUST hand the Storage Media over to the Carrier for Shipping.

Shipping Normally, a Sender using DTTP can obtain the location of the Storage Media from the Carrier. The Payload on Storage Media MUST NOT be modified during Shipping.

Shipment Format 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: SN (Serial Number) PN (Part Number) Transmission Medium identifier Integrity Verification value The Manifest MUST identify which Storage Media are assigned to which Transmission Medium.

Control Information Transmission

Manifest 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 . The Manifest and Cargo Manifest MUST contain the following fields: SN (Serial Number) PN (Part Number) Transmission Medium identifier Integrity Verification value 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.

E-Mail 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.

E-Mail Security 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.

Integrity and Verification When generating the Integrity Verification value for each Storage Media, the Sender MUST use SHA-256 . 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.

Transfer State This section defines the states of a single Storage Media.

NONE

When Triggered The Storage Media is in the initial state and has not been copied, has not undergone Shipping, and has no generated Integrity Verification value.

BACKUP

When Triggered The Storage Media is being copied to another Storage Media for backup.

CHECKSUM_VALUE

When Triggered The backup of the Storage Media has been completed, and the Integrity Verification value for the Payload on the Storage Media has been generated.

LOADED

When Triggered The Storage Media is being loaded onto the Transmission Medium.

SHIPMENT

When Triggered The Storage Media has been loaded, but the Carrier's Transmission Medium has not yet officially departed.

IN_TRANSIT

When Triggered The Transmission Medium has departed, and the Receiver has not yet received the Storage Media.

ACKNOWLEDGE_RECEIPT

When Triggered The Receiver has received the Storage Media and is verifying the Payload.

RESHIPMENT

When Triggered LOST or DAMAGE has been triggered and an ARQ E-Mail has been sent.

LOST

When Triggered The corresponding Storage Media is missing when the Receiver compares the Manifest with the Cargo Manifest.

DAMAGE

When Triggered The Cargo Manifest, Manifest, and Storage Media Integrity Verification values do not match.

COMMIT

When Triggered The Storage Media have been received, and all Storage Media have passed verification against the Cargo Manifest, Manifest, and Integrity Verification values.

State Transitions 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.

Error Handling

Storage Media Damage, Loss, Incorrect Data, or Duplicate Data 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.

Transmission Medium Timeout 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.

Security Considerations 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.

IANA Considerations This document has no IANA actions.

This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Acknowledgments None.