draft-ietf-dtn-tcpclv4-10.txt   draft-ietf-dtn-tcpclv4-11.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: May 9, 2019 J. Ott Expires: September 1, 2019 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
November 5, 2018 February 28, 2019
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-10 draft-ietf-dtn-tcpclv4-11
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 May 9, 2019. This Internet-Draft will expire on September 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 35 skipping to change at page 2, line 35
3.4. Example Message Exchange . . . . . . . . . . . . . . . . 17 3.4. Example Message Exchange . . . . . . . . . . . . . . . . 17
4. Session Establishment . . . . . . . . . . . . . . . . . . . . 19 4. Session Establishment . . . . . . . . . . . . . . . . . . . . 19
4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 19 4.1. TCP Connection . . . . . . . . . . . . . . . . . . . . . 19
4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 19 4.2. Contact Header . . . . . . . . . . . . . . . . . . . . . 19
4.3. Contact Validation and Negotiation . . . . . . . . . . . 20 4.3. Contact Validation and Negotiation . . . . . . . . . . . 20
4.4. Session Security . . . . . . . . . . . . . . . . . . . . 21 4.4. Session Security . . . . . . . . . . . . . . . . . . . . 21
4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 22 4.4.1. TLS Handshake Result . . . . . . . . . . . . . . . . 22
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.6.1. Session Extension Items . . . . . . . . . . . . . . . 26 4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 26
4.7. Session Parameter Negotiation . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 30 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 31
5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 31 5.2.2. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 31
5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 34 5.2.3. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 33
5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 35 5.2.4. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 34
5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 36 5.2.5. Transfer Extension Items . . . . . . . . . . . . . . 37
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 39
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 41 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 41
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 44
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 45
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 46
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Normative References . . . . . . . . . . . . . . . . . . 49 11.1. Normative References . . . . . . . . . . . . . . . . . . 49
11.2. Informative References . . . . . . . . . . . . . . . . . 49 11.2. Informative References . . . . . . . . . . . . . . . . . 50
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
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 entity rejects the bundle or when a TCPCL session ends before peer entity 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 Initialized The TCPCL supports indication to the reciver Reception Initialized The TCPCL supports indication to the reciver
just before any transmssion data is sent. This corresponds to just before any transmssion data is sent. This corresponds to
reception of the XFER_INIT message. reception of the XFER_SEGMENT message with the START flag set.
Interrupt Reception 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). Interruption can occur any time after the reception is not). Interruption can occur any time after the reception is
initialized. initialized.
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 entity. bundle has been fully transferred from a peer entity.
Reception Intermediate Progress The TCPCL supports positive Reception Intermediate Progress The TCPCL supports positive
skipping to change at page 10, line 11 skipping to change at page 10, line 11
Once negotiated, the parameters of a TCPCL session cannot change and Once negotiated, the parameters of a TCPCL session cannot change and
if there is a desire by either peer to transfer data under different if there is a desire by either peer to transfer data under different
parameters then a new session must be established. This makes CL parameters then a new session must be established. This makes CL
logic simpler but relies on the assumption that establishing a TCP logic simpler but relies on the assumption that establishing a TCP
connection is lightweight enough that TCP connection overhead is connection is lightweight enough that TCP connection overhead is
negligable compared to TCPCL data sizes. negligable compared to TCPCL data sizes.
Once the TCPCL session is established and configured in this way, Once the TCPCL session is established and configured in this way,
bundles can be transferred in either direction. Each transfer is bundles can be transferred in either direction. Each transfer is
performed by an initialization (XFER_INIT) message followed by one or performed by an sequence of logical segments of data within
more logical segments of data within an XFER_SEGMENT message. XFER_SEGMENT messages. Multiple bundles can be transmitted
Multiple bundles can be transmitted consecutively on a single TCPCL consecutively in a single direction on a single TCPCL connection.
connection. Segments from different bundles are never interleaved. Segments from different bundles are never interleaved. Bundle
Bundle interleaving can be accomplished by fragmentation at the BP interleaving can be accomplished by fragmentation at the BP layer or
layer or by establishing multiple TCPCL sessions between the same by establishing multiple TCPCL sessions between the same peers.
peers.
A feature of this protocol is for the receiving node to send A feature of this protocol is for the receiving node to send
acknowledgment (XFER_ACK) messages as bundle data segments arrive . acknowledgment (XFER_ACK) messages as bundle data segments arrive.
The rationale behind these acknowledgments is to enable the sender The rationale behind these acknowledgments is to enable the sender
node to determine how much of the bundle has been received, so that node to determine how much of the bundle has been received, so that
in case the session is interrupted, it can perform reactive in case the session is interrupted, it can perform reactive
fragmentation to avoid re-sending the already transmitted part of the fragmentation to avoid re-sending the already transmitted part of the
bundle. In addition, there is no explicit flow control on the TCPCL bundle. In addition, there is no explicit flow control on the TCPCL
layer. layer.
A TCPCL receiver can interrupt the transmission of a bundle at any A TCPCL receiver can interrupt the transmission of a bundle at any
point in time by replying with a XFER_REFUSE message, which causes point in time by replying with a XFER_REFUSE message, which causes
the sender to stop transmission of the associated bundle (if it the sender to stop transmission of the associated bundle (if it
skipping to change at page 15, line 37 skipping to change at page 15, line 37
V V
[SESSTERM] [SESSTERM]
Figure 10: Processing of Session Initiation (PSI) Figure 10: Processing of Session Initiation (PSI)
Transfers can occur after a session is established and it's not in Transfers can occur after a session is established and it's not in
the ending state. Each transfer occurs within a single logical the ending state. Each transfer occurs within a single logical
transfer stream between a sender and a receiver, as illustrated in transfer stream between a sender and a receiver, as illustrated in
Figure 11 and Figure 12 respectively. Figure 11 and Figure 12 respectively.
+--Send XFER_DATA--+ +--Send XFER_SEGMENT--+
+--------+ | | +--------+ | |
| Stream | +-------------+ | | Stream | +-------------+ |
| Idle |---Send XFER_INIT-->| In Progress |<---------+ | Idle |---Send XFER_SEGMENT-->| In Progress |<------------+
+--------+ +-------------+ +--------+ +-------------+
| |
+------All segments sent-------+ +---------All segments sent-------+
| |
V V
+---------+ +--------+ +---------+ +--------+
| Waiting |---- Receive Final---->| Stream | | Waiting |---- Receive Final---->| Stream |
| for Ack | Ack | IDLE | | for Ack | XFER_ACK | IDLE |
+---------+ +--------+ +---------+ +--------+
Figure 11: Transfer sender states Figure 11: Transfer sender states
Notes on transfer sending: Notes on transfer sending:
Pipelining of transfers can occur when the sending entity begins a Pipelining of transfers can occur when the sending entity begins a
new transfer while in the "Waiting for Ack" state. new transfer while in the "Waiting for Ack" state.
+-Receive XFER_DATA-+ +-Receive XFER_SEGMENT-+
+--------+ | Send Ack | +--------+ | Send XFER_ACK |
| Stream | +-------------+ | | Stream | +-------------+ |
| IDLE |--Receive XFER_INIT-->| In Progress |<----------+ | IDLE |--Receive XFER_SEGMENT-->| In Progress |<-------------+
+--------+ +-------------+ +--------+ +-------------+
| |
+---------Sent Final Ack---------+ +--------Sent Final XFER_ACK--------+
| |
V V
+--------+ +--------+
| Stream | | Stream |
| IDLE | | IDLE |
+--------+ +--------+
Figure 12: Transfer receiver states Figure 12: Transfer receiver states
3.3. Transfer Segmentation Policies 3.3. Transfer Segmentation Policies
skipping to change at page 17, line 31 skipping to change at page 17, line 31
and transfer extension types can apply further nuance to transfer and transfer extension types can apply further nuance to transfer
policies and policy negotiation. policies and policy negotiation.
3.4. Example Message Exchange 3.4. Example Message Exchange
The following figure depicts the protocol exchange for a simple The following figure depicts the protocol exchange for a simple
session, showing the session establishment and the transmission of a session, showing the session establishment and the transmission of a
single bundle split into three data segments (of lengths "L1", "L2", single bundle split into three data segments (of lengths "L1", "L2",
and "L3") from Entity A to Entity B. and "L3") from Entity A to Entity B.
Note that the sending node MAY transmit multiple XFER_SEGMENT Note that the sending node can transmit multiple XFER_SEGMENT
messages without necessarily waiting for the corresponding XFER_ACK messages without waiting for the corresponding XFER_ACK responses.
responses. This enables pipelining of messages on a transfer stream. This enables pipelining of messages on a transfer stream. Although
Although this example only demonstrates a single bundle transmission, this example only demonstrates a single bundle transmission, it is
it is also possible to pipeline multiple XFER_SEGMENT messages for also possible to pipeline multiple XFER_SEGMENT messages for
different bundles without necessarily waiting for XFER_ACK messages different bundles without necessarily waiting for XFER_ACK messages
to be returned for each one. However, interleaving data segments to be returned for each one. However, interleaving data segments
from different bundles is not allowed. from different bundles is not allowed.
No errors or rejections are shown in this example. No errors or rejections are shown in this example.
Entity A Entity B Entity A Entity B
======== ======== ======== ========
+-------------------------+ +-------------------------+
| Contact Header | -> +-------------------------+ | Contact Header | -> +-------------------------+
+-------------------------+ <- | Contact Header | +-------------------------+ <- | Contact Header |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| SESS_INIT | -> +-------------------------+ | SESS_INIT | -> +-------------------------+
+-------------------------+ <- | SESS_INIT | +-------------------------+ <- | SESS_INIT |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+
| XFER_INIT | ->
| Transfer ID [I1] |
| Total Length [L1] |
+-------------------------+
+-------------------------+
| XFER_SEGMENT (start) | -> | XFER_SEGMENT (start) | ->
| Transfer ID [I1] | | Transfer ID [I1] |
| Length [L1] | | Length [L1] |
| Bundle Data 0..(L1-1) | | Bundle Data 0..(L1-1) |
+-------------------------+ +-------------------------+
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| XFER_SEGMENT | -> <- | XFER_ACK (start) | | XFER_SEGMENT | -> <- | XFER_ACK (start) |
| Transfer ID [I1] | | Transfer ID [I1] | | Transfer ID [I1] | | Transfer ID [I1] |
| Length [L2] | | Length [L1] | | Length [L2] | | Length [L1] |
|Bundle Data L1..(L1+L2-1)| +-------------------------+ |Bundle Data L1..(L1+L2-1)| +-------------------------+
skipping to change at page 20, line 18 skipping to change at page 20, line 18
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
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| magic='dtn!' | | magic='dtn!' |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| Version | Flags | | Version | Flags |
+---------------+---------------+ +---------------+---------------+
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. The fields of the contact header are: header fields.
The fields of the contact header are:
magic: A four-octet field that always contains the octet sequence magic: A four-octet field that always contains the octet sequence
0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and 0x64 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII (and
UTF-8). UTF-8).
Version: A one-octet field value containing the value 4 (current Version: A one-octet field value containing the value 4 (current
version of the protocol). version of the protocol).
Flags: A one-octet field of single-bit flags, interpreted according Flags: A one-octet field of single-bit flags, interpreted according
to the descriptions in Table 1. to the descriptions in Table 1.
skipping to change at page 24, line 11 skipping to change at page 24, line 11
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 | | Type | Description |
+--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+
| SESS_INIT | Contains the session parameter inputs from one of | | SESS_INIT | Contains the session parameter inputs from one of |
| | the entities, as described in Section 4.6. | | | the entities, as described in Section 4.6. |
| | | | | |
| XFER_INIT | Contains the length (in octets) of the next |
| | transfer, as described in Section 5.2.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.2.3. | | | data, as described in Section 5.2.2. |
| | | | | |
| XFER_ACK | Acknowledges reception of a data segment, as | | XFER_ACK | Acknowledges reception of a data segment, as |
| | described in Section 5.2.4. | | | described in Section 5.2.3. |
| | | | | |
| XFER_REFUSE | Indicates that the transmission of the current | | XFER_REFUSE | Indicates that the transmission of the current |
| | bundle SHALL be stopped, as described in Section | | | bundle SHALL be stopped, as described in Section |
| | 5.2.5. | | | 5.2.4. |
| | | | | |
| KEEPALIVE | Used to keep TCPCL session active, as described in | | KEEPALIVE | Used to keep TCPCL session active, as described in |
| | Section 5.1.1. | | | Section 5.1.1. |
| | | | | |
| SESS_TERM | Indicates that one of the entities participating | | SESS_TERM | Indicates that one of the entities participating |
| | in the session wishes to cleanly terminate the | | | in 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.1.2. | | | 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. which are used together to negotiate the per-session parameters as
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 (U64)| | Session Extension Length (U32)|
+-------------------------------+ +-------------------------------+
| Session Extension Items (var.)| | Session Extension Items (var.)|
+-------------------------------+ +-------------------------------+
Figure 17: SESS_INIT Format Figure 17: SESS_INIT Format
A 16-bit unsigned integer indicating the interval, in seconds, The fields of the SESS_INIT message are:
between any subsequent messages being transmitted by the peer.
The peer receiving this contact header uses this interval to
determine how long to wait after any last-message transmission and
a necessary subsequent KEEPALIVE message transmission.
A 64-bit unsigned integer indicating the largest allowable single- Keepalive Interval: A 16-bit unsigned integer indicating the
segment data payload size to be received in this session. Any interval, in seconds, between any subsequent messages being
XFER_SEGMENT sent to this peer SHALL have a data payload no longer transmitted by the peer. The peer receiving this contact header
than the peer's Segment MRU. The two entities of a single session uses this interval to determine how long to wait after any last-
MAY have different Segment MRUs, and no relation between the two message transmission and a necessary subsequent KEEPALIVE message
is required. transmission.
A 64-bit unsigned integer indicating the largest allowable total- Segment MRU: A 64-bit unsigned integer indicating the largest
bundle data size to be received in this session. Any bundle allowable single-segment data payload size to be received in this
transfer sent to this peer SHALL have a Total Bundle Length session. Any XFER_SEGMENT sent to this peer SHALL have a data
payload no longer than the peer's Transfer MRU. This value can be payload no longer than the peer's Segment MRU. The two entities
used to perform proactive bundle fragmentation. The two entities of a single session MAY have different Segment MRUs, and no
of a single session MAY have different Transfer MRUs, and no
relation between the two is required. relation between the two is required.
Together these fields represent a variable-length text string. Transfer MRU: A 64-bit unsigned integer indicating the largest
The EID Length is a 16-bit unsigned integer indicating the number allowable total-bundle data size to be received in this session.
of octets of EID Data to follow. A zero EID Length SHALL be used Any bundle transfer sent to this peer SHALL have a Total Bundle
to indicate the lack of EID rather than a truly empty EID. This Length payload no longer than the peer's Transfer MRU. This value
case allows an entity to avoid exposing EID information on an can be used to perform proactive bundle fragmentation. The two
untrusted network. A non-zero-length EID Data SHALL contain the entities of a single session MAY have different Transfer MRUs, and
UTF-8 encoded EID of some singleton endpoint in which the sending no relation between the two is required.
entity is a member, in the canonical format of <scheme
name>:<scheme-specific part>. This EID encoding is consistent
with [I-D.ietf-dtn-bpbis].
Together these fields represent protocol extension data not EID Length and EID Data: Together these fields represent a variable-
defined by this specification. The Session Extension Length is length text string. The EID Length is a 16-bit unsigned integer
the total number of octets to follow which are used to encode the indicating the number of octets of EID Data to follow. A zero EID
Session Extension Item list. The encoding of each Session Length SHALL be used to indicate the lack of EID rather than a
Extension Item is within a consistent data container as described truly empty EID. This case allows an entity to avoid exposing EID
in Section 4.6.1. The full set of Session Extension Items apply information on an untrusted network. A non-zero-length EID Data
for the duration of the TCPCL session to follow. The order and SHALL contain the UTF-8 encoded EID of some singleton endpoint in
mulitplicity of these Session Extension Items MAY be significant, which the sending entity is a member, in the canonical format of
as defined in the associated type specification(s). <scheme name>:<scheme-specific part>. This EID encoding is
consistent with [I-D.ietf-dtn-bpbis].
4.6.1. Session Extension Items Session Extension Length and Session Extension Items: Together these
fields represent protocol extension data not defined by this
specification. The Session Extension Length is the total number
of octets to follow which are used to encode the Session Extension
Item list. The encoding of each Session Extension Item is within
a consistent data container as described in Section 4.8. The full
set of Session Extension Items apply for the duration of the TCPCL
session to follow. The order and mulitplicity of these Session
Extension Items MAY be significant, as defined in the associated
type specification(s).
4.7. Session Parameter Negotiation
An entity calculates the parameters for a TCPCL session by
negotiating the values from its own preferences (conveyed by the
contact header it sent to the peer) with the preferences of the peer
node (expressed in the contact header that it received from the
peer). The negotiated parameters defined by this specification are
described in the following paragraphs.
Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for
whole transfers and individual segments are idententical to the
Transfer MRU and Segment MRU, respectively, of the recevied
contact header. A transmitting peer can send individual segments
with any size smaller than the Segment MTU, depending on local
policy, dynamic network conditions, etc. Determining the size of
each transmitted segment is an implementation matter.
Session Keepalive: Negotiation of the Session Keepalive parameter is
performed by taking the minimum of this two contact headers'
Keepalive Interval. The Session Keepalive interval is a parameter
for the behavior described in Section 5.1.1.
Enable TLS: Negotiation of the Enable TLS parameter is performed by
taking the logical AND of the two contact headers' CAN_TLS flags.
A local security policy is then applied to determine of the
negotated value of Enable TLS is acceptable. It can be a
reasonable security policy to both require or disallow the use of
TLS depending upon the desired network flows. If the Enable TLS
state is unacceptable, the node SHALL terminate the session with a
reason code of "Contact Failure". Note that this contact failure
is different than a failure of TLS handshake after an agreed-upon
and acceptable Enable TLS state. If the negotiated Enable TLS
value is true and acceptable then TLS negotiation feature
(described in Section 4.4) begins immediately following the
contact header exchange.
Once this process of parameter negotiation is completed (which
includes a possible completed TLS handshake of the connection to use
TLS), this protocol defines no additional mechanism to change the
parameters of an established session; to effect such a change, the
TCPCL session MUST be terminated and a new session established.
4.8. Session Extension Items
Each of the Session Extension Items SHALL be encoded in an identical Each of the Session Extension Items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 18. Type-Length-Value (TLV) container form as indicated in Figure 18.
The fields of the Session Extension Item are: The fields of the Session Extension Item are:
Flags: A one-octet field containing generic bit flags about the Flags: A one-octet field containing generic bit flags about the
Item, which are listed in Table 3. If a TCPCL entity receives a Item, which are listed in Table 3. If a TCPCL entity receives a
Session Extension Item with an unknown Item Type and the CRITICAL Session Extension Item with an unknown Item Type and the CRITICAL
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.
skipping to change at page 26, line 43 skipping to change at page 27, line 42
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 32-bit unsigned integer field containing the number
of Item Value octets to follow. of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted Item Value: A variable-length data field which is interpreted
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 specification SHOULD avoid the use of large data data. Extension specifications SHOULD avoid the use of large data
exchanges within the TCPCL contact header as no bundle transfers lengths, as no bundle transfers can begin until the full extension
can begin until the full contact exchange and negotiation has been data is sent.
completed.
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. | | value contd. |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
skipping to change at page 27, line 28 skipping to change at page 28, line 28
| 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. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 3: Session Extension Item Flags Table 3: Session Extension Item Flags
4.7. Session Parameter Negotiation
An entity calculates the parameters for a TCPCL session by
negotiating the values from its own preferences (conveyed by the
contact header it sent to the peer) with the preferences of the peer
node (expressed in the contact header that it received from the
peer). The negotiated parameters defined by this specification are
described in the following paragraphs.
Transfer MTU and Segment MTU: The maximum transmit unit (MTU) for
whole transfers and individual segments are idententical to the
Transfer MRU and Segment MRU, respectively, of the recevied
contact header. A transmitting peer can send individual segments
with any size smaller than the Segment MTU, depending on local
policy, dynamic network conditions, etc. Determining the size of
each transmitted segment is an implementation matter.
Session Keepalive: Negotiation of the Session Keepalive parameter is
performed by taking the minimum of this two contact headers'
Keepalive Interval. The Session Keepalive interval is a parameter
for the behavior described in Section 5.1.1.
Enable TLS: Negotiation of the Enable TLS parameter is performed by
taking the logical AND of the two contact headers' CAN_TLS flags.
A local security policy is then applied to determine of the
negotated value of Enable TLS is acceptable. It can be a
reasonable security policy to both require or disallow the use of
TLS depending upon the desired network flows. If the Enable TLS
state is unacceptable, the node SHALL terminate the session with a
reason code of "Contact Failure". Note that this contact failure
is different than a failure of TLS handshake after an agreed-upon
and acceptable Enable TLS state. If the negotiated Enable TLS
value is true and acceptable then TLS negotiation feature
(described in Section 4.4) begins immediately following the
contact header exchange.
Once this process of parameter negotiation is completed (which
includes a possible completed TLS handshake of the connection to use
TLS), this protocol defines no additional mechanism to change the
parameters of an established session; to effect such a change, the
TCPCL session MUST be terminated and a new session established.
5. Established Session Operation 5. Established Session Operation
This section describes the protocol operation for the duration of an This section describes the protocol operation for the duration of an
established session, including the mechanism for transmitting bundles established session, including the mechanism for transmitting bundles
over the session. over the session.
5.1. Upkeep and Status Messages 5.1. Upkeep and Status Messages
5.1.1. Session Upkeep (KEEPALIVE) 5.1.1. Session Upkeep (KEEPALIVE)
skipping to change at page 29, line 9 skipping to change at page 29, line 15
choose a keepalive interval no longer than 10 minutes (600 seconds). choose a 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 2) with no additional data. Both KEEPALIVE (as described in Table 2) with no additional data. Both
sides SHOULD send a KEEPALIVE message whenever the negotiated sides SHALL send a KEEPALIVE message whenever the negotiated interval
interval has elapsed with no transmission of any message (KEEPALIVE 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 SHOULD 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 keepout 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
skipping to change at page 31, line 6 skipping to change at page 31, line 14
5.2.1. Bundle Transfer ID 5.2.1. Bundle Transfer ID
Each of the bundle transfer messages contains a Transfer ID which is Each of the bundle transfer messages contains a Transfer ID which is
used to correlate messages (from both sides of a transfer) for each used to correlate messages (from both sides of a transfer) for each
bundle. A Transfer ID does not attempt to address uniqueness of the bundle. A Transfer ID does not attempt to address uniqueness of the
bundle data itself and has no relation to concepts such as bundle bundle data itself and has no relation to concepts such as bundle
fragmentation. Each invocation of TCPCL by the bundle protocol fragmentation. Each invocation of TCPCL by the bundle protocol
agent, requesting transmission of a bundle (fragmentary or agent, requesting transmission of a bundle (fragmentary or
otherwise), results in the initiation of a single TCPCL transfer. otherwise), results in the initiation of a single TCPCL transfer.
Each transfer entails the sending of a XFER_INIT message and some Each transfer entails the sending of a sequence of some number of
number of XFER_SEGMENT and XFER_ACK messages; all are correlated by XFER_SEGMENT and XFER_ACK messages; all are correlated by the same
the same Transfer ID. Transfer ID.
Transfer IDs from each node SHALL be unique within a single TCPCL Transfer IDs from each node SHALL be unique within a single TCPCL
session. The initial Transfer ID from each node SHALL have value session. The initial Transfer ID from each node SHALL have value
zero. Subsequent Transfer ID values SHALL be incremented from the zero. Subsequent Transfer ID values SHALL be incremented from the
prior Transfer ID value by one. Upon exhaustion of the entire 64-bit prior Transfer ID value by one. Upon exhaustion of the entire 64-bit
Transfer ID space, the sending node SHALL terminate the session with Transfer ID space, the sending node SHALL terminate the session with
SESS_TERM reason code "Resource Exhaustion". SESS_TERM reason code "Resource Exhaustion".
For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on For bidirectional bundle transfers, a TCPCL node SHOULD NOT rely on
any relation between Transfer IDs originating from each side of the any relation between Transfer IDs originating from each side of the
TCPCL session. TCPCL session.
5.2.2. Transfer Initialization (XFER_INIT) 5.2.2. Data Transmission (XFER_SEGMENT)
The XFER_INIT message contains the total length, in octets, of the
bundle data in the associated transfer. The total length is
formatted as a 64-bit unsigned integer.
The purpose of the XFER_INIT message is to allow entities to
preemptively refuse bundles that would exceed their resources or to
prepare storage on the receiving node for the upcoming bundle data.
See Section 5.2.5 for details on when refusal based on XFER_INIT
content is acceptable.
The Total Bundle Length field within a XFER_INIT message SHALL be
treated as authoritative by the receiver. If, for whatever reason,
the actual total length of bundle data received differs from the
value indicated by the XFER_INIT message, the receiver SHOULD treat
the transmitted data as invalid.
The format of the XFER_INIT message is as follows in Figure 20.
+-----------------------------+
| Message Header |
+-----------------------------+
| Transfer ID (U64) |
+-----------------------------+
| Total Bundle Length (U64) |
+-----------------------------+
| Transfer Extension |
| Length (U64) |
+-----------------------------+
| Transfer Extension Items... |
+-----------------------------+
Figure 20: Format of XFER_INIT Messages
The fields of the XFER_INIT message are:
Transfer ID: A 64-bit unsigned integer identifying the transfer
about to begin.
Total Bundle Length: A 64-bit unsigned integer indicating the size
of the data-to-be-transferred.
Transfer Extension Length and Transfer Extension Items: Together
these fields represent protocol extension data not defined by this
specification. The Transfer Extension Length is the total number
of octets to follow which are used to encode the Transfer
Extension Item list. The encoding of each Transfer Extension Item
is within a consistent data container as described in
Section 5.2.2.1. The full set of transfer extension items apply
only to the assoicated single transfer. The order and
mulitplicity of these transfer extension items MAY be significant,
as defined in the associated type specification(s).
An XFER_INIT message SHALL be sent as the first message in a transfer
sequence, before transmission of any XFER_SEGMENT messages for the
same Transfer ID. XFER_INIT messages MUST NOT be sent unless the
next XFER_SEGMENT message has the 'START' bit set to "1" (i.e., just
before the start of a new transfer).
5.2.2.1. Transfer Extension Items
Each of the Transfer Extension Items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 21.
The fields of the Transfer Extension Item are:
Flags: A one-octet field containing generic bit flags about the
Item, which are listed in Table 5. If a TCPCL node receives a
Transfer Extension Item with an unknown Item Type and the CRITICAL
flag set, the node SHALL refuse the transfer with an XFER_REFUSE
reason code of "Extension Failure". If the CRITICAL flag is not
set, an entity SHALL skip over and ignore any item with an unknown
Item Type.
Item Type: A 16-bit unsigned integer field containing the type of
the extension item. This specification does not define any
extension types directly, but does allocate an IANA registry for
such codes (see Section 9.4).
Item Length: A 32-bit unsigned integer field containing the number
of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted
according to the associated Item Type. This specification places
no restrictions on an extension's use of available Item Value
data. Extension specification SHOULD avoid the use of large data
exchanges within the XFER_INIT as the associated transfer cannot
begin until the full initialization message is sent.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+
| length contd. | Item Value... |
+---------------+---------------+---------------+---------------+
| value contd. |
+---------------+---------------+---------------+---------------+
Figure 21: Transfer Extension Item Format
+----------+--------+-----------------------------------------------+
| Name | Code | Description |
+----------+--------+-----------------------------------------------+
| CRITICAL | 0x01 | If bit is set, indicates that the receiving |
| | | peer must handle the extension item. |
| | | |
| Reserved | others |
+----------+--------+-----------------------------------------------+
Table 5: Transfer Extension Item Flags
5.2.3. Data Transmission (XFER_SEGMENT)
Each bundle is transmitted in one or more data segments. The format Each bundle is transmitted in one or more data segments. The format
of a XFER_SEGMENT message follows in Figure 22. 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 |
| Length (U32) |
| (only for START segment) |
+------------------------------+
| Transfer Extension |
| Items (var.) |
| (only for START segment) |
+------------------------------+
| Data length (U64) | | Data length (U64) |
+------------------------------+ +------------------------------+
| Data contents (octet string) | | Data contents (octet string) |
+------------------------------+ +------------------------------+
Figure 22: Format of XFER_SEGMENT Messages Figure 20: 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 6. according to the descriptions in Table 5.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being made. being made.
Transfer Extension Length and Transfer Extension Items: Together
these fields represent protocol extension data for this
specification. The Transfer Extension Length and Transfer
Extension Item fields SHALL only be present when the 'START' flag
is set on the message. The Transfer Extension Length is the total
number of octets to follow which are used to encode the Transfer
Extension Item list. The encoding of each Transfer Extension Item
is within a consistent data container as described in
Section 5.2.5. The full set of transfer extension items apply
only to the assoicated single transfer. The order and
mulitplicity of these transfer extension items MAY be significant,
as defined in the associated type specification(s).
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.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| 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 6: XFER_SEGMENT Flags Table 5: 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 6. The two low-order bits, denoted 'START' and 'END' in Table 5. The
'START' bit MUST be set to one if it precedes the transmission of the 'START' bit MUST be set to one if it precedes the transmission of the
first segment of a transfer. The 'END' bit MUST be set to one when first segment of a transfer. The 'END' bit MUST be set to one when
transmitting the last segment of a transfer. In the case where an transmitting the last segment of a transfer. In the case where an
entire transfer is accomplished in a single segment, both the 'START' entire transfer is accomplished in a single segment, both the 'START'
and 'END' bits MUST be set to one. and 'END' bits MUST be set to one.
Once a transfer of a bundle has commenced, the node MUST only send Once a transfer of a bundle has commenced, the node MUST only send
segments containing sequential portions of that bundle until it sends segments containing sequential portions of that bundle until it sends
a segment with the 'END' bit set. No interleaving of multiple a segment with the 'END' bit set. No interleaving of multiple
transfers from the same node is possible within a single TCPCL transfers from the same node is possible within a single TCPCL
session. Simultaneous transfers between two entities MAY be achieved session. Simultaneous transfers between two entities MAY be achieved
using multiple TCPCL sessions. using multiple TCPCL sessions.
5.2.4. Data Acknowledgments (XFER_ACK) 5.2.3. Data Acknowledgments (XFER_ACK)
Although the TCP transport provides reliable transfer of data between Although the TCP transport provides reliable transfer of data between
transport peers, the typical BSD sockets interface provides no means transport peers, the typical BSD sockets interface provides no means
to inform a sending application of when the receiving application has to inform a sending application of when the receiving application has
processed some amount of transmitted data. Thus, after transmitting processed some amount of transmitted data. Thus, after transmitting
some data, the TCPCL needs an additional mechanism to determine some data, the TCPCL needs an additional mechanism to determine
whether the receiving agent has successfully received the segment. whether the receiving agent has successfully received the segment.
To this end, the TCPCL protocol provides feedback messaging whereby a To this end, the TCPCL protocol provides feedback messaging whereby a
receiving node transmits acknowledgments of reception of data receiving node transmits acknowledgments of reception of data
segments. segments.
The format of an XFER_ACK message follows in Figure 23. The format of an XFER_ACK message follows in Figure 21.
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
| Acknowledged length (U64) | | Acknowledged length (U64) |
+-----------------------------+ +-----------------------------+
Figure 23: Format of XFER_ACK Messages Figure 21: 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 6. according to the descriptions in Table 5.
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
message being acknowledged. The acknowledged length of each XFER_ACK message being acknowledged. The acknowledged length of each XFER_ACK
contains the sum of the data length fields of all XFER_SEGMENT contains the sum of the data length fields of all XFER_SEGMENT
messages received so far in the course of the indicated transfer. messages received so far in the course of the indicated transfer.
The sending node MAY transmit multiple XFER_SEGMENT messages without The sending node SHOULD transmit multiple XFER_SEGMENT messages
necessarily waiting for the corresponding XFER_ACK responses. This without waiting for the corresponding XFER_ACK responses. This
enables pipelining of messages on a transfer stream. enables pipelining of messages on a transfer stream.
For example, suppose the sending node transmits four segments of For example, suppose the sending node transmits four segments of
bundle data with lengths 100, 200, 500, and 1000, respectively. bundle data with lengths 100, 200, 500, and 1000, respectively.
After receiving the first segment, the node sends an acknowledgment After receiving the first segment, the node sends an acknowledgment
of length 100. After the second segment is received, the node sends of length 100. After the second segment is received, the node sends
an acknowledgment of length 300. The third and fourth an acknowledgment of length 300. The third and fourth
acknowledgments are of length 800 and 1800, respectively. acknowledgments are of length 800 and 1800, respectively.
5.2.5. Transfer Refusal (XFER_REFUSE) 5.2.4. Transfer Refusal (XFER_REFUSE)
The TCPCL supports a mechanism by which a receiving node can indicate The TCPCL supports a mechanism by which a receiving node can indicate
to the sender that it does not want to receive the corresponding to the sender that it does not want to receive the corresponding
bundle. To do so, upon receiving a XFER_INIT or XFER_SEGMENT bundle. To do so, upon receiving an XFER_SEGMENT message, the node
message, the node MAY transmit a XFER_REFUSE message. As data MAY transmit a XFER_REFUSE message. As data segments and
segments and acknowledgments MAY cross on the wire, the bundle that acknowledgments MAY cross on the wire, the bundle that is being
is being refused SHALL be identified by the Transfer ID of the refused SHALL be identified by the Transfer ID of the refusal.
refusal.
There is no required relation between the Transfer MRU of a TCPCL There is no required relation between the Transfer MRU of a TCPCL
node (which is supposed to represent a firm limitation of what the node (which is supposed to represent a firm limitation of what the
node will accept) and sending of a XFER_REFUSE message. A node will accept) and sending of a XFER_REFUSE message. A
XFER_REFUSE can be used in cases where the agent's bundle storage is XFER_REFUSE can be used in cases where the agent's bundle storage is
temporarily depleted or somehow constrained. A XFER_REFUSE can also temporarily depleted or somehow constrained. A XFER_REFUSE can also
be used after the bundle header or any bundle data is inspected by an be used after the bundle header or any bundle data is inspected by an
agent and determined to be unacceptable. agent and determined to be unacceptable.
A receiver MAY send an XFER_REFUSE message as soon as it receives a A receiver MAY send an XFER_REFUSE message as soon as it receives any
XFER_INIT message without waiting for the next XFER_SEGMENT message. XFER_SEGMENT message. The sender MUST be prepared for this and MUST
The sender MUST be prepared for this and MUST associate the refusal associate the refusal with the correct bundle via the Transfer ID
with the correct bundle via the Transfer ID fields. fields.
The format of the XFER_REFUSE message is as follows in Figure 24. The format of the XFER_REFUSE message is as follows in Figure 22.
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
| Transfer ID (U64) | | Transfer ID (U64) |
+-----------------------------+ +-----------------------------+
Figure 24: 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 7. to the descriptions in Table 6.
Transfer ID: A 64-bit unsigned integer identifying the transfer Transfer ID: A 64-bit unsigned integer identifying the transfer
being refused. being refused.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Name | Semantics | | Name | Semantics |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Unknown | Reason for refusal is unknown or not specified. | | Unknown | Reason for refusal is unknown or not specified. |
| | | | | |
| Extension | A failure processing the Transfer Extension Items ha | | Extension | A failure processing the Transfer Extension Items ha |
skipping to change at page 37, line 43 skipping to change at page 36, line 25
| | 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 7: 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
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
transmission of any further segments of the refused bundle transmission of any further segments of the refused bundle
subsequently. Note, however, that this requirement does not ensure subsequently. Note, however, that this requirement does not ensure
that an entity will not receive another XFER_SEGMENT for the same that an entity will not receive another XFER_SEGMENT for the same
bundle after transmitting a XFER_REFUSE message since messages MAY bundle after transmitting a XFER_REFUSE message since messages MAY
cross on the wire; if this happens, subsequent segments of the bundle cross on the wire; if this happens, subsequent segments of the bundle
SHOULD also be refused with a XFER_REFUSE message. SHALL also be refused with a XFER_REFUSE message.
Note: If a bundle transmission is aborted in this way, the receiver Note: If a bundle transmission is aborted in this way, the receiver
MAY not receive a segment with the 'END' flag set to '1' for the MAY not receive a segment with the 'END' flag set to '1' for the
aborted bundle. The beginning of the next bundle is identified by aborted bundle. The beginning of the next bundle is identified by
the '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.
5.2.5. Transfer Extension Items
Each of the Transfer Extension Items SHALL be encoded in an identical
Type-Length-Value (TLV) container form as indicated in Figure 23.
The fields of the Transfer Extension Item are:
Flags: A one-octet field containing generic bit flags about the
Item, which are listed in Table 7. If a TCPCL node receives a
Transfer Extension Item with an unknown Item Type and the CRITICAL
flag set, the node SHALL refuse the transfer with an XFER_REFUSE
reason code of "Extension Failure". If the CRITICAL flag is not
set, an entity SHALL skip over and ignore any item with an unknown
Item Type.
Item Type: A 16-bit unsigned integer field containing the type of
the extension item. This specification allocates an IANA registry
for such codes (see Section 9.4).
Item Length: A 32-bit unsigned integer field containing the number
of Item Value octets to follow.
Item Value: A variable-length data field which is interpreted
according to the associated Item Type. This specification places
no restrictions on an extension's use of available Item Value
data. Extension specifications SHOULD avoid the use of large data
lengths, as the associated transfer cannot begin until the full
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
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+
| length contd. | Item Value... |
+---------------+---------------+---------------+---------------+
| value contd. |
+---------------+---------------+---------------+---------------+
Figure 23: Transfer Extension Item Format
+----------+--------+-----------------------------------------------+
| Name | Code | Description |
+----------+--------+-----------------------------------------------+
| CRITICAL | 0x01 | If bit is set, indicates that the receiving |
| | | peer must handle the extension item. |
| | | |
| Reserved | others |
+----------+--------+-----------------------------------------------+
Table 7: Transfer Extension Item Flags
5.2.5.1. Transfer Length Extension
The purpose of the Transfer Length extension is to allow entities to
preemptively refuse bundles that would exceed their resources or to
prepare storage on the receiving node for the upcoming bundle data.
Multiple Transfer Length extension items SHALL NOT occurr within the
same transfer. The lack of a Transfer Length extension item in any
transfer SHALL NOT imply anything about the potential length of the
transfer. The Transfer Length extension SHALL be assigned transfer
extension type ID 0x0001.
The format of the Transfer Length data is as follows in Figure 24.
+----------------------+
| Total Length (U64) |
+----------------------+
Figure 24: Format of Transfer Length data
The fields of the Transfer Length extension are:
Total Length: A 64-bit unsigned integer indicating the size of the
data-to-be-transferred. The Total Length field SHALL be treated
as authoritative by the receiver. If, for whatever reason, the
actual total length of bundle data received differs from the value
indicated by the Total Length value, the receiver SHALL treat the
transmitted data as invalid.
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. Session Termination Message (SESS_TERM) 6.1. Session Termination Message (SESS_TERM)
To cleanly shut down a session, a SESS_TERM message SHALL be To cleanly shut down a session, a SESS_TERM 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. When sent to initiate a transmission of any other message. When sent to initiate a
termination, the REPLY bit of a SESS_TERM message SHALL NOT be set. termination, the REPLY bit of a SESS_TERM message SHALL NOT be set.
Upon receiving a SESS_TERM message after not sending a SESS_TERM Upon receiving a SESS_TERM message after not sending a SESS_TERM
message in the same session, an entity SHOULD send an acknowledging message in the same session, an entity SHALL send an acknowledging
SESS_TERM message. When sent to acknowledge a termination, a SESS_TERM message. When sent to acknowledge a termination, a
SESS_TERM message SHALL have identical data content from the message SESS_TERM message SHALL have identical data content from the message
being acknowledged except for the REPLY bit, which is set to indicate being acknowledged except for the REPLY bit, which is set to indicate
acknowledgement. acknowledgement.
After sending a SESS_TERM message, an entity MAY continue a possible After sending a SESS_TERM message, an entity MAY continue a possible
in-progress transfer in either direction. After sending a SESS_TERM in-progress transfer in either direction. After sending a SESS_TERM
message, an entity SHALL NOT begin any new outgoing transfer (i.e. message, an entity SHALL NOT begin any new outgoing transfer (i.e.
send an XFER_INIT message) for the remainder of the session. After send an XFER_SEGMENT message) for the remainder of the session.
receving a SESS_TERM message, an entity SHALL NOT accept any new After receving a SESS_TERM message, an entity SHALL NOT accept any
incoming transfer for the remainder of the session. new incoming transfer for the remainder of the session.
Instead of following a clean shutdown sequence, after transmitting a Instead of following a clean shutdown sequence, after transmitting a
SESS_TERM message an entity MAY immediately close the associated TCP SESS_TERM message an entity MAY immediately close the associated TCP
connection. When performing an unclean shutdown, a receiving node connection. When performing an unclean shutdown, a receiving node
SHOULD acknowledge all received data segments before closing the TCP SHOULD acknowledge all received data segments before closing the TCP
connection. When performing an unclean shutodwn, a transmitting node connection. Not acknowledging received segments can result in
SHALL treat either sending or receiving a SESS_TERM message (i.e. unnecessary retransmission. When performing an unclean shutodwn, a
before the final acknowledgment) as a failure of the transfer. Any transmitting node SHALL treat either sending or receiving a SESS_TERM
delay between request to terminate the TCP connection and actual message (i.e. before the final acknowledgment) as a failure of the
closing of the connection (a "half-closed" state) MAY be ignored by transfer. Any delay between request to terminate the TCP connection
the TCPCL node. and actual closing of the connection (a "half-closed" state) MAY be
ignored by the TCPCL node.
The format of the SESS_TERM message is as follows in Figure 25. The format of the SESS_TERM message is as follows in Figure 25.
+-----------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------+ +-----------------------------+
| Reason Code (U8) | | Reason Code (U8) |
+-----------------------------+ +-----------------------------+
skipping to change at page 40, line 34 skipping to change at page 40, line 49
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
invalid "magic string" is recevied), an entity SHOULD close the TCP invalid "magic string" is recevied), an entity SHALL close the TCP
connection without sending a SESS_TERM message. If the content of connection without sending a SESS_TERM message. If the content of
the Session Extension Items data disagrees with the Session Extension the Session Extension Items data disagrees with the Session Extension
Length (i.e. the last Item claims to use more octets than are present Length (i.e. the last Item claims to use more octets than are present
in the Session Extension Length), the reception of the contact header in the Session Extension Length), the reception of the contact header
is considered to have failed. is considered to have failed.
If a session is to be terminated before a protocol message has If a session is to be terminated before a protocol message has
completed being sent, then the node MUST NOT transmit the SESS_TERM completed being sent, then the node MUST NOT transmit the SESS_TERM
message but still SHOULD close the TCP connection. Each TCPCL message but still SHALL close the TCP connection. Each TCPCL message
message is contiguous in the octet stream and has no ability to be is contiguous in the octet stream and has no ability to be cut short
cut short and/or preempted by an other message. This is particularly and/or preempted by an other message. This is particularly important
important when large segment sizes are being transmitted; either when large segment sizes are being transmitted; either entire
entire XFER_SEGMENT is sent before a SESS_TERM message or the XFER_SEGMENT is sent before a SESS_TERM message or the connection is
connection is simply terminated mid-XFER_SEGMENT. simply terminated mid-XFER_SEGMENT.
6.2. Idle Session Shutdown 6.2. Idle Session Shutdown
The protocol includes a provision for clean shutdown of idle The protocol includes a provision for clean shutdown of idle
sessions. Determining the length of time to wait before closing idle sessions. Determining the length of time to wait before closing idle
sessions, if they are to be closed at all, is an implementation and sessions, if they are to be closed at all, is an implementation and
configuration matter. configuration matter.
If there is a configured time to close idle links and if no 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
skipping to change at page 45, line 10 skipping to change at page 45, line 35
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 | Message Type |
+----------------+--------------------------+ +----------------+---------------------------+
| 0x0000 | Reserved | | 0x0000 | Reserved |
| | | | | |
| 0x0001--0x7fff | Unassigned | | 0x0001 | Transfer Length Extension |
| | | | | |
| 0x8000--0xffff | Private/Experimental Use | | 0x0002--0x7fff | Unassigned |
+----------------+--------------------------+ | | |
| 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-
registry titled "Bundle Protocol TCP Convergence-Layer Version 4 registry titled "Bundle Protocol TCP Convergence-Layer Version 4
skipping to change at page 46, line 20 skipping to change at page 46, line 30
| 0x01 | XFER_SEGMENT | | 0x01 | XFER_SEGMENT |
| | | | | |
| 0x02 | XFER_ACK | | 0x02 | XFER_ACK |
| | | | | |
| 0x03 | XFER_REFUSE | | 0x03 | XFER_REFUSE |
| | | | | |
| 0x04 | KEEPALIVE | | 0x04 | KEEPALIVE |
| | | | | |
| 0x05 | SESS_TERM | | 0x05 | SESS_TERM |
| | | | | |
| 0x06 | XFER_INIT | | 0x06 | MSG_REJECT |
| | |
| 0x07 | MSG_REJECT |
| | | | | |
| 0x08--0xf | Unassigned | | 0x07--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-
skipping to change at page 49, line 21 skipping to change at page 49, line 21
11.1. Normative References 11.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015. 2015.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Fall, K. and E. Birrane, "Bundle Protocol Version 7", Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol
draft-ietf-dtn-bpbis-11 (work in progress), May 2018. Version 7", draft-ietf-dtn-bpbis-12 (work in progress),
November 2018.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
skipping to change at page 50, line 12 skipping to change at page 50, line 14
11.2. Informative References 11.2. Informative References
[github-dtn-bpbis-tcpcl] [github-dtn-bpbis-tcpcl]
Sipos, B., "TCPCL Example Implementation", Sipos, B., "TCPCL Example Implementation",
<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/ <https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/
develop>. develop>.
[I-D.ietf-dtn-bpsec] [I-D.ietf-dtn-bpsec]
Birrane, E. and K. McKeever, "Bundle Protocol Security Birrane, E. and K. McKeever, "Bundle Protocol Security
Specification", draft-ietf-dtn-bpsec-08 (work in Specification", draft-ietf-dtn-bpsec-09 (work in
progress), October 2018. progress), February 2019.
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, DOI 10.17487/RFC2595, June 1999, RFC 2595, DOI 10.17487/RFC2595, June 1999,
<https://www.rfc-editor.org/info/rfc2595>. <https://www.rfc-editor.org/info/rfc2595>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>. April 2007, <https://www.rfc-editor.org/info/rfc4838>.
skipping to change at page 51, line 13 skipping to change at page 51, line 13
length. length.
o Changed contact header content to limit number of negotiated o Changed contact header content to limit number of negotiated
options. options.
o Added contact option to negotiate maximum segment size (per each o Added contact option to negotiate maximum segment size (per each
direction). direction).
o Added session extension capability. o Added session extension capability.
o Added transfer extension capability. o Added transfer extension capability. Moved transfer total length
into an extension item.
o Defined new IANA registries for message / type / reason codes to o Defined new IANA registries for message / type / reason codes to
allow renaming some codes for clarity. allow renaming some codes for clarity.
o Expanded Message Header to octet-aligned fields instead of bit- o Expanded Message Header to octet-aligned fields instead of bit-
packing. packing.
o Added a bundle transfer identification number to all bundle- o Added a bundle transfer identification number to all bundle-
related messages (XFER_INIT, XFER_SEGMENT, XFER_ACK, XFER_REFUSE). related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE).
o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT. o Use flags in XFER_ACK to mirror flags from XFER_SEGMENT.
o Removed all uses of SDNV fields and replaced with fixed-bit-length o Removed all uses of SDNV fields and replaced with fixed-bit-length
fields. fields.
o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown". o Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown".
o Removed the notion of a re-connection delay parameter. o Removed the notion of a re-connection delay parameter.
 End of changes. 73 change blocks. 
326 lines changed or deleted 315 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/