JAS Packet Service

Error: unable to migrate element with tag=""

The CCSDS/SOIS subnetwork packet service standard can be referenced if a generic packet service is needed. The JAS Packet Service is an implementation of the CCSDS/SOIS packet service, specifically tailored for the JAS packet.

The following diagram shows how the JAS Packet Service fits into the overall communication stack. JAS packets provide a method for encapsulating any type of data so it can be communicated between applications. The JAS Packet Service uses JAS packets to encapsulate and describe the data. It also ensures enough metadata is delivered to enable decoding by the receiving applications. JAS packets provide a standard and independent format that can be used with any data link.

Applications provide data and communication parameters to the JAS Packet Service. The JAS Packet Service is responsible for packaging application data with the appropriate metadata so it can be routed to the correct application at the destination processing element. It provides functions such as data segmentation and reassembly, packet creation and parsing, and data sequencing.

The packet service routes the data to the appropriate protocol based on the Quality of Service (QoS) parameters. The protocols segment the data for the network, create the data link packets, apply sequencing, and buffer the data if necessary. Data segmentation is based on network requirements such as the use of a Maximum Transmission Unit (MTU) size. Data buffering depends on the protocol, but is typically used to support retransmission requirements in a reliable delivery protocol. The example shows that JAS packets can be routed to SpaceWire, Serial RapidIO (SRIO), or Ethernet protocols suggesting that the packet service can support multiple data links. Routing is determined using abstract application identifiers provided by the applications. This design is slightly different than the approach described in the CCSDS SOIS standards which suggest using a specific packet service for each type of data link. This approach eliminates the need for applications to know which data link they are potentially using. Instead lookup tables can be used at lower levels of the communication stack to determine the exact routing.

The protocols send the data to their respective data link interfaces for communication across the network. Priority and resource reservation are handled at a system level, which means these functions are provided at the data link layer as the data comes together from potentially different protocols. Implementation of priority and resource reservation within JAS is optional and system specific. Some data links may support priority and resource reservation inherently, such as SRIO, and others may not, such as SpaceWire. If needed, a simple method for implementing priority is to use a priority queue at the data link interface and assign each data link packet a priority level. Resource reservation can be implemented using a time multiplexed or bandwidth based approach. JAS systems should be able to support either if necessary, but there is no specific standard defined for JAS at this time. A simple method for implementing guaranteed bandwidth is to create a set of channels for a particular data link. Data link packets get assigned to a specific channel and then data is pulled from the channels and written to the data links based on the percent of bandwidth that is allocated to the channel.

Implementation Approach

The following diagram describes the implementation approach for the JAS Packet Service and shows how it maps to the CCSDS SOIS packet service standard. It shows the communication service layers from applications to data links and describes the information provided at each layer and how it is used. At each service layer, information is provided through lookup tables or argument parameters that are passed to route the data through the communications stack. The left hand side of the diagram, the transmit side, describes the information used going down the stack and the right hand side, the receive side, describes the information used going up the stack. These paths correlate to the request and indication primitives described in the CCSDS SOIS memory access service standard.

Lookup tables are stored in configuration data files and provide much of the information that is needed. This is referred to as Management Information Base (MIB) within the CCSDS SOIS standards. Using a MIB reduces the need to hardcode the data into applications making them more reusable. MIB data is typically stored in nonvolatile memory separate from applications and read in upon startup. The details are implementation specific.

Application identifiers (APIDs) are used to route data within a system. Unique APIDs shall be assigned to every application within the system that will send or receive data. Source APIDs (SAPIDs) and destination APIDs (DAPIDs) map directly to a header field in a JAS packet. An application may have more than one APID assigned to it which allows it to receive data from different data links. Since APIDs are used to route data through a communication stack, one can be used to route data across SpaceWire and another over SRIO, as an example. This is also what allows a single JAS packet service to support multiple data links. APIDs map directly to the PSSAP and PDSAP parameters defined within the CCSDS SOIS packet service standard.

QoS attributes relate directly to the service class, channel and priority within the CCSDS SOIS standard. The use of QoS values is optional in JAS and based on the needs of the program. These parameters drive the network and data link protocols features that will be used. They shall be provided for consistency but can be ignored if not used.

Lookup tables are used by the services to facilitate passing data between the layers of the communication stack. The use of these lookup tables is specific for each data link. For example, SRIO may encapsulate the protocol and data link functions within a single interface, while they may be separate and distinct functions for SpaceWire. The mechanism for passing data between the layers is implementation specific, but it is expected that the APIDs and QoS parameters will be used as indexes into the lookup tables to determine how data ultimately gets transmitted on the data link. On the transmit side, the packet service lookup table and data link lookup table will be indexed by the DAPID and the protocol lookup table will be indexed by the service class QoS parameter. On the receive side, the protocol lookup table is indexed by a protocol identifier that is part of the data link packet, assuming the data link supports more than one protocol. The packet service lookup table is indexed by a data identifier that is part of the protocol packet. Finally, the application lookup table is indexed by a data identifier and/or a DAPID that is part of the JAS packet. Using the data identifier allows routing to multiple destination applications and using the DAPID allows routing to a specific application.

There are additional parameters passed between applications and the JAS packet service which are used within the packet header fields of a JAS packet. These fields are not specified in the CCSDS SOIS packet service standard but are specific to the JAS packet service which is an implementation of the CCSDS/PUS standard. The main parameters are the service type and service subtype, which identifies the data in the packet, and the transaction identifier, which can be used if handshaking is required between applications. Refer to the JAS packet specification to see a complete list of parameters and a description of how they are used.

Error Handling

A variety of errors may exist throughout the communication process. Errors should be handled at the lowest level of the communication stack as possible. For example, hardware errors, such as resetting a data link, should be handled at the data link level. Errors should only be propagated up to applications as needed. The CCSDS SOIS packet service specifically identifies errors related to the unsuccessful delivery of data transmitted with the guaranteed or assured service classes. This means that a reliable protocol failed to deliver the data even with multiple retries. Applications sending data may need to know this for a variety of reasons. For example, if the data was a critical command, the application may need to take additional action or alert operators if the command failed to be received and/or executed. Other error conditions may be useful to pass up to applications, and nothing should preclude adding error conditions if needed.

Programs shall define the set of error conditions that are appropriate to propagate up to applications and share this information to application developers. For flexibility, error identifiers should use a lookup table approach where an error number is sent to the application and additional information on actions can be provided in the table. An example would be to use an approach similar to the standard set of errors returned by the “errno” flag, which is available in many programming languages such as C & C++. Additional metadata should be made available to applications if needed. For example, the packet service may provide a unique tracking number for the packet that failed to be delivered. The tracking number can contain a combination of fields that were originally passed in from applications to the packet service such as APIDs, services types and subtypes, and transaction identifiers. The specifics of what metadata will be used shall be defined by the program, and it shall be documented and provided to each application as part of the packet service interface definition.