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/