-
Notifications
You must be signed in to change notification settings - Fork 32
PDU Headers
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.
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.
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.
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.
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.
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.
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.
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.