DDSIRTP23 — Message Size should be included as part of DDSI/RTPS Messages

Original Description

The DDSI/RTPS wire protocol currently expects the transport to provide the size for the message – said in other terms, the current version of the protocol can only work with message oriented transports, such as UDP/IP.

This assumptions should be dropped in order to enable the use of DDSI/RTPS over stream oriented transports such as TCP/IP.

One possible approach to overcome this limitation w/o breaking backward compatibility with other implementation is to add a new sub-message element, say MESSAGE_LEN structured as follows:

+--------+--------+--------+--------+
|   ID   | Flags  | octect2NextSME  |
+--------+--------+--------+--------+
|          Message Length           |
+-----------------------------------+

In addition, for efficient parsing, if the sub-message above, when used, should be always placed right after the RTPS header.

RTF 2.3 Discussion

The RTF is recommending this issue is deferred until the transports PSMs that need it (e.g. the RTPS TCP PSM) define the requirements in a more complete way. The point is that these PSMs will need more than just the message length and RTPS should include a mechanism that is sufficiently generic to accommodate it. We are not ready yet to define it.

The latest proposal we had developed is below. It is left here so future revisions of the specification can leverage these ideas.

Overall Approach
-----------------------
Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:

• rtpsMsgLength

The rtpsMsgLength indicates the length of the RTPS message

The RTPSHeaderExtension submessage, if present, shall follow immediately after the RTPS Header

The DDS Security specification will leave this RTPSHeaderExtension following the RTPS Header and before the SecureRTPSPrefixSubMsg. The length will be updated to the new length after processing by the security plugins.

Another option would be that the RTPSHeaderExtension (therefore not a header extension) would go after the SecureRTPSPrefixSubMsg, but it would be useless there because it can't be used before applying security. The length is no longer serving its purpose, so this is therefore not an option.

RTF 2.3 Latest Proposed Revised Text

In section 7.6 'The RTPS Transport Model', update the following bullet point as shown:

• The transport provides a means to deduce the size of the received message.

Update Figure 8.8 'Structure of RTPS Messages' to include RTPSHeaderExtension as one if the Submessages.

In Section 8.3.2 (Type Definitions), Table 8.13 'Types used to define RTPS messages', update the 'Purpose' column for Type SubmessageKind to add RTPS_HE to the list of reserved kinds:
Enumeration used to identify the kind of Submessage.
The following values are reserved by this version of the protocol:
RTPS_HE, DATA, GAP, HEARTBEAT, ACKNACK, PAD, INFO_TS, INFO_REPLY, INFO_DST, INFO_SRC, DATA_FRAG, NACK_FRAG, HEARTBEAT_FRAG

In section 8.3.2 'Type Definitions' in Table 8.13 add the following row after the row for 'Count_t'

In section 8.3.3 'The Overall Structure of an RTPS Message' update the final paragraph as follows:
Each message sent by the RTPS protocol has a finite length. This length is not sent explicitly by the RTPS protocol but is part of the underlying transport with which RTPS messages are sent. This length is optionally sent in the RTPS HeaderExtension Submessage.

The length may also be sent by the underlying transport that carries the RTPS message and, in these cases, may be omitted from the HeaderExtension. In For example, in the case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport encapsulation.

A In contrast, a stream-oriented transport (like TCP) would need to insert the length ahead of the message include the length in the RTPS HeaderExtension in order to identify the boundary of the RTPS message.

Add the following subsection following subsection 8.3.5.10 (Count):
8.3.7.1.2 Checksum
Checksum is used in the HeaderExtension Submessage and enables the receiver to detect messages corrupted by the transport.

Table 29 – Structure of the Checksum SubmessageElement

Add the following subsection as the first subsection in section 8.3.7 'RTPS Submessages':
8.3.7.1 HeaderExtension
8.3.7.1.1 Purpose
The HeaderExtension Submessage is used to convey optional information about the RTPS Message. This submessage, if present, shall appear directly after the RTPS Header.

8.3.7.1.2 Content
The elements that form the structure of the HeaderExtension message are described in the table below.
Table 8.XX - Structure of the HeaderExtension Submessage

8.3.7.1.3 Validity
This Submessage is invalid when any of the following is true:

• submessageLength in the Submessage header is too small to fit the fields that are present as indicated by the submessage flags.
• rtpsMessageLength is too small.

8.3.7.1.4 Change in state of Receiver
None.

8.3.7.1.5 Logical Interpretation
The RTPSHeaderExtension may be sent to communicate the length of the RTPS Message. This information may be useful to for managing memory while receiving incoming RTPS Messages.

The rtpsMsgLength contains the entire length of the RTPS Message starting from the beginning of the RTPS Header.

In section 9.4.5.1.1 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:

enum SubmessageKind {
    @value(0x00)
    RTPS_HE,    /* RTPSHeaderExtension */
    @value(0x01)
    PAD, /* Pad */            
    @value(0x06)
    ACKNACK, /* AckNack */        
    @value(0x07)
    HEARTBEAT, /* Heartbeat */      
    @value(0x08)
    GAP, /* Gap */            
    @value(0x09)
    INFO_TS, /* InfoTimestamp */  
    @value(0x0c)
    INFO_SRC, /* InfoSource */     
    @value(0x0d)
    INFO_REPLY_IP4, /* InfoReplyIp4 */   
    @value(0x0e)
    INFO_DST, /* InfoDestination */
    @value(0x0f)
    INFO_REPLY, /* InfoReply */      
    @value(0x12)
    NACK_FRAG, /* NackFrag */       
    @value(0x13)
    HEARTBEAT_FRAG, /* HeartbeatFrag */  
    @value(0x15)
    DATA, /* Data */           
    @value(0x16)
    DATA_FRAG /* DataFrag */
};

Add the following subsection as the subsection directly following 9.4.5.1 'Submessage Header' in section 9.4.5 'Mapping of the RTPS Submessages':
9.4.5.2 RTPSHeaderExtension Submessage
Sub clause 8.3.7.1 in the PIM defines the logical contents of the RTPSHeaderExtension Submessage. The PSM maps the RTPSHeaderExtension Submessage into the following wire representation:

0...2...........8...............16..............24..............32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    RTPS_HE    |X|X|X|X|X|X|X|E|       octetsToNextHeader      |
+---------------+---------------+---------------+---------------+
|                          ulong rtpsMsgLength                  |
+---------------+---------------+---------------+---------------+

In section 9.3.2, add the following IDL following the IDL for:
typedef long Count_t;

typedef unsigned long Checksum_t;

Defer until we have a specification for the RTPS-TCP PSM

This requirement is mostly driven from the needs of additional transport PSMs (such as the RTPS-TCP) that are currently under development.

It is unclear whether these PSMs will just need this or also other information beyond the port number which can be addressed at the same time as suggested by some of the discussions and proposed resolutions.

Therefore the opinion of the RTF is to defer this issue until an additional RTPS Transport PSM is approved to better understand the requirements.