Skip to content

PDU Headers

mcgredonps edited this page Oct 25, 2018 · 13 revisions

There are dozens of PDUs, but remember that every one of them in DIS starts with the same few fields. You can think of the header as the superclass that all subclasses possess. Remember again that the programming language representation of the problem in DIS can work with any network traffic. The language implementation need not have inheritance in their language.

Remember, Wireshark has good features to interpret DIS PDUs. You can start up a DIS PDU and see what each of the applications are doing.

Field Name Data Type Purpose
Protocol Version 8 bit enumeration Version of DIS; often 6 or 7
Exercise ID 8 bit unsigned integer ID if this simulation
PDU Type 8 bit enumeration Type of message
Protocol Family 8 bit integer Group PDU belongs to
Timestamp 32 bit unsigned integer Time PDU was sent
Length 16 bit unsigned integer How many bytes in message
PDU Status 8 bit record Used to add information to certain PDUs
Padding 8 bits unused Unused, save for later designs

This fields are at the start of every one of the dozens of PDUs. The the values inside these fields vary. An Entity State PDU will always have a "PDU type" field value of 1, the "Fire PDU," involving shooting at others, will always have a PDU type value of 2, and so on.

Protocol Version

As with many software implementations new and updated software is sometimes released. In the case of DIS, there are typically three versions of DIS that some use by developers.

DIS Protocol Version 5 is is a IEEE standard of DIS introduced in 1995. The binary value for 5 is placed in the field. Version 5 is somewhat rarely seen in lab applications, but they are seen.

DIS Protocol Version 6 was introduced by a later IEEE version in 1998. It corrected some ambiguous or incorrect implementations of DIS. It is likely the most seen version of DIS used in applications.

DIS Protocol Version 7 was approved by SISO and IEEE in 2012. It introduced some new PDUs related to energy emissions for military action.

This information can be important. DIS versions are typically backward-compatible, but not always forward-compatible. Version 7 implementations can usually handle version 6 messages, but version 6 and be confused by new messages sent by version 7 energy emission PDUs.

DIS version 7 added the PDU Status field. That was not present in versions 5 and 6.

Exercise ID

On any given network there may be multiple copies of a single simulation running. Perhaps there was a single given application may have five copies running on the same network. This can introduce confusion, and we would want some way for the first copy to distinguish itself from copies two, three, four, and five. This is what the Exercise ID and do in UDP traffic. When we start the application we can specify a unique number for each copy of the simulation.

PDU Type

Every type of PDU in DIS has a different number assigned to it. The Entity State PDU has a value of 1 in this field, for example. Simulations that receive a binary format PDU can peak at this binary field, decode the value, and then parse the rest of the PDU accordingly. Once we decode the value we know what we need to do to decode the rest of the PDU.

Timestamp

The Timestamp field relates to when the PDU was sent. It's a 32 bit field, and the subject discussed is complex. In fact, some different users simply choose different timestamp advancement techniques. It can be used to determine which PDU was sent first; if send via UDP networks, the PDUs might not arrive in the same order they were sent.

One implementaton is are two versions of time saved, one based on absolute time values, and another based on the sender's local clock time. The field itself represents units of time that have passed since the start of the hour, which means that the value of the field will drop at the start of the hour.

The major desire is that time advances, period. The timestamp field can be used to detect UDP events such as duplicated, doubled, or out of order packets. Remember, UDP packets can be any of these things. If we receive two Entity State PDU (ESPDU) with exactly the same timestamp we expect that we have received duplicate packets, and simply drop one.

The timestamp field is discussed in greater depth elsewhere. The 1278.1 standard runs at nearly a chapter of work. There is more to the subject. Section 4.6 in IEEE-1278.1 contains a long discussion.

Length

Some PDUs are of variable length. The length field tells us exactly how long the PDU is, from the start of the PDU to it's end. In some cases network packets contain several PDUs; knowing the exact length of each PDU in the packet helps us decode the entire set of several PDUs.

PDU Status

This is also a somewhat complex topic that needs more space to explain. It is primarily used to help multiple simulations work with which traffic has different features.

Padding

The PDU header was originally sent with 16 bits of unused space. This was intended to allow some later expansions of headers and cause few problems in backward compatibility. DIS version 7 used 8 of the original 16 bits to implement the PDU Status field, and there are 8 bits that are still unused. The standard is to always zero out the padding fields.

Remember, all PDUs start with the same set of fields listed above. There is a free utility called WireShark that can be used to capture network traffic and decode the PDU fields, including the PDU header fields.

Clone this wiki locally