Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages
Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
The following issue https://issues.omg.org/browse/DDSIRTP23-6 was deferred in the last RTF so it should have been moved to this RTF. Since it didn't happen automatically we are entering this issue manually here.
The latest proposal we had is copied below. See to
DDSIRTP23-6for more background and previous discussions.
Introduce a new RTPS submessage "RTPSHeaderExtension" with the following elements:
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:
, 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'
Checksum_t Type used to hold a checksum. Used to detect message corruption.
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. Inthe case of a packet-oriented transport (like UDP/IP), the length of the message is already provided by the transport encapsulation. Astream-oriented transport (like TCP) would need to insert the length ahead of the messagein order to identify the boundary of the RTPS message.
Add the following subsection following subsection 18.104.22.168 (Count):
Checksum is used in the HeaderExtension Submessage and enables the receiver to detect messages corrupted by the transport.
The Checksum has four possible representations, the representation used depends on the value of the ChecksumFlags, see clause 22.214.171.124.2 'Content'.
Add the following subsection as the first subsection in section 8.3.7 'RTPS Submessages':
The HeaderExtension Submessage is used to convey optional information about the RTPS Message. This submessage, if present, shall appear directly after the RTPS Header.
The elements that form the structure of the HeaderExtension message are described in the table below.
Table 8.XX - Structure of the HeaderExtension Submessage
element type meaning EndiannessFlag (E) SubmessageFlag Appears in the Submessage header flags. Indicates endianness. LenghtFlag (L) SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageLength field is present. ChecksumFlags (C) SubmessageFlag Appears in the Submessage header flags. Indicates the the rtpsMessageChecksum field is present. InlineParamatersFlag (I) SubmessageFlag Appears in the Submessage header flags. Indicates the the inlineParameters field is present. rtpsMessageLength ulong Present only if the LenghtFlag is set in the header. Contains the length of the RTPS Message starting from the beginning of the RTPS Header. rtpsMessageChecksum Checksum Present only if the ChecksumFlags are different than 000.. Contains a checksum computed over the content of the RTPS Message, which includes the HeaderExtension submessage. inlineParameters ParameterList Present only if the InlineParamatersFlag is set in the header. Contains additional information encoded using PL_CDR
The Checksum has four possible type definitions: Checksum32_t, Checksum64_t, Checksum128_t , and Checksum256_t.
The type used for the Checksum and its interpretation shall depend on the value of the 3 bits in the ChecksumFlags as indicated in Table 8.XX below.
Table 8.XX - Type used and interpretation of the Checksum
ChecksumFlags (CCC) Type Interpretation 000 N/A No checksum is included in the RTPSHeaderExtension 001 Checksum32_t CRC-32 as defined in ISO/IEC 13239:2002, polynomial x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x+1 010 Checksum64_t CRC-64 as defined in ISO/IEC 13239:2002, polynomial x^64+x^4+x^3+x+1 011 Checksum128_t MD5 (128 bits) 100 Checksum32_t Custom 32 bit CRC 101 Checksum64_t Custom 64 bit CRC 110 Checksum128_t Custom 128 bit CRC 111 Checksum256_t Custom 256 bit CRC
For the purposes of computing the checksum the rtpsMessageChecksum field in the HeaderExtension shall be set to zero and updated once the checksum is calculated over the RTPS Message.
FIX the WORDING:
When encoding the CRC-32 and CRC-64 into the corresponding Checksum32_t and Checksum64_t the integers shall use Big Endian representation.
This Submessage is invalid when any of the following is true:
- The submessage is present but does not immediately follow the RTPSHeader.
- 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.
- The representation used for the Checksum does not correspond to what is indicated by the ChecksumFlags.
126.96.36.199.4 Change in state of Receiver
188.8.131.52.5 Logical Interpretation
The RTPSHeaderExtension may be sent to communicate the length of the RTPS Message, a Checksum of the RTPS Message, or additional information about the RTPS message.
The length of the RTPS Message may be useful to for managing memory while receiving incoming RTPS Messages.
The checksum may be useful to detect message corruption by the underlying transport.
The rtpsMsgLength contains the entire length of the RTPS Message starting from the beginning of the RTPS Header.
The rtpsMessageChecksum contains the checksum of the RTPS message.
The inlineParamaters contain additional information about the RTPS message encoded using PL_CDR.
In section 184.108.40.206.1 'SubmessageId', add RTPS_HE to the enum SubmessageKind and update the definition to use new IDL syntax:
Add the following subsection as the subsection directly following 220.127.116.11 'Submessage Header' in section 9.4.5 'Mapping of the RTPS Submessages':
18.104.22.168 RTPSHeaderExtension Submessage
Sub clause 22.214.171.124 in the PIM defines the logical contents of the RTPSHeaderExtension Submessage. The PSM maps the RTPSHeaderExtension Submessage into the following wire representation:
In section 9.3.2, add the following IDL following the IDL for:
typedef long Count_t;
Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
Updated: Tue, 24 Mar 2020 15:47 GMT