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