draft-ietf-dtn-tcpclv4-01.txt		draft-ietf-dtn-tcpclv4-02.txt
	Delay Tolerant Networking B. Sipos		Delay Tolerant Networking B. Sipos
	Internet-Draft RKF Engineering		Internet-Draft RKF Engineering
	Obsoletes: RFC7242 (if approved) M. Demmer		Obsoletes: 7242 (if approved) M. Demmer
	Intended status: Standards Track UC Berkeley		Intended status: Standards Track UC Berkeley
	Expires: May 31, 2017 J. Ott		Expires: November 23, 2017 J. Ott
	Aalto University		Aalto University
	S. Perreault		S. Perreault
	November 27, 2016		May 22, 2017
	Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4		Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
	draft-ietf-dtn-tcpclv4-01		draft-ietf-dtn-tcpclv4-02
	Abstract		Abstract
	This document describes a revised protocol for the TCP-based		This document describes a revised protocol for the TCP-based
	convergence layer for Delay-Tolerant Networking (DTN). The protocol		convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
	revision is based on implementation issues in the original [RFC7242]		protocol revision is based on implementation issues in the original
	and updates to the Bundle Protocol contents, encodings, and		TCPCL Version 3 and updates to the Bundle Protocol contents,
	convergence layer requirements in [I-D.ietf-dtn-bpbis].		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.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 31, 2017.		This Internet-Draft will expire on November 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	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 . . . . . . . . . . . 6		3.1. Bidirectional Use of TCPCL Sessions . . . . . . . . . . . 6
	3.2. Example Message Exchange . . . . . . . . . . . . . . . . 6		3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7
	4. Session Establishment . . . . . . . . . . . . . . . . . . . . 7		4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8
	4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 8		4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10
	4.2. Validation and Parameter Negotiation . . . . . . . . . . 10		4.1.1. Header Extension Items . . . . . . . . . . . . . . . 11
	5. Established Session Operation . . . . . . . . . . . . . . . . 11		4.2. Validation and Parameter Negotiation . . . . . . . . . . 13
	5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 11		5. Established Session Operation . . . . . . . . . . . . . . . . 14
	5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 12		5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 14
	5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 12		5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 15
	5.2.2. Message Rejection (REJECT) . . . . . . . . . . . . . 13		5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 15
	5.3. Session Security . . . . . . . . . . . . . . . . . . . . 14		5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 16
	5.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 14		5.3. Session Security . . . . . . . . . . . . . . . . . . . . 17
	5.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15		5.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 17
	5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 15		5.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 18
	5.4.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 16		5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 18
	5.4.2. Bundle Length (LENGTH) . . . . . . . . . . . . . . . 16		5.4.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19
	5.4.3. Bundle Data Transmission (DATA_SEGMENT) . . . . . . . 17		5.4.2. Transfer initialization (XFER_INIT) . . . . . . . . . 19
	5.4.4. Bundle Acknowledgments (ACK_SEGMENT) . . . . . . . . 18		5.4.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 20
	5.4.5. Bundle Refusal (REFUSE_BUNDLE) . . . . . . . . . . . 19		5.4.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22
	6. Session Termination . . . . . . . . . . . . . . . . . . . . . 21		5.4.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23
	6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 21		6. Session Termination . . . . . . . . . . . . . . . . . . . . . 24
	6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 23		6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 23		6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 27
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 25		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 25		8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 29
	8.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 26		8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 29
	8.4. REFUSE_BUNDLE Reason Codes . . . . . . . . . . . . . . . 26		8.3. Header Extension Types . . . . . . . . . . . . . . . . . 30
	8.5. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 27		8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 31
	8.6. REJECT Reason Codes . . . . . . . . . . . . . . . . . . . 27		8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 31
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28		8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 32
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28		8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 33
	10.1. Normative References . . . . . . . . . . . . . . . . . . 28		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
	10.2. Informative References . . . . . . . . . . . . . . . . . 29		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Appendix A. Significant changes from RFC7242 . . . . . . . . . . 29		10.1. Normative References . . . . . . . . . . . . . . . . . . 33
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30		10.2. Informative References . . . . . . . . . . . . . . . . . 34
			Appendix A. Significant changes from RFC7242 . . . . . . . . . . 35
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
	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 35 ¶		skipping to change at page 5, line 9 ¶
	This section contains definitions that are interpreted to be specific		This section contains definitions that are interpreted to be specific
	to the operation of the TCPCL protocol, as described below.		to the operation of the TCPCL protocol, as described below.
	TCP Connection: A TCP connection refers to a transport connection		TCP Connection: A TCP connection refers to a transport connection
	using TCP as the transport protocol.		using TCP as the transport protocol.
	TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a		TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a
	TCPCL communication relationship between two bundle nodes. The		TCPCL communication relationship between two bundle nodes. The
	lifetime of a TCPCL session is bound to the lifetime of an		lifetime of a TCPCL session is bound to the lifetime of an
	underlying TCP connection. Therefore, a TCPCL session is		underlying TCP connection. Therefore, a TCPCL session is
	initiated when a bundle node initiates a TCP connection to be		initiated after a bundle node establishes a TCP connection to for
	established for the purposes of bundle communication. A TCPCL		the purposes of bundle communication. A TCPCL session is
	session is terminated when the TCP connection ends, due either to		terminated when the TCP connection ends, due either to one or both
	one or both nodes actively terminating the TCP connection or due		nodes actively terminating the TCP connection or due to network
	to network errors causing a failure of the TCP connection. For		errors causing a failure of the TCP connection. For the remainder
	the remainder of this document, the term "session" without the		of this document, the term "session" without the prefix "TCPCL"
	prefix "TCPCL" refer to a TCPCL session.		refer 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.
	Transmission: Transmission refers to the procedures and mechanisms		Transfer Transfer refers to the procedures and mechanisms (described
	(described below) for conveyance of a bundle from one node to		below) for conveyance of an individual bundle from one node to
	another.		another. Each transfer within TCPCLv4 is identified by a Transfer
			ID number which is unique only to a single direction within a
			single Session.
	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 over
	TCP. This document specifies the encapsulation of bundles,		TCP. This document specifies the encapsulation of bundles,
	procedures for TCP setup and teardown, and a set of messages and node		procedures for TCP setup and teardown, and a set of messages and node
	requirements. The general operation of the protocol is as follows.		requirements. The general operation of the protocol is as follows.
	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. After setup of the TCP connection is
	complete, an initial contact header is exchanged in both directions		complete, an initial contact header is exchanged in both directions
	to set parameters of the TCPCL session and exchange a singleton		to set parameters of the TCPCL session and exchange a singleton
	endpoint identifier for each node (not the singleton Endpoint		endpoint identifier for each node (not the singleton Endpoint
	Identifier (EID) of any application running on the node) to denote		Identifier (EID) of any application running on the node) to denote
	the bundle-layer identity of each DTN node. This is used to assist		the bundle-layer identity of each DTN node. This is used to assist
	in routing and forwarding messages, e.g., to prevent loops.		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 in one or more logical segments of data. Each logical data
	segment consists of a DATA_SEGMENT message header, a count of the		segment consists of a XFER_SEGMENT message header and flags, a count
	length of the segment, and finally the octet range of the bundle		of the length of the segment, and finally the octet range of the
	data. The choice of the length to use for segments is an		bundle data. The choice of the length to use for segments is an
	implementation matter (but must be within the Segment MRU size of		implementation matter (but must be within the Segment MRU size of
	Section 4.1). The first segment for a bundle MUST set the 'start'		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 DATA_SEGMENT		flag, and the last one MUST set the 'end' flag in the XFER_SEGMENT
	message header.		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 (ACK_SEGMENT). 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
	to determine how much of the bundle has been received, so that in		to determine how much of the bundle has been received, so that in
	case the session is interrupted, it can perform reactive		case the session is interrupted, it can perform reactive
	fragmentation to avoid re-sending the already transmitted part of the		fragmentation to avoid re-sending the already transmitted part of the
	bundle. For each data segment that is received, the receiving node		bundle. For each data segment that is received, the receiving node
	sends an ACK_SEGMENT code followed by an count containing the		sends an XFER_ACK message containing the cumulative length of the
	cumulative length of the bundle that has been received. The sending		bundle that has been received. The sending node MAY transmit
	node MAY transmit multiple DATA_SEGMENT messages without necessarily		multiple XFER_SEGMENT messages without necessarily waiting for the
	waiting for the corresponding ACK_SEGMENT responses. This enables		corresponding XFER_ACK responses. This enables pipelining of
	pipelining of messages on a channel. In addition, there is no		messages on a channel. In addition, there is no explicit flow
	explicit flow control on the TCPCL layer.		control on the TCPCL layer.
	Another feature is that a receiver MAY interrupt the transmission of		Another feature is that a receiver MAY interrupt the transmission of
	a bundle at any point in time by replying with a REFUSE_BUNDLE		a bundle at any point in time by replying with a XFER_REFUSE message,
	message, which causes the sender to stop transmission of the current		which causes the sender to stop transmission of the current bundle,
	bundle, after completing transmission of a partially sent data		after completing transmission of a partially sent data segment.
	segment. Note: This enables a cross-layer optimization in that it		Note: This enables a cross-layer optimization in that it allows a
	allows a receiver that detects that it already has received a certain		receiver that detects that it already has received a certain bundle
	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 liveness information.		negotiated interval. This is used to convey liveness 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. After sending a SHUTDOWN message, the sender of this
	message MAY send further acknowledgments (ACK_SEGMENT or		message MAY send further acknowledgments (XFER_ACK or XFER_REFUSE)
	REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A		but no further data messages (XFER_SEGMENT). A SHUTDOWN message MAY
	SHUTDOWN message MAY also be used to refuse a session setup by a		also be used to refuse a session setup by a peer.
	peer.
	3.1. Bidirectional Use of TCPCL Sessions		3.1. Bidirectional Use of TCPCL Sessions
	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,		Note that in the case of concurrent bidirectional transmission,
	acknowledgment segments MAY be 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 visually depicts the protocol exchange for a
	simple session, showing the session establishment and the		simple session, showing the session establishment and the
	transmission of a single bundle split into three data segments (of		transmission of a single bundle split into three data segments (of
	lengths L1, L2, and L3) from Node A to Node B.		lengths "L1", "L2", and "L3") from Node A to Node B.
	Note that the sending node MAY transmit multiple DATA_SEGMENT		Note that the sending node MAY transmit multiple XFER_SEGMENT
	messages without necessarily waiting for the corresponding		messages without necessarily waiting for the corresponding XFER_ACK
	ACK_SEGMENT responses. This enables pipelining of messages on a		responses. This enables pipelining of messages on a channel.
	channel. Although this example only demonstrates a single bundle		Although this example only demonstrates a single bundle transmission,
	transmission, it is also possible to pipeline multiple DATA_SEGMENT		it is also possible to pipeline multiple XFER_SEGMENT messages for
	messages for different bundles without necessarily waiting for		different bundles without necessarily waiting for XFER_ACK messages
	ACK_SEGMENT messages to be returned for each one. However,		to be returned for each one. However, interleaving data segments
	interleaving data segments from different bundles is not allowed.		from different bundles is not allowed.
	No errors or rejections are shown in this example.		No errors or rejections are shown in this example.
	Node A Node B		Node A Node B
	====== ======		====== ======
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	| Contact Header | -> <- | Contact Header |		| Contact Header | -> <- | Contact Header |
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	+-------------------------+		+-------------------------+
	| LENGTH | ->		| XFER_INIT | ->
	| Transfer ID [I1] |		| Transfer ID [I1] |
	| Total Length [L1] |		| Total Length [L1] |
	+-------------------------+		+-------------------------+
	+-------------------------+		+-------------------------+
	| DATA_SEGMENT (start) | ->		| XFER_SEGMENT (start) | ->
	| Transfer ID [I1] |		| Transfer ID [I1] |
	| Length [L1] |		| Length [L1] |
	| Bundle Data 0..(L1-1) |		| Bundle Data 0..(L1-1) |
	+-------------------------+		+-------------------------+
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	| DATA_SEGMENT | -> <- | ACK_SEGMENT (start) |		| XFER_SEGMENT | -> <- | XFER_ACK (start) |
	| Transfer ID [I1] | | Transfer ID [I1] |		| Transfer ID [I1] | | Transfer ID [I1] |
	| Length [L2] | | Length [L1] |		| Length [L2] | | Length [L1] |
	|Bundle Data L1..(L1+L2-1)| +-------------------------+		|Bundle Data L1..(L1+L2-1)| +-------------------------+
	+-------------------------+		+-------------------------+
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	| DATA_SEGMENT (end) | -> <- | ACK_SEGMENT |		| XFER_SEGMENT (end) | -> <- | XFER_ACK |
	| Transfer ID [I1] | | Transfer ID [I1] |		| Transfer ID [I1] | | Transfer ID [I1] |
	| Length [L3] | | Length [L1+L2] |		| Length [L3] | | Length [L1+L2] |
	|Bundle Data | +-------------------------+		|Bundle Data | +-------------------------+
	| (L1+L2)..(L1+L2+L3-1)|		| (L1+L2)..(L1+L2+L3-1)|
	+-------------------------+		+-------------------------+
	+-------------------------+		+-------------------------+
	<- | ACK_SEGMENT (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 Simple Visual Example of the Flow of Protocol Messages on		Figure 2: A SL1e Visual Example of the Flow of Protocol Messages on a
	a Single TCP Session between Two Nodes (A and B)		Single TCP 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. Port number 4556 has been		services provided by the operating system. Destination port number
	assigned by IANA as the well-known port number for the TCP		4556 has been assigned by IANA as the well-known port number for the
	convergence layer. Other port numbers MAY be used per local		TCP convergence layer. Other destination port numbers MAY be used
	configuration. Determining a peer's port number (if different from		per local configuration. Determining a peer's destination port
	the well-known TCPCL port) is up to the implementation.		number (if different from the well-known TCPCL port) 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,		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
	mechanism to increase this delay in case of repeated failures. In		mechanism to increase this delay in case of repeated failures. In
	case a SHUTDOWN message specifying a reconnection delay is received,		case a SHUTDOWN message specifying a reconnection delay is received,
	skipping to change at page 9, line 24 ¶		skipping to change at page 10, line 30 ¶
	| Segment MRU... |		| Segment MRU... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| contd. |		| contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Transfer MRU... |		| Transfer MRU... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| contd. |		| contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| EID Length | EID Data... |		| EID Length | EID Data... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| contd. |		| EID Data contd. |
			+---------------+---------------+---------------+---------------+
			| TCPCLv4 Header Extension Items... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 3: Contact Header Format		Figure 3: Contact Header Format
	The fields of the contact header are:		See Section 4.2 for details on the use of each of these contact
			header fields. The fields of the contact header are:
	magic: A four-octet field that always contains the octet sequence		magic: A four-octet field that always contains the octet sequence
	0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and		0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and
	UTF-8).		UTF-8).
	Version: A one-octet field value containing the value 4 (current		Version: A one-octet field value containing the value 4 (current
	version of the protocol).		version of the protocol).
	Flags: A one-octet field of single-bit flags, interpreted according		Flags: A one-octet field of single-bit flags, interpreted according
	to the descriptions in Table 1.		to the descriptions in Table 1.
	Keepalive Interval: A 16-bit unsigned integer indicating the longest		Keepalive Interval: A 16-bit unsigned integer indicating the longest
	allowable interval in seconds between KEEPALIVE messages received		allowable interval in seconds between KEEPALIVE messages received
	in this session.		in this session.
	Segment MRU: A 64-bit unsigned integer indicating the largest		Segment MRU: A 64-bit unsigned integer indicating the largest
	allowable single-segment data payload size to be received in this		allowable single-segment data payload size to be received in this
	session. Any DATA_SEGMENT sent to this peer SHALL have a data		session. Any XFER_SEGMENT sent to this peer SHALL have a data
	payload no longer than the peer's Segment MRU. The two endpoints		payload no longer than the peer's Segment MRU. The two endpoints
	of a single session MAY have different Segment MRUs, and no		of a single session MAY have different Segment MRUs, and no
	relation between the two is required.		relation between the two is required.
	Transfer MRU: A 64-bit unsigned integer indicating the largest		Transfer MRU: A 64-bit unsigned integer indicating the largest
	allowable total-bundle data size to be received in this session.		allowable total-bundle data size to be received in this session.
	Any bundle transfer sent to this peer SHALL have a Total bundle		Any bundle transfer sent to this peer SHALL have a Total bundle
	data payload no longer than the peer's Transfer MRU. This value		data payload no longer than the peer's Transfer MRU. This value
	can be used to perform proactive bundle fragmentation. The two		can be used to perform proactive bundle fragmentation. The two
	endpoints of a single session MAY have different Transfer MRUs,		endpoints of a single session MAY have different Transfer MRUs,
	and no relation between the two is required.		and no relation between the two is required.
	EID Length and EID Data: Together these fields represent a variable-		EID Length and EID Data: Together these fields represent a variable-
	length text string. The EID Length is a 16-bit unsigned integer		length text string. The EID Length is a 16-bit unsigned integer
	indicating the number of octets of EID Data to follow. A zero EID		indicating the number of octets of EID Data to follow. A zero EID
	Length is a special case which indicates the lack of EID rather		Length SHALL be used to indicate the lack of EID rather than a
	than a truly empty EID. A non-zero-length EID Data contains the		truly empty EID. This case allows an endpoint to avoid exposing
	UTF-8 encoded EID of some singleton endpoint in which the sending		EID information on an untrusted network. A non-zero-length EID
	node is a member, in the canonical format of <scheme		Data SHALL contain the UTF-8 encoded EID of some singleton
	name>:<scheme-specific part>.		endpoint in which the sending node is a member, in the canonical
			format of <scheme name>:<scheme-specific part>. This EID encoding
			is consistent with [I-D.ietf-dtn-bpbis].
	+---------+------+--------------------------------------------------+		Header Extension Values: The remaining items of the contact header
	| Type | Code | Description |		represent protocol extension data not defined by this
	+---------+------+--------------------------------------------------+		specification. The encoding of each Header Extension Item is
	| CAN_TLS | 0x01 | If bit is set, indicates that the sending peer |		identical form as described in Section 4.1.1.
	| | | is capable of TLS security. |
	+---------+------+--------------------------------------------------+		+----------+--------+-----------------------------------------------+
			| Name | Code | Description |
			+----------+--------+-----------------------------------------------+
			| CAN_TLS | 0x01 | If bit is set, indicates that the sending |
			| | | peer is capable of TLS security. |
			| | | |
			| Reserved | others |
			+----------+--------+-----------------------------------------------+
	Table 1: Contact Header Flags		Table 1: Contact Header Flags
			4.1.1. Header Extension Items
			Each of the Header Extension items SHALL be encoded in an identical
			Type-Length-Value (TLV) container form as indicated in Figure 4. The
			fields of the header extension item are:
			Flags: A one-octet field containing generic bit flags about the
			item, which are listed in Table 2. If a TCPCL endpoint receives
			an extension item with an unknown Item Type and the CRITICAL flag
			set, the endpoint SHALL close the TCPCL session with SHUTDOWN
			reason code of "Contact Failure". If the CRITICAL flag is not
			set, an endpoint 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).
			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
			been completed.
			1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+---------------+---------------+---------------+---------------+
			| Item Flags | Item Type | Item Length...|
			+---------------+---------------+---------------+---------------+
			| length contd. | Item Value... |
			+---------------+---------------+---------------+---------------+
			| value contd. |
			+---------------+---------------+---------------+---------------+
			Figure 4: Header Extention Item Format
			+----------+--------+-----------------------------------------------+
			| Name | Code | Description |
			+----------+--------+-----------------------------------------------+
			| CRITICAL | 0x01 | If bit is set, indicates that the receiving |
			| | | peer must handle the extension item. |
			| | | |
			| Reserved | others |
			+----------+--------+-----------------------------------------------+
			Table 2: Header Extension Item Flags
	4.2. Validation and Parameter Negotiation		4.2. Validation and Parameter Negotiation
	Upon reception of the contact header, each node follows the following		Upon reception of the contact header, each node follows the following
	procedures to ensure the validity of the TCPCL session and to		procedures to ensure the validity of the TCPCL session and to
	negotiate values for the session parameters.		negotiate values for the session parameters.
	If the magic string is not present or is not valid, the connection		If the magic string is not present or is not valid, the connection
	MUST be terminated. The intent of the magic string is to provide		MUST be terminated. The intent of the magic string is to provide
	some protection against an inadvertent TCP connection by a different		some protection against an inadvertent TCP connection by a different
	protocol than the one described in this document. To prevent a flood		protocol than the one described in this document. To prevent a flood
	skipping to change at page 11, line 5 ¶		skipping to change at page 13, line 27 ¶
	before closing it.		before closing it.
	If a node receives a contact header containing a version that is		If a node receives a contact header containing a version that is
	greater than the current version of the protocol that the node		greater than the current version of the protocol that the node
	implements, then the node SHALL shutdown the session with a reason		implements, then the node SHALL shutdown the session with a reason
	code of "Version mismatch". If a node receives a contact header with		code of "Version mismatch". If a node receives a contact header with
	a version that is lower than the version of the protocol that the		a version that is lower than the version of the protocol that the
	node implements, the node MAY either terminate the session (with a		node implements, the node MAY either terminate the session (with a
	reason code of "Version mismatch"). Otherwise, the node MAY adapt		reason code of "Version mismatch"). Otherwise, the node MAY adapt
	its operation to conform to the older version of the protocol. This		its operation to conform to the older version of the protocol. This
	decision is an implementation matter.		decision is an implementation matter. When establishing the TCPCL
			session, a node SHOULD send the contact header for the latest version
			of TCPCL that it can use.
	A node calculates the parameters for a TCPCL session by negotiating		A node calculates the parameters for a TCPCL session by negotiating
	the values from its own preferences (conveyed by the contact header		the values from its own preferences (conveyed by the contact header
	it sent to the peer) with the preferences of the peer node (expressed		it sent to the peer) with the preferences of the peer node (expressed
	in the contact header that it received from the peer). The		in the contact header that it received from the peer). The
	negotatiated parameters defined by this specification are described		negotatiated parameters defined by this specification are described
	in the following paragraphs.		in the following paragraphs.
	Session Keepalive: Negotiation of the Session Keepalive parameter is		Session Keepalive: Negotiation of the Session Keepalive parameter is
	performed by taking the minimum of this two contact headers'		performed by taking the minimum of this two contact headers'
	Keepalive Interval. If the negotiated Session Keepalive is zero		Keepalive Interval. If the negotiated Session Keepalive is zero
	(i.e. one or both contact headers contains a zero Keepalive		(i.e. one or both contact headers contains a zero Keepalive
	Interval), then the keepalive feature (described in Section 5.2.1)		Interval), then the keepalive feature (described in Section 5.2.1)
	is disabled.		is disabled. There is no logical minimum value for the keepalive
			interval, but when used for many sessions on an open, shared
			network a short interval could lead to excessive traffic. For
			shared network use, endpoints SHOULD choose a keepalive interval
			no shorter than 30 seconds. There is no logical maximum value for
			the keepalive interval, but an idle TCP connection is liable for
			closure by the host operating system if the keepalive time is
			longer than tens-of-minutes. Endpoints SHOULD choose a keepalive
			interval no longer than 10 minutes (600 seconds).
	Enable TLS: Negotiation of the Enable TLS parameter is performed by		Enable TLS: Negotiation of the Enable TLS parameter is performed by
	taking the logical AND of the two contact headers' CAN_TLS flags.		taking the logical AND of the two contact headers' CAN_TLS flags.
	If the negotiated Enable TLS value is true then TLS negotiation		If the negotiated Enable TLS value is true then TLS negotiation
	feature (described in Section 5.3) begins immediately following		feature (described in Section 5.3) begins immediately following
	the contact header exchange.		the contact header exchange.
	Once this process of parameter negotiation is completed, the protocol		Once this process of parameter negotiation is completed, the protocol
	defines no additional mechanism to change the parameters of an		defines no additional mechanism to change the parameters of an
	established session; to effect such a change, the session MUST be		established session; to effect such a change, the session MUST be
	skipping to change at page 11, line 45 ¶		skipping to change at page 14, line 29 ¶
	established session, including the mechanism for transmitting bundles		established session, including the mechanism for transmitting bundles
	over the session.		over the session.
	5.1. Message Type Codes		5.1. Message Type Codes
	After the initial exchange of a contact header, all messages		After the initial exchange of a contact header, all messages
	transmitted over the session are identified by a one-octet header		transmitted over the session are identified by a one-octet header
	with the following structure:		with the following structure:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+---------------+
	| type | flags |		| Message Type |
	+-+-+-+-+-+-+-+-+		+---------------+
	Figure 4: Format of the One-Octet Message Header		Figure 5: Format of the Message Header
	type: Indicates the type of the message as per Table 2 below.		The message header fields are as follows:
	flags: Optional flags defined based on message type.		Message Type: Indicates the type of the message as per Table 3
			below.
	The types and values for the message type code are as follows.		The message types defined in this specificaiton are listed in
			Table 3. Encoded values are listed in Section 8.4.
	+---------------+------+--------------------------------------------+		+--------------+----------------------------------------------------+
	| Type | Code | Description |		| Type | Description |
	+---------------+------+--------------------------------------------+		+--------------+----------------------------------------------------+
	| DATA_SEGMENT | 0x1 | Indicates the transmission of a segment of |		| XFER_INIT | Contains the length (in octets) of the next |
	| | | bundle data, as described in Section |		| | transfer, as described in Section 5.4.2. |
	| | | 5.4.3. |		| | |
	| | | |		| XFER_SEGMENT | Indicates the transmission of a segment of bundle |
	| ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, |		| | data, as described in Section 5.4.3. |
	| | | as described in Section 5.4.4. |		| | |
	| | | |		| XFER_ACK | Acknowledges reception of a data segment, as |
	| REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the |		| | described in Section 5.4.4. |
	| | | current bundle SHALL be stopped, as |		| | |
	| | | described in Section 5.4.5. |		| XFER_REFUSE | Indicates that the transmission of the current |
	| | | |		| | bundle SHALL be stopped, as described in Section |
	| KEEPALIVE | 0x4 | KEEPALIVE message for the session, as |		| | 5.4.5. |
	| | | described in Section 5.2.1. |		| | |
	| | | |		| KEEPALIVE | Used to keep TCPCL session active, as described in |
	| SHUTDOWN | 0x5 | Indicates that one of the nodes |		| | Section 5.2.1. |
	| | | participating in the session wishes to |		| | |
	| | | cleanly terminate the session, as |		| SHUTDOWN | Indicates that one of the nodes participating in |
	| | | described in Section 6. |		| | the session wishes to cleanly terminate the |
	| | | |		| | session, as described in Section 6. |
	| LENGTH | 0x6 | Contains the length (in octets) of the |		| | |
	| | | next bundle, as described in Section |		| MSG_REJECT | Contains a TCPCL message rejection, as described |
	| | | 5.4.2. |		| | in Section 5.2.2. |
	| | | |		+--------------+----------------------------------------------------+
	| REJECT | TBD | Contains a TCPCL message rejection, as |
	| | | described in Section 5.2.2. |
	+---------------+------+--------------------------------------------+
	Table 2: TCPCL Message Types		Table 3: 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.1, one of the parameters in the contact		As described in Section 4.1, one of the parameters in the contact
	header is the Keepalive Interval. Both sides populate this field		header is the Keepalive Interval. Both sides populate this field
	with their requested intervals (in seconds) between KEEPALIVE		with their requested intervals (in seconds) between KEEPALIVE
	messages.		messages.
	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 2) with no additional data. Both		KEEPALIVE (as described in Table 3) 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 for at least		If no message (KEEPALIVE or other) has been received for at least
	twice the Keepalive Interval, then either party MAY terminate the		twice the Keepalive Interval, then either party MAY terminate the
	session by transmitting a one-octet SHUTDOWN message (as described in		session by transmitting a one-octet SHUTDOWN message (as described in
	Table 2, with reason code "Idle Timeout") and by closing the session.		Section 6.1, with reason code "Idle Timeout") and by closing the
			session.
	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.
	5.2.2. Message Rejection (REJECT)		5.2.2. Message Rejection (MSG_REJECT)
	If a TCPCL endpoint receives a message which is unknown to it		If a TCPCL endpoint receives a message which is unknown to it
	(possibly due to an unhandled protocol mismatch) or is inappropriate		(possibly due to an unhandled protocol mismatch) or is inappropriate
	for the current session state (e.g. a KEEPALIVE message received		for the current session state (e.g. a KEEPALIVE message received
	after contact header negotation has disabled that feature), there is		after contact header negotation has disabled that feature), there is
	a protocol-level message to signal this condition in the form of a		a protocol-level message to signal this condition in the form of a
	REJECT reply.		MSG_REJECT reply.
	The format of a REJECT message follows:		The format of a MSG_REJECT message follows:
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
	| Reason Code (U8) |		| Reason Code (U8) |
	+-----------------------------+		+-----------------------------+
	| Rejected Message Header |		| Rejected Message Header |
	+-----------------------------+		+-----------------------------+
	Figure 5: Format of REJECT Messages		Figure 6: Format of MSG_REJECT Messages
	The Rejected Message Header is a copy of the Message Header to which		The fields of the MSG_REJECT message are:
	the REJECT message is sent as a response. The REJECT Reason Code is
	an 8-bit unsigned integer and indicates why the REJECT itself was		Reason Code: A one-octet refusal reason code interpreted according
	sent. The specified values of the reason code are:		to the descriptions in Table 4.
			Rejected Message Header: The Rejected Message Header is a copy of
			the Message Header to which the MSG_REJECT message is sent as a
			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 endpoint. |		| Type | | code unknown to the TCPCL endpoint. |
	| Unknown | | |		| Unknown | | |
	| | | |		| | | |
	| Message | 0x02 | A message was received but the TCPCL |		| Message | 0x02 | A message was received but the TCPCL |
	| Unsupported | | endpoint cannot comply with the message |		| Unsupported | | endpoint cannot comply with the message |
	| | | contents. |		| | | 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 3: REJECT Reason Codes		Table 4: MSG_REJECT Reason Codes
	5.3. Session Security		5.3. Session Security
	This version of the TCPCL supports establishing a session-level		This version of the TCPCL supports establishing a session-level
	Transport Layer Security (TLS) session within an existing TCPCL		Transport Layer Security (TLS) session within an existing TCPCL
	session. Negotation of whether or not to initiate TLS within TCPCL		session. Negotation of whether or not to initiate TLS within TCPCL
	session is part of the contact header as described in Section 4.2.		session is part of the contact header as described in Section 4.2.
	When TLS is used within the TCPCL it affects the entire session. By		When TLS is used within the TCPCL it affects the entire session. By
	convention, this protocol uses the endpoint which initiated the		convention, this protocol uses the endpoint which initiated the
	skipping to change at page 15, line 11 ¶		skipping to change at page 18, line 11 ¶
	After a TLS session is successfuly established, both TCPCL endpoints		After a TLS session is successfuly established, both TCPCL endpoints
	SHALL re-exchange TCPCL Contact Header messages. Any information		SHALL re-exchange TCPCL Contact Header messages. Any information
	cached from the prior Contact Header exchange SHALL be discarded.		cached from the prior Contact Header exchange SHALL be discarded.
	This re-exchange avoids man-in-the-middle attack in identical fashion		This re-exchange avoids man-in-the-middle attack in identical fashion
	to [RFC2595].		to [RFC2595].
	5.3.2. Example TLS Initiation		5.3.2. Example TLS Initiation
	A summary of a typical CAN_TLS usage is shown in the sequence in		A summary of a typical CAN_TLS usage is shown in the sequence in
	Figure 6 below.		Figure 7 below.
	Node A Node B		Node A Node B
	====== ======		====== ======
	+-------------------------+		+-------------------------+
	| Open TCP Connnection | ->		| Open TCP Connnection | ->
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	<- | Accept Connection |		<- | Accept Connection |
	+-------------------------+		+-------------------------+
	skipping to change at page 15, line 41 ¶		skipping to change at page 18, line 41 ¶
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	| Contact Header | -> <- | Contact Header |		| Contact Header | -> <- | Contact Header |
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	... secured TCPCL messaging ...		... secured TCPCL messaging ...
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	| SHUTDOWN | -> <- | SHUTDOWN |		| SHUTDOWN | -> <- | SHUTDOWN |
	+-------------------------+ +-------------------------+		+-------------------------+ +-------------------------+
	Figure 6: A simple visual example of TCPCL TLS Establishment between		Figure 7: A simple visual example of TCPCL TLS Establishment between
	two nodes		two nodes
	5.4. Bundle Transfer		5.4. Bundle Transfer
	All of the message in this section are directly associated with		All of the message in this section are directly associated with
	tranfering a bundle between TCPCL endpoints.		tranfering a bundle between TCPCL endpoints.
	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 endpoint		convergence layer as opaque data) being exchanged from one endpoint
	to the other. In TCPCL a transfer is accomplished by dividing a		to the other. In TCPCL a transfer is accomplished by dividing a
	skipping to change at page 16, line 20 ¶		skipping to change at page 19, line 20 ¶
	5.4.1. Bundle Transfer ID		5.4.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
	uniqueness of the bundle data itself and has no relation to concepts		uniqueness of the bundle data itself and has no relation to concepts
	such as bundle fragmentation. Each invocation of TCPCL by the bundle		such as bundle fragmentation. Each invocation of TCPCL by the bundle
	protocol agent, requesting transmission of a bundle (fragmentary or		protocol agent, requesting transmission of a bundle (fragmentary or
	otherwise), results in the initiation of a single TCPCL transfer.		otherwise), results in the initiation of a single TCPCL transfer.
	Each transfer entails the sending of a LENGTH message and some number		Each transfer entails the sending of a XFER_INIT message and some
	of DATA_SEGMENT and ACK_SEGMENT messages; all are correlated by the		number of XFER_SEGMENT and XFER_ACK messages; all are correlated by
	same Transfer ID.		the same Transfer ID.
	Transfer IDs from each endpoint SHALL be unique within a single TCPCL		Transfer IDs from each endpoint SHALL be unique within a single TCPCL
	session. The initial Transfer ID from each endpoint SHALL have value		session. The initial Transfer ID from each endpoint SHALL have value
	zero. Subsequent Transfer ID values SHALL be incremented from the		zero. Subsequent Transfer ID values SHALL be incremented from the
	prior Transfer ID value by one. Upon exhaustion of the entire 64-bit		prior Transfer ID value by one. Upon exhaustion of the entire 64-bit
	Transfer ID space, the sending endpoint SHALL terminate the session		Transfer ID space, the sending endpoint SHALL terminate the session
	with SHUTDOWN reason code "Resource Exhaustion".		with SHUTDOWN reason code "Resource Exhaustion".
	For bidirectional bundle transfers, a TCPCL endpoint SHOULD NOT rely		For bidirectional bundle transfers, a TCPCL endpoint SHOULD NOT rely
	on any relation between Transfer IDs originating from each side of		on any relation between Transfer IDs originating from each side of
	the TCPCL session.		the TCPCL session.
	5.4.2. Bundle Length (LENGTH)		5.4.2. Transfer initialization (XFER_INIT)
	The LENGTH message contains the total length, in octets, of the		The XFER_INIT message contains the total length, in octets, of the
	bundle data in the associated transfer. The total length is		bundle data in the associated transfer. The total length is
	formatted as a 64-bit unsigned integer.		formatted as a 64-bit unsigned integer.
	The purpose of the LENGTH message is to allow nodes to preemptively		The purpose of the XFER_INIT message is to allow nodes to
	refuse bundles that would exceed their resources or to prepare		preemptively refuse bundles that would exceed their resources or to
	storage on the receiving node for the upcoming bundle data. See		prepare storage on the receiving node for the upcoming bundle data.
	Section 5.4.5 for details on when refusal based on LENGTH content is		See Section 5.4.5 for details on when refusal based on XFER_INIT
	acceptable.		content is acceptable.
	The Total Bundle Length field within a LENGTH message SHALL be used		The Total Bundle Length field within a XFER_INIT message SHALL be
	as informative data by the receiver. If, for whatever reason, the		treated as authoritative by the receiver. If, for whatever reason,
	actual total length of bundle data received differs from the value		the actual total length of bundle data received differs from the
	indicated by the LENGTH message, the receiver SHOULD accept the full		value indicated by the XFER_INIT message, the receiver SHOULD treat
	set of bundle data as valid.		the transmitted data as invalid.
	The format of the LENGTH message is as follows:		The format of the XFER_INIT message is as follows:
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	+-----------------------------+		+-----------------------------+
	| Total bundle length (U64) |		| Total bundle length (U64) |
	+-----------------------------+		+-----------------------------+
	Figure 7: Format of LENGTH Messages		Figure 8: Format of XFER_INIT Messages
	LENGTH messages SHALL be sent immediately before transmission of any		The fields of the XFER_INIT message are:
	DATA_SEGMENT messages. LENGTH messages MUST NOT be sent unless the
	next DATA_SEGMENT message has the 'S' bit set to "1" (i.e., just		Transfer ID: A 64-bit unsigned integer identifying the transfer
	before the start of a new transfer).		about to begin.
			Total bundle length: A 64-bit unsigned integer indicating the size
			of the data-to-be-transferred.
			XFER_INIT messages SHALL be sent immediately before transmission of
			any XFER_SEGMENT messages. XFER_INIT messages MUST NOT be sent
			unless the next XFER_SEGMENT message has the 'START' bit set to "1"
			(i.e., just before the start of a new transfer).
	A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a		A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a
	LENGTH message without waiting for the next DATA_SEGMENT message.		XFER_INIT message without waiting for the next XFER_SEGMENT message.
	The sender MUST be prepared for this and MUST associate the refusal		The sender MUST be prepared for this and MUST associate the refusal
	with the correct bundle via the Transfer ID fields.		with the correct bundle via the Transfer ID fields.
	Upon reception of a LENGTH message not immediately before the start		Upon reception of a XFER_INIT message not immediately before the
	of a starting DATA_SEGMENT the reciever SHALL send a REJECT message		start of a starting XFER_SEGMENT the reciever SHALL send a MSG_REJECT
	with a Reason Code of "Message Unexpected".		message with a Reason Code of "Message Unexpected".
	5.4.3. Bundle Data Transmission (DATA_SEGMENT)		5.4.3. Data Transmission (XFER_SEGMENT)
	Each bundle is transmitted in one or more data segments. The format		Each bundle is transmitted in one or more data segments. The format
	of a DATA_SEGMENT message follows in Figure 8 and its use of header		of a XFER_SEGMENT message follows in Figure 9.
	flags is shown in Figure 9.
	+------------------------------+		+------------------------------+
	| Message Header |		| Message Header |
	+------------------------------+		+------------------------------+
			| Message Flags (U8) |
			+------------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	+------------------------------+		+------------------------------+
	| Data length (U64) |		| Data length (U64) |
	+------------------------------+		+------------------------------+
	| Data contents (octet string) |		| Data contents (octet string) |
	+------------------------------+		+------------------------------+
	Figure 8: Format of DATA_SEGMENT Messages		Figure 9: Format of XFER_SEGMENT Messages
	4 5 6 7
	+-+-+-+-+
	|0|0|S|E|
	+-+-+-+-+
	Figure 9: Format of DATA_SEGMENT Header flags		The fields of the XFER_SEGMENT message are:
	The flags portion of the message header octet contains two optional		Message Flags: A one-octet field of single-bit flags, interpreted
	values in the two low-order bits, denoted 'S' and 'E' in Figure 9.		according to the descriptions in Table 5.
	The 'S' bit MUST be set to one if it precedes the transmission of the
	first segment of a transfer. The 'E' bit MUST be set to one when
	transmitting the last segment of a transfer. In the case where an
	entire transfer is accomplished in a single segment, both the 'S' and
	'E' bits MUST be set to one.
	Following the message header, the length field is a 64-bit unsigned		Transfer ID: A 64-bit unsigned integer identifying the transfer
	integer containing the number of octets of bundle data that are		being made.
	transmitted in this segment. Following the length are the actual
	data contents.		Data length: A 64-bit unsigned integer indicating the number of
			octets in the Data contents to follow.
			Data contents: The variable-length data payload of the message.
			+----------+--------+-----------------------------------------------+
			| Name | Code | Description |
			+----------+--------+-----------------------------------------------+
			| END | 0x01 | If bit is set, indicates that this is the |
			| | | last segment of the transfer. |
			| | | |
			| START | 0x02 | If bit is set, indicates that this is the |
			| | | first segment of the transfer. |
			| | | |
			| Reserved | others |
			+----------+--------+-----------------------------------------------+
			Table 5: XFER_SEGMENT Flags
			The flags portion of the message contains two optional values in the
			two low-order bits, denoted 'START' and 'END' in Table 5. 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
			transmitting the last segment of a transfer. In the case where an
			entire transfer is accomplished in a single segment, both the 'START'
			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 'E' bit set. No interleaving of multiple		a segment with the 'END' bit set. No interleaving of multiple
	transfers from the same endpoint is possible (within a single TCPCL		transfers from the same endpoint is possible within a single TCPCL
	session).		session. Simultaneous transfers between two endpoints MAY be
			achieved using multiple TCPCL sessions.
	5.4.4. Bundle Acknowledgments (ACK_SEGMENT)		5.4.4. Data Acknowledgments (XFER_ACK)
	Although the TCP transport provides reliable transfer of data between		Although the TCP transport provides reliable transfer of data between
	transport peers, the typical BSD sockets interface provides no means		transport peers, the typical BSD sockets interface provides no means
	to inform a sending application of when the receiving application has		to inform a sending application of when the receiving application has
	processed some amount of transmitted data. Thus, after transmitting		processed some amount of transmitted data. Thus, after transmitting
	some data, a Bundle Protocol agent needs an additional mechanism to		some data, a Bundle Protocol agent needs an additional mechanism to
	determine whether the receiving agent has successfully received the		determine whether the receiving agent has successfully received the
	segment. To this end, the TCPCL protocol provides feedback messaging		segment. To this end, the TCPCL protocol provides feedback messaging
	whereby a receiving node transmits acknowledgments of reception of		whereby a receiving node transmits acknowledgments of reception of
	data segments.		data segments.
	The format of an ACK_SEGMENT message follows in Figure 10 and its use		The format of an XFER_ACK message follows in Figure 10.
	of header flags is the same as for DATA_SEGMENT (shown in Figure 9).
	The flags of an ACK_SEGMENT message SHALL be identical to the flags
	of the DATA_SEGMENT message for which it is a reply.
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
			| Message Flags (U8) |
			+-----------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	+-----------------------------+		+-----------------------------+
	| Acknowledged length (U64) |		| Acknowledged length (U64) |
	+-----------------------------+		+-----------------------------+
	Figure 10: Format of ACK_SEGMENT Messages		Figure 10: Format of XFER_ACK Messages
	A receving TCPCL endpoing SHALL send an ACK_SEGMENT message in		The fields of the XFER_ACK message are:
	response to each received DATA_SEGMENT message. The flags portion of
	the ACK_SEGMENT header SHALL be set to match the corresponding		Message Flags: A one-octet field of single-bit flags, interpreted
	DATA_SEGEMNT message being acknowledged. The acknowledged length of		according to the descriptions in Table 5.
	each ACK_SEGMENT contains the sum of the data length fields of all
	DATA_SEGMENT messages received so far in the course of the indicated		Transfer ID: A 64-bit unsigned integer identifying the transfer
	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
			to each received XFER_SEGMENT message. The flags portion of the
			XFER_ACK header SHALL be set to match the corresponding DATA_SEGEMNT
			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		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.4.5. Bundle Refusal (REFUSE_BUNDLE)		5.4.5. Transfer Refusal (XFER_REFUSE)
	As bundles can be large, the TCPCL supports an optional mechanism by		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		which a receiving node MAY indicate to the sender that it does not
	want to receive the corresponding bundle.		want to receive the corresponding bundle.
	To do so, upon receiving a LENGTH or DATA_SEGMENT message, the node		To do so, upon receiving a XFER_INIT or XFER_SEGMENT message, the
	MAY transmit a REFUSE_BUNDLE message. As data segments and		node MAY transmit a XFER_REFUSE message. As data segments and
	acknowledgments MAY cross on the wire, the bundle that is being		acknowledgments MAY cross on the wire, the bundle that is being
	refused SHALL be identified by the Transfer ID 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
	endpoint (which is supposed to represent a firm limitation of what		endpoint (which is supposed to represent a firm limitation of what
	the endpoint will accept) and sending of a REFUSE_BUNDLE message. A		the endpoint will accept) and sending of a XFER_REFUSE message. A
	REFUSE_BUNDLE can be used in cases where the agent's bundle storage		XFER_REFUSE can be used in cases where the agent's bundle storage is
	is temporarily depleted or somehow constrained. A REFUSE_BUNDLE can		temporarily depleted or somehow constrained. A XFER_REFUSE can also
	also be used after the bundle header or any bundle data is inspected		be used after the bundle header or any bundle data is inspected by an
	by an agent and determined to be unacceptable.		agent and determined to be unacceptable.
	The format of the REFUSE_BUNDLE message is as follows:		The format of the XFER_REFUSE message is as follows:
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
			| Reason Code (U8) |
			+-----------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	+-----------------------------+		+-----------------------------+
	Figure 11: Format of REFUSE_BUNDLE Messages		Figure 11: Format of XFER_REFUSE Messages
	4 5 6 7		The fields of the XFER_REFUSE message are:
	+-+-+-+-+
	| RCode |
	+-+-+-+-+
	Figure 12: Format of REFUSE_BUNDLE Header flags		Reason Code: A one-octet refusal reason code interpreted according
			to the descriptions in Table 6.
	The RCode field, which stands for "reason code", contains a value		Transfer ID: A 64-bit unsigned integer identifying the transfer
	indicating why the bundle was refused. The following table contains		being refused.
	semantics for some values. Other values MAY be registered with IANA,
	as defined in Section 8.
	+------------+-------+----------------------------------------------+		+------------+------------------------------------------------------+
	| Name | RCode | Semantics |		| Name | Semantics |
	+------------+-------+----------------------------------------------+		+------------+------------------------------------------------------+
	| Unknown | 0x0 | Reason for refusal is unknown or not |		| Unknown | Reason for refusal is unknown or not specified. |
	| | | specified. |		| | |
	| | | |		| Completed | The receiver now has the complete bundle. The sender |
	| Completed | 0x1 | The receiver now has the complete bundle. |		| | MAY now consider the bundle as completely received. |
	| | | The sender MAY now consider the bundle as |		| | |
	| | | completely received. |		| No | The receiver's resources are exhausted. The sender |
	| | | |		| Resources | SHOULD apply reactive bundle fragmentation before |
	| No | 0x2 | The receiver's resources are exhausted. The |		| | retrying. |
	| Resources | | sender SHOULD apply reactive bundle |		| | |
	| | | fragmentation before retrying. |		| Retransmit | The receiver has encountered a problem that requires |
	| | | |		| | the bundle to be retransmitted in its entirety. |
	| Retransmit | 0x3 | The receiver has encountered a problem that |		+------------+------------------------------------------------------+
	| | | requires the bundle to be retransmitted in |
	| | | its entirety. |
	+------------+-------+----------------------------------------------+
	Table 4: REFUSE_BUNDLE Reason Codes		Table 6: 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 DATA_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 REFUSE_BUNDLE message, the		is received. If a sender receives a XFER_REFUSE message, the sender
	sender MUST complete the transmission of any partially sent		MUST complete the transmission of any partially sent XFER_SEGMENT
	DATA_SEGMENT message. There is no way to interrupt an individual		message. There is no way to interrupt an individual TCPCL message
	TCPCL message partway through sending it. The sender MUST NOT		partway through sending it. The sender MUST NOT commence
	commence transmission of any further segments of the refused bundle		transmission of any further segments of the refused bundle
	subsequently. Note, however, that this requirement does not ensure		subsequently. Note, however, that this requirement does not ensure
	that a node will not receive another DATA_SEGMENT for the same bundle		that a node will not receive another XFER_SEGMENT for the same bundle
	after transmitting a REFUSE_BUNDLE message since messages MAY cross		after transmitting a XFER_REFUSE message since messages MAY cross on
	on the wire; if this happens, subsequent segments of the bundle		the wire; if this happens, subsequent segments of the bundle SHOULD
	SHOULD also be refused with a REFUSE_BUNDLE message.		also be refused with a XFER_REFUSE message.
	Note: If a bundle transmission is aborted in this way, the receiver		Note: If a bundle transmission is aborted in this way, the receiver
	MAY not receive a segment with the 'E' flag set to '1' for the		MAY not receive a segment with the 'END' flag set to '1' for the
	aborted bundle. The beginning of the next bundle is identified by		aborted bundle. The beginning of the next bundle is identified by
	the 'S' bit set to '1', indicating the start of a new transfer, and		the 'START' bit set to '1', indicating the start of a new transfer,
	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 MUST be
	transmitted by either node at any point following complete		transmitted by either node at any point following complete
	transmission of any other message. A receiving node SHOULD		transmission of any other message. A receiving node SHOULD
	acknowledge all received data segments before sending a SHUTDOWN		acknowledge all received data segments before sending a SHUTDOWN
	message to end the session. A transmitting node SHALL treat a		message to end the session. A transmitting node SHALL treat a
	SHUTDOWN message received mid-transfer (i.e. before the final		SHUTDOWN message received mid-transfer (i.e. before the final
	acknowledgement) as a failure of the transfer.		acknowledgement) as a failure of the transfer.
			After transmitting a SHUTDOWN message, an endpoint MAY immediately
			close the associated TCP connection. Once the SHUTDOWN message is
			sent, any further received data on the TCP connection SHOULD be
			ignored. Any delay between request to terminate the TCP connection
			and actual closing of the connection (a "half-closed" state) MAY be
			ignored by the TCPCL endpoint.
	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) |
			+-----------------------------------+
	| Reason Code (optional U8) |		| Reason Code (optional U8) |
	+-----------------------------------+		+-----------------------------------+
	| Reconnection Delay (optional U16) |		| Reconnection Delay (optional U16) |
	+-----------------------------------+		+-----------------------------------+
	Figure 13: Format of SHUTDOWN Messages		Figure 12: Format of SHUTDOWN Messages
	4 5 6 7		The fields of the SHUTDOWN message are:
	+-+-+-+-+
	|0|0|R|D|
	+-+-+-+-+
	Figure 14: Format of SHUTDOWN Header flags		Message Flags: A one-octet field of single-bit flags, interpreted
			according to the descriptions in Table 7.
			Reason Code: A one-octet refusal reason code interpreted according
			to the descriptions in Table 8. The Reason Code is present or
			absent as indicated by one of the flags.
			Reconnection Delay: A 16-bit unsigned integer indicating the desired
			delay until further TCPCL sessions to the sending endpoint. The
			Reconnection Delay is present or absent as indicated by one of the
			flags.
			+----------+--------+-----------------------------------------------+
			| Name | Code | Description |
			+----------+--------+-----------------------------------------------+
			| D | 0x01 | If bit is set, indicates that a Reconnection |
			| | | Delay field is present. |
			| | | |
			| R | 0x02 | If bit is set, indicates that a Reason Code |
			| | | field is present. |
			| | | |
			| Reserved | others |
			+----------+--------+-----------------------------------------------+
			Table 7: SHUTDOWN Flags
	It is possible for a node to convey additional information regarding		It is possible for a node to convey additional 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 header flags and transmit a one-octet reason		'R' bit in the message flags and transmit a one-octet reason code
	code immediately following the message header. The specified values		immediately following the message header. The specified values of
	of the reason code are:		the reason code are:
	+--------------+------+---------------------------------------------+		+---------------+---------------------------------------------------+
	| Name | Code | Description |		| Name | Description |
	+--------------+------+---------------------------------------------+		+---------------+---------------------------------------------------+
	| Idle timeout | 0x00 | The session is being closed due to |		| Idle timeout | The session is being closed due to idleness. |
	| | | idleness. |		| | |
	| | | |		| Version | The node cannot conform to the specified TCPCL |
	| Version | 0x01 | The node cannot conform to the specified |		| mismatch | protocol version. |
	| mismatch | | TCPCL protocol version. |		| | |
	| | | |		| Busy | The node is too busy to handle the current |
	| Busy | 0x02 | The node is too busy to handle the current |		| | session. |
	| | | session. |		| | |
	| | | |		| Contact | The node cannot interpret or negotiate contact |
	| Contact | 0x03 | The node cannot interpret or negotiate |		| Failure | header option. |
	| Failure | | contact header option. |		| | |
	| | | |		| TLS failure | The node failed to negotiate TLS session and |
	| TLS failure | 0x04 | The node failed to negotiate TLS session |		| | cannot continue the session. |
	| | | and cannot continue the session. |		| | |
	| | | |		| Resource | The node has run into some resoure limit and |
	| Resource | 0x05 | The node has run into some resoure limit |		| Exhaustion | cannot continue the session. |
	| Exhaustion | | and cannot continue the session. |		+---------------+---------------------------------------------------+
	+--------------+------+---------------------------------------------+
	Table 5: SHUTDOWN Reason Codes		Table 8: SHUTDOWN Reason Codes
	It is also possible to convey a requested reconnection delay to		It is also possible to convey a requested reconnection delay to
	indicate how long the other node MUST wait before attempting session		indicate how long the other node MUST wait before attempting session
	re-establishment. To do so, the node sets the 'D' bit in the message		re-establishment. To do so, the node sets the 'D' bit in the message
	header flags and then transmits an 16-bit unsigned integer specifying		flags and then transmits an 16-bit unsigned integer specifying the
	the requested delay, in seconds, following the message header (and		requested delay, in seconds, following the message header (and
	optionally, the SHUTDOWN reason code). The value 0 SHALL be		optionally, the SHUTDOWN reason code). The value 0 SHALL be
	interpreted as an infinite delay, i.e., that the connecting node MUST		interpreted as an infinite delay, i.e., that the connecting node MUST
	NOT re-establish the session. In contrast, if the node does not wish		NOT re-establish the session. In contrast, if the node does not wish
	to request a delay, it SHOULD omit the reconnection delay field (and		to request a delay, it SHOULD omit the reconnection delay field (and
	set the 'D' bit to zero).		set the 'D' bit to zero).
	A session shutdown MAY occur immediately after TCP connection		A session shutdown MAY occur immediately after TCP connection
	establishment or reception of a contact header (and prior to any		establishment or reception of a contact header (and prior to any
	further data exchange). This MAY, for example, be used to notify		further data exchange). This MAY, for example, be used to notify
	that the node is currently not able or willing to communicate.		that the node is currently not able or willing to communicate.
	skipping to change at page 23, line 32 ¶		skipping to change at page 27, line 44 ¶
	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 5). After receiving a SHUTDOWN		timeout' (as described in Table 8). After receiving a SHUTDOWN
	message in response, both sides MAY close the TCP connection.		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
	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
	mandatory, an endpoint SHALL transmit initial unsecured contact		mandatory, an endpoint SHALL transmit initial unsecured contact
	header values indicated in Table 6 in order. These values avoid		header values indicated in Table 9 in order. These values avoid
	unnecessarily leaking endpoing parameters and will be ignored when		unnecessarily leaking endpoing parameters and will be ignored when
	secure contact header re-exchange occurs.		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, indating lack of EID. |		| EID | Empty, indating lack of EID. |
	+--------------------+---------------------------------------------+		+--------------------+---------------------------------------------+
	Table 6: Recommended Unsecured Contact Header		Table 9: 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
	ensure that the negotiated TLS ciphersuite meets transport security		ensure that the negotiated TLS ciphersuite meets transport security
	requirements. This is identical behavior to STARTTLS use in		requirements. This is identical behavior to STARTTLS use in
	[RFC2595].		[RFC2595].
	Another consideration for this protocol relates to denial-of-service		Another consideration for this protocol relates to denial-of-service
	attacks. A node MAY send a large amount of data over a TCPCL		attacks. A node MAY send a large amount of data over a TCPCL
	session, requiring the receiving node to handle the data, attempt to		session, requiring the receiving node to handle the data, attempt to
	stop the flood of data by sending a REFUSE_BUNDLE message, or		stop the flood of data by sending a XFER_REFUSE message, or forcibly
	forcibly terminate the session. This burden could cause denial of		terminate the session. This burden could cause denial of service on
	service on other, well-behaving sessions. There is also nothing to		other, well-behaving sessions. There is also nothing to prevent a
	prevent a malicious node from continually establishing sessions and		malicious node from continually establishing sessions and repeatedly
	repeatedly trying to send copious amounts of bundle data. A		trying to send copious amounts of bundle data. A listening node MAY
	listening node MAY take countermeasures such as ignoring TCP SYN		take countermeasures such as ignoring TCP SYN messages, closing TCP
	messages, closing TCP connections as soon as they are established,		connections as soon as they are established, waiting before sending
	waiting before sending the contact header, sending a SHUTDOWN message		the contact header, sending a SHUTDOWN message quickly or with a
	quickly or with a delay, etc.		delay, etc.
	8. IANA Considerations		8. IANA Considerations
	In this section, registration procedures are as defined in [RFC5226]		In this section, registration procedures are as defined in [RFC5226].
			Some of the registries below are created new for TCPCLv4 but share
			code values with TCPCLv3. This was done to disambiguate the use of
			these values between TCPCLv3 and TCPCLv4 while preserving the
			semantics of some values.
	8.1. Port Number		8.1. Port Number
	Port number 4556 has been previously assigned as the default port for		Port number 4556 has been previously assigned as the default port for
	the TCP convergence layer in [RFC7242]. This assignment is unchanged		the TCP convergence layer in [RFC7242]. This assignment is unchanged
	by protocol version 4.		by protocol version 4. Each TCPCL endpoint identifies its TCPCL
			protocol version in its initial contact (see Section 8.2), so there
			is no ambiguity about what protocol is being used.
	+------------------------+-------------------------------------+		+------------------------+-------------------------------------+
	| Parameter | Value |		| Parameter | Value |
	+------------------------+-------------------------------------+		+------------------------+-------------------------------------+
	| Service Name: | dtn-bundle |		| Service Name: | dtn-bundle |
	| | |		| | |
	| Transport Protocol(s): | TCP |		| Transport Protocol(s): | TCP |
	| | |		| | |
	| Assignee: | Simon Perreault <simon@per.reau.lt> |		| Assignee: | Simon Perreault <simon@per.reau.lt> |
	| | |		| | |
	skipping to change at page 26, line 5 ¶		skipping to change at page 30, line 23 ¶
	| | | |		| | | |
	| 2 | Reserved | [RFC7242] |		| 2 | Reserved | [RFC7242] |
	| | | |		| | | |
	| 3 | TCPCL | [RFC7242] |		| 3 | TCPCL | [RFC7242] |
	| | | |		| | | |
	| 4 | TCPCLbis | This specification. |		| 4 | TCPCLbis | This specification. |
	| | | |		| | | |
	| 5-255 | Unassigned |		| 5-255 | Unassigned |
	+-------+-------------+---------------------+		+-------+-------------+---------------------+
	8.3. Message Types		8.3. Header Extension Types
	IANA has created, under the "Bundle Protocol" registry, a sub-		EDITOR NOTE: sub-registry to-be-created upon publication of this
	registry titled "Bundle Protocol TCP Convergence-Layer Message Types"		specification.
	and initialized it with the contents below. The registration
	procedure is RFC Required.
	+----------+---------------+		IANA will create, under the "Bundle Protocol" registry, a sub-
	| Code | Message Type |		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	+----------+---------------+		Header Extension Types" and initialized it with the contents of
	| 0x0 | Reserved |		Table 10. The registration procedure is RFC Required within the
	| | |		lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are
	| 0x1 | DATA_SEGMENT |		resrved for use on private networks for functions not published to
	| | |		the IANA.
	| 0x2 | ACK_SEGMENT |
	| | |
	| 0x3 | REFUSE_BUNDLE |
	| | |
	| 0x4 | KEEPALIVE |
	| | |
	| 0x5 | SHUTDOWN |
	| | |
	| 0x6 | LENGTH |
	| | |
	| TBD | REJECT |
	| | |
	| TBD--0xf | Unassigned |
	+----------+---------------+
	Message Type Codes		+----------------+--------------------------+
			| Code | Message Type |
			+----------------+--------------------------+
			| 0x0000 | Reserved |
			| | |
			| 0x0001--0x3fff | Unassigned |
			| | |
			| 0x8000--0xffff | Private/Experimental Use |
			+----------------+--------------------------+
	8.4. REFUSE_BUNDLE Reason Codes		Table 10: Header Extension Type Codes
	IANA has created, under the "Bundle Protocol" registry, a sub-		8.4. Message Types
	registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE
	Reason Codes" and initialized it with the contents of Table 3. The		EDITOR NOTE: sub-registry to-be-created upon publication of this
			specification.
			IANA will create, under the "Bundle Protocol" registry, a sub-
			registry titled "Bundle Protocol TCP Convergence-Layer Version 4
			Message Types" and initialized it with the contents of Table 11. The
	registration procedure is RFC Required.		registration procedure is RFC Required.
			+-----------+--------------+
			| Code | Message Type |
			+-----------+--------------+
			| 0x00 | Reserved |
			| | |
			| 0x01 | XFER_SEGMENT |
			| | |
			| 0x02 | XFER_ACK |
			| | |
			| 0x03 | XFER_REFUSE |
			| | |
			| 0x04 | KEEPALIVE |
			| | |
			| 0x05 | SHUTDOWN |
			| | |
			| 0x06 | XFER_INIT |
			| | |
			| 0x07 | MSG_REJECT |
			| | |
			| 0x08--0xf | Unassigned |
			+-----------+--------------+
			Table 11: Message Type Codes
			8.5. XFER_REFUSE Reason Codes
			EDITOR NOTE: sub-registry to-be-created upon publication of this
			specification.
			IANA will create, under the "Bundle Protocol" registry, a sub-
			registry titled "Bundle Protocol TCP Convergence-Layer Version 4
			XFER_REFUSE Reason Codes" and initialized it with the contents of
			Table 12. 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 |
	+----------+---------------------------+		+----------+---------------------------+
	REFUSE_BUNDLE Reason Codes		Table 12: XFER_REFUSE Reason Codes
	8.5. SHUTDOWN Reason Codes		8.6. SHUTDOWN Reason Codes
	IANA has created, under the "Bundle Protocol" registry, a sub-		EDITOR NOTE: sub-registry to-be-created upon publication of this
	registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN		specification.
	Reason Codes" and initialized it with the contents of Table 4. The
	registration procedure is RFC Required.
	+-----------+------------------+		IANA will create, under the "Bundle Protocol" registry, a sub-
	| Code | Shutdown Reason |		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	+-----------+------------------+		SHUTDOWN Reason Codes" and initialized it with the contents of
	| 0x00 | Idle timeout |		Table 13. The registration procedure is RFC Required.
	| | |
	| 0x01 | Version mismatch |
	| | |
	| 0x02 | Busy |
	| | |
	| TBD | Contact Failure |
	| | |
	| TBD | TLS failure |
	| | |
	| TBD--0xFF | Unassigned |
	+-----------+------------------+
	SHUTDOWN Reason Codes		+------------+------------------+
			| Code | Shutdown Reason |
			+------------+------------------+
			| 0x00 | Idle timeout |
			| | |
			| 0x01 | Version mismatch |
			| | |
			| 0x02 | Busy |
			| | |
			| 0x03 | Contact Failure |
			| | |
			| 0x04 | TLS failure |
			| | |
			| 0x05--0xFF | Unassigned |
			+------------+------------------+
	8.6. REJECT Reason Codes		Table 13: SHUTDOWN 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 REJECT Reason		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	Codes" and initialized it with the contents of Table 4. The		MSG_REJECT Reason Codes" and initialized it with the contents of
	registration procedure is RFC Required.		Table 14. 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 |
	+-----------+----------------------+		+-----------+----------------------+
	REJECT Reason Codes		Table 14: REJECT Reason Codes
	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
	skipping to change at page 29, line 41 ¶		skipping to change at page 34, line 46 ¶
	DOI 10.17487/RFC6257, May 2011,		DOI 10.17487/RFC6257, May 2011,
	<http://www.rfc-editor.org/info/rfc6257>.		<http://www.rfc-editor.org/info/rfc6257>.
	[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant		[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
	Networking TCP Convergence-Layer Protocol", RFC 7242,		Networking TCP Convergence-Layer Protocol", RFC 7242,
	DOI 10.17487/RFC7242, June 2014,		DOI 10.17487/RFC7242, June 2014,
	<http://www.rfc-editor.org/info/rfc7242>.		<http://www.rfc-editor.org/info/rfc7242>.
	[I-D.ietf-dtn-bpsec]		[I-D.ietf-dtn-bpsec]
	Birrane, E. and K. McKeever, "Bundle Protocol Security		Birrane, E. and K. McKeever, "Bundle Protocol Security
	Specification", draft-ietf-dtn-bpsec-03 (work in		Specification", draft-ietf-dtn-bpsec-04 (work in
	progress), October 2016.		progress), March 2017.
	Appendix A. Significant changes from RFC7242		Appendix A. Significant changes from RFC7242
	The areas in which changes from [RFC7242] have been made to existing		The areas in which changes from [RFC7242] have been made to existing
	messages are:		headers and messages are:
	o Changed contact header content to limit number of negotiated		o Changed contact header content to limit number of negotiated
	options.		options.
	o Added contact option to negotiate maximum segment size (per each		o Added contact option to negotiate maximum segment size (per each
	direction).		direction).
			o Added contact header extension capability.
			o Defined new IANA registries for message / type / reason codes to
			allow renaming some codes for clarity.
			o Expanded Message Header to octet-aligned fields instead of bit-
			packing.
	o Added a bundle transfer identification number to all bundle-		o Added a bundle transfer identification number to all bundle-
	related messages (LENGTH, DATA_SEGMENT, ACK_SEGMENT,		related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE).
	REFUSE_BUNDLE).
	o Use flags in ACK_SEGMENT to mirror flags from DATA_SEGMENT.		o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT.
	o Removed all uses of SDNV fields and replaced with fixed-bit-length		o Removed all uses of SDNV fields and replaced with fixed-bit-length
	fields.		fields.
	The areas in which extensions from [RFC7242] have been made as new		The areas in which extensions from [RFC7242] have been made as new
	messages and codes are:		messages and codes are:
	o Added contact negotation failure SHUTDOWN reason code.		o Added contact negotation failure SHUTDOWN reason code.
	o Added REJECT message to indicate an unknown or unhandled message		o Added MSG_REJECT message to indicate an unknown or unhandled
	was received.		message was received.
	o Added TLS session security mechanism.		o Added TLS session security mechanism.
	o Added TLS failure SHUTDOWN reason code.		o Added TLS failure SHUTDOWN reason code.
	Authors' Addresses		Authors' Addresses
	Brian Sipos		Brian Sipos
	RKF Engineering Solutions, LLC		RKF Engineering Solutions, LLC
	1229 19th Street NW		7500 Old Georgetown Road
	Wasington, DC 20036		Suite 1275
			Bethesda, MD 20814-6198
	US		US
	Email: BSipos@rkf-eng.com		Email: BSipos@rkf-eng.com
	Michael Demmer		Michael Demmer
	University of California, Berkeley		University of California, Berkeley
	Computer Science Division		Computer Science Division
	445 Soda Hall		445 Soda Hall
	Berkeley, CA 94720-1776		Berkeley, CA 94720-1776
	US		US
End of changes. 127 change blocks.
	393 lines changed or deleted		588 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/