1. OMG Mailing List
  2. DDSI-RTPS 2.5 Revision Task Force

Open Issues

  • Issues not resolved
  • Name: ddsi-rtps-rtf5
  • Issues Count: 11

Issues Descriptions

Address deferred issue: Inclusion of Message Size & CRC as part of DDSI/RTPS Messages

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    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-6 for more background and previous discussions.

    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'

    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. 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.

    The Checksum has four possible representations, the representation used depends on the value of the ChecksumFlags, see clause 8.3.7.1.2 'Content'.



    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

    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.

    typedef octet  Checksum32_t[4];
    typedef octet  Checksum64_t[8];
    typedef octet  Checksum128_t[16];
    typedef octet  Checksum256_t[32];
    

    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.

    8.3.7.1.3 Validity
    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.

    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, 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 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|I|C|C|C|L|E|       octetsToNextHeader      |
    +---------------+---------------+---------------+---------------+
    |                ulong rtpsMsgLength   [iff L == 1]             |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     rtpsMessageChecksum  [iff CCC != 000]     ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    |                                                               |
    ~                     inlineParameters     [iff I != 0]         ~
    |                                                               |
    +---------------+---------------+---------------+---------------+
    


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

    typedef octet  Checksum32_t[4];
    typedef octet  Checksum64_t[8];
    typedef octet  Checksum128_t[16];
    typedef octet  Checksum256_t[32];
    
  • Reported: DDSI-RTPS 2.3b1 — Fri, 20 Mar 2020 20:07 GMT
  • Updated: Tue, 24 Mar 2020 15:47 GMT

SEQUENCENUMBER_UNKNOWN missing from PSM

  • Status: open  
  • Source: OCI ( Adam Mitz)
  • Summary:

    The previous version of the spec (formal/14-09-01) contained the following in Table 9.4
    #define SEQUENCENUMBER_UNKNOWN {-1, 0}
    However, the equivalent definition is missing in the 2018 "Beta" spec.

  • Reported: DDSI-RTPS 2.3b1 — Tue, 22 Jan 2019 18:12 GMT
  • Updated: Tue, 24 Mar 2020 14:41 GMT


currentGSN.value < lastGSN.value condition seems wrong

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    The last condition seems wrong. Shouldn't that be greater than instead of less than?
    If GroupInfoFlag is set and:
    • currentGSN.value is zero or negative
    • firstGSN.value is zero or negative
    • lastGSN.value is negative
    • lastGSN.value < firstGSN.value - 1
    • currentGSN.value < firstGSN.value
    • currentGSN.value < lastGSN.value

  • Reported: DDSI-RTPS 2.3 — Mon, 10 Feb 2020 08:26 GMT
  • Updated: Tue, 18 Feb 2020 15:48 GMT

8.3.7.5 / 9.4.5.6 HeartBeat Submessage

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage heartbeat defines the flag GroupInfoFlag and the fields currentGSN, firstGSN, lastGSN. writerSet and secureWriterSet. A specification for this flag and the fileds is missing in the PSM.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 13:20 GMT
  • Updated: Tue, 18 Feb 2020 15:47 GMT

flag GroupInfoFlag and fields gapStartGSN and gapEndGSN unspecified in PSM

  • Status: open  
  • Source: N/A ( Frans Schneider)
  • Summary:

    In the message module, the submessage gap defines the flag GroupInfoFlag and the fields gapStartGSN and gapEndGSN. However, in the PSM, both this flag and the two fileds are not specified further.

  • Reported: DDSI-RTPS 2.3 — Fri, 7 Feb 2020 12:28 GMT
  • Updated: Tue, 18 Feb 2020 15:47 GMT

PSM and PIM description of Gap message not matching

  • Status: open  
  • Source: S2E Systems ( Joao Rebelo)
  • Summary:

    The wire representation of the GAP message given in 9.4.5.5. does not match the logical PIM description given in the sub-clause 8.3.7.4 in the following points:

    • Section 9.4.5.5.1 mentions that "This Submessage has no flags in addition to the EndiannessFlag". Section 8.3.7.4.2 describes "GroupInfoFlag" with the following text "Appears in the Submessage header flags"
    • "gapStartGSN" and "gapEndGSN" sequence numbers do not appear in the wire representation
  • Reported: DDSI-RTPS 2.3 — Mon, 11 Nov 2019 20:45 GMT
  • Updated: Mon, 11 Nov 2019 20:51 GMT

Update Acknowledgemts, Copyright and Statement of Proof

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    Section 6.3 'Acknowledgments' lists the companies that contributed to the spec. This list needs to be updated to include the companies that contributed to the latests revisions (e.g. as members of the RTF task forces). This includes TwinOaks, Kongsberg, OCI, ADLink, MITRE, NSWC, etc.

    We may also want to list contributor's names as we do for other specs.

    Section 6.4 'Statement of Proof ...' needs to be updated this text has been carried from the original version. Something much stronger can be said today.

    Copyright should be updated to include the companies in the 'Acknowledgments'

  • Reported: DDSI-RTPS 2.3b1 — Tue, 24 Sep 2019 21:23 GMT
  • Updated: Tue, 24 Sep 2019 21:23 GMT

Incomplete specification of how a Publisher and Subscriber are identified

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:56 GMT
  • Updated: Sat, 2 Mar 2019 19:58 GMT

Unclear specification on how the Publisher GUID is communicated

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The specification uses a field called remoteGroupEntityId (see Table 8.67) to identify Publishers and Subscribers.

    Furthermore it specifies that this s communicated using a PID_ENDPOINT_GUID.

    It seems that this is related to PID_GROUP_GUID.
    But Table 9.14 says that PID_GROUP_GUID is "reserved for future versions"

    The relationship between this should be clarified.
    Furthermore the implementation of GROUP order and coherent access (8.7.5 and 8.7.6) require knowledge of which DataWriter belong to which Publishers. But how this is discovered is not specified.

    Minimally we should say that:

    A Publisher has a GUID that should be constructed from the GuidPrefix_t and an Entity_id.

    The PublisherGUID shall be communicated vis discovery using either a PID_GROUP_ENTITYID or PID_GROUP_GUID

    The WriterProxy::remoteGroupEntityId should contain the Publisher GUID

  • Reported: DDSI-RTPS 2.3b1 — Sat, 2 Mar 2019 19:57 GMT
  • Updated: Sat, 2 Mar 2019 19:57 GMT

Discriminating the reasons for a GAP

  • Status: open  
  • Source: Real-Time Innovations ( Gerardo Pardo-Castellote)
  • Summary:

    The GAP message indicates a gap in sequence numbers that is "not available" to the DataReader. It may be caused by filters (time, content), history keep last, or lifespan.

    In some cases the reason behind the gap is important to the receiving application. For example a missing sequence number caused by a writer-side content filter does not invalidate a coherent change. However if the gap is caused by keep-last history the coherent change must be discarded by the subscriber/reader.

    Currently there is no way for the receiving application to tell the difference.

    There may be also other situations where it may be desirable to account for the different reasons that cause a gap. For example if the reader maintains a "sample lost count" it needs some way to distinguish sample loss from things it it chose to not receive.

    The RTF should address this issue and provide the means to discriminate these cases. A possible approach would be include the information in the flags of the GAP message.

  • Reported: DDSI-RTPS 2.3b1 — Thu, 28 Feb 2019 02:41 GMT
  • Updated: Thu, 28 Feb 2019 02:41 GMT