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.

The DDS interoperability protocol is also referred to as RTPS. OMG staff have received conflicting suggestions for the short name of the protocol (RTPS vs. DDSI). This short name determines (amongst other things) the URL by which the mist recent version of the specification is always accessible.

The RTF must decide what short name to use for this specification.

Yes/No vote to decide whether to keep DDSI-RTPS or change to DDS-RTPS

If we do nothing the name will remain DDSI-RTPS.

The proposed resolution to this issue is to change the acronym to DDS-RTPS. So if the issue is approved the acronym will change. If it is rejected it will stay the same.

Please excuse my learning curve here.

Section 6.1 says that this formal is a supplement to Version 1.1 formal, However there is now a version 1.2. That MIGHT suggest that aspects of 1.2 is not within interoperability to this specification. and that this one is interoperable to 1.1. Which I understand is across major versions and not a mandate.

Anyway Please clareify.
Is there a document that has version differences overview. If so a reference to that would be value added as well.

Update references to the DDS Spec with the current 1.4 version

Replace references to DDS version 1.2 with the most current version, 1.4

The DDSI v2.1 specification describes in section 8.4.13 the Writer Liveliness Protocol as the mechanism used by participants to assess the liveliness of their contained data writers (with automatic liveliness).

The Writer Liveliness Protocol is specified as mandatory for compliant implementations.

The first remark is that the Writer Liveliness Protocol is not required at all for interoperability, thus it should not be a mandatory requirement for compliant implementation. This is not only easy to reason about, but wireshark captures made during the DDS interoperability demo of the past March 2012 showed how different DDS implementations could work w/o using this protocol.

Beyond that, the protocol is simply superfluous as DataWriter liveliness can be anyway asserted via the Participant Liveliness, this in turns is asserted by the participant discovery protocol.

Beyond the potential waste of resource required by yet another periodic information flow, what seems very odd is the choices of QoS for the built-in entities that write this periodic message. As described in section 8.4.13.3 these built-int entities communicate reliably and have a history set to KeepLast(1), along with TransientLocal durability.

This QoS settings only "works" best for those implementations that tie the reliability send queue to the writer history but is less than ideal for those that rightfully decouple history and reliability.

Anyway, however one looks at it this part of the specs seems bogus. In addition as mentioned above is not required for interoperability and generates yet another stream of periodic messages.

The recommendation is to remove this section from the next version of the standard.

No Need to remove the Writer Liveliness Protocol

The RTF does not see a need to remove the Writer Liveliness Protocol from the specification.