draft-ietf-dtn-tcpclv4-03.txt   draft-ietf-dtn-tcpclv4-04.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: May 17, 2018 J. Ott Expires: June 13, 2018 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
November 13, 2017 December 10, 2017
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-03 draft-ietf-dtn-tcpclv4-04
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 Protocl encodings, and convergence layer requirements in Bundle Protocol
Version 7. Several new IANA registries are defined for TCPCLv4 which Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles
define some behaviors inherited from TCPCLv3 but with updated as its service data unit being transported and provides a reliable
encodings and/or semantics. transport of such bundles. Several new IANA registries are defined
for TCPCLv4 which define some behaviors inherited from TCPCLv3 but
with updated encodings and/or semantics.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 17, 2018. This Internet-Draft will expire on June 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 18 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4
3. General Protocol Description . . . . . . . . . . . . . . . . 5 3. General Protocol Description . . . . . . . . . . . . . . . . 5
3.1. Bidirectional Use of TCPCL Sessions . . . . . . . . . . . 7 3.1. TCPCL Session Overview . . . . . . . . . . . . . . . . . 6
3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7 3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8
4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12 4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12
4.2. Validation and Parameter Negotiation . . . . . . . . . . 13 4.2. Validation and Parameter Negotiation . . . . . . . . . . 13
4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14 4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14
4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15 4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15
4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15 4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15
5. Established Session Operation . . . . . . . . . . . . . . . . 16 5. Established Session Operation . . . . . . . . . . . . . . . . 16
5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16
5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 18 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 17
5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 18 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 17
5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18 5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18
5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19 5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 20 5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19
5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20 5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20
5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 21 5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 21
5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22 5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22
5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23 5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 25 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 25
6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 26 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 28 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 30 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 30
8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 31 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 30
8.3. Header Extension Types . . . . . . . . . . . . . . . . . 31 8.3. Header Extension Types . . . . . . . . . . . . . . . . . 31
8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 32 8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 31
8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 32 8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 32
8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 33 8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 33
8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 34 8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 34
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 35 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 3, line 33 skipping to change at page 3, line 36
[I-D.ietf-dtn-bpbis], an application-layer protocol that is used to [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to
construct a store-and- forward overlay network. As described in the construct a store-and- forward overlay network. As described in the
Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the
services of a "convergence- layer adapter" (CLA) to send and receive services of a "convergence- layer adapter" (CLA) to send and receive
bundles using the service of some "native" link, network, or Internet bundles using the service of some "native" link, network, or Internet
protocol. This document describes one such convergence-layer adapter protocol. This document describes one such convergence-layer adapter
that uses the well-known Transmission Control Protocol (TCP). This that uses the well-known Transmission Control Protocol (TCP). This
convergence layer is referred to as TCPCL. convergence layer is referred to as TCPCL.
The locations of the TCPCL and the BP in the Internet model protocol The locations of the TCPCL and the BP in the Internet model protocol
stack are shown in Figure 1. In particular, when BP is using TCP as stack (described in [RFC1122]) are shown in Figure 1. In particular,
its bearer with TCPCL as its convergence layer, both BP and TCPCL when BP is using TCP as its bearer with TCPCL as its convergence
reside at the application layer of the Internet model. layer, both BP and TCPCL reside at the application layer of the
Internet model.
+-------------------------+ +-------------------------+
| DTN Application | -\ | DTN Application | -\
+-------------------------| | +-------------------------| |
| Bundle Protocol (BP) | -> Application Layer | Bundle Protocol (BP) | -> Application Layer
+-------------------------+ | +-------------------------+ |
| TCP Conv. Layer (TCPCL) | -/ | TCP Conv. Layer (TCPCL) | |
+-------------------------+ +-------------------------+ |
| TLS (optional) | ---> Presentation Layer | TLS (optional) | -/
+-------------------------+ +-------------------------+
| TCP | ---> Transport Layer | TCP | ---> Transport Layer
+-------------------------+ +-------------------------+
| IP | ---> Network Layer | IPv4/IPv6 | ---> Network Layer
+-------------------------+ +-------------------------+
| Link-Layer Protocol | ---> Link Layer | Link-Layer Protocol | ---> Link Layer
+-------------------------+ +-------------------------+
| Physical Medium | ---> Physical Layer
+-------------------------+
Figure 1: The Locations of the Bundle Protocol and the TCP Figure 1: The Locations of the Bundle Protocol and the TCP
Convergence-Layer Protocol above the Internet Protocol Stack Convergence-Layer Protocol above the Internet Protocol Stack
This document describes the format of the protocol data units passed This document describes the format of the protocol data units passed
between entities participating in TCPCL communications. This between entities participating in TCPCL communications. This
document does not address: document does not address:
o The format of protocol data units of the Bundle Protocol, as those o The format of protocol data units of the Bundle Protocol, as those
are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. This are defined elsewhere in [RFC5050] and [I-D.ietf-dtn-bpbis]. This
skipping to change at page 5, line 30 skipping to change at page 5, line 29
of this document, the term "session" without the prefix "TCPCL" of this document, the term "session" without the prefix "TCPCL"
refers to a TCPCL session. refers to a TCPCL session.
Session parameters: The session parameters are a set of values used Session parameters: The session parameters are a set of values used
to affect the operation of the TCPCL for a given session. The to affect the operation of the TCPCL for a given session. The
manner in which these parameters are conveyed to the bundle node manner in which these parameters are conveyed to the bundle node
and thereby to the TCPCL is implementation dependent. However, and thereby to the TCPCL is implementation dependent. However,
the mechanism by which two bundle nodes exchange and negotiate the the mechanism by which two bundle nodes exchange and negotiate the
values to be used for a given session is described in Section 4.2. values to be used for a given session is described in Section 4.2.
Transfer Transfer refers to the procedures and mechanisms (described Transfer: Transfer refers to the procedures and mechanisms
below) for conveyance of an individual bundle from one node to (described below) for conveyance of an individual bundle from one
another. Each transfer within TCPCLv4 is identified by a Transfer node to another. Each transfer within TCPCLv4 is identified by a
ID number which is unique only to a single direction within a Transfer ID number which is unique only to a single direction
single Session. within a single Session.
Reason Codes: The TCPCL uses numeric codes to encode specific
reasons for individual failure/error message types. This limits
the expressiveness of TCPCL error encodings, but simplifies the
encoding of errors and allows an application policy to attempt
recovery from expected 'failure' modes (e.g. if a Session cannot
be established with USE_TLS disabled because of a Contact Failure
shutdown, a re-attempt can be made with USE_TLS enabled).
3. General Protocol Description 3. General Protocol Description
The service of this protocol is the transmission of DTN bundles over The service of this protocol is the transmission of DTN bundles via
TCP. This document specifies the encapsulation of bundles, the Transmission Control Protocol (TCP). This document specifies the
procedures for TCP setup and teardown, and a set of messages and node encapsulation of bundles, procedures for TCP setup and teardown, and
requirements. The general operation of the protocol is as follows. a set of messages and node requirements. The general operation of
the protocol is as follows.
3.1. TCPCL Session Overview
First, one node establishes a TCPCL session to the other by First, one node establishes a TCPCL session to the other by
initiating a TCP connection. After setup of the TCP connection is initiating a TCP connection in accordance with [RFC0793]. After
complete, an initial contact header is exchanged in both directions setup of the TCP connection is complete, an initial contact header is
to set parameters of the TCPCL session and exchange a singleton exchanged in both directions to set parameters of the TCPCL session
endpoint identifier for each node (not the singleton Endpoint and exchange a singleton endpoint identifier for each node (not the
Identifier (EID) of any application running on the node) to denote singleton Endpoint Identifier (EID) of any application running on the
the bundle-layer identity of each DTN node. This is used to assist node) to denote the bundle-layer identity of each DTN node. This is
in routing and forwarding messages, e.g., to prevent loops. used to assist in routing and forwarding messages (e.g. to prevent
loops).
Once the TCPCL session is established and configured in this way, Once the TCPCL session is established and configured in this way,
bundles can be transferred in either direction. Each transfer is bundles can be transferred in either direction. Each transfer is
performed in one or more logical segments of data. Each logical data performed by an initialization (XFER_INIT) message followed by one or
segment consists of a XFER_SEGMENT message header and flags, a count more logical segments of data within an XFER_SEGMENT message. The
of the length of the segment, and finally the octet range of the choice of the length to use for segments is an implementation matter,
bundle data. The choice of the length to use for segments is an but each segment must be no larger than the receiving node's maximum
implementation matter (but must be within the Segment MRU size of receive unit (MRU) (see the field "Segment MRU" of Section 4.1). The
Section 4.1). The first segment for a bundle MUST set the 'START' first segment for a bundle MUST set the 'START' flag, and the last
flag, and the last one MUST set the 'end' flag in the XFER_SEGMENT one MUST set the 'end' flag in the XFER_SEGMENT message flags.
message flags.
If multiple bundles are transmitted on a single TCPCL connection, If multiple bundles are transmitted on a single TCPCL connection,
they MUST be transmitted consecutively. Interleaving data segments they MUST be transmitted consecutively. Interleaving data segments
from different bundles is not allowed. Bundle interleaving can be from different bundles is not allowed. Bundle interleaving can be
accomplished by fragmentation at the BP layer or by establishing accomplished by fragmentation at the BP layer or by establishing
multiple TCPCL sessions. multiple TCPCL sessions.
A feature of this protocol is for the receiving node to send A feature of this protocol is for the receiving node to send
acknowledgments as bundle data segments arrive (XFER_ACK). The acknowledgments as bundle data segments arrive (XFER_ACK). The
rationale behind these acknowledgments is to enable the sender node rationale behind these acknowledgments is to enable the sender node
skipping to change at page 6, line 50 skipping to change at page 7, line 12
Note: This enables a cross-layer optimization in that it allows a Note: This enables a cross-layer optimization in that it allows a
receiver that detects that it already has received a certain bundle receiver that detects that it already has received a certain bundle
to interrupt transmission as early as possible and thus save to interrupt transmission as early as possible and thus save
transmission capacity for other bundles. transmission capacity for other bundles.
For sessions that are idle, a KEEPALIVE message is sent at a For sessions that are idle, a KEEPALIVE message is sent at a
negotiated interval. This is used to convey node liveness negotiated interval. This is used to convey node liveness
information. information.
Finally, before sessions close, a SHUTDOWN message is sent to the Finally, before sessions close, a SHUTDOWN message is sent to the
session peer. After sending a SHUTDOWN message, the sender of this session peer. A SHUTDOWN message MAY also be used to refuse a
message MAY send further acknowledgments (XFER_ACK or XFER_REFUSE) session setup by a peer (see Section 4.2). After sending a SHUTDOWN
but no further data messages (XFER_SEGMENT). A SHUTDOWN message MAY message, the sender of the message MAY send further acknowledgments
also be used to refuse a session setup by a peer. (XFER_ACK or XFER_REFUSE) but no further data messages (XFER_INIT or
XFER_SEGMENT). After receving a SHUTDOWN message and when no
3.1. Bidirectional Use of TCPCL Sessions transfers are in-progress (i.e. have unacknowledged segemnts)
There are specific messages for sending and receiving operations (in There are specific messages for sending and receiving operations (in
addition to session setup/teardown). TCPCL is symmetric, i.e., both addition to session setup/teardown). TCPCL is symmetric, i.e., both
sides can start sending data segments in a session, and one side's sides can start sending data segments in a session, and one side's
bundle transfer does not have to complete before the other side can bundle transfer does not have to complete before the other side can
start sending data segments on its own. Hence, the protocol allows start sending data segments on its own. Hence, the protocol allows
for a bi-directional mode of communication. for a bi-directional mode of communication. Note that in the case of
concurrent bidirectional transmission, acknowledgment segments MAY be
Note that in the case of concurrent bidirectional transmission, interleaved with data segments.
acknowledgment segments MAY be interleaved with data segments.
3.2. Example Message Exchange 3.2. Example Message Exchange
The following figure visually depicts the protocol exchange for a The following figure depicts the protocol exchange for a simple
simple session, showing the session establishment and the session, showing the session establishment and the transmission of a
transmission of a single bundle split into three data segments (of single bundle split into three data segments (of lengths "L1", "L2",
lengths "L1", "L2", and "L3") from Node A to Node B. and "L3") from Node A to Node B.
Note that the sending node MAY transmit multiple XFER_SEGMENT Note that the sending node MAY transmit multiple XFER_SEGMENT
messages without necessarily waiting for the corresponding XFER_ACK messages without necessarily waiting for the corresponding XFER_ACK
responses. This enables pipelining of messages on a channel. responses. This enables pipelining of messages on a channel.
Although this example only demonstrates a single bundle transmission, Although this example only demonstrates a single bundle transmission,
it is also possible to pipeline multiple XFER_SEGMENT messages for it is also possible to pipeline multiple XFER_SEGMENT messages for
different bundles without necessarily waiting for XFER_ACK messages different bundles without necessarily waiting for XFER_ACK messages
to be returned for each one. However, interleaving data segments to be returned for each one. However, interleaving data segments
from different bundles is not allowed. from different bundles is not allowed.
skipping to change at page 8, line 45 skipping to change at page 8, line 45
+-------------------------+ +-------------------------+
<- | XFER_ACK (end) | <- | XFER_ACK (end) |
| Transfer ID [I1] | | Transfer ID [I1] |
| Length [L1+L2+L3] | | Length [L1+L2+L3] |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| SHUTDOWN | -> <- | SHUTDOWN | | SHUTDOWN | -> <- | SHUTDOWN |
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
Figure 2: A SL1e Visual Example of the Flow of Protocol Messages on a Figure 2: An Example of the Flow of Protocol Messages on a Single TCP
Single TCP Session between Two Nodes (A and B) Session between Two Nodes (A and B)
4. Session Establishment 4. Session Establishment
For bundle transmissions to occur using the TCPCL, a TCPCL session For bundle transmissions to occur using the TCPCL, a TCPCL session
MUST first be established between communicating nodes. It is up to MUST first be established between communicating nodes. It is up to
the implementation to decide how and when session setup is triggered. the implementation to decide how and when session setup is triggered.
For example, some sessions MAY be opened proactively and maintained For example, some sessions MAY be opened proactively and maintained
for as long as is possible given the network conditions, while other for as long as is possible given the network conditions, while other
sessions MAY be opened only when there is a bundle that is queued for sessions MAY be opened only when there is a bundle that is queued for
transmission and the routing algorithm selects a certain next-hop transmission and the routing algorithm selects a certain next-hop
node. node.
To establish a TCPCL session, a node MUST first establish a TCP To establish a TCPCL session, a node MUST first establish a TCP
connection with the intended peer node, typically by using the connection with the intended peer node, typically by using the
services provided by the operating system. Destination port number services provided by the operating system. Destination port number
4556 has been assigned by IANA as the well-known port number for the 4556 has been assigned by IANA as the Registered Port number for the
TCP convergence layer. Other destination port numbers MAY be used TCP convergence layer. Other destination port numbers MAY be used
per local configuration. Determining a peer's destination port per local configuration. Determining a peer's destination port
number (if different from the well-known TCPCL port) is up to the number (if different from the registered TCPCL port number) is up to
implementation. Any source port number MAY be used for TCPCL the implementation. Any source port number MAY be used for TCPCL
sessions. Typically an operating system assigned number in the TCP sessions. Typically an operating system assigned number in the TCP
Ephemeral range (49152--65535) is used. Ephemeral range (49152--65535) is used.
If the node is unable to establish a TCP connection for any reason, If the node is unable to establish a TCP connection for any reason,
then it is an implementation matter to determine how to handle the then it is an implementation matter to determine how to handle the
connection failure. A node MAY decide to re-attempt to establish the connection failure. A node MAY decide to re-attempt to establish the
connection. If it does so, it MUST NOT overwhelm its target with connection. If it does so, it MUST NOT overwhelm its target with
repeated connection attempts. Therefore, the node MUST retry the repeated connection attempts. Therefore, the node MUST retry the
connection setup only after some delay (a 1-second minimum is connection setup only after some delay (a 1-second minimum is
RECOMMENDED), and it SHOULD use a (binary) exponential backoff RECOMMENDED), and it SHOULD use a (binary) exponential backoff
skipping to change at page 12, line 20 skipping to change at page 12, line 20
Flags: A one-octet field containing generic bit flags about the Flags: A one-octet field containing generic bit flags about the
item, which are listed in Table 2. If a TCPCL node receives an item, which are listed in Table 2. If a TCPCL node receives an
extension item with an unknown Item Type and the CRITICAL flag extension item with an unknown Item Type and the CRITICAL flag
set, the node SHALL close the TCPCL session with SHUTDOWN reason set, the node SHALL close the TCPCL session with SHUTDOWN reason
code of "Contact Failure". If the CRITICAL flag is not set, an code of "Contact Failure". If the CRITICAL flag is not set, an
node SHALL skip over and ignore any item with an unkonwn Item node SHALL skip over and ignore any item with an unkonwn Item
Type. Type.
Item Type: A 16-bit unsigned integer field containing the type of Item Type: A 16-bit unsigned integer field containing the type of
the extension item. Each type This specification does not define the extension item. This specification does not define any
any extension types directly, but does allocate an IANA registry extension types directly, but does allocate an IANA registry for
for such codes (see Section 8.3). such codes (see Section 8.3).
Item Length: A 32-bit unsigned integer field containing the number Item Length: A 32-bit unsigned integer field containing the number
of Item Value octets to follow. of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted Item Value: A variable-length data field which is interpreted
according to the associated Item Type. This specification places according to the associated Item Type. This specification places
no restrictions on an extensions use of available Item Value data. no restrictions on an extensions use of available Item Value data.
Extension specification SHOULD avoid the use of large data Extension specification SHOULD avoid the use of large data
exchanges within the TCPCLv4 contact header as no bundle transfers exchanges within the TCPCLv4 contact header as no bundle transfers
can begin until the a full contact exchange and negotiation has can begin until the a full contact exchange and negotiation has
skipping to change at page 17, line 15 skipping to change at page 17, line 15
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 3
below. below. Encoded values are listed in Section 8.4.
The message types defined in this specificaiton are listed in
Table 3. 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 19, line 49 skipping to change at page 19, line 34
Table 4: MSG_REJECT Reason Codes Table 4: MSG_REJECT Reason Codes
5.3. Bundle Transfer 5.3. Bundle Transfer
All of the message in this section are directly associated with All of the message in this section are directly associated with
transfering a bundle between TCPCL nodes. transfering 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 receving-side Segment MRU (see bundle up into "segments" based on the receiving-side Segment MRU
Section 4.1). (see Section 4.1).
A single transfer (and by extension a single segment) SHALL NOT A single transfer (and by extension a single segment) SHALL NOT
contain data of more than a single bundle. This requirement is contain data of more than a single bundle. This requirement is
imposed on the agent using the TCPCL rather than TCPCL itself. imposed on the agent using the TCPCL rather than TCPCL itself.
5.3.1. Bundle Transfer ID 5.3.1. Bundle Transfer ID
Each of the bundle transfer messages contains a Transfer ID number Each of the bundle transfer messages contains a Transfer ID number
which is used to correlate messages originating from sender and which is used to correlate messages originating from sender and
receiver of a bundle. A Transfer ID does not attempt to address receiver of a bundle. A Transfer ID does not attempt to address
skipping to change at page 23, line 33 skipping to change at page 23, line 28
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 5.
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 receving TCPCL endpoing SHALL send an XFER_ACK message in response A receiving TCPCL endpoing SHALL send an XFER_ACK message in response
to each received XFER_SEGMENT message. The flags portion of the to each received XFER_SEGMENT message. The flags portion of the
XFER_ACK header SHALL be set to match the corresponding DATA_SEGEMNT XFER_ACK header SHALL be set to match the corresponding DATA_SEGMENT
message being acknowledged. The acknowledged length of each XFER_ACK message being acknowledged. The acknowledged length of each XFER_ACK
contains the sum of the data length fields of all XFER_SEGMENT contains the sum of the data length fields of all XFER_SEGMENT
messages received so far in the course of the indicated transfer. messages received so far in the course of the indicated transfer.
For example, suppose the sending node transmits four segments of For example, suppose the sending node transmits four segments of
bundle data with lengths 100, 200, 500, and 1000, respectively. bundle data with lengths 100, 200, 500, and 1000, respectively.
After receiving the first segment, the node sends an acknowledgment After receiving the first segment, the node sends an acknowledgment
of length 100. After the second segment is received, the node sends of length 100. After the second segment is received, the node sends
an acknowledgment of length 300. The third and fourth an acknowledgment of length 300. The third and fourth
acknowledgments are of length 800 and 1800, respectively. acknowledgments are of length 800 and 1800, respectively.
5.3.5. Transfer Refusal (XFER_REFUSE) 5.3.5. Transfer Refusal (XFER_REFUSE)
As bundles can be large, the TCPCL supports an optional mechanism by The TCPCL supports an mechanism by which a receiving node can
which a receiving node MAY indicate to the sender that it does not indicate to the sender that it does not want to receive the
want to receive the corresponding bundle. corresponding bundle. To do so, upon receiving a XFER_INIT or
XFER_SEGMENT message, the node MAY transmit a XFER_REFUSE message.
To do so, upon receiving a XFER_INIT or XFER_SEGMENT message, the As data segments and acknowledgments MAY cross on the wire, the
node MAY transmit a XFER_REFUSE message. As data segments and bundle that is being refused SHALL be identified by the Transfer ID
acknowledgments MAY cross on the wire, the bundle that is being of the refusal.
refused SHALL be identified by the Transfer ID of the refusal.
There is no required relation between the Transfer MRU of a TCPCL There is no required relation between the Transfer MRU of a TCPCL
node (which is supposed to represent a firm limitation of what the node (which is supposed to represent a firm limitation of what the
node will accept) and sending of a XFER_REFUSE message. A node will accept) and sending of a XFER_REFUSE message. A
XFER_REFUSE can be used in cases where the agent's bundle storage is XFER_REFUSE can be used in cases where the agent's bundle storage is
temporarily depleted or somehow constrained. A XFER_REFUSE can also temporarily depleted or somehow constrained. A XFER_REFUSE can also
be used after the bundle header or any bundle data is inspected by an be used after the bundle header or any bundle data is inspected by an
agent and determined to be unacceptable. agent and determined to be unacceptable.
The format of the XFER_REFUSE message is as follows: The format of the XFER_REFUSE message is as follows:
skipping to change at page 28, line 46 skipping to change at page 28, line 27
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 bundle If there is a configured time to close idle links and if no bundle
data (other than KEEPALIVE messages) has been received for at least data (other than KEEPALIVE messages) has been received for at least
that amount of time, then either node MAY terminate the session by that amount of time, then either node MAY terminate the session by
transmitting a SHUTDOWN message indicating the reason code of 'Idle transmitting a SHUTDOWN message indicating the reason code of 'Idle
timeout' (as described in Table 8). After receiving a SHUTDOWN timeout' (as described in Table 8).
message in response, both sides MAY close the TCP connection.
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
skipping to change at page 34, line 41 skipping to change at page 34, line 41
9. Acknowledgments 9. Acknowledgments
This memo is based on comments on implementation of [RFC7242] This memo is based on comments on implementation of [RFC7242]
provided from Scott Burleigh. provided from Scott Burleigh.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
draft-ietf-dtn-bpbis-08 (work in progress), August 2017. Version 7", draft-ietf-dtn-bpbis-10 (work in progress),
November 2017.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>. 2007, <https://www.rfc-editor.org/info/rfc5050>.
 End of changes. 36 change blocks. 
94 lines changed or deleted 111 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/