draft-ietf-dtn-tcpclv4-11.txt		draft-ietf-dtn-tcpclv4-12.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: September 1, 2019 J. Ott		Expires: October 2, 2019 J. Ott
	Aalto University		Aalto University
	S. Perreault		S. Perreault
	February 28, 2019		March 31, 2019
	Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4		Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
	draft-ietf-dtn-tcpclv4-11		draft-ietf-dtn-tcpclv4-12
	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 of RFC7242 and updates to the Bundle Protocol		TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
	contents, encodings, and convergence layer requirements in Bundle		contents, encodings, and convergence layer requirements in Bundle
	Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7		Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7
	bundles as its service data unit being transported and provides a		bundles as its service data unit being transported and provides a
	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 September 1, 2019.		This Internet-Draft will expire on October 2, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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 42 ¶		skipping to change at page 2, line 42 ¶
	4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 22		4.4.2. Example TLS Initiation . . . . . . . . . . . . . . . 22
	4.5. Message Type Codes . . . . . . . . . . . . . . . . . . . 23		4.5. Message Type Codes . . . . . . . . . . . . . . . . . . . 23
	4.6. Session Initialization Message (SESS_INIT) . . . . . . . 24		4.6. Session Initialization Message (SESS_INIT) . . . . . . . 24
	4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 26		4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 26
	4.8. Session Extension Items . . . . . . . . . . . . . . . . . 27		4.8. Session Extension Items . . . . . . . . . . . . . . . . . 27
	5. Established Session Operation . . . . . . . . . . . . . . . . 28		5. Established Session Operation . . . . . . . . . . . . . . . . 28
	5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 28		5.1. Upkeep and Status Messages . . . . . . . . . . . . . . . 28
	5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28		5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28
	5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29		5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29
	5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30		5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30
	5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 31		5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 30
	5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 31		5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 31
	5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 33		5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 33
	5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 34		5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 34
	5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 37		5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 36
	6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38		6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38
	6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 39		6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38
	6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 41		6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 40
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 40
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 42		8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
	9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43		9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 42
	9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 44		9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43
	9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44		9.3. Session Extension Types . . . . . . . . . . . . . . . . . 43
	9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 45		9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44
	9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 46		9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45
	9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46		9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 45
	9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47		9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 46
	9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48		9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 47
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
	11.1. Normative References . . . . . . . . . . . . . . . . . . 49		11.1. Normative References . . . . . . . . . . . . . . . . . . 48
	11.2. Informative References . . . . . . . . . . . . . . . . . 50		11.2. Informative References . . . . . . . . . . . . . . . . . 49
	Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50		Appendix A. Significant changes from RFC7242 . . . . . . . . . . 49
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
	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 20, line 23 ¶		skipping to change at page 20, line 23 ¶
	+---------------+---------------+		+---------------+---------------+
	Figure 14: Contact Header Format		Figure 14: Contact Header Format
	See Section 4.3 for details on the use of each of these contact		See Section 4.3 for details on the use of each of these contact
	header fields.		header fields.
	The fields of the contact header are:		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.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	skipping to change at page 24, line 5 ¶		skipping to change at page 24, line 5 ¶
	| Message Type |		| Message Type |
	+---------------+		+---------------+
	Figure 16: Format of the Message Header		Figure 16: 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 2		Message Type: Indicates the type of the message as per Table 2
	below. Encoded values are listed in Section 9.5.		below. Encoded values are listed in Section 9.5.
	+--------------+----------------------------------------------------+		+--------------+------+---------------------------------------------+
	| Type | Description |		| Name | Code | Description |
	+--------------+----------------------------------------------------+		+--------------+------+---------------------------------------------+
	| SESS_INIT | Contains the session parameter inputs from one of |		| SESS_INIT | 0x07 | Contains the session parameter inputs from |
	| | the entities, as described in Section 4.6. |		| | | one of the entities, as described in |
	| | |		| | | Section 4.6. |
	| XFER_SEGMENT | Indicates the transmission of a segment of bundle |		| | | |
	| | data, as described in Section 5.2.2. |		| SESS_TERM | 0x05 | Indicates that one of the entities |
	| | |		| | | participating in the session wishes to |
	| XFER_ACK | Acknowledges reception of a data segment, as |		| | | cleanly terminate the session, as described |
	| | described in Section 5.2.3. |		| | | in Section 6. |
	| | |		| | | |
	| XFER_REFUSE | Indicates that the transmission of the current |		| XFER_SEGMENT | 0x01 | Indicates the transmission of a segment of |
	| | bundle SHALL be stopped, as described in Section |		| | | bundle data, as described in Section 5.2.2. |
	| | 5.2.4. |		| | | |
	| | |		| XFER_ACK | 0x02 | Acknowledges reception of a data segment, |
	| KEEPALIVE | Used to keep TCPCL session active, as described in |		| | | as described in Section 5.2.3. |
	| | Section 5.1.1. |		| | | |
	| | |		| XFER_REFUSE | 0x03 | Indicates that the transmission of the |
	| SESS_TERM | Indicates that one of the entities participating |		| | | current bundle SHALL be stopped, as |
	| | in the session wishes to cleanly terminate the |		| | | described in Section 5.2.4. |
	| | session, as described in Section 6. |		| | | |
	| | |		| KEEPALIVE | 0x04 | Used to keep TCPCL session active, as |
	| MSG_REJECT | Contains a TCPCL message rejection, as described |		| | | described in Section 5.1.1. |
	| | in Section 5.1.2. |		| | | |
	+--------------+----------------------------------------------------+		| MSG_REJECT | 0x06 | Contains a TCPCL message rejection, as |
			| | | described in Section 5.1.2. |
			+--------------+------+---------------------------------------------+
	Table 2: TCPCL Message Types		Table 2: TCPCL Message Types
	4.6. Session Initialization Message (SESS_INIT)		4.6. Session Initialization Message (SESS_INIT)
	Before a session is established and ready to transfer bundles, the		Before a session is established and ready to transfer bundles, the
	session parameters are negotiated between the connected entities.		session parameters are negotiated between the connected entities.
	The SESS_INIT message is used to convey the per-entity parameters		The SESS_INIT message is used to convey the per-entity parameters
	which are used together to negotiate the per-session parameters as		which are used together to negotiate the per-session parameters as
	described in Section 4.7.		described in Section 4.7.
	The format of a SESS_INIT message is as follows in Figure 17.		The format of a SESS_INIT message is as follows in Figure 17.
	+-------------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-------------------------------+		+-----------------------------+
	| Keepalive Interval (U16) |		| Keepalive Interval (U16) |
	+-------------------------------+		+-----------------------------+
	| Segment MRU (U64) |		| Segment MRU (U64) |
	+-------------------------------+		+-----------------------------+
	| Transfer MRU (U64) |		| Transfer MRU (U64) |
	+-------------------------------+		+-----------------------------+
	| EID Length (U16) |		| EID Length (U16) |
	+-------------------------------+		+-----------------------------+
	| EID Data (variable) |		| EID Data (variable) |
	+-------------------------------+		+-----------------------------+
	| Session Extension Length (U32)|		| Session Extension |
	+-------------------------------+		| Items Length (U32) |
	| Session Extension Items (var.)|		+-----------------------------+
	+-------------------------------+		| Session Extension |
			| Items (var.) |
			+-----------------------------+
	Figure 17: SESS_INIT Format		Figure 17: SESS_INIT Format
	The fields of the SESS_INIT message are:		The fields of the SESS_INIT message are:
	Keepalive Interval: A 16-bit unsigned integer indicating the		Keepalive Interval: A 16-bit unsigned integer indicating the
	interval, in seconds, between any subsequent messages being		interval, in seconds, between any subsequent messages being
	transmitted by the peer. The peer receiving this contact header		transmitted by the peer. The peer receiving this contact header
	uses this interval to determine how long to wait after any last-		uses this interval to determine how long to wait after any last-
	message transmission and a necessary subsequent KEEPALIVE message		message transmission and a necessary subsequent KEEPALIVE message
	skipping to change at page 27, line 36 ¶		skipping to change at page 27, line 38 ¶
	flag set, the entity SHALL close the TCPCL session with SESS_TERM		flag set, the entity SHALL close the TCPCL session with SESS_TERM
	reason code of "Contact Failure". If the CRITICAL flag is not		reason code of "Contact Failure". If the CRITICAL flag is not
	set, an entity SHALL skip over and ignore any item with an unknown		set, an entity SHALL skip over and ignore any item with an unknown
	Item Type.		Item 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. This specification does not define any		the extension item. This specification does not define any
	extension types directly, but does allocate an IANA registry for		extension types directly, but does allocate an IANA registry for
	such codes (see Section 9.3).		such codes (see Section 9.3).
	Item Length: A 32-bit unsigned integer field containing the number		Item Length: A 16-bit unsigned integer field containing the number
	of Item Value octets to follow.		of Item Value octets to follow.
	Item Value: A variable-length data field which is interpreted		Item Value: A variable-length data field which is interpreted
	according to the associated Item Type. This specification places		according to the associated Item Type. This specification places
	no restrictions on an extension's use of available Item Value		no restrictions on an extension's use of available Item Value
	data. Extension specifications SHOULD avoid the use of large data		data. Extension specifications SHOULD avoid the use of large data
	lengths, as no bundle transfers can begin until the full extension		lengths, as no bundle transfers can begin until the full extension
	data is sent.		data is sent.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Item Flags | Item Type | Item Length...|		| Item Flags | Item Type | Item Length...|
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| length contd. | Item Value... |		| length contd. | Item Value... |
	+---------------+---------------+---------------+---------------+
	| value contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 18: Session Extension Item Format		Figure 18: Session Extension Item Format
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| CRITICAL | 0x01 | If bit is set, indicates that the receiving |		| CRITICAL | 0x01 | If bit is set, indicates that the receiving |
	| | | peer must handle the extension item. |		| | | peer must handle the extension item. |
	| | | |		| | | |
	skipping to change at page 29, line 24 ¶		skipping to change at page 29, line 22 ¶
	KEEPALIVE (as described in Table 2) with no additional data. Both		KEEPALIVE (as described in Table 2) with no additional data. Both
	sides SHALL send a KEEPALIVE message whenever the negotiated interval		sides SHALL send a KEEPALIVE message whenever the negotiated interval
	has elapsed with no transmission of any message (KEEPALIVE or other).		has elapsed with no transmission of any message (KEEPALIVE 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 SHALL		after some implementation-defined time duration, then the node SHALL
	terminate the session by transmitting a SESS_TERM message (as		terminate the session by transmitting a SESS_TERM message (as
	described in Section 6.1) with reason code "Idle Timeout". If		described in Section 6.1) with reason code "Idle Timeout". If
	configurable, the idle timeout duration SHOULD be no shorter than		configurable, the idle timeout duration SHOULD be no shorter than
	twice the keepalive interval. If not configurable, the idle timeout		twice the keepalive interval. If not configurable, the idle timeout
	duration SHOULD be exactly twice the keepout interval.		duration SHOULD be exactly twice the keepalive interval.
	5.1.2. Message Rejection (MSG_REJECT)		5.1.2. Message Rejection (MSG_REJECT)
	If a TCPCL node receives a message which is unknown to it (possibly		If a TCPCL node receives a message which is unknown to it (possibly
	due to an unhandled protocol mismatch) or is inappropriate for the		due to an unhandled protocol mismatch) or is inappropriate for the
	current session state (e.g. a KEEPALIVE message received after		current session state (e.g. a KEEPALIVE message received after
	contact header negotiation has disabled that feature), there is a		contact header negotiation has disabled that feature), there is 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.
	skipping to change at page 32, line 13 ¶		skipping to change at page 31, line 34 ¶
	of a XFER_SEGMENT message follows in Figure 20.		of a XFER_SEGMENT message follows in Figure 20.
	+------------------------------+		+------------------------------+
	| Message Header |		| Message Header |
	+------------------------------+		+------------------------------+
	| Message Flags (U8) |		| Message Flags (U8) |
	+------------------------------+		+------------------------------+
	| Transfer ID (U64) |		| Transfer ID (U64) |
	+------------------------------+		+------------------------------+
	| Transfer Extension |		| Transfer Extension |
	| Length (U32) |		| Items Length (U32) |
	| (only for START segment) |		| (only for START segment) |
	+------------------------------+		+------------------------------+
	| Transfer Extension |		| Transfer Extension |
	| Items (var.) |		| Items (var.) |
	| (only for START segment) |		| (only for START segment) |
	+------------------------------+		+------------------------------+
	| Data length (U64) |		| Data length (U64) |
	+------------------------------+		+------------------------------+
	| Data contents (octet string) |		| Data contents (octet string) |
	+------------------------------+		+------------------------------+
	skipping to change at page 36, line 5 ¶		skipping to change at page 35, line 8 ¶
	Figure 22: Format of XFER_REFUSE Messages		Figure 22: 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 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 | Code | Description |
	+------------+------------------------------------------------------+		+------------+------+-----------------------------------------------+
	| Unknown | Reason for refusal is unknown or not specified. |		| Unknown | 0x00 | Reason for refusal is unknown or not |
	| | |		| | | specified. |
	| Extension | A failure processing the Transfer Extension Items ha |		| | | |
	| Failure | occurred. |		| Extension | 0x01 | A failure processing the Transfer Extension |
	| | |		| Failure | | Items ha occurred. |
	| Completed | The receiver already has the complete bundle. The |		| | | |
	| | sender MAY consider the bundle as completely |		| Completed | 0x02 | The receiver already has the complete bundle. |
	| | received. |		| | | The sender MAY consider the bundle as |
	| | |		| | | completely received. |
	| No | The receiver's resources are exhausted. The sender |		| | | |
	| Resources | SHOULD apply reactive bundle fragmentation before |		| No | 0x03 | The receiver's resources are exhausted. The |
	| | retrying. |		| Resources | | sender SHOULD apply reactive bundle |
	| | |		| | | fragmentation before retrying. |
	| Retransmit | The receiver has encountered a problem that requires |		| | | |
	| | the bundle to be retransmitted in its entirety. |		| Retransmit | 0x04 | The receiver has encountered a problem that |
	+------------+------------------------------------------------------+		| | | requires the bundle to be retransmitted in |
			| | | its entirety. |
			+------------+------+-----------------------------------------------+
	Table 6: XFER_REFUSE Reason Codes		Table 6: XFER_REFUSE Reason Codes
	The receiver MUST, for each transfer preceding the one to be refused,		The receiver MUST, for each transfer preceding the one to be refused,
	have either acknowledged all 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
	skipping to change at page 37, line 24 ¶		skipping to change at page 36, line 24 ¶
	Transfer Extension Item with an unknown Item Type and the CRITICAL		Transfer Extension Item with an unknown Item Type and the CRITICAL
	flag set, the node SHALL refuse the transfer with an XFER_REFUSE		flag set, the node SHALL refuse the transfer with an XFER_REFUSE
	reason code of "Extension Failure". If the CRITICAL flag is not		reason code of "Extension Failure". If the CRITICAL flag is not
	set, an entity SHALL skip over and ignore any item with an unknown		set, an entity SHALL skip over and ignore any item with an unknown
	Item Type.		Item 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. This specification allocates an IANA registry		the extension item. This specification allocates an IANA registry
	for such codes (see Section 9.4).		for such codes (see Section 9.4).
	Item Length: A 32-bit unsigned integer field containing the number		Item Length: A 16-bit unsigned integer field containing the number
	of Item Value octets to follow.		of Item Value octets to follow.
	Item Value: A variable-length data field which is interpreted		Item Value: A variable-length data field which is interpreted
	according to the associated Item Type. This specification places		according to the associated Item Type. This specification places
	no restrictions on an extension's use of available Item Value		no restrictions on an extension's use of available Item Value
	data. Extension specifications SHOULD avoid the use of large data		data. Extension specifications SHOULD avoid the use of large data
	lengths, as the associated transfer cannot begin until the full		lengths, as the associated transfer cannot begin until the full
	extension data is sent.		extension data is sent.
	1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3		1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| Item Flags | Item Type | Item Length...|		| Item Flags | Item Type | Item Length...|
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	| length contd. | Item Value... |		| length contd. | Item Value... |
	+---------------+---------------+---------------+---------------+
	| value contd. |
	+---------------+---------------+---------------+---------------+		+---------------+---------------+---------------+---------------+
	Figure 23: Transfer Extension Item Format		Figure 23: Transfer Extension Item Format
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| CRITICAL | 0x01 | If bit is set, indicates that the receiving |		| CRITICAL | 0x01 | If bit is set, indicates that the receiving |
	| | | peer must handle the extension item. |		| | | peer must handle the extension item. |
	| | | |		| | | |
	skipping to change at page 38, line 22 ¶		skipping to change at page 37, line 22 ¶
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	Table 7: Transfer Extension Item Flags		Table 7: Transfer Extension Item Flags
	5.2.5.1. Transfer Length Extension		5.2.5.1. Transfer Length Extension
	The purpose of the Transfer Length extension is to allow entities to		The purpose of the Transfer Length extension is to allow entities 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.
	Multiple Transfer Length extension items SHALL NOT occurr within the		Multiple Transfer Length extension items SHALL NOT occur within the
	same transfer. The lack of a Transfer Length extension item in any		same transfer. The lack of a Transfer Length extension item in any
	transfer SHALL NOT imply anything about the potential length of the		transfer SHALL NOT imply anything about the potential length of the
	transfer. The Transfer Length extension SHALL be assigned transfer		transfer. The Transfer Length extension SHALL be assigned transfer
	extension type ID 0x0001.		extension type ID 0x0001.
			If a transfer occupies exactly one segment (i.e. both START and END
			bits are set) the Transfer Length extension SHOULD NOT be present.
			The extension does not provide any additional information for single-
			segment transfers.
	The format of the Transfer Length data is as follows in Figure 24.		The format of the Transfer Length data is as follows in Figure 24.
	+----------------------+		+----------------------+
	| Total Length (U64) |		| Total Length (U64) |
	+----------------------+		+----------------------+
	Figure 24: Format of Transfer Length data		Figure 24: Format of Transfer Length data
	The fields of the Transfer Length extension are:		The fields of the Transfer Length extension are:
	skipping to change at page 40, line 20 ¶		skipping to change at page 39, line 25 ¶
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| REPLY | 0x01 | If bit is set, indicates that this message is |		| REPLY | 0x01 | If bit is set, indicates that this message is |
	| | | an acknowledgement of an earlier SESS_TERM |		| | | an acknowledgement of an earlier SESS_TERM |
	| | | message. |		| | | message. |
	| | | |		| | | |
	| Reserved | others |		| Reserved | others |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	Table 8: SESS_TERM Flags		Table 8: SESS_TERM Flags
	+---------------+---------------------------------------------------+		+--------------+------+---------------------------------------------+
	| Name | Description |		| Name | Code | Description |
	+---------------+---------------------------------------------------+		+--------------+------+---------------------------------------------+
	| Unknown | A termination reason is not available. |		| Unknown | 0x00 | A termination reason is not available. |
	| | |		| | | |
	| Idle timeout | The session is being closed due to idleness. |		| Idle timeout | 0x01 | The session is being closed due to |
	| | |		| | | idleness. |
	| Version | The node cannot conform to the specified TCPCL |		| | | |
	| mismatch | protocol version. |		| Version | 0x02 | The node cannot conform to the specified |
	| | |		| mismatch | | TCPCL protocol version. |
	| Busy | The node is too busy to handle the current |		| | | |
	| | session. |		| Busy | 0x03 | The node is too busy to handle the current |
	| | |		| | | session. |
	| Contact | The node cannot interpret or negotiate contact |		| | | |
	| Failure | header option. |		| Contact | 0x04 | The node cannot interpret or negotiate |
	| | |		| Failure | | contact header option. |
	| Resource | The node has run into some resource limit and |		| | | |
	| Exhaustion | cannot continue the session. |		| Resource | 0x05 | The node has run into some resource limit |
	+---------------+---------------------------------------------------+		| Exhaustion | | and cannot continue the session. |
			+--------------+------+---------------------------------------------+
	Table 9: SESS_TERM Reason Codes		Table 9: SESS_TERM Reason Codes
	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
	MAY, for example, be used to notify that the node is currently not		MAY, for example, be used to notify that the node is currently not
	able or willing to communicate. However, an entity MUST always send		able or willing to communicate. However, an entity MUST always send
	the contact header to its peer before sending a SESS_TERM message.		the contact header to its peer before sending a SESS_TERM message.
	If reception of the contact header itself somehow fails (e.g. an		If reception of the contact header itself somehow fails (e.g. an
	skipping to change at page 44, line 41 ¶		skipping to change at page 43, line 41 ¶
	| Value | Description | Reference |		| Value | Description | Reference |
	+-------+-------------+---------------------+		+-------+-------------+---------------------+
	| 0 | Reserved | [RFC7242] |		| 0 | Reserved | [RFC7242] |
	| | | |		| | | |
	| 1 | Reserved | [RFC7242] |		| 1 | Reserved | [RFC7242] |
	| | | |		| | | |
	| 2 | Reserved | [RFC7242] |		| 2 | Reserved | [RFC7242] |
	| | | |		| | | |
	| 3 | TCPCL | [RFC7242] |		| 3 | TCPCL | [RFC7242] |
	| | | |		| | | |
	| 4 | TCPCLbis | This specification. |		| 4 | TCPCLv4 | This specification. |
	| | | |		| | | |
	| 5-255 | Unassigned |		| 5-255 | Unassigned |
	+-------+-------------+---------------------+		+-------+-------------+---------------------+
	9.3. Session Extension Types		9.3. Session 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
	Session Extension Types" and initialize it with the contents of		Session Extension Types" and initialize it with the contents of
	Table 11. The registration procedure is RFC Required within the		Table 11. The registration procedure is RFC Required within the
	lower range 0x0001--0x7fff. Values in the range 0x8000--0xffff are		lower range 0x0001--0x7FFF. 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 | Session Extension Type |
	+----------------+--------------------------+		+----------------+--------------------------+
	| 0x0000 | Reserved |		| 0x0000 | Reserved |
	| | |		| | |
	| 0x0001--0x7fff | Unassigned |		| 0x0001--0x7FFF | Unassigned |
	| | |		| | |
	| 0x8000--0xffff | Private/Experimental Use |		| 0x8000--0xFFFF | Private/Experimental Use |
	+----------------+--------------------------+		+----------------+--------------------------+
	Table 11: Session Extension Type Codes		Table 11: Session Extension Type Codes
	9.4. Transfer Extension Types		9.4. Transfer 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
	Transfer Extension Types" and initialize it with the contents of		Transfer Extension Types" and initialize it with the contents of
	Table 12. The registration procedure is RFC Required within the		Table 12. The registration procedure is RFC Required within the
	lower range 0x0001--0x7fff. Values in the range 0x8000--0xffff are		lower range 0x0001--0x7FFF. 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 | Transfer Extension Type |
	+----------------+---------------------------+		+----------------+---------------------------+
	| 0x0000 | Reserved |		| 0x0000 | Reserved |
	| | |		| | |
	| 0x0001 | Transfer Length Extension |		| 0x0001 | Transfer Length Extension |
	| | |		| | |
	| 0x0002--0x7fff | Unassigned |		| 0x0002--0x7FFF | Unassigned |
	| | |		| | |
	| 0x8000--0xffff | Private/Experimental Use |		| 0x8000--0xFFFF | Private/Experimental Use |
	+----------------+---------------------------+		+----------------+---------------------------+
	Table 12: Transfer Extension Type Codes		Table 12: Transfer Extension Type Codes
	9.5. Message Types		9.5. 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-
	skipping to change at page 46, line 32 ¶		skipping to change at page 45, line 32 ¶
	| 0x02 | XFER_ACK |		| 0x02 | XFER_ACK |
	| | |		| | |
	| 0x03 | XFER_REFUSE |		| 0x03 | XFER_REFUSE |
	| | |		| | |
	| 0x04 | KEEPALIVE |		| 0x04 | KEEPALIVE |
	| | |		| | |
	| 0x05 | SESS_TERM |		| 0x05 | SESS_TERM |
	| | |		| | |
	| 0x06 | MSG_REJECT |		| 0x06 | MSG_REJECT |
	| | |		| | |
	| 0x07--0xf | Unassigned |		| 0x07 | SESS_INIT |
			| | |
			| 0x08--0xf | Unassigned |
	+-----------+--------------+		+-----------+--------------+
	Table 13: Message Type Codes		Table 13: Message Type Codes
	9.6. XFER_REFUSE Reason Codes		9.6. 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 14. The registration procedure is RFC Required.		Table 14. The registration procedure is RFC Required.
	+----------+---------------------------+		+------------+---------------------------+
	| Code | Refusal Reason |		| Code | Refusal Reason |
	+----------+---------------------------+		+------------+---------------------------+
	| 0x0 | Unknown |		| 0x00 | Unknown |
	| | |		| | |
	| 0x1 | Extension Failure |		| 0x01 | Extension Failure |
	| | |		| | |
	| 0x2 | Completed |		| 0x02 | Completed |
	| | |		| | |
	| 0x3 | No Resources |		| 0x03 | No Resources |
	| | |		| | |
	| 0x4 | Retransmit |		| 0x04 | Retransmit |
	| | |		| | |
	| 0x5--0x7 | Unassigned |		| 0x05--0x07 | Unassigned |
	| | |		| | |
	| 0x8--0xf | Reserved for future usage |		| 0x08--0xFF | Reserved for future usage |
	+----------+---------------------------+		+------------+---------------------------+
	Table 14: XFER_REFUSE Reason Codes		Table 14: XFER_REFUSE Reason Codes
	9.7. SESS_TERM Reason Codes		9.7. SESS_TERM 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
	SESS_TERM Reason Codes" and initialize it with the contents of		SESS_TERM Reason Codes" and initialize it with the contents of
	Table 15. The registration procedure is RFC Required.		Table 15. The registration procedure is RFC Required.
	+------------+---------------------+		+------------+---------------------+
	| Code | Shutdown Reason |		| Code | Termination Reason |
	+------------+---------------------+		+------------+---------------------+
	| 0x00 | Unknown |		| 0x00 | Unknown |
	| | |		| | |
	| 0x01 | Idle timeout |		| 0x01 | Idle timeout |
	| | |		| | |
	| 0x02 | Version mismatch |		| 0x02 | Version mismatch |
	| | |		| | |
	| 0x03 | Busy |		| 0x03 | Busy |
	| | |		| | |
	| 0x04 | Contact Failure |		| 0x04 | Contact Failure |
	skipping to change at page 48, line 49 ¶		skipping to change at page 47, line 49 ¶
	| | |		| | |
	| 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 16: REJECT Reason Codes		Table 16: MSG_REJECT Reason Codes
	10. Acknowledgments		10. 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.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	skipping to change at page 52, line 29 ¶		skipping to change at page 51, line 29 ¶
	Email: demmer@cs.berkeley.edu		Email: demmer@cs.berkeley.edu
	Joerg Ott		Joerg Ott
	Aalto University		Aalto University
	Department of Communications and Networking		Department of Communications and Networking
	PO Box 13000		PO Box 13000
	Aalto 02015		Aalto 02015
	Finland		Finland
	Email: jo@netlab.tkk.fi		Email: ott@in.tum.de
	Simon Perreault		Simon Perreault
	Quebec, QC		Quebec, QC
	Canada		Canada
	Email: simon@per.reau.lt		Email: simon@per.reau.lt
End of changes. 34 change blocks.
	148 lines changed or deleted		158 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/