All JEEP packets shall include a fixed length header, followed by a variable length payload. The figure below shows how the JEEP packet is embedded within the standard SpaceWire packet. Note that while a SpaceWire packet may have zero or more destination addresses before the JEEP header, the JEEP requires that exactly one destination address be delivered to the protocol logic.
The first byte of the header shall contain the Destination SpaceWire Logical Address (SLA) field that is associated with the destination TEP to which the packet is being sent.
The second byte of the header shall contain the SpaceWire Protocol ID field and is assigned a value of decimal 248 (TBD) by the ECSS.
The third byte of the header shall contain the Packet Control field.
Protocol Version Number
The two most significant bits of the Packet Control field shall contain the protocol version number of the JEEP protocol specification to which the format of the packet complies. These bits shall be set to 0b00 (0) for this version of the specification.
A two-bit field of Sequence Flags (bits 3-4) of the Packet Control field is used to signal the first, intermediate, and final packets in a series of JEEP packets that collectively represent a data buffer. The Sequence Flags are set by the transmit TEP during segmentation and are used by the receive TEP for data buffer reassembly.
|First packet of the buffer||1|
|Last packet of the buffer||2|
Buffer Sequence Flag Values
Data Content Type
The four least significant bits (0-3) of the Packet Control field shall identify the data content of the packet.
|Data Content Type||Value|
Packet Type Values
The Payload Length field in bytes four and five of the header specifies the number of bytes in the Payload field and is a 16-bit value. It does not include any bytes in the JEEP header.
The fourth header byte shall contain the most significant byte of the Payload Length field and the fifth header byte shall contain the least significant byte of the Payload Length field.
The maximum size of the Payload field shall be constrained to be the MTU size minus the maximum size of the header. It shall also not be greater than 65536 bytes.
Application IDs are 16-bit values that uniquely identify a sending or receiving application and are primarily used when the data content of the JEEP packet contains raw bytes. These IDs may be used by higher-level software layers for routing the data to appropriate receiving applications while also identifying the data source. Application IDs are implementation dependent and are generally used and assigned in the application layer.
|Application ID Type||Definition|
|Destination Application ID (DAPID)||A destination application ID is a 16-bit value that uniquely identifies the application to receive the packet. The sixth byte of the header shall contain the most significant byte of the DAPID and the seventh byte of the header shall contain the least significant byte of the DAPID.|
|Source Application ID (SAPID)||A source application ID is a 16-bit value that uniquely identifies the application sending the packet. The eighth byte of the header shall contain the most significant byte of the SAPID and the ninth byte of the header shall contain the least significant byte of the SAPID.|
Application ID Definitions
Cyclic Redundancy Check (CRC)
The 8-bit CCITT CRC shall be computed for the preceding nine (9) header bytes according to the following polynomial:
Prior to computing each packet’s CRC, the initial value for the computation shall be set to all 1s.
The protocol’s packets shall contain a Payload field containing from 0 to N bytes of content for delivery to the receive TEP. The maximum value for N is the MTU size minus the size of the header or 65536.
"Internal Standards developed by Sandia National Laboratories". Experience Base, Sandia National Laboratories, Albuquerque, NM, 0000.