--- 1/draft-ietf-dtn-tcpclv4-03.txt 2017-12-11 19:13:13.467906602 -0800 +++ 2/draft-ietf-dtn-tcpclv4-04.txt 2017-12-11 19:13:13.547908346 -0800 @@ -1,50 +1,52 @@ Delay Tolerant Networking B. Sipos Internet-Draft RKF Engineering Obsoletes: 7242 (if approved) M. Demmer Intended status: Standards Track UC Berkeley -Expires: May 17, 2018 J. Ott +Expires: June 13, 2018 J. Ott Aalto University S. Perreault - November 13, 2017 + December 10, 2017 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 - draft-ietf-dtn-tcpclv4-03 + draft-ietf-dtn-tcpclv4-04 Abstract This document describes a revised protocol for the TCP-based convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The protocol revision is based on implementation issues in the original TCPCL Version 3 and updates to the Bundle Protocol contents, - encodings, and convergence layer requirements in Bundle Protocl - Version 7. Several new IANA registries are defined for TCPCLv4 which - define some behaviors inherited from TCPCLv3 but with updated - encodings and/or semantics. + encodings, and convergence layer requirements in Bundle Protocol + Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7 bundles + as its service data unit being transported and provides a reliable + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 17, 2018. + This Internet-Draft will expire on June 13, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -53,58 +55,59 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions Specific to the TCPCL Protocol . . . . . . . 4 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 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12 4.2. Validation and Parameter Negotiation . . . . . . . . . . 13 4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14 4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15 4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15 5. Established Session Operation . . . . . . . . . . . . . . . . 16 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16 - 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 18 - 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 18 + 5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 17 + 5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 17 5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18 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.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 21 5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22 5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 25 - 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 26 + 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 28 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 30 - 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 31 + 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 30 8.3. Header Extension Types . . . . . . . . . . . . . . . . . 31 - 8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 32 + 8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 31 8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 32 8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 33 8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 34 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 35 - Appendix A. Significant changes from RFC7242 . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + Appendix A. Significant changes from RFC7242 . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction This document describes the TCP-based convergence-layer protocol for Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to- end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Network Architecture" @@ -116,41 +119,40 @@ [I-D.ietf-dtn-bpbis], an application-layer protocol that is used to construct a store-and- forward overlay network. As described in the Bundle Protocol specification [I-D.ietf-dtn-bpbis], it requires the services of a "convergence- layer adapter" (CLA) to send and receive bundles using the service of some "native" link, network, or Internet protocol. This document describes one such convergence-layer adapter that uses the well-known Transmission Control Protocol (TCP). This convergence layer is referred to as TCPCL. 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 - its bearer with TCPCL as its convergence layer, both BP and TCPCL - reside at the application layer of the Internet model. + stack (described in [RFC1122]) are shown in Figure 1. In particular, + when BP is using TCP as its bearer with TCPCL as its convergence + layer, both BP and TCPCL reside at the application layer of the + Internet model. +-------------------------+ | DTN Application | -\ +-------------------------| | | Bundle Protocol (BP) | -> Application Layer +-------------------------+ | - | TCP Conv. Layer (TCPCL) | -/ - +-------------------------+ - | TLS (optional) | ---> Presentation Layer + | TCP Conv. Layer (TCPCL) | | + +-------------------------+ | + | TLS (optional) | -/ +-------------------------+ | TCP | ---> Transport Layer +-------------------------+ - | IP | ---> Network Layer + | IPv4/IPv6 | ---> Network Layer +-------------------------+ | Link-Layer Protocol | ---> Link Layer +-------------------------+ - | Physical Medium | ---> Physical Layer - +-------------------------+ Figure 1: The Locations of the Bundle Protocol and the TCP Convergence-Layer Protocol above the Internet Protocol Stack This document describes the format of the protocol data units passed between entities participating in TCPCL communications. This document does not address: 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 @@ -194,52 +196,63 @@ of this document, the term "session" without the prefix "TCPCL" refers to a TCPCL session. Session parameters: The session parameters are a set of values used to affect the operation of the TCPCL for a given session. The manner in which these parameters are conveyed to the bundle node and thereby to the TCPCL is implementation dependent. However, 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. - Transfer Transfer refers to the procedures and mechanisms (described - below) for conveyance of an individual bundle from one node to - another. Each transfer within TCPCLv4 is identified by a Transfer - ID number which is unique only to a single direction within a - single Session. + Transfer: Transfer refers to the procedures and mechanisms + (described below) for conveyance of an individual bundle from one + node to another. Each transfer within TCPCLv4 is identified by a + Transfer ID number which is unique only to a single direction + 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 - The service of this protocol is the transmission of DTN bundles over - TCP. This document specifies the encapsulation of bundles, - procedures for TCP setup and teardown, and a set of messages and node - requirements. The general operation of the protocol is as follows. + The service of this protocol is the transmission of DTN bundles via + the Transmission Control Protocol (TCP). This document specifies the + encapsulation of bundles, procedures for TCP setup and teardown, and + 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 - initiating a TCP connection. After setup of the TCP connection is - complete, an initial contact header is exchanged in both directions - to set parameters of the TCPCL session and exchange a singleton - endpoint identifier for each node (not the singleton Endpoint - Identifier (EID) of any application running on the node) to denote - the bundle-layer identity of each DTN node. This is used to assist - in routing and forwarding messages, e.g., to prevent loops. + initiating a TCP connection in accordance with [RFC0793]. After + setup of the TCP connection is complete, an initial contact header is + exchanged in both directions to set parameters of the TCPCL session + and exchange a singleton endpoint identifier for each node (not the + singleton Endpoint Identifier (EID) of any application running on the + node) to denote the bundle-layer identity of each DTN node. This is + used to assist in routing and forwarding messages (e.g. to prevent + loops). Once the TCPCL session is established and configured in this way, bundles can be transferred in either direction. Each transfer is - performed in one or more logical segments of data. Each logical data - segment consists of a XFER_SEGMENT message header and flags, a count - of the length of the segment, and finally the octet range of the - bundle data. The choice of the length to use for segments is an - implementation matter (but must be within the Segment MRU size of - Section 4.1). The first segment for a bundle MUST set the 'START' - flag, and the last one MUST set the 'end' flag in the XFER_SEGMENT - message flags. + performed by an initialization (XFER_INIT) message followed by one or + more logical segments of data within an XFER_SEGMENT message. The + choice of the length to use for segments is an implementation matter, + but each segment must be no larger than the receiving node's maximum + receive unit (MRU) (see the field "Segment MRU" of Section 4.1). The + first segment for a bundle MUST set the 'START' flag, and the last + one MUST set the 'end' flag in the XFER_SEGMENT message flags. If multiple bundles are transmitted on a single TCPCL connection, they MUST be transmitted consecutively. Interleaving data segments from different bundles is not allowed. Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions. A feature of this protocol is for the receiving node to send acknowledgments as bundle data segments arrive (XFER_ACK). The rationale behind these acknowledgments is to enable the sender node @@ -261,43 +274,42 @@ Note: This enables a cross-layer optimization in that it allows a receiver that detects that it already has received a certain bundle to interrupt transmission as early as possible and thus save transmission capacity for other bundles. For sessions that are idle, a KEEPALIVE message is sent at a negotiated interval. This is used to convey node liveness information. Finally, before sessions close, a SHUTDOWN message is sent to the - session peer. After sending a SHUTDOWN message, the sender of this - message MAY send further acknowledgments (XFER_ACK or XFER_REFUSE) - but no further data messages (XFER_SEGMENT). A SHUTDOWN message MAY - also be used to refuse a session setup by a peer. - -3.1. Bidirectional Use of TCPCL Sessions + session peer. A SHUTDOWN message MAY also be used to refuse a + session setup by a peer (see Section 4.2). After sending a SHUTDOWN + message, the sender of the message MAY send further acknowledgments + (XFER_ACK or XFER_REFUSE) but no further data messages (XFER_INIT or + XFER_SEGMENT). After receving a SHUTDOWN message and when no + transfers are in-progress (i.e. have unacknowledged segemnts) There are specific messages for sending and receiving operations (in addition to session setup/teardown). TCPCL is symmetric, i.e., both 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 start sending data segments on its own. Hence, the protocol allows - for a bi-directional mode of communication. - - Note that in the case of concurrent bidirectional transmission, - acknowledgment segments MAY be interleaved with data segments. + for a bi-directional mode of communication. Note that in the case of + concurrent bidirectional transmission, acknowledgment segments MAY be + interleaved with data segments. 3.2. Example Message Exchange - The following figure visually depicts the protocol exchange for a - simple session, showing the session establishment and the - transmission of a single bundle split into three data segments (of - lengths "L1", "L2", and "L3") from Node A to Node B. + The following figure depicts the protocol exchange for a simple + session, showing the session establishment and the transmission of a + single bundle split into three data segments (of lengths "L1", "L2", + and "L3") from Node A to Node B. Note that the sending node MAY transmit multiple XFER_SEGMENT messages without necessarily waiting for the corresponding XFER_ACK responses. This enables pipelining of messages on a channel. Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple XFER_SEGMENT messages for different bundles without necessarily waiting for XFER_ACK messages to be returned for each one. However, interleaving data segments from different bundles is not allowed. @@ -336,43 +348,43 @@ +-------------------------+ <- | XFER_ACK (end) | | Transfer ID [I1] | | Length [L1+L2+L3] | +-------------------------+ +-------------------------+ +-------------------------+ | SHUTDOWN | -> <- | SHUTDOWN | +-------------------------+ +-------------------------+ - Figure 2: A SL1e Visual Example of the Flow of Protocol Messages on a - Single TCP Session between Two Nodes (A and B) + Figure 2: An Example of the Flow of Protocol Messages on a Single TCP + Session between Two Nodes (A and B) 4. Session Establishment For bundle transmissions to occur using the TCPCL, a TCPCL session MUST first be established between communicating nodes. It is up to the implementation to decide how and when session setup is triggered. For example, some sessions MAY be opened proactively and maintained 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 transmission and the routing algorithm selects a certain next-hop node. To establish a TCPCL session, a node MUST first establish a TCP connection with the intended peer node, typically by using the 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 per local configuration. Determining a peer's destination port - number (if different from the well-known TCPCL port) is up to the - implementation. Any source port number MAY be used for TCPCL + number (if different from the registered TCPCL port number) is up to + the implementation. Any source port number MAY be used for TCPCL sessions. Typically an operating system assigned number in the TCP Ephemeral range (49152--65535) is used. 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 connection failure. A node MAY decide to re-attempt to establish the connection. If it does so, it MUST NOT overwhelm its target with repeated connection attempts. Therefore, the node MUST retry the connection setup only after some delay (a 1-second minimum is RECOMMENDED), and it SHOULD use a (binary) exponential backoff @@ -503,23 +515,23 @@ Flags: A one-octet field containing generic bit flags about the item, which are listed in Table 2. If a TCPCL node receives an extension item with an unknown Item Type and the CRITICAL flag set, the node SHALL close the TCPCL session with SHUTDOWN reason code of "Contact Failure". If the CRITICAL flag is not set, an node SHALL skip over and ignore any item with an unkonwn Item Type. Item Type: A 16-bit unsigned integer field containing the type of - the extension item. Each type This specification does not define - any extension types directly, but does allocate an IANA registry - for such codes (see Section 8.3). + the extension item. This specification does not define any + extension types directly, but does allocate an IANA registry for + such codes (see Section 8.3). Item Length: A 32-bit unsigned integer field containing the number of Item Value octets to follow. Item Value: A variable-length data field which is interpreted according to the associated Item Type. This specification places no restrictions on an extensions use of available Item Value data. Extension specification SHOULD avoid the use of large data exchanges within the TCPCLv4 contact header as no bundle transfers can begin until the a full contact exchange and negotiation has @@ -712,24 +724,21 @@ 0 1 2 3 4 5 6 7 +---------------+ | Message Type | +---------------+ Figure 6: Format of the Message Header The message header fields are as follows: Message Type: Indicates the type of the message as per Table 3 - below. - - The message types defined in this specificaiton are listed in - Table 3. Encoded values are listed in Section 8.4. + below. Encoded values are listed in Section 8.4. +--------------+----------------------------------------------------+ | Type | Description | +--------------+----------------------------------------------------+ | XFER_INIT | Contains the length (in octets) of the next | | | transfer, as described in Section 5.3.2. | | | | | XFER_SEGMENT | Indicates the transmission of a segment of bundle | | | data, as described in Section 5.3.3. | | | | @@ -832,22 +841,22 @@ Table 4: MSG_REJECT Reason Codes 5.3. Bundle Transfer All of the message in this section are directly associated with transfering a bundle between TCPCL nodes. A single TCPCL transfer results in a bundle (handled by the convergence layer as opaque data) being exchanged from one node to the other. In TCPCL a transfer is accomplished by dividing a single - bundle up into "segments" based on the receving-side Segment MRU (see - Section 4.1). + bundle up into "segments" based on the receiving-side Segment MRU + (see Section 4.1). A single transfer (and by extension a single segment) SHALL NOT contain data of more than a single bundle. This requirement is imposed on the agent using the TCPCL rather than TCPCL itself. 5.3.1. Bundle Transfer ID Each of the bundle transfer messages contains a Transfer ID number which is used to correlate messages originating from sender and receiver of a bundle. A Transfer ID does not attempt to address @@ -1009,44 +1018,43 @@ Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5. Transfer ID: A 64-bit unsigned integer identifying the transfer being acknowledged. Acknowledged length: A 64-bit unsigned integer indicating the total 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 - 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 contains the sum of the data length fields of all XFER_SEGMENT messages received so far in the course of the indicated transfer. For example, suppose the sending node transmits four segments of bundle data with lengths 100, 200, 500, and 1000, respectively. After receiving the first segment, the node sends an acknowledgment of length 100. After the second segment is received, the node sends an acknowledgment of length 300. The third and fourth acknowledgments are of length 800 and 1800, respectively. 5.3.5. Transfer Refusal (XFER_REFUSE) - As bundles can be large, the TCPCL supports an optional mechanism by - which a receiving node MAY indicate to the sender that it does not - want to receive the corresponding bundle. - - To do so, upon receiving a XFER_INIT or XFER_SEGMENT message, the - node MAY transmit a XFER_REFUSE message. As data segments and - acknowledgments MAY cross on the wire, the bundle that is being - refused SHALL be identified by the Transfer ID of the refusal. + The TCPCL supports an mechanism by which a receiving node can + indicate to the sender that it does not want to receive the + corresponding bundle. To do so, upon receiving a XFER_INIT or + XFER_SEGMENT message, the node MAY transmit a XFER_REFUSE message. + As data segments and acknowledgments MAY cross on the wire, the + bundle that is being refused SHALL be identified by the Transfer ID + of the refusal. 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 will accept) and sending of a XFER_REFUSE message. A XFER_REFUSE can be used in cases where the agent's bundle storage is temporarily depleted or somehow constrained. A XFER_REFUSE can also be used after the bundle header or any bundle data is inspected by an agent and determined to be unacceptable. The format of the XFER_REFUSE message is as follows: @@ -1242,22 +1250,21 @@ The protocol includes a provision for clean shutdown of 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 configuration matter. 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 that amount of time, then either node MAY terminate the session by transmitting a SHUTDOWN message indicating the reason code of 'Idle - timeout' (as described in Table 8). After receiving a SHUTDOWN - message in response, both sides MAY close the TCP connection. + timeout' (as described in Table 8). 7. Security Considerations One security consideration for this protocol relates to the fact that nodes present their endpoint identifier as part of the contact header 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 a member, essentially masquerading as another DTN node. If this identifier is used outside of a TLS-secured session or without further verification as a means to determine which bundles are @@ -1515,22 +1522,32 @@ 9. Acknowledgments This memo is based on comments on implementation of [RFC7242] provided from Scott Burleigh. 10. References 10.1. Normative References [I-D.ietf-dtn-bpbis] - Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol", - draft-ietf-dtn-bpbis-08 (work in progress), August 2017. + Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol + 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, + . + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, November 2007, .