draft-ietf-dtn-tcpclv4-02.txt		draft-ietf-dtn-tcpclv4-03.txt
	Delay Tolerant Networking B. Sipos		Delay Tolerant Networking B. Sipos
	Internet-Draft RKF Engineering		Internet-Draft RKF Engineering
	Obsoletes: 7242 (if approved) M. Demmer		Obsoletes: 7242 (if approved) M. Demmer
	Intended status: Standards Track UC Berkeley		Intended status: Standards Track UC Berkeley
	Expires: November 23, 2017 J. Ott		Expires: May 17, 2018 J. Ott
	Aalto University		Aalto University
	S. Perreault		S. Perreault
	May 22, 2017		November 13, 2017
	Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4		Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
	draft-ietf-dtn-tcpclv4-02		draft-ietf-dtn-tcpclv4-03
	Abstract		Abstract
	This document describes a revised protocol for the TCP-based		This document describes a revised protocol for the TCP-based
	convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The		convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
	protocol revision is based on implementation issues in the original		protocol revision is based on implementation issues in the original
	TCPCL Version 3 and updates to the Bundle Protocol contents,		TCPCL Version 3 and updates to the Bundle Protocol contents,
	encodings, and convergence layer requirements in Bundle Protocl		encodings, and convergence layer requirements in Bundle Protocl
	Version 7. Several new IANA registries are defined for TCPCLv4 which		Version 7. Several new IANA registries are defined for TCPCLv4 which
	define some behaviors inherited from TCPCLv3 but with updated		define some behaviors inherited from TCPCLv3 but with updated
	encodings and/or semantics.		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 https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 23, 2017.		This Internet-Draft will expire on May 17, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	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 . . . . . . . . . . . 7
	3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7		3.2. Example Message Exchange . . . . . . . . . . . . . . . . 7
	4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8		4. Session Establishment . . . . . . . . . . . . . . . . . . . . 8
	4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10		4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 10
	4.1.1. Header Extension Items . . . . . . . . . . . . . . . 11		4.1.1. Header Extension Items . . . . . . . . . . . . . . . 12
	4.2. Validation and Parameter Negotiation . . . . . . . . . . 13		4.2. Validation and Parameter Negotiation . . . . . . . . . . 13
	5. Established Session Operation . . . . . . . . . . . . . . . . 14		4.3. Session Security . . . . . . . . . . . . . . . . . . . . 14
	5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 14		4.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 15
	5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 15		4.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 15
	5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 15		5. Established Session Operation . . . . . . . . . . . . . . . . 16
	5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 16		5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 16
	5.3. Session Security . . . . . . . . . . . . . . . . . . . . 17		5.2. Upkeep and Status Messages . . . . . . . . . . . . . . . 18
	5.3.1. TLS Handshake Result . . . . . . . . . . . . . . . . 17		5.2.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 18
	5.3.2. Example TLS Initiation . . . . . . . . . . . . . . . 18		5.2.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 18
	5.4. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 18		5.3. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 19
	5.4.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 19		5.3.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 20
	5.4.2. Transfer initialization (XFER_INIT) . . . . . . . . . 19		5.3.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 20
	5.4.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 20		5.3.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 21
	5.4.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22		5.3.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 22
	5.4.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23		5.3.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 23
	6. Session Termination . . . . . . . . . . . . . . . . . . . . . 24		6. Session Termination . . . . . . . . . . . . . . . . . . . . . 25
	6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 25		6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 26
	6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 27		6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 28
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 27		7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
	8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 29		8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 30
	8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 29		8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 31
	8.3. Header Extension Types . . . . . . . . . . . . . . . . . 30		8.3. Header Extension Types . . . . . . . . . . . . . . . . . 31
	8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 31		8.4. Message Types . . . . . . . . . . . . . . . . . . . . . . 32
	8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 31		8.5. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 32
	8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 32		8.6. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 33
	8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 33		8.7. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 34
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
	10.1. Normative References . . . . . . . . . . . . . . . . . . 33		10.1. Normative References . . . . . . . . . . . . . . . . . . 34
	10.2. Informative References . . . . . . . . . . . . . . . . . 34		10.2. Informative References . . . . . . . . . . . . . . . . . 35
	Appendix A. Significant changes from RFC7242 . . . . . . . . . . 35		Appendix A. Significant changes from RFC7242 . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
	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 49 ¶		skipping to change at page 4, line 49 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2.1. Definitions Specific to the TCPCL Protocol		2.1. Definitions Specific to the TCPCL Protocol
	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.
			TCPCL Node: A TCPCL node refers to either side of an negotiating or
			in-service TCPCL Session. For most TCPCL behavior, the two nodes
			are symmetric and there is no protocol distinction between them.
			Some specific behavior, particularly during negotiation,
			distinguishes between the connecting node and the connected-to
			node. For the remainder of this document, the term "node" without
			the prefix "TCPCL" refers to a TCPCL node.
	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 after a bundle node establishes a TCP connection to for		initiated after a bundle node establishes a TCP connection to for
	the purposes of bundle communication. A TCPCL session is		the purposes of bundle communication. A TCPCL session is
	terminated when the TCP connection ends, due either to one or both		terminated when the TCP connection ends, due either to one or both
	nodes actively terminating the TCP connection or due to network		nodes actively terminating the TCP connection or due to network
	errors causing a failure of the TCP connection. For the remainder		errors causing a failure of the TCP connection. For the remainder
	of this document, the term "session" without the prefix "TCPCL"		of this document, the term "session" without the prefix "TCPCL"
	refer to a TCPCL session.		refers to a TCPCL session.
	Session parameters: The session parameters are a set of values used		Session parameters: The session parameters are a set of values used
	to affect the operation of the TCPCL for a given session. The		to affect the operation of the TCPCL for a given session. The
	manner in which these parameters are conveyed to the bundle node		manner in which these parameters are conveyed to the bundle node
	and thereby to the TCPCL is implementation dependent. However,		and thereby to the TCPCL is implementation dependent. However,
	the mechanism by which two bundle nodes exchange and negotiate the		the mechanism by which two bundle nodes exchange and negotiate the
	values to be used for a given session is described in Section 4.2.		values to be used for a given session is described in Section 4.2.
	Transfer Transfer refers to the procedures and mechanisms (described		Transfer Transfer refers to the procedures and mechanisms (described
	below) for conveyance of an individual bundle from one node to		below) for conveyance of an individual bundle from one node to
	skipping to change at page 6, line 38 ¶		skipping to change at page 6, line 46 ¶
	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 XFER_REFUSE message,		a bundle at any point in time by replying with a XFER_REFUSE message,
	which causes the sender to stop transmission of the current bundle,		which causes the sender to stop transmission of the current bundle,
	after completing transmission of a partially sent data segment.		after completing transmission of a partially sent data segment.
	Note: This enables a cross-layer optimization in that it allows a		Note: This enables a cross-layer optimization in that it allows a
	receiver that detects that it already has received a certain bundle		receiver that detects that it already has received a certain bundle
	to interrupt transmission as early as possible and thus save		to interrupt transmission as early as possible and thus save
	transmission capacity for other bundles.		transmission capacity for other bundles.
	For sessions that are idle, a KEEPALIVE message is sent at a		For sessions that are idle, a KEEPALIVE message is sent at a
	negotiated interval. This is used to convey liveness information.		negotiated interval. This is used to convey node 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 (XFER_ACK or XFER_REFUSE)		message MAY send further acknowledgments (XFER_ACK or XFER_REFUSE)
	but no further data messages (XFER_SEGMENT). A SHUTDOWN message MAY		but no further data messages (XFER_SEGMENT). A SHUTDOWN message MAY
	also be used to refuse a session setup by a peer.		also be used to refuse a session setup by a 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
	skipping to change at page 10, line 32 ¶		skipping to change at page 10, line 32 ¶
	| contd. |		| contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Transfer MRU... |		| Transfer MRU... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| contd. |		| contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| EID Length | EID Data... |		| EID Length | EID Data... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| EID Data contd. |		| EID Data contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| TCPCLv4 Header Extension Items... |		| Header Extension Length... |
			+---------------+---------------+---------------+---------------+
			| contd. |
			+---------------+---------------+---------------+---------------+
			| Header Extension Items... |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 3: Contact Header Format		Figure 3: Contact Header Format
	See Section 4.2 for details on the use of each of these contact		See Section 4.2 for details on the use of each of these contact
	header fields. The fields of the contact header are:		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 any message being received
	in this session.		in this session and a subsequent KEEPALIVE message being received.
	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 XFER_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 nodes of a
	of a single session MAY have different Segment MRUs, and no		single session MAY have different Segment MRUs, and no relation
	relation between the two is required.		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,		nodes of a single session MAY have different Transfer MRUs, and no
	and no relation between the two is required.		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 SHALL be used to indicate the lack of EID rather than a		Length SHALL be used to indicate the lack of EID rather than a
	truly empty EID. This case allows an endpoint to avoid exposing		truly empty EID. This case allows an node to avoid exposing EID
	EID information on an untrusted network. A non-zero-length EID		information on an untrusted network. A non-zero-length EID Data
	Data SHALL contain the UTF-8 encoded EID of some singleton		SHALL contain the UTF-8 encoded EID of some singleton endpoint in
	endpoint in which the sending node is a member, in the canonical		which the sending node is a member, in the canonical format of
	format of <scheme name>:<scheme-specific part>. This EID encoding		<scheme name>:<scheme-specific part>. This EID encoding is
	is consistent with [I-D.ietf-dtn-bpbis].		consistent with [I-D.ietf-dtn-bpbis].
	Header Extension Values: The remaining items of the contact header		Header Extension Length Header Extension Items: Together these
	represent protocol extension data not defined by this		fields represent protocol extension data not defined by this
	specification. The encoding of each Header Extension Item is		specification. The Header Extension Length is the total number of
			octets to follow which are used to encode the Header Extension
			Item list. The encoding of each Header Extension Item is
	identical form as described in Section 4.1.1.		identical form as described in Section 4.1.1.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| CAN_TLS | 0x01 | If bit is set, indicates that the sending |		| CAN_TLS | 0x01 | If bit is set, indicates that the sending |
	| | | peer is capable of TLS security. |		| | | peer is capable of TLS security. |
	| | | |		| | | |
	| Reserved | others |		| Reserved | others |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	Table 1: Contact Header Flags		Table 1: Contact Header Flags
	4.1.1. Header Extension Items		4.1.1. Header Extension Items
	Each of the Header Extension items SHALL be encoded in an identical		Each of the Header Extension items SHALL be encoded in an identical
	Type-Length-Value (TLV) container form as indicated in Figure 4. The		Type-Length-Value (TLV) container form as indicated in Figure 4. The
	fields of the header extension item are:		fields of the header extension item are:
	Flags: A one-octet field containing generic bit flags about the		Flags: A one-octet field containing generic bit flags about the
	item, which are listed in Table 2. If a TCPCL endpoint receives		item, which are listed in Table 2. If a TCPCL node receives an
	an extension item with an unknown Item Type and the CRITICAL flag		extension item with an unknown Item Type and the CRITICAL flag
	set, the endpoint SHALL close the TCPCL session with SHUTDOWN		set, the node SHALL close the TCPCL session with SHUTDOWN reason
	reason code of "Contact Failure". If the CRITICAL flag is not		code of "Contact Failure". If the CRITICAL flag is not set, an
	set, an endpoint SHALL skip over and ignore any item with an		node SHALL skip over and ignore any item with an unkonwn Item
	unkonwn Item Type.		Type.
	Item Type: A 16-bit unsigned integer field containing the type of		Item Type: A 16-bit unsigned integer field containing the type of
	the extension item. Each type This specification does not define		the extension item. Each type This specification does not define
	any extension types directly, but does allocate an IANA registry		any extension types directly, but does allocate an IANA registry
	for such codes (see Section 8.3).		for such codes (see Section 8.3).
	Item Length: A 32-bit unsigned integer field containing the number		Item Length: A 32-bit unsigned integer field containing the number
	of Item Value octets to follow.		of Item Value octets to follow.
	Item Value: A variable-length data field which is interpreted		Item Value: A variable-length data field which is interpreted
	skipping to change at page 13, line 19 ¶		skipping to change at page 13, line 30 ¶
	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
	of repeated connections from a misconfigured application, a node MAY		of repeated connections from a misconfigured application, a node MAY
	elect to hold an invalid connection open and idle for some time		elect to hold an invalid connection open and idle for some time
	before closing it.		before closing it.
			A connecting TCPCL node SHALL send the highest TCPCL protocol version
			on a first session attempt for a TCPCL peer. If a connecting node
			receives a SHUTDOWN message with reason of "Version Mismatch", that
			node MAY attempt further TCPCL sessions with the peer using earlier
			protocol version numbers in decreasing order. Managing multi-TCPCL-
			session state such as this is an implementation matter.
	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. The
	decision is an implementation matter. When establishing the TCPCL		decision of version fall-back is an implementation matter.
	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. There is no logical minimum value for the keepalive		is disabled. There is no logical minimum value for the keepalive
	interval, but when used for many sessions on an open, shared		interval, but when used for many sessions on an open, shared
	network a short interval could lead to excessive traffic. For		network a short interval could lead to excessive traffic. For
	shared network use, endpoints SHOULD choose a keepalive interval		shared network use, nodes SHOULD choose a keepalive interval no
	no shorter than 30 seconds. There is no logical maximum value for		shorter than 30 seconds. There is no logical maximum value for
	the keepalive interval, but an idle TCP connection is liable for		the keepalive interval, but an idle TCP connection is liable for
	closure by the host operating system if the keepalive time is		closure by the host operating system if the keepalive time is
	longer than tens-of-minutes. Endpoints SHOULD choose a keepalive		longer than tens-of-minutes. Nodes SHOULD choose a keepalive
	interval no longer than 10 minutes (600 seconds).		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 4.3) begins immediately following
	the contact header exchange.		the contact header exchange. The security policy on either node
			MAY forbid the establishment of a TCPCL session for any Enable TLS
			result (or for any combination of local or peer CAN_TLS flag), in
			which case the node SHALL shutdown the session with a reason code
			of "Contact Failure". For example, one node may disallow TCPCL
			sessions without TLS, while a second node may disallow sessions
			with TLS. Also note that this Contact Failure (of the header
			negotiation) is different than a TLS Failure (after an agreed-upon
			Enable TLS state).
	Once this process of parameter negotiation is completed, the protocol		Once this process of parameter negotiation is completed (which
	defines no additional mechanism to change the parameters of an		includes a possible completed TLS handshakede of the connection to
	established session; to effect such a change, the session MUST be		use TLS), this protocol defines no additional mechanism to change the
	terminated and a new session established.		parameters of an established session; to effect such a change, the
			TCPCL session MUST be terminated and a new session established.
			4.3. Session Security
			This version of the TCPCL supports establishing a Transport Layer
			Security (TLS) session within an existing TCP connection. Negotation
			of whether or not to initiate TLS within a TCPCL session is part of
			the contact header as described in Section 4.2. The TLS handshake,
			if it occurs, is considered to be part of the contact negotiation
			before the TCPCL session itself is established. Specifics about
			sensitive data exposure are discussed in Section 7.
			When TLS is used within the TCPCL it affects the entire session. By
			convention, this protocol uses the node which initiated the
			underlying TCP connection as the "client" role of the TLS handshake
			request. Once a TLS session is established within TCPCL, there is no
			mechanism provided to end the TLS session and downgrade the session.
			If a non-TLS session is desired after a TLS session is started then
			the entire TCPCL session MUST be shutdown first.
			After negotiating an Enable TLS parameter of true, and before any
			other TCPCL messages are sent within the session, the session nodes
			SHALL begin a TLS handshake in accordance with [RFC5246]. The
			parameters within each TLS negotation are implementation dependent
			but any TCPCL node SHOULD follow all recommended best practices of
			[RFC7525].
			4.3.1. TLS Handshake Result
			If a TLS handshake cannot negotiate a TLS session, both nodes of the
			TCPCL session SHALL cause a TCPCL shutdown with reason "TLS Failure".
			After a TLS session is successfuly established, both TCPCL nodes
			SHALL re-exchange TCPCL Contact Header messages. Any information
			cached from the prior Contact Header exchange SHALL be discarded.
			This re-exchange avoids man-in-the-middle attack in identical fashion
			to [RFC2595]. Each re-exchange header CAN_TLS flag SHALL be
			identical to the original header CAN_TLS flag from the same node.
			The CAN_TLS logic (TLS negotiation) SHALL NOT apply during header re-
			exchange. This reinforces the fact that there is no TLS downgrade
			mechanism.
			4.3.2. Example TLS Initiation
			A summary of a typical CAN_TLS usage is shown in the sequence in
			Figure 5 below.
			Node A Node B
			====== ======
			+-------------------------+
			| Open TCP Connnection | ->
			+-------------------------+ +-------------------------+
			<- | Accept Connection |
			+-------------------------+
			+-------------------------+ +-------------------------+
			| Contact Header | -> <- | Contact Header |
			+-------------------------+ +-------------------------+
			+-------------------------+ +-------------------------+
			| TLS Negotiation | -> <- | TLS Negotiation |
			| (as client) | | (as server) |
			+-------------------------+ +-------------------------+
			+-------------------------+ +-------------------------+
			| Contact Header | -> <- | Contact Header |
			+-------------------------+ +-------------------------+
			... secured TCPCL messaging ...
			+-------------------------+ +-------------------------+
			| SHUTDOWN | -> <- | SHUTDOWN |
			+-------------------------+ +-------------------------+
			Figure 5: A simple visual example of TCPCL TLS Establishment between
			two nodes
	5. Established Session Operation		5. Established Session Operation
	This section describes the protocol operation for the duration of an		This section describes the protocol operation for the duration of an
	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
	+---------------+		+---------------+
	| Message Type |		| Message Type |
	+---------------+		+---------------+
	Figure 5: Format of the Message Header		Figure 6: Format of the Message Header
	The message header fields are as follows:		The message header fields are as follows:
	Message Type: Indicates the type of the message as per Table 3		Message Type: Indicates the type of the message as per Table 3
	below.		below.
	The message types defined in this specificaiton are listed in		The message types defined in this specificaiton are listed in
	Table 3. Encoded values are listed in Section 8.4.		Table 3. Encoded values are listed in Section 8.4.
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| Type | Description |		| Type | Description |
	+--------------+----------------------------------------------------+		+--------------+----------------------------------------------------+
	| XFER_INIT | Contains the length (in octets) of the next |		| XFER_INIT | Contains the length (in octets) of the next |
	| | transfer, as described in Section 5.4.2. |		| | transfer, as described in Section 5.3.2. |
	| | |		| | |
	| XFER_SEGMENT | Indicates the transmission of a segment of bundle |		| XFER_SEGMENT | Indicates the transmission of a segment of bundle |
	| | data, as described in Section 5.4.3. |		| | data, as described in Section 5.3.3. |
	| | |		| | |
	| XFER_ACK | Acknowledges reception of a data segment, as |		| XFER_ACK | Acknowledges reception of a data segment, as |
	| | described in Section 5.4.4. |		| | described in Section 5.3.4. |
	| | |		| | |
	| XFER_REFUSE | Indicates that the transmission of the current |		| XFER_REFUSE | Indicates that the transmission of the current |
	| | bundle SHALL be stopped, as described in Section |		| | bundle SHALL be stopped, as described in Section |
	| | 5.4.5. |		| | 5.3.5. |
	| | |		| | |
	| KEEPALIVE | Used to keep TCPCL session active, as described in |		| KEEPALIVE | Used to keep TCPCL session active, as described in |
	| | Section 5.2.1. |		| | Section 5.2.1. |
	| | |		| | |
	| SHUTDOWN | Indicates that one of the nodes participating in |		| SHUTDOWN | Indicates that one of the nodes participating in |
	| | the session wishes to cleanly terminate the |		| | the session wishes to cleanly terminate the |
	| | session, as described in Section 6. |		| | session, as described in Section 6. |
	| | |		| | |
	| MSG_REJECT | Contains a TCPCL message rejection, as described |		| MSG_REJECT | Contains a TCPCL message rejection, as described |
	| | in Section 5.2.2. |		| | in Section 5.2.2. |
	skipping to change at page 16, line 19 ¶		skipping to change at page 18, line 38 ¶
	session.		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 (MSG_REJECT)		5.2.2. Message Rejection (MSG_REJECT)
	If a TCPCL endpoint receives a message which is unknown to it		If a TCPCL node receives a message which is unknown to it (possibly
	(possibly due to an unhandled protocol mismatch) or is inappropriate		due to an unhandled protocol mismatch) or is inappropriate for the
	for the current session state (e.g. a KEEPALIVE message received		current session state (e.g. a KEEPALIVE message received after
	after contact header negotation has disabled that feature), there is		contact header negotation has disabled that feature), there is a
	a protocol-level message to signal this condition in the form of a		protocol-level message to signal this condition in the form of a
	MSG_REJECT reply.		MSG_REJECT reply.
	The format of a MSG_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 6: Format of MSG_REJECT Messages		Figure 7: Format of MSG_REJECT Messages
	The fields of the MSG_REJECT message are:		The fields of the MSG_REJECT message are:
	Reason Code: A one-octet refusal reason code interpreted according		Reason Code: A one-octet refusal reason code interpreted according
	to the descriptions in Table 4.		to the descriptions in Table 4.
	Rejected Message Header: The Rejected Message Header is a copy of		Rejected Message Header: The Rejected Message Header is a copy of
	the Message Header to which the MSG_REJECT message is sent as a		the Message Header to which the MSG_REJECT message is sent as a
	response.		response.
	+-------------+------+----------------------------------------------+		+-------------+------+----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+-------------+------+----------------------------------------------+		+-------------+------+----------------------------------------------+
	| Message | 0x01 | A message was received with a Message Type |		| Message | 0x01 | A message was received with a Message Type |
	| Type | | code unknown to the TCPCL endpoint. |		| Type | | code unknown to the TCPCL node. |
	| Unknown | | |		| Unknown | | |
	| | | |		| | | |
	| Message | 0x02 | A message was received but the TCPCL |		| Message | 0x02 | A message was received but the TCPCL node |
	| Unsupported | | endpoint cannot comply with the message |		| Unsupported | | 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 4: MSG_REJECT Reason Codes		Table 4: MSG_REJECT Reason Codes
	5.3. Session Security		5.3. Bundle Transfer
	This version of the TCPCL supports establishing a session-level
	Transport Layer Security (TLS) session within an existing 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.
	When TLS is used within the TCPCL it affects the entire session. By
	convention, this protocol uses the endpoint which initiated the
	underlying TCP connection as the "client" role of the TLS handshake
	request. Once a TLS session is established within TCPCL, there is no
	mechanism provided to end the TLS session and downgrade the session.
	If a non-TLS session is desired after a TLS session is started then
	the entire TCPCL session MUST be shutdown first.
	After negotiating an Enable TLS parameter of true, and before any
	other TCPCL messages are sent within the session, the session
	endpoints SHALL begin a TLS handshake in accordance with [RFC5246].
	The parameters within each TLS negotation are implementation
	dependent but any TCPCL endpoint SHOULD follow all recommended best
	practices of [RFC7525].
	5.3.1. TLS Handshake Result
	If a TLS handshake cannot negotiate a TLS session, both endpoints of
	the TCPCL session SHALL cause a TCPCL shutdown with reason "TLS
	negotiation failed".
	After a TLS session is successfuly established, both TCPCL endpoints
	SHALL re-exchange TCPCL Contact Header messages. Any information
	cached from the prior Contact Header exchange SHALL be discarded.
	This re-exchange avoids man-in-the-middle attack in identical fashion
	to [RFC2595].
	5.3.2. Example TLS Initiation
	A summary of a typical CAN_TLS usage is shown in the sequence in
	Figure 7 below.
	Node A Node B
	====== ======
	+-------------------------+
	| Open TCP Connnection | ->
	+-------------------------+ +-------------------------+
	<- | Accept Connection |
	+-------------------------+
	+-------------------------+ +-------------------------+
	| Contact Header | -> <- | Contact Header |
	+-------------------------+ +-------------------------+
	+-------------------------+ +-------------------------+
	| TLS Negotiation | -> <- | TLS Negotiation |
	| (as client) | | (as server) |
	+-------------------------+ +-------------------------+
	+-------------------------+ +-------------------------+
	| Contact Header | -> <- | Contact Header |
	+-------------------------+ +-------------------------+
	... secured TCPCL messaging ...
	+-------------------------+ +-------------------------+
	| SHUTDOWN | -> <- | SHUTDOWN |
	+-------------------------+ +-------------------------+
	Figure 7: A simple visual example of TCPCL TLS Establishment between
	two nodes
	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.		transfering a bundle between TCPCL nodes.
	A single TCPCL transfer results in a bundle (handled by the		A single TCPCL transfer results in a bundle (handled by the
	convergence layer as opaque data) being exchanged from one endpoint		convergence layer as opaque data) being exchanged from one node to
	to the other. In TCPCL a transfer is accomplished by dividing a		the other. In TCPCL a transfer is accomplished by dividing a single
	single bundle up into "segments" based on the receving-side Segment		bundle up into "segments" based on the receving-side Segment MRU (see
	MRU (see Section 4.1).		Section 4.1).
	A single transfer (and by extension a single segment) SHALL NOT		A single transfer (and by extension a single segment) SHALL NOT
	contain data of more than a single bundle. This requirement is		contain data of more than a single bundle. This requirement is
	imposed on the agent using the TCPCL rather than TCPCL itself.		imposed on the agent using the TCPCL rather than TCPCL itself.
	5.4.1. Bundle Transfer ID		5.3.1. Bundle Transfer ID
	Each of the bundle transfer messages contains a Transfer ID number		Each of the bundle transfer messages contains a Transfer ID number
	which is used to correlate messages originating from sender and		which is used to correlate messages originating from sender and
	receiver of a bundle. A Transfer ID does not attempt to address		receiver of a bundle. A Transfer ID does not attempt to address
	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 XFER_INIT message and some		Each transfer entails the sending of a XFER_INIT message and some
	number of XFER_SEGMENT and XFER_ACK messages; all are correlated by		number of XFER_SEGMENT and XFER_ACK messages; all are correlated by
	the same Transfer ID.		the same Transfer ID.
	Transfer IDs from each endpoint SHALL be unique within a single TCPCL		Transfer IDs from each node 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 node 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 node SHALL terminate the session with
	with SHUTDOWN reason code "Resource Exhaustion".		SHUTDOWN reason code "Resource Exhaustion".
	For bidirectional bundle transfers, a TCPCL endpoint SHOULD NOT rely		For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on
	on any relation between Transfer IDs originating from each side of		any relation between Transfer IDs originating from each side of the
	the TCPCL session.		TCPCL session.
	5.4.2. Transfer initialization (XFER_INIT)		5.3.2. Transfer Initialization (XFER_INIT)
	The XFER_INIT 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 XFER_INIT message is to allow nodes to		The purpose of the XFER_INIT message is to allow nodes to
	preemptively refuse bundles that would exceed their resources or to		preemptively refuse bundles that would exceed their resources or to
	prepare storage on the receiving node for the upcoming bundle data.		prepare storage on the receiving node for the upcoming bundle data.
	See Section 5.4.5 for details on when refusal based on XFER_INIT		See Section 5.3.5 for details on when refusal based on XFER_INIT
	content is acceptable.		content is acceptable.
	The Total Bundle Length field within a XFER_INIT message SHALL be		The Total Bundle Length field within a XFER_INIT message SHALL be
	treated as authoritative by the receiver. If, for whatever reason,		treated as authoritative by the receiver. If, for whatever reason,
	the actual total length of bundle data received differs from the		the actual total length of bundle data received differs from the
	value indicated by the XFER_INIT message, the receiver SHOULD treat		value indicated by the XFER_INIT message, the receiver SHOULD treat
	the transmitted data as invalid.		the transmitted data as invalid.
	The format of the XFER_INIT message is as follows:		The format of the XFER_INIT message is as follows:
	skipping to change at page 20, line 25 ¶		skipping to change at page 21, line 23 ¶
	Figure 8: Format of XFER_INIT Messages		Figure 8: Format of XFER_INIT Messages
	The fields of the XFER_INIT message are:		The fields of the XFER_INIT message are:
	Transfer ID: A 64-bit unsigned integer identifying the transfer		Transfer ID: A 64-bit unsigned integer identifying the transfer
	about to begin.		about to begin.
	Total bundle length: A 64-bit unsigned integer indicating the size		Total bundle length: A 64-bit unsigned integer indicating the size
	of the data-to-be-transferred.		of the data-to-be-transferred.
	XFER_INIT messages SHALL be sent immediately before transmission of		An XFER_INIT message SHALL be sent immediately before transmission of
	any XFER_SEGMENT messages. XFER_INIT messages MUST NOT be sent		any XFER_SEGMENT messages for each Transfer ID. XFER_INIT messages
	unless the next XFER_SEGMENT message has the 'START' bit set to "1"		MUST NOT be sent unless the next XFER_SEGMENT message has the 'START'
	(i.e., just before the start of a new transfer).		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
	XFER_INIT message without waiting for the next XFER_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 XFER_INIT message not immediately before the		5.3.3. Data Transmission (XFER_SEGMENT)
	start of a starting XFER_SEGMENT the reciever SHALL send a MSG_REJECT
	message with a Reason Code of "Message Unexpected".
	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 XFER_SEGMENT message follows in Figure 9.		of a XFER_SEGMENT message follows in Figure 9.
	+------------------------------+		+------------------------------+
	| Message Header |		| Message Header |
	+------------------------------+		+------------------------------+
	| Message Flags (U8) |		| Message Flags (U8) |
	+------------------------------+		+------------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	skipping to change at page 22, line 8 ¶		skipping to change at page 22, line 41 ¶
	two low-order bits, denoted 'START' and 'END' in Table 5. 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		'START' bit MUST be set to one if it precedes the transmission of the
	first segment of a transfer. The 'END' bit MUST be set to one when		first segment of a transfer. The 'END' bit MUST be set to one when
	transmitting the last segment of a transfer. In the case where an		transmitting the last segment of a transfer. In the case where an
	entire transfer is accomplished in a single segment, both the 'START'		entire transfer is accomplished in a single segment, both the 'START'
	and 'END' bits MUST be set to one.		and 'END' bits MUST be set to one.
	Once a transfer of a bundle has commenced, the node MUST only send		Once a transfer of a bundle has commenced, the node MUST only send
	segments containing sequential portions of that bundle until it sends		segments containing sequential portions of that bundle until it sends
	a segment with the 'END' bit set. No interleaving of multiple		a segment with the 'END' bit set. No interleaving of multiple
	transfers from the same endpoint is possible within a single TCPCL		transfers from the same node is possible within a single TCPCL
	session. Simultaneous transfers between two endpoints MAY be		session. Simultaneous transfers between two nodes MAY be achieved
	achieved using multiple TCPCL sessions.		using multiple TCPCL sessions.
	5.4.4. Data Acknowledgments (XFER_ACK)		5.3.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.
	skipping to change at page 23, line 14 ¶		skipping to change at page 23, line 47 ¶
	contains the sum of the data length fields of all XFER_SEGMENT		contains the sum of the data length fields of all XFER_SEGMENT
	messages received so far in the course of the indicated transfer.		messages received so far in the course of the indicated transfer.
	For example, suppose the sending node transmits four segments of		For example, suppose the sending node transmits four segments of
	bundle data with lengths 100, 200, 500, and 1000, respectively.		bundle data with lengths 100, 200, 500, and 1000, respectively.
	After receiving the first segment, the node sends an acknowledgment		After receiving the first segment, the node sends an acknowledgment
	of length 100. After the second segment is received, the node sends		of length 100. After the second segment is received, the node sends
	an acknowledgment of length 300. The third and fourth		an acknowledgment of length 300. The third and fourth
	acknowledgments are of length 800 and 1800, respectively.		acknowledgments are of length 800 and 1800, respectively.
	5.4.5. Transfer Refusal (XFER_REFUSE)		5.3.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 XFER_INIT or XFER_SEGMENT message, the		To do so, upon receiving a XFER_INIT or XFER_SEGMENT message, the
	node MAY transmit a XFER_REFUSE 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		node (which is supposed to represent a firm limitation of what the
	the endpoint will accept) and sending of a XFER_REFUSE message. A		node will accept) and sending of a XFER_REFUSE message. A
	XFER_REFUSE can be used in cases where the agent's bundle storage is		XFER_REFUSE can be used in cases where the agent's bundle storage is
	temporarily depleted or somehow constrained. A XFER_REFUSE can also		temporarily depleted or somehow constrained. A XFER_REFUSE can also
	be used after the bundle header or any bundle data is inspected by an		be used after the bundle header or any bundle data is inspected by an
	agent and determined to be unacceptable.		agent and determined to be unacceptable.
	The format of the XFER_REFUSE message is as follows:		The format of the XFER_REFUSE message is as follows:
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
	skipping to change at page 24, line 10 ¶		skipping to change at page 25, line 10 ¶
	to the descriptions in Table 6.		to the descriptions in Table 6.
	Transfer ID: A 64-bit unsigned integer identifying the transfer		Transfer ID: A 64-bit unsigned integer identifying the transfer
	being refused.		being refused.
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| Name | Semantics |		| Name | Semantics |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	| Unknown | Reason for refusal is unknown or not specified. |		| Unknown | Reason for refusal is unknown or not specified. |
	| | |		| | |
	| Completed | The receiver now has the complete bundle. The sender |		| Completed | The receiver already has the complete bundle. The |
	| | MAY now consider the bundle as completely received. |		| | sender MAY consider the bundle as completely |
			| | received. |
	| | |		| | |
	| No | The receiver's resources are exhausted. The sender |		| No | The receiver's resources are exhausted. The sender |
	| Resources | SHOULD apply reactive bundle fragmentation before |		| Resources | SHOULD apply reactive bundle fragmentation before |
	| | retrying. |		| | retrying. |
	| | |		| | |
	| Retransmit | The receiver has encountered a problem that requires |		| Retransmit | The receiver has encountered a problem that requires |
	| | the bundle to be retransmitted in its entirety. |		| | the bundle to be retransmitted in its entirety. |
	+------------+------------------------------------------------------+		+------------+------------------------------------------------------+
	Table 6: XFER_REFUSE Reason Codes		Table 6: XFER_REFUSE Reason Codes
	skipping to change at page 25, line 15 ¶		skipping to change at page 26, line 15 ¶
	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		After transmitting a SHUTDOWN message, an node MAY immediately close
	close the associated TCP connection. Once the SHUTDOWN message is		the associated TCP connection. Once the SHUTDOWN message is sent,
	sent, any further received data on the TCP connection SHOULD be		any further received data on the TCP connection SHOULD be ignored.
	ignored. Any delay between request to terminate the TCP connection		Any delay between request to terminate the TCP connection and actual
	and actual closing of the connection (a "half-closed" state) MAY be		closing of the connection (a "half-closed" state) MAY be ignored by
	ignored by the TCPCL endpoint.		the TCPCL node.
	The format of the SHUTDOWN message is as follows:		The format of the SHUTDOWN message is as follows:
	+-----------------------------------+		+-----------------------------------+
	| Message Header |		| Message Header |
	+-----------------------------------+		+-----------------------------------+
	| Message Flags (U8) |		| Message Flags (U8) |
	+-----------------------------------+		+-----------------------------------+
	| Reason Code (optional U8) |		| Reason Code (optional U8) |
	+-----------------------------------+		+-----------------------------------+
	skipping to change at page 25, line 46 ¶		skipping to change at page 26, line 46 ¶
	The fields of the SHUTDOWN message are:		The fields of the SHUTDOWN message are:
	Message Flags: A one-octet field of single-bit flags, interpreted		Message Flags: A one-octet field of single-bit flags, interpreted
	according to the descriptions in Table 7.		according to the descriptions in Table 7.
	Reason Code: A one-octet refusal reason code interpreted according		Reason Code: A one-octet refusal reason code interpreted according
	to the descriptions in Table 8. The Reason Code is present or		to the descriptions in Table 8. The Reason Code is present or
	absent as indicated by one of the flags.		absent as indicated by one of the flags.
	Reconnection Delay: A 16-bit unsigned integer indicating the desired		Reconnection Delay: A 16-bit unsigned integer indicating the desired
	delay until further TCPCL sessions to the sending endpoint. The		delay until further TCPCL sessions to the sending node. The
	Reconnection Delay is present or absent as indicated by one of the		Reconnection Delay is present or absent as indicated by one of the
	flags.		flags.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| D | 0x01 | If bit is set, indicates that a Reconnection |		| D | 0x01 | If bit is set, indicates that a Reconnection |
	| | | Delay field is present. |		| | | Delay field is present. |
	| | | |		| | | |
	| R | 0x02 | If bit is set, indicates that a Reason Code |		| R | 0x02 | If bit is set, indicates that a Reason Code |
	skipping to change at page 26, line 39 ¶		skipping to change at page 27, line 39 ¶
	| | |		| | |
	| Version | The node cannot conform to the specified TCPCL |		| Version | The node cannot conform to the specified TCPCL |
	| mismatch | protocol version. |		| mismatch | protocol version. |
	| | |		| | |
	| Busy | The node is too busy to handle the current |		| Busy | The node is too busy to handle the current |
	| | session. |		| | session. |
	| | |		| | |
	| Contact | The node cannot interpret or negotiate contact |		| Contact | The node cannot interpret or negotiate contact |
	| Failure | header option. |		| Failure | header option. |
	| | |		| | |
	| TLS failure | The node failed to negotiate TLS session and |		| TLS Failure | The node failed to negotiate TLS session and |
	| | cannot continue the session. |		| | cannot continue the session. |
	| | |		| | |
	| Resource | The node has run into some resoure limit and |		| Resource | The node has run into some resoure limit and |
	| Exhaustion | cannot continue the session. |		| Exhaustion | cannot continue the session. |
	+---------------+---------------------------------------------------+		+---------------+---------------------------------------------------+
	Table 8: 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
	skipping to change at page 27, line 26 ¶		skipping to change at page 28, line 26 ¶
	If either node terminates a session prematurely in this manner, it		If either node terminates a session prematurely in this manner, it
	SHOULD send a SHUTDOWN message and MUST indicate a reason code unless		SHOULD send a SHUTDOWN message and MUST indicate a reason code unless
	the incoming connection did not include the magic string. If the		the incoming connection did not include the magic string. If the
	magic string was not present, a node SHOULD close the TCP connection		magic string was not present, a node SHOULD close the TCP connection
	without sending a SHUTDOWN message. If a node does not want its peer		without sending a SHUTDOWN message. If a node does not want its peer
	to reopen a connection immediately, it SHOULD set the 'D' bit in the		to reopen a connection immediately, it SHOULD set the 'D' bit in the
	flags and include a reconnection delay to indicate when the peer is		flags and include a reconnection delay to indicate when the peer is
	allowed to attempt another session setup.		allowed to attempt another session setup.
	If a session is to be terminated before another protocol message has		If a session is to be terminated before a protocol message has
	completed being sent, then the node MUST NOT transmit the SHUTDOWN		completed being sent, then the node MUST NOT transmit the SHUTDOWN
	message but still SHOULD close the TCP connection. This means that a		message but still SHOULD close the TCP connection. Each TCPCL
	SHUTDOWN cannot be used to preempt any other TCPCL messaging in-		message is contiguous in the octet stream and has no ability to be
	progress (particularly important when large segment sizes are being		cut short and/or preempted by an other message. This is particularly
	transmitted).		important when large segment sizes are being transmitted; either
			entire XFER_SEGMENT is sent before a SHUTDOWN message or the
			connection is simply termiated mid-XFER_SEGMENT.
	6.2. Idle Session Shutdown		6.2. Idle Session Shutdown
	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
	skipping to change at page 29, line 25 ¶		skipping to change at page 30, line 31 ¶
	Some of the registries below are created new for TCPCLv4 but share		Some of the registries below are created new for TCPCLv4 but share
	code values with TCPCLv3. This was done to disambiguate the use of		code values with TCPCLv3. This was done to disambiguate the use of
	these values between TCPCLv3 and TCPCLv4 while preserving the		these values between TCPCLv3 and TCPCLv4 while preserving the
	semantics of some values.		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. Each TCPCL endpoint identifies its TCPCL		by protocol version 4. Each TCPCL node identifies its TCPCL protocol
	protocol version in its initial contact (see Section 8.2), so there		version in its initial contact (see Section 8.2), so there is no
	is no ambiguity about what protocol is being used.		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 30, line 33 ¶		skipping to change at page 31, line 38 ¶
	8.3. Header Extension Types		8.3. Header Extension Types
	EDITOR NOTE: sub-registry to-be-created upon publication of this		EDITOR NOTE: sub-registry to-be-created upon publication of this
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	Header Extension Types" and initialized it with the contents of		Header Extension Types" and initialized it with the contents of
	Table 10. The registration procedure is RFC Required within the		Table 10. The registration procedure is RFC Required within the
	lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are		lower range 0x0001--0x3fff. Values in the range 0x8000--0xffff are
	resrved for use on private networks for functions not published to		reserved for use on private networks for functions not published to
	the IANA.		the IANA.
	+----------------+--------------------------+		+----------------+--------------------------+
	| Code | Message Type |		| Code | Message Type |
	+----------------+--------------------------+		+----------------+--------------------------+
	| 0x0000 | Reserved |		| 0x0000 | Reserved |
	| | |		| | |
	| 0x0001--0x3fff | Unassigned |		| 0x0001--0x3fff | Unassigned |
	| | |		| | |
	| 0x8000--0xffff | Private/Experimental Use |		| 0x8000--0xffff | Private/Experimental Use |
	skipping to change at page 33, line 40 ¶		skipping to change at page 34, line 40 ¶
	9. Acknowledgments		9. Acknowledgments
	This memo is based on comments on implementation of [RFC7242]		This memo is based on comments on implementation of [RFC7242]
	provided from Scott Burleigh.		provided from Scott Burleigh.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-dtn-bpbis]
			Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
			draft-ietf-dtn-bpbis-08 (work in progress), August 2017.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol		[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
	Specification", RFC 5050, DOI 10.17487/RFC5050, November		Specification", RFC 5050, DOI 10.17487/RFC5050, November
	2007, <http://www.rfc-editor.org/info/rfc5050>.		2007, <https://www.rfc-editor.org/info/rfc5050>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<https://www.rfc-editor.org/info/rfc5226>.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<http://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May		(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
	2015, <http://www.rfc-editor.org/info/rfc7525>.		2015, <https://www.rfc-editor.org/info/rfc7525>.
	[I-D.ietf-dtn-bpbis]
	Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol",
	draft-ietf-dtn-bpbis-06 (work in progress), October 2016.
	[refs.IANA-BP]
	IANA, "Bundle Protocol registry", May 2016.
	10.2. Informative References		10.2. Informative References
			[I-D.ietf-dtn-bpsec]
			Birrane, E. and K. McKeever, "Bundle Protocol Security
			Specification", draft-ietf-dtn-bpsec-06 (work in
			progress), October 2017.
	[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",		[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, DOI 10.17487/RFC2595, June 1999,		RFC 2595, DOI 10.17487/RFC2595, June 1999,
	<http://www.rfc-editor.org/info/rfc2595>.		<https://www.rfc-editor.org/info/rfc2595>.
	[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,		[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
	R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant		R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
	Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,		Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
	April 2007, <http://www.rfc-editor.org/info/rfc4838>.		April 2007, <https://www.rfc-editor.org/info/rfc4838>.
	[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,		[RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell,
	"Bundle Security Protocol Specification", RFC 6257,		"Bundle Security Protocol Specification", RFC 6257,
	DOI 10.17487/RFC6257, May 2011,		DOI 10.17487/RFC6257, May 2011,
	<http://www.rfc-editor.org/info/rfc6257>.		<https://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>.		<https://www.rfc-editor.org/info/rfc7242>.
	[I-D.ietf-dtn-bpsec]
	Birrane, E. and K. McKeever, "Bundle Protocol Security
	Specification", draft-ietf-dtn-bpsec-04 (work in
	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
	headers and 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
End of changes. 70 change blocks.
	235 lines changed or deleted		265 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/