draft-ietf-dtn-tcpclv4-06.txt   draft-ietf-dtn-tcpclv4-07.txt 
Delay Tolerant Networking B. Sipos Delay Tolerant Networking B. Sipos
Internet-Draft RKF Engineering Internet-Draft RKF Engineering
Obsoletes: 7242 (if approved) M. Demmer Obsoletes: 7242 (if approved) M. Demmer
Intended status: Standards Track UC Berkeley Intended status: Standards Track UC Berkeley
Expires: August 1, 2018 J. Ott Expires: September 21, 2018 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
January 28, 2018 Mar 20, 2018
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-06 draft-ietf-dtn-tcpclv4-07
Abstract Abstract
This document describes a revised protocol for the TCP-based This document describes a revised protocol for the TCP-based
convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
protocol revision is based on implementation issues in the original protocol revision is based on implementation issues in the original
TCPCL Version 3 and updates to the Bundle Protocol contents, TCPCL Version 3 and updates to the Bundle Protocol contents,
encodings, and convergence layer requirements in Bundle Protocol encodings, and convergence layer requirements in Bundle Protocol
Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles
as its service data unit being transported and provides a reliable as its service data unit being transported and provides a reliable
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2018. This Internet-Draft will expire on September 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Convergence Layer Services . . . . . . . . . . . . . . . 4 1.1. Convergence Layer Services . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 6 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 6
3. General Protocol Description . . . . . . . . . . . . . . . . 7 3. General Protocol Description . . . . . . . . . . . . . . . . 7
3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 7 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 7
3.2. Example Message Exchange . . . . . . . . . . . . . . . . 8 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 8
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 9 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 10
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 10 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 11
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 10 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Header Extension Items . . . . . . . . . . . . . . . 13 4.2.1. Header Extension Items . . . . . . . . . . . . . . . 14
4.3. Validation and Parameter Negotiation . . . . . . . . . . 14 4.3. Validation and Parameter Negotiation . . . . . . . . . . 15
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 15 4.3.1. Reactive Fragmentation Extension . . . . . . . . . . 16
4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 16 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 17
4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 16 4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 18
5. Established Session Operation . . . . . . . . . . . . . . . . 17 4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 18
5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 17 5. Established Session Operation . . . . . . . . . . . . . . . . 19
5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 18 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 19
5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 18 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 20
5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 19 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 20
5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 20 5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 21
5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 21 5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 22
5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 21 5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 23
5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 22 5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 23
5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 24 5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 24
5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 25 5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 26
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 27 5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 27
6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 27 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 29
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 29 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 29
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 32
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 31 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 34
8.3. Header Extension Types . . . . . . . . . . . . . . . . . 32 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 34
8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 33 8.3. Header Extension Types . . . . . . . . . . . . . . . . . 35
8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 33 8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 35
8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 34 8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 36
8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 35 8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 37
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 36 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 37 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document describes the TCP-based convergence-layer protocol for This document describes the TCP-based convergence-layer protocol for
Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
end architecture providing communications in and/or through highly end architecture providing communications in and/or through highly
stressed environments, including those with intermittent stressed environments, including those with intermittent
connectivity, long and/or variable delays, and high bit error rates. connectivity, long and/or variable delays, and high bit error rates.
More detailed descriptions of the rationale and capabilities of these More detailed descriptions of the rationale and capabilities of these
networks can be found in "Delay-Tolerant Network Architecture" networks can be found in "Delay-Tolerant Network Architecture"
skipping to change at page 4, line 46 skipping to change at page 4, line 46
1.1. Convergence Layer Services 1.1. Convergence Layer Services
This version of the TCPCL provides the following services to support This version of the TCPCL provides the following services to support
the overlaying Bundle Protocol agent: the overlaying Bundle Protocol agent:
Attempt Session The TCPCL allows a BP agent to pre-emptively attempt Attempt Session The TCPCL allows a BP agent to pre-emptively attempt
to establish a TCPCL session with a peer node. Each session to establish a TCPCL session with a peer node. Each session
attempt can send a different set of contact header parameters as attempt can send a different set of contact header parameters as
directed by the BP agent. directed by the BP agent.
Session Started The TCPCL supports indication when a new TCP Shutdown Session The TCPCL allows a BP agent to pre-emptively
shutdown an established TCPCL session with a peer node. The
shutdown request is on a per-session basis.
Session is Started The TCPCL supports indication when a new TCP
connection has been started (as either client or server) before connection has been started (as either client or server) before
the TCPCL handshake has begun. the TCPCL handshake has begun.
Session Established The TCPCL supports indication when a new session Session is Established The TCPCL supports indication when a new
has been fully established and is ready for its first transfer. session has been fully established and is ready for its first
transfer.
Session Shutdown The TCPCL supports indication when an established Session is Shutdown The TCPCL supports indication when an
session has been ended by normal exchange of SHUTDOWN messages established session has been ended by normal exchange of SHUTDOWN
with all transfers completed. messages with all transfers completed.
Session Failed The TCPCL supports indication when a session fails, Session is Failed The TCPCL supports indication when a session
either during contact negotiation, TLS negotiation, or after fails, either during contact negotiation, TLS negotiation, or
establishement for any reason other than normal shutdown. after establishement for any reason other than normal shutdown.
Begin Transmission The principal purpose of the TCPCL is to allow a
BP agent to transmit bundle data over an established TCPCL
session. Transmission request is on a per-session basis, the CL
does not necessarily perform any per-session or inter-session
queueing. Any queueing of transmissions is the obligation of the
BP agent.
Transmission Availability Because TCPCL transmits serially over a Transmission Availability Because TCPCL transmits serially over a
TCP connection, it suffers from "head of queue blocking" and TCP connection, it suffers from "head of queue blocking" and
supports indication of when an established session is live-but- supports indication of when an established session is live-but-
idle (i.e. available for immediate transfer start) or live-and- idle (i.e. available for immediate transfer start) or live-and-
not-idle. not-idle.
Transmission Success The TCPCL supports positive indication when a Transmission Success The TCPCL supports positive indication when a
bundle has been fully transferred to a peer node. bundle has been fully transferred to a peer node.
skipping to change at page 5, line 33 skipping to change at page 5, line 44
indication of intermediate progress of transferr to a peer node. indication of intermediate progress of transferr to a peer node.
This intermediate progress is at the granularity of each This intermediate progress is at the granularity of each
transferred segment. transferred segment.
Transmission Failure The TCPCL supports positive indication of Transmission Failure The TCPCL supports positive indication of
certain reasons for bundle transmission failure, notably when the certain reasons for bundle transmission failure, notably when the
peer node rejects the bundle or when a TCPCL session ends before peer node rejects the bundle or when a TCPCL session ends before
transferr success. The TCPCL itself does not have a notion of transferr success. The TCPCL itself does not have a notion of
transfer timeout. transfer timeout.
Reception Interruption The TCPCL allows a BP agent to interrupt an Interrupt Reception The TCPCL allows a BP agent to interrupt an
individual transfer before it has fully completed (successfully or individual transfer before it has fully completed (successfully or
not). not).
Reception Success The TCPCL supports positive indication when a Reception Success The TCPCL supports positive indication when a
bundle has been fully transferred from a peer node. bundle has been fully transferred from a peer node.
Reception Intermediate Progress The TCPCL supports positive Reception Intermediate Progress The TCPCL supports positive
indication of intermediate progress of transfer from the peer indication of intermediate progress of transfer from the peer
node. This intermediate progress is at the granularity of each node. This intermediate progress is at the granularity of each
transferred segment. Intermediate reception indication allows a transferred segment. Intermediate reception indication allows a
skipping to change at page 15, line 35 skipping to change at page 16, line 35
the negotiated Enable TLS value is true and acceptable then TLS the negotiated Enable TLS value is true and acceptable then TLS
negotiation feature (described in Section 4.4) begins immediately negotiation feature (described in Section 4.4) begins immediately
following the contact header exchange. following the contact header exchange.
Once this process of parameter negotiation is completed (which Once this process of parameter negotiation is completed (which
includes a possible completed TLS handshake of the connection to use includes a possible completed TLS handshake of the connection to use
TLS), this protocol defines no additional mechanism to change the TLS), this protocol defines no additional mechanism to change the
parameters of an established session; to effect such a change, the parameters of an established session; to effect such a change, the
TCPCL session MUST be terminated and a new session established. TCPCL session MUST be terminated and a new session established.
4.3.1. Reactive Fragmentation Extension
In order to allow BP agents to use this reliable convergence layer to
perform reactive fragmentation, a header extension type
REACTIVE_FRAGMENT is defined to negotate the fragmentation
capabilities of the node sending the extension item. If either node
does not send a REACTIVE_FRAGMENT item then no reactive fragmentation
is allowed to be initiated within that session. Reactive
fragmentation is performed after a failed transfer, so it necessarily
spans more than a single TCPCL session. In fact, follow-on bundle
fragments may be sent via an entirely different convergence layer.
For these reasons, details of how reactive fragmentation and
reassembly takes place are outside the scope of this specification.
Within a single contact header there SHALL be no more than one item
with an extension type of REACTIVE_FRAGMENT. If no REACTIVE_FRAGMENT
item is received from a peer, all REACTIVE_FRAGMENT flags of that
peer SHALL be considered to be not set. The CRITICAL flag of the
REACTIVE_FRAGMENT item MAY be set to indicate that the peer node has
to interpret and negotiate the reactive fragmentation capability.
The order of the REACTIVE_FRAGMENT item within the extension items is
not significant. The Item Length of a REACTIVE_FRAGMENT item SHALL
be a single octet. The contents of the REACTIVE_FRAGMENT item shall
be interpreted as a bit mask, with flags interpreted according to
Table 3.
When a transfer-sending node has set the CAN_GENERATE flag and the
peer node has set the CAN_RECEIVE flag, the sending node SHALL use
acknowledged data segment information to reactively fragment a failed
transfer within some later transfers. When a transfer-receving node
has set the CAN_RECEIVE flag and the peer node has set the
CAN_GENERATE flag, the receving node SHALL treat partial received
transfers as reactively fragmented bundles and use the partial
transfer to reassemble future fragments of that bundle.
+--------------+--------+-------------------------------------------+
| Name | Code | Description |
+--------------+--------+-------------------------------------------+
| CAN_GENERATE | 0x01 | If bit is set, indicates that the sending |
| | | node is capable of generating reactively |
| | | fragmented bundles. |
| | | |
| CAN_RECEIVE | 0x02 | If bit is set, indicates that the sending |
| | | node is capable of receving and |
| | | reassembling reactively fragmented |
| | | bundles. |
| | | |
| Reserved | others |
+--------------+--------+-------------------------------------------+
Table 3: REACTIVE_FRAGMENT Flags
4.4. Session Security 4.4. Session Security
This version of the TCPCL supports establishing a Transport Layer This version of the TCPCL supports establishing a Transport Layer
Security (TLS) session within an existing TCP connection. When TLS Security (TLS) session within an existing TCP connection. When TLS
is used within the TCPCL it affects the entire session. Once is used within the TCPCL it affects the entire session. Once
established, there is no mechanism available to downgrade a TCPCL established, there is no mechanism available to downgrade a TCPCL
session to non-TLS operation. If this is desired, the entire TCPCL session to non-TLS operation. If this is desired, the entire TCPCL
session MUST be shutdown and a new non-TLS-negotiated session session MUST be shutdown and a new non-TLS-negotiated session
established. established.
skipping to change at page 18, line 14 skipping to change at page 20, line 14
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---------------+ +---------------+
| Message Type | | Message Type |
+---------------+ +---------------+
Figure 6: Format of the Message Header Figure 6: Format of the Message Header
The message header fields are as follows: The message header fields are as follows:
Message Type: Indicates the type of the message as per Table 3 Message Type: Indicates the type of the message as per Table 4
below. Encoded values are listed in Section 8.4. below. Encoded values are listed in Section 8.4.
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| Type | Description | | Type | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| XFER_INIT | Contains the length (in octets) of the next | | XFER_INIT | Contains the length (in octets) of the next |
| | transfer, as described in Section 5.3.2. | | | transfer, as described in Section 5.3.2. |
| | | | | |
| XFER_SEGMENT | Indicates the transmission of a segment of bundle | | XFER_SEGMENT | Indicates the transmission of a segment of bundle |
| | data, as described in Section 5.3.3. | | | data, as described in Section 5.3.3. |
skipping to change at page 18, line 44 skipping to change at page 20, line 44
| | Section 5.2.1. | | | Section 5.2.1. |
| | | | | |
| SHUTDOWN | Indicates that one of the nodes participating in | | SHUTDOWN | Indicates that one of the nodes participating in |
| | the session wishes to cleanly terminate the | | | the session wishes to cleanly terminate the |
| | session, as described in Section 6. | | | session, as described in Section 6. |
| | | | | |
| MSG_REJECT | Contains a TCPCL message rejection, as described | | MSG_REJECT | Contains a TCPCL message rejection, as described |
| | in Section 5.2.2. | | | in Section 5.2.2. |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
Table 3: TCPCL Message Types Table 4: TCPCL Message Types
5.2. Upkeep and Status Messages 5.2. Upkeep and Status Messages
5.2.1. Session Upkeep (KEEPALIVE) 5.2.1. Session Upkeep (KEEPALIVE)
The protocol includes a provision for transmission of KEEPALIVE The protocol includes a provision for transmission of KEEPALIVE
messages over the TCPCL session to help determine if the underlying messages over the TCPCL session to help determine if the underlying
TCP connection has been disrupted. TCP connection has been disrupted.
As described in Section 4.3, a negotiated parameter of each session As described in Section 4.3, a negotiated parameter of each session
skipping to change at page 19, line 25 skipping to change at page 21, line 25
keepalive time is longer than tens-of-minutes. Nodes SHOULD choose a keepalive time is longer than tens-of-minutes. Nodes SHOULD choose a
keepalive interval no longer than 10 minutes (600 seconds). keepalive interval no longer than 10 minutes (600 seconds).
Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP Note: The Keepalive Interval SHOULD NOT be chosen too short as TCP
retransmissions MAY occur in case of packet loss. Those will have to retransmissions MAY occur in case of packet loss. Those will have to
be triggered by a timeout (TCP retransmission timeout (RTO)), which be triggered by a timeout (TCP retransmission timeout (RTO)), which
is dependent on the measured RTT for the TCP connection so that is dependent on the measured RTT for the TCP connection so that
KEEPALIVE messages MAY experience noticeable latency. KEEPALIVE messages MAY experience noticeable latency.
The format of a KEEPALIVE message is a one-octet message type code of The format of a KEEPALIVE message is a one-octet message type code of
KEEPALIVE (as described in Table 3) with no additional data. Both KEEPALIVE (as described in Table 4) with no additional data. Both
sides SHOULD send a KEEPALIVE message whenever the negotiated sides SHOULD send a KEEPALIVE message whenever the negotiated
interval has elapsed with no transmission of any message (KEEPALIVE interval has elapsed with no transmission of any message (KEEPALIVE
or other). or other).
If no message (KEEPALIVE or other) has been received in a session If no message (KEEPALIVE or other) has been received in a session
after some implementation-defined time duration, then the node MAY after some implementation-defined time duration, then the node MAY
terminate the session by transmitting a one-octet SHUTDOWN message terminate the session by transmitting a one-octet SHUTDOWN message
(as described in Section 6.1) with reason code "Idle Timeout. (as described in Section 6.1) with reason code "Idle Timeout.
5.2.2. Message Rejection (MSG_REJECT) 5.2.2. Message Rejection (MSG_REJECT)
skipping to change at page 20, line 18 skipping to change at page 22, line 18
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Rejected Message Header | | Rejected Message Header |
+-----------------------------+ +-----------------------------+
Figure 7: Format of MSG_REJECT Messages Figure 7: Format of MSG_REJECT Messages
The fields of the MSG_REJECT message are: The fields of the MSG_REJECT message are:
Reason Code: A one-octet refusal reason code interpreted according Reason Code: A one-octet refusal reason code interpreted according
to the descriptions in Table 4. to the descriptions in Table 5.
Rejected Message Header: The Rejected Message Header is a copy of Rejected Message Header: The Rejected Message Header is a copy of
the Message Header to which the MSG_REJECT message is sent as a the Message Header to which the MSG_REJECT message is sent as a
response. response.
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
| Message | 0x01 | A message was received with a Message Type | | Message | 0x01 | A message was received with a Message Type |
| Type | | code unknown to the TCPCL node. | | Type | | code unknown to the TCPCL node. |
| Unknown | | | | Unknown | | |
| | | | | | | |
| Message | 0x02 | A message was received but the TCPCL node | | Message | 0x02 | A message was received but the TCPCL node |
| Unsupported | | cannot comply with the message contents. | | Unsupported | | cannot comply with the message contents. |
| | | | | | | |
| Message | 0x03 | A message was received while the session is | | Message | 0x03 | A message was received while the session is |
| Unexpected | | in a state in which the message is not | | Unexpected | | in a state in which the message is not |
| | | expected. | | | | expected. |
+-------------+------+----------------------------------------------+ +-------------+------+----------------------------------------------+
Table 4: MSG_REJECT Reason Codes Table 5: MSG_REJECT Reason Codes
5.3. Bundle Transfer 5.3. Bundle Transfer
All of the messages in this section are directly associated with All of the messages in this section are directly associated with
transferring a bundle between TCPCL nodes. transferring a bundle between TCPCL nodes.
A single TCPCL transfer results in a bundle (handled by the A single TCPCL transfer results in a bundle (handled by the
convergence layer as opaque data) being exchanged from one node to convergence layer as opaque data) being exchanged from one node to
the other. In TCPCL a transfer is accomplished by dividing a single the other. In TCPCL a transfer is accomplished by dividing a single
bundle up into "segments" based on the receiving-side Segment MRU bundle up into "segments" based on the receiving-side Segment MRU
skipping to change at page 23, line 22 skipping to change at page 25, line 22
| Data length (U64) | | Data length (U64) |
+------------------------------+ +------------------------------+
| Data contents (octet string) | | Data contents (octet string) |
+------------------------------+ +------------------------------+
Figure 9: Format of XFER_SEGMENT Messages Figure 9: Format of XFER_SEGMENT Messages
The fields of the XFER_SEGMENT message are: The fields of the XFER_SEGMENT message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 5. according to the descriptions in Table 6.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being made. being made.
Data length: A 64-bit unsigned integer indicating the number of Data length: A 64-bit unsigned integer indicating the number of
octets in the Data contents to follow. octets in the Data contents to follow.
Data contents: The variable-length data payload of the message. Data contents: The variable-length data payload of the message.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
skipping to change at page 23, line 44 skipping to change at page 25, line 44
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| END | 0x01 | If bit is set, indicates that this is the | | END | 0x01 | If bit is set, indicates that this is the |
| | | last segment of the transfer. | | | | last segment of the transfer. |
| | | | | | | |
| START | 0x02 | If bit is set, indicates that this is the | | START | 0x02 | If bit is set, indicates that this is the |
| | | first segment of the transfer. | | | | first segment of the transfer. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 5: XFER_SEGMENT Flags Table 6: XFER_SEGMENT Flags
The flags portion of the message contains two optional values in the The flags portion of the message contains two optional values in the
two low-order bits, denoted 'START' and 'END' in Table 5. The two low-order bits, denoted 'START' and 'END' in Table 6. The
'START' bit MUST be set to one if it precedes the transmission of the 'START' bit MUST be set to one if it precedes the transmission of the
first segment of a transfer. The 'END' bit MUST be set to one when first segment of a transfer. The 'END' bit MUST be set to one when
transmitting the last segment of a transfer. In the case where an transmitting the last segment of a transfer. In the case where an
entire transfer is accomplished in a single segment, both the 'START' entire transfer is accomplished in a single segment, both the 'START'
and 'END' bits MUST be set to one. and 'END' bits MUST be set to one.
Once a transfer of a bundle has commenced, the node MUST only send Once a transfer of a bundle has commenced, the node MUST only send
segments containing sequential portions of that bundle until it sends segments containing sequential portions of that bundle until it sends
a segment with the 'END' bit set. No interleaving of multiple a segment with the 'END' bit set. No interleaving of multiple
transfers from the same node is possible within a single TCPCL transfers from the same node is possible within a single TCPCL
skipping to change at page 24, line 41 skipping to change at page 26, line 41
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
| Acknowledged length (U64) | | Acknowledged length (U64) |
+-----------------------------+ +-----------------------------+
Figure 10: Format of XFER_ACK Messages Figure 10: Format of XFER_ACK Messages
The fields of the XFER_ACK message are: The fields of the XFER_ACK message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 5. according to the descriptions in Table 6.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being acknowledged. being acknowledged.
Acknowledged length: A 64-bit unsigned integer indicating the total Acknowledged length: A 64-bit unsigned integer indicating the total
number of octets in the transfer which are being acknowledged. number of octets in the transfer which are being acknowledged.
A receiving TCPCL node SHALL send an XFER_ACK message in response to A receiving TCPCL node SHALL send an XFER_ACK message in response to
each received XFER_SEGMENT message. The flags portion of the each received XFER_SEGMENT message. The flags portion of the
XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT
skipping to change at page 26, line 8 skipping to change at page 28, line 8
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
Figure 11: Format of XFER_REFUSE Messages Figure 11: Format of XFER_REFUSE Messages
The fields of the XFER_REFUSE message are: The fields of the XFER_REFUSE message are:
Reason Code: A one-octet refusal reason code interpreted according Reason Code: A one-octet refusal reason code interpreted according
to the descriptions in Table 6. to the descriptions in Table 7.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being refused. being refused.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Name | Semantics | | Name | Semantics |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Unknown | Reason for refusal is unknown or not specified. | | Unknown | Reason for refusal is unknown or not specified. |
| | | | | |
| Completed | The receiver already has the complete bundle. The | | Completed | The receiver already has the complete bundle. The |
skipping to change at page 26, line 30 skipping to change at page 28, line 30
| | received. | | | received. |
| | | | | |
| No | The receiver's resources are exhausted. The sender | | No | The receiver's resources are exhausted. The sender |
| Resources | SHOULD apply reactive bundle fragmentation before | | Resources | SHOULD apply reactive bundle fragmentation before |
| | retrying. | | | retrying. |
| | | | | |
| Retransmit | The receiver has encountered a problem that requires | | Retransmit | The receiver has encountered a problem that requires |
| | the bundle to be retransmitted in its entirety. | | | the bundle to be retransmitted in its entirety. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
Table 6: XFER_REFUSE Reason Codes Table 7: XFER_REFUSE Reason Codes
The receiver MUST, for each transfer preceding the one to be refused, The receiver MUST, for each transfer preceding the one to be refused,
have either acknowledged all XFER_SEGMENTs or refused the bundle have either acknowledged all XFER_SEGMENTs or refused the bundle
transfer. transfer.
The bundle transfer refusal MAY be sent before an entire data segment The bundle transfer refusal MAY be sent before an entire data segment
is received. If a sender receives a XFER_REFUSE message, the sender is received. If a sender receives a XFER_REFUSE message, the sender
MUST complete the transmission of any partially sent XFER_SEGMENT MUST complete the transmission of any partially sent XFER_SEGMENT
message. There is no way to interrupt an individual TCPCL message message. There is no way to interrupt an individual TCPCL message
partway through sending it. The sender MUST NOT commence partway through sending it. The sender MUST NOT commence
skipping to change at page 27, line 11 skipping to change at page 29, line 11
aborted bundle. The beginning of the next bundle is identified by aborted bundle. The beginning of the next bundle is identified by
the 'START' bit set to '1', indicating the start of a new transfer, the 'START' bit set to '1', indicating the start of a new transfer,
and with a distinct Transfer ID value. and with a distinct Transfer ID value.
6. Session Termination 6. Session Termination
This section describes the procedures for ending a TCPCL session. This section describes the procedures for ending a TCPCL session.
6.1. Shutdown Message (SHUTDOWN) 6.1. Shutdown Message (SHUTDOWN)
To cleanly shut down a session, a SHUTDOWN message MUST be To cleanly shut down a session, a SHUTDOWN message SHALL be
transmitted by either node at any point following complete transmitted by either node at any point following complete
transmission of any other message. After sending a SHUTDOWN message, transmission of any other message. Upon receiving a SHUTDOWN message
the sender of the message MAY send further acknowledgments (XFER_ACK after not sending a SHUTDOWN message in the same session, a node
or XFER_REFUSE) but no further data messages (XFER_INIT or SHOULD send a confirmation SHUTDOWN message with identical content to
XFER_SEGMENT). A receiving node SHOULD acknowledge all received data the SHUTDOWN for which it is confirming.
segments before sending a SHUTDOWN message to end the session. A
transmitting node SHALL treat a SHUTDOWN message received mid-
transfer (i.e. before the final acknowledgment) as a failure of the
transfer.
After transmitting a SHUTDOWN message, a node MAY immediately close After sending a SHUTDOWN message, a node MAY continue a possible in-
the associated TCP connection. Once the SHUTDOWN message is sent, progress transfer in either direction. After sending a SHUTDOWN
any further received data on the TCP connection SHOULD be ignored. message, a node SHALL NOT begin any new outgoing transfer (i.e. send
Any delay between request to terminate the TCP connection and actual an XFER_INIT message) for the remainder of the session. After
receving a SHUTDOWN message, a node SHALL NOT accept any new incoming
transfer for the remainder of the session.
Instead of following a clean shutdown sequence, after transmitting a
SHUTDOWN message a node MAY immediately close the associated TCP
connection. When performing an unclean shutdown, a receiving node
SHOULD acknowledge all received data segments before closing the TCP
connection. When performing an unclean shutodwn, a transmitting node
SHALL treat either sending or receiving a SHUTDOWN message (i.e.
before the final acknowledgment) as a failure of the transfer. Any
delay between request to terminate the TCP connection and actual
closing of the connection (a "half-closed" state) MAY be ignored by closing of the connection (a "half-closed" state) MAY be ignored by
the TCPCL node. the TCPCL node.
The format of the SHUTDOWN message is as follows: The format of the SHUTDOWN message is as follows:
+-----------------------------------+ +-----------------------------------+
| Message Header | | Message Header |
+-----------------------------------+ +-----------------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------------+ +-----------------------------------+
| Reason Code (optional U8) | | Reason Code (optional U8) |
+-----------------------------------+ +-----------------------------------+
| Reconnection Delay (optional U16) | | Reconnection Delay (optional U16) |
+-----------------------------------+ +-----------------------------------+
Figure 12: Format of SHUTDOWN Messages Figure 12: Format of SHUTDOWN Messages
The fields of the SHUTDOWN message are: The fields of the SHUTDOWN message are:
Message Flags: A one-octet field of single-bit flags, interpreted Message Flags: A one-octet field of single-bit flags, interpreted
according to the descriptions in Table 7. according to the descriptions in Table 8.
Reason Code: A one-octet refusal reason code interpreted according Reason Code: A one-octet refusal reason code interpreted according
to the descriptions in Table 8. The Reason Code is present or to the descriptions in Table 9. The Reason Code is present or
absent as indicated by one of the flags. absent as indicated by one of the flags.
Reconnection Delay: A 16-bit unsigned integer indicating the desired Reconnection Delay: A 16-bit unsigned integer indicating the desired
delay, in seconds, before re-attepmting a TCPCL session to the delay, in seconds, before re-attepmting a TCPCL session to the
sending node. The Reconnection Delay is present or absent as sending node. The Reconnection Delay is present or absent as
indicated by one of the flags. indicated by one of the flags.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| D | 0x01 | If bit is set, indicates that a Reconnection | | D | 0x01 | If bit is set, indicates that a Reconnection |
| | | Delay field is present. | | | | Delay field is present. |
| | | | | | | |
| R | 0x02 | If bit is set, indicates that a Reason Code | | R | 0x02 | If bit is set, indicates that a Reason Code |
| | | field is present. | | | | field is present. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 7: SHUTDOWN Flags Table 8: SHUTDOWN Flags
It is possible for a node to convey optional information regarding It is possible for a node to convey optional information regarding
the reason for session termination. To do so, the node MUST set the the reason for session termination. To do so, the node MUST set the
'R' bit in the message flags and transmit a one-octet reason code 'R' bit in the message flags and transmit a one-octet reason code
immediately following the message header. The specified values of immediately following the message header. The specified values of
the reason code are: the reason code are:
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Name | Description | | Name | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
skipping to change at page 28, line 51 skipping to change at page 31, line 26
| Contact | The node cannot interpret or negotiate contact | | Contact | The node cannot interpret or negotiate contact |
| Failure | header option. | | Failure | header option. |
| | | | | |
| TLS Failure | The node failed to negotiate TLS session and | | TLS Failure | The node failed to negotiate TLS session and |
| | cannot continue the session. | | | cannot continue the session. |
| | | | | |
| Resource | The node has run into some resource limit and | | Resource | The node has run into some resource limit and |
| Exhaustion | cannot continue the session. | | Exhaustion | cannot continue the session. |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
Table 8: SHUTDOWN Reason Codes Table 9: SHUTDOWN Reason Codes
If a node does not want its peer to reopen a connection immediately, If a node does not want its peer to reopen a connection immediately,
it SHALL set the 'D' bit in the flags and include a reconnection it SHALL set the 'D' bit in the flags and include a reconnection
delay to indicate when the peer is allowed to attempt another session delay to indicate when the peer is allowed to attempt another session
setup. The Reconnection Delay value 0 SHALL be interpreted as an setup. The Reconnection Delay value 0 SHALL be interpreted as an
infinite delay, i.e., that the connecting node MUST NOT re-establish infinite delay, i.e., that the connecting node MUST NOT re-establish
the session. the session.
A session shutdown MAY occur immediately after transmission of a A session shutdown MAY occur immediately after transmission of a
contact header (and prior to any further message transmit). This contact header (and prior to any further message transmit). This
skipping to change at page 29, line 46 skipping to change at page 32, line 20
The protocol includes a provision for clean shutdown of idle The protocol includes a provision for clean shutdown of idle
sessions. Determining the length of time to wait before closing idle sessions. Determining the length of time to wait before closing idle
sessions, if they are to be closed at all, is an implementation and sessions, if they are to be closed at all, is an implementation and
configuration matter. configuration matter.
If there is a configured time to close idle links and if no TCPCL If there is a configured time to close idle links and if no TCPCL
messages (other than KEEPALIVE messages) has been received for at messages (other than KEEPALIVE messages) has been received for at
least that amount of time, then either node MAY terminate the session least that amount of time, then either node MAY terminate the session
by transmitting a SHUTDOWN message indicating the reason code of by transmitting a SHUTDOWN message indicating the reason code of
"Idle timeout" (as described in Table 8). "Idle timeout" (as described in Table 9).
7. Security Considerations 7. Security Considerations
One security consideration for this protocol relates to the fact that One security consideration for this protocol relates to the fact that
nodes present their endpoint identifier as part of the contact header nodes present their endpoint identifier as part of the contact header
exchange. It would be possible for a node to fake this value and exchange. It would be possible for a node to fake this value and
present the identity of a singleton endpoint in which the node is not present the identity of a singleton endpoint in which the node is not
a member, essentially masquerading as another DTN node. If this a member, essentially masquerading as another DTN node. If this
identifier is used outside of a TLS-secured session or without identifier is used outside of a TLS-secured session or without
further verification as a means to determine which bundles are further verification as a means to determine which bundles are
transmitted over the session, then the node that has falsified its transmitted over the session, then the node that has falsified its
identity would be able to obtain bundles that it otherwise would not identity would be able to obtain bundles that it otherwise would not
have. Therefore, a node SHALL NOT use the EID value of an unsecured have. Therefore, a node SHALL NOT use the EID value of an unsecured
contact header to derive a peer node's identity unless it can contact header to derive a peer node's identity unless it can
corroborate it via other means. When TCPCL session security is corroborate it via other means. When TCPCL session security is
mandated by a TCPCL peer, that peer SHALL transmit initial unsecured mandated by a TCPCL peer, that peer SHALL transmit initial unsecured
contact header values indicated in Table 9 in order. These values contact header values indicated in Table 10 in order. These values
avoid unnecessarily leaking session parameters and will be ignored avoid unnecessarily leaking session parameters and will be ignored
when secure contact header re-exchange occurs. when secure contact header re-exchange occurs.
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
| Parameter | Value | | Parameter | Value |
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
| Flags | The USE_TLS flag is set. | | Flags | The USE_TLS flag is set. |
| | | | | |
| Keepalive Interval | Zero, indicating no keepalive. | | Keepalive Interval | Zero, indicating no keepalive. |
| | | | | |
| Segment MRU | Zero, indicating all segments are refused. | | Segment MRU | Zero, indicating all segments are refused. |
| | | | | |
| Transfer MRU | Zero, indicating all transfers are refused. | | Transfer MRU | Zero, indicating all transfers are refused. |
| | | | | |
| EID | Empty, indicating lack of EID. | | EID | Empty, indicating lack of EID. |
+--------------------+---------------------------------------------+ +--------------------+---------------------------------------------+
Table 9: Recommended Unsecured Contact Header Table 10: Recommended Unsecured Contact Header
TCPCL can be used to provide point-to-point transport security, but TCPCL can be used to provide point-to-point transport security, but
does not provide security of data-at-rest and does not guarantee end- does not provide security of data-at-rest and does not guarantee end-
to-end bundle security. The mechanisms defined in [RFC6257] and to-end bundle security. The mechanisms defined in [RFC6257] and
[I-D.ietf-dtn-bpsec] are to be used instead. [I-D.ietf-dtn-bpsec] are to be used instead.
Even when using TLS to secure the TCPCL session, the actual Even when using TLS to secure the TCPCL session, the actual
ciphersuite negotiated between the TLS peers MAY be insecure. TLS ciphersuite negotiated between the TLS peers MAY be insecure. TLS
can be used to perform authentication without data confidentiality, can be used to perform authentication without data confidentiality,
for example. It is up to security policies within each TCPCL node to for example. It is up to security policies within each TCPCL node to
skipping to change at page 32, line 31 skipping to change at page 35, line 29
+-------+-------------+---------------------+ +-------+-------------+---------------------+
8.3. Header Extension Types 8.3. Header Extension Types
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Header Extension Types" and initialize it with the contents of Header Extension Types" and initialize it with the contents of
Table 10. The registration procedure is RFC Required within the Table 11. The registration procedure is RFC Required within the
lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are
reserved for use on private networks for functions not published to reserved for use on private networks for functions not published to
the IANA. the IANA.
+----------------+--------------------------+ +----------------+--------------------------+
| Code | Message Type | | Code | Message Type |
+----------------+--------------------------+ +----------------+--------------------------+
| 0x0000 | Reserved | | 0x0000 | Reserved |
| | | | | |
| 0x0001--0x3fff | Unassigned | | 0x0001 | REACTIVE_FRAGMENT |
| | |
| 0x0002--0x3fff | Unassigned |
| | | | | |
| 0x8000--0xffff | Private/Experimental Use | | 0x8000--0xffff | Private/Experimental Use |
+----------------+--------------------------+ +----------------+--------------------------+
Table 10: Header Extension Type Codes Table 11: Header Extension Type Codes
8.4. Message Types 8.4. Message Types
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
Message Types" and initialize it with the contents of Table 11. The Message Types" and initialize it with the contents of Table 12. The
registration procedure is RFC Required. registration procedure is RFC Required.
+-----------+--------------+ +-----------+--------------+
| Code | Message Type | | Code | Message Type |
+-----------+--------------+ +-----------+--------------+
| 0x00 | Reserved | | 0x00 | Reserved |
| | | | | |
| 0x01 | XFER_SEGMENT | | 0x01 | XFER_SEGMENT |
| | | | | |
| 0x02 | XFER_ACK | | 0x02 | XFER_ACK |
skipping to change at page 33, line 37 skipping to change at page 36, line 32
| | | | | |
| 0x05 | SHUTDOWN | | 0x05 | SHUTDOWN |
| | | | | |
| 0x06 | XFER_INIT | | 0x06 | XFER_INIT |
| | | | | |
| 0x07 | MSG_REJECT | | 0x07 | MSG_REJECT |
| | | | | |
| 0x08--0xf | Unassigned | | 0x08--0xf | Unassigned |
+-----------+--------------+ +-----------+--------------+
Table 11: Message Type Codes Table 12: Message Type Codes
8.5. XFER_REFUSE Reason Codes 8.5. XFER_REFUSE Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
XFER_REFUSE Reason Codes" and initialize it with the contents of XFER_REFUSE Reason Codes" and initialize it with the contents of
Table 12. The registration procedure is RFC Required. Table 13. The registration procedure is RFC Required.
+----------+---------------------------+ +----------+---------------------------+
| Code | Refusal Reason | | Code | Refusal Reason |
+----------+---------------------------+ +----------+---------------------------+
| 0x0 | Unknown | | 0x0 | Unknown |
| | | | | |
| 0x1 | Completed | | 0x1 | Completed |
| | | | | |
| 0x2 | No Resources | | 0x2 | No Resources |
| | | | | |
| 0x3 | Retransmit | | 0x3 | Retransmit |
| | | | | |
| 0x4--0x7 | Unassigned | | 0x4--0x7 | Unassigned |
| | | | | |
| 0x8--0xf | Reserved for future usage | | 0x8--0xf | Reserved for future usage |
+----------+---------------------------+ +----------+---------------------------+
Table 12: XFER_REFUSE Reason Codes Table 13: XFER_REFUSE Reason Codes
8.6. SHUTDOWN Reason Codes 8.6. SHUTDOWN Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
SHUTDOWN Reason Codes" and initialize it with the contents of SHUTDOWN Reason Codes" and initialize it with the contents of
Table 13. The registration procedure is RFC Required. Table 14. The registration procedure is RFC Required.
+------------+---------------------+ +------------+---------------------+
| Code | Shutdown Reason | | Code | Shutdown Reason |
+------------+---------------------+ +------------+---------------------+
| 0x00 | Idle timeout | | 0x00 | Idle timeout |
| | | | | |
| 0x01 | Version mismatch | | 0x01 | Version mismatch |
| | | | | |
| 0x02 | Busy | | 0x02 | Busy |
| | | | | |
| 0x03 | Contact Failure | | 0x03 | Contact Failure |
| | | | | |
| 0x04 | TLS failure | | 0x04 | TLS failure |
| | | | | |
| 0x05 | Resource Exhaustion | | 0x05 | Resource Exhaustion |
| | | | | |
| 0x06--0xFF | Unassigned | | 0x06--0xFF | Unassigned |
+------------+---------------------+ +------------+---------------------+
Table 13: SHUTDOWN Reason Codes Table 14: SHUTDOWN Reason Codes
8.7. MSG_REJECT Reason Codes 8.7. MSG_REJECT Reason Codes
EDITOR NOTE: sub-registry to-be-created upon publication of this EDITOR NOTE: sub-registry to-be-created upon publication of this
specification. specification.
IANA will create, under the "Bundle Protocol" registry, a sub- IANA will create, under the "Bundle Protocol" registry, a sub-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
MSG_REJECT Reason Codes" and initialize it with the contents of MSG_REJECT Reason Codes" and initialize it with the contents of
Table 14. The registration procedure is RFC Required. Table 15. The registration procedure is RFC Required.
+-----------+----------------------+ +-----------+----------------------+
| Code | Rejection Reason | | Code | Rejection Reason |
+-----------+----------------------+ +-----------+----------------------+
| 0x00 | reserved | | 0x00 | reserved |
| | | | | |
| 0x01 | Message Type Unknown | | 0x01 | Message Type Unknown |
| | | | | |
| 0x02 | Message Unsupported | | 0x02 | Message Unsupported |
| | | | | |
| 0x03 | Message Unexpected | | 0x03 | Message Unexpected |
| | | | | |
| 0x04-0xFF | Unassigned | | 0x04-0xFF | Unassigned |
+-----------+----------------------+ +-----------+----------------------+
Table 14: REJECT Reason Codes Table 15: REJECT Reason Codes
9. Acknowledgments 9. Acknowledgments
This specification is based on comments on implementation of This specification is based on comments on implementation of
[RFC7242] provided from Scott Burleigh. [RFC7242] provided from Scott Burleigh.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 38, line 5 skipping to change at page 40, line 49
o Added contact negotiation failure SHUTDOWN reason code. o Added contact negotiation failure SHUTDOWN reason code.
o Added MSG_REJECT message to indicate an unknown or unhandled o Added MSG_REJECT message to indicate an unknown or unhandled
message was received. message was received.
o Added TLS session security mechanism. o Added TLS session security mechanism.
o Added TLS failure and Resource Exhaustion SHUTDOWN reason code. o Added TLS failure and Resource Exhaustion SHUTDOWN reason code.
o Added extension for reactive fragmentation negotiation
(REACTIVE_FRAGMENT).
Authors' Addresses Authors' Addresses
Brian Sipos Brian Sipos
RKF Engineering Solutions, LLC RKF Engineering Solutions, LLC
7500 Old Georgetown Road 7500 Old Georgetown Road
Suite 1275 Suite 1275
Bethesda, MD 20814-6198 Bethesda, MD 20814-6198
US US
Email: BSipos@rkf-eng.com Email: BSipos@rkf-eng.com
 End of changes. 44 change blocks. 
93 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/