1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Time Critical Onboard Network Services Working Group Meeting Washington, USA October 2003
Date: 27th-30th October 2003
Approved:
Steve Parkes (UoD/ESA) ______
Time Critical Onboard Network Services Working Group 1 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
WG Chair Date
Jane Marquart (GSFC/NASA) ______
Deputy WG Chair Date
Patrick Plancke ______
Area Director Date
Time Critical Onboard Network Services Working Group 2 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
1 Introduction...... 5 1.1 Responsibilities of TCONS...... 5 1.2 Working Group Membership...... 5 1.3 Scope of TCONS Working Group Activities...... 6 1.4 Network Layer...... 6 1.5 Transport Layer...... 7 1.6 Existing Protocols...... 8 1.7 Objectives of the Working Group...... 9 1.8 Planned Schedule...... 9 1.9 Current Activities...... 10 2 October 2003 Meeting...... 10 2.1 Summary of TCONS activities during meeting...... 11 2.2 Monday 27/10/03 and Tuesday 28/10/03...... 11 2.2.1 Split of responsibilities...... 11 2.2.2 Sub-Network Independent...... 12 2.2.3 Sub-Network Dependent...... 14 2.2.4 Schedule table...... 15 2.2.5 Retry and Redundancy...... 15 2.2.6 Header size reduction...... 16 2.2.7 Use Cases...... 17 2.3 Wednesday 29/10/03...... 17 2.3.1 QoS Parameters...... 17 2.3.2 PDU Format...... 18 2.3.3 SDU Formats...... 18 2.3.4 QoS Fields...... 20 2.3.5 Asynchronous channels...... 21 2.4 Thursday 30/10/03...... 23 2.4.1 Driving Requirements...... 23 2.4.2 Buffer schemes...... 23
Time Critical Onboard Network Services Working Group 3 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
3 Appendix – Diagrams exploring addressing and QoS...... 24
Time Critical Onboard Network Services Working Group 4 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
1 Introduction The meeting in Washington from 27th – 30th October 2003 was the first meeting of the Time Critical Onboard Network Serives (TCONS) working group since the reorganisation of the SOIF (Spacecraft Onboard InterFaces) into the SOIS (Spacecraft Onboard Interfaces Services) group. This document presents work in progress and is does not represent a proposed standard or specification.
1.1 Responsibilities of TCONS The responsibilities of the Time Critical Onboard Network Services (TCONS) working group are as follows: 1. Identify a set of standard network and transport layer services that should be provided to enable inter agency cross support in the onboard domain and which support time critical onboard applications; 2. Specify the layer management parameters that may be used to control the operation of the network and transport layers of the onboard communication stack; 3. Define layer management procedures for the control of configurable parameters and the reporting of errors; 4. Make representations to the other Working Groups and BOFs about the use of the onboard network and transport layer services in real systems; and 5. Address the issue of onboard to off-board communication and develop recommendations for inter-operation between the onboard systems with other off-board systems, including the ground. The responsibilities were presented and accepted by the working group members at the meeting.
1.2 Working Group Membership The working group membership at the time of the October 2003 meeting is listed below: Max Ciccone ESA - ESTEC Jane Marquart NASA – GSFC (deputy chair) Greg Menke NASA - GSFC Stuart Mills UoD Steve Parkes UoD / ESA (chair)
Time Critical Onboard Network Services Working Group 5 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Rick Schnurr NASA - GSFC
1.3 Scope of TCONS Working Group Activities The work being done by the TCONS working group covers the end to end transfer of information or messages across an onboard data communications network which may comprise one or more different forms of sub-network. The end-points are processors, memory units, sensors, telemetry and telecommand units and related onboard equipment that requires the services of an onboard communication network. More specifically the end-points may be processes running on these processors or other equipments. The sub-networks from which the onboard network is constructed may include low data rate sensor buses like I2C and SPI, medium rate data buses like MILSTD 1553 and CAN bus, high speed buses like IEEE 1394 or USB and high speed networks like SpaceWire and Ethernet. A primary aim of the TCONS working group is to specify transport and network layer protocols which allow these disparate buses and networks to interoperate allowing a homogeneous end-point interface to the potentially heterogeneous communication mechanisms being used to carry information between end-points. The TCONS activity is responsible for two layers of the onboard communication network: the transport layer that provides end-to-end information transfer and the network layer that provides a “datagram” delivery service across the different sub-networks. Included within these layers are the corresponding network management services used to control the operation of the onboard transport and network layers. TCONS is not responsible for communications off a spacecraft. It may be responsible for carrying other protocols that have one end-point off the spacecraft and another one somewhere on the spacecraft. TCONS protocols must be able to carry CCSDS off- spacecraft protocols like SCPS TP/NP. The “Time Critical” responsibility of TCONS extends to low latency, priority driven asynchronous services and isochronous, deterministic delivery services.
1.4 Network Layer The SOIS Network layer transfers packets of information across an underlying onboard network comprising one or more sub-networks. It provides asynchronous datagram delivery service with no guarantee about delivery or the order of delivery and an isochronous datagram delivery service which ensures deterministic delivery (i.e. delivery with a certain amount of time). The Network layer is responsible for: Address translation from network logical address to physical address. Fragmentation and de-fragmentation of datagrams to suit a particular sub- network. Note that any fragmentation is to be contained with the sub-network that
Time Critical Onboard Network Services Working Group 6 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
implements fragmentation i.e. fragmentation on entry to a sub-net is followed by de-fragmentation on exit from the sub-net. Multiplexing various network protocols across underlying network QoS at the network level which include o Deterministic delivery of datagrams when required o Priority based forwarding of datagrams when required Fault management
1.5 Transport Layer The SOIS Transport layer transfers packets of information from one end-point to another end-point using the network layer services to move segments of the information across the onboard network. It provides a guaranteed, connection-oriented service where the arrival of information sent to a destination is ensured, with no parts of the information missing or in the wrong order. It also provides a non-guaranteed, connection-less service delivers information on a best effort basis without ensuring the arrival or order of arrival of the information. The Guaranteed, Connection-Oriented Service is responsible for: End-to-end connection Connection flow control Order preservation Error recovery and reporting Connection QoS The Non-Guaranteed, Connectionless Service is responsible for: Sending Data Units Receiving Data Units Error statistics Connectionless QoS A connection-oriented services is defined as one where one or both end-points keep state information about the connection e.g. waiting for acknowledge at the sending end or missing datagrams at the receive end. Keeping this state information about the connection binds the two end-points together until the connection is terminated.
Time Critical Onboard Network Services Working Group 7 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
1.6 Existing Protocols An initial investigation of relevant exiting network protocols were considered for use as the CCSDS onboard transport and network protocols, prior to the establishment of the TCONS working group. TCP/IP and SCPS TP/NP were considered. There were several potential problems identified with these protocols: Large overhead for small packets – The TCP/IP header is 40 bytes in total. This can impose a significant overhead for small packets. This has to be balanced with the potential packet handling rate of an end-point. That is, if an end-point can only handle packets at a certain rate it may not be able to make use of the available communication bandwidth when sending small packets. For example if 100 byte packets are being sent to an end-point that can handle 10,000 packets per second then the maximum bandwidth being used is 10 Mbits/s, even if the link can support 100 Mbits/s. Adding a large header to this 100 byte packet would increase the necessary bandwidth, but if that bandwidth is available in the communications link then there is no problem. Complex protocols can reduce the packet handling rate even if header overhead is kept small. There is a need for a balance between packet handling speed and header size. It may be advantageous to increase the header size, if this simplifies the packet handing and increases the packet handling rate. The achieved data rate may then be higher for a small packet even though the header is bigger. The network and transport layer headers should be structured to support simple, rapid packet handling. Latency – Onboard communications often require low latency, which is normally achievable with an onboard network. Use of TCP/IP can result in high latency due to the buffering mechanisms employed. Careful buffer management is important to achieve low latency. Retry mechanisms in TCP/IP are slow. Determinism – TCP/IP is an asynchronous transport/network protocol. While priority may be included in QoS fields no attempt at deterministic data delivery is made in TCP/IP. Deterministic delivery requires guaranteed access to network resources. This is normally achieved by some time division multiplexing method which allocates communication slots for particular end-to-end communication. Support for fault tolerance – Management of network failures (links, routers and nodes) is essential for a spacecraft network. Recommendations for fault tolerant architectures. Rapid repair of a network failure essential where possible. Retry mechanisms in TCP/IP are slow. Router table updating is slow. QoS – Quality of Service is something of an afterthought in TCP/IP. Flow control mechanisms are used to provide congestion control by backing off an increasing amount of time when receipt of a packet is not acknowledged. Packet loss is assumed by TCP/IP to be due to congestion.
Time Critical Onboard Network Services Working Group 8 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
1.7 Objectives of the Working Group The objectives of the TCONS working group are: To define the requirements for the TCONS services which include the requirements of the SOIS Transport and Network layers and the network management requirements To provide a definition of the TCON Services which must support time critical applications, be interoperable and provide for inter-agency cross support. Network management services must be defined to configure, control and report the status of the network. To prove the defined services through simulation and prototyping done by different groups using different underlying sub-networks. To consolidate the results of the simulation and prototyping and update the TCON Service definitions accordingly To ensure coherency with work of other SOIS working groups, in particular the Time Critical Onboard Applications and Time Critical Onboard Bus and LAN working groups and those CCSDS groups working on off-board communication.
1.8 Planned Schedule The planned schedule for the TCONS working group activities is shown in figure xx. This is dependent upon appropriate resources being available to the TCONS group.
Time Critical Onboard Network Services Working Group 9 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
3Q034Q031Q04 2Q043Q044Q041Q05 2Q053Q054Q05
Network Requirem ents
Network Services
Managed Parameters
Managem ent Services Simulation and Protyping Finalise Red Books
Meetings
1.9 Current Activities The present activities of the TCONS working group include: Network Layer Green Book which covers the Network layer requirements. Draft C has been issued. Transport Layer Green Book which covers the Transport layer requirements. Draft D has been issued Effort is currently concentrating on QoS and deterministic delivery services. The intention is that these services are to be as generic as possible 2 October 2003 Meeting The aims of meeting in October 2003 were to: Review the aims of TCONS working group Rationalise work on prototypes by UoD and GSFC Push forward definition of TCON services
Time Critical Onboard Network Services Working Group 10 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
2.1 Summary of TCONS activities during meeting The activities covered by the TCONS group during the meeting are summarised below: The split between Sub-Network Independent Layer and Sub-Network Dependent Layer was examined. This addressed the distribution of responsibility between border between work being done by TCONS WG and the Onboard Bus and LAN WG. It was clear that particularly close cooperation between these two groups was necessary. The types of time-critical services and the QoS requirements needed for onboard applications were considered. Work was done on the definitions of service primitives, protocol data units and service data units. The SEA group meeting was attended by representatives from the TCONS and TOBL groups and inputs from this meeting were fed back to the rest of the TCONS working group. The main comments were: Onboard destination address and Onboard Source Address must not come out of the SOIS Transport Layer and the channel concept being developed, based on concepts from USB, was not recommended by SEA. Efficient buffer management was explored with send and receive queues using the zero copy principal as far as possible to avoid wasting processing resource copying data. A technique using a Message Sequence Number and a Packet Sequence Offset Number was developed and explored. This appeared to provide a high degree of efficiency The following subsections summarise the work done by the group on each day of the meeting.
2.2 Monday 27/10/03 and Tuesday 28/10/03 Work on Monday began with a reorientation session where the slit of responsibilities between the TCONS and TOBL working groups was examined. The sub-network independent and dependent layers were then considered in detail, exploring their responsibilities and interfaces. The schedule table for isochronous communications was then considered followed by retry and redundancy, header size reduction and finally use cases.
2.2.1 Split of responsibilities The original split between Inter-Network and Intra-Network layers was: Inter-Network Layer o Datagram delivery o Addressing
Time Critical Onboard Network Services Working Group 11 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
o Routing o Fault Management Intra-Network Layer o Address translation o Fragmentation o Protocol multiplexing o QoS This split of responsibility was clarified through the definition of sub-network independent and sub-network dependent layers. The aim is to provide a convergence layer which is independent of the underlying bus/network and which provides a common service interface to the layers above, that use the TCON services.
2.2.2 Sub-Network Independent The sub-network independent layer provides the services which are independent of the underlying bus/network. It has to provide three principal services: The asynchronous connection-oriented service provides reliability (guaranteed delivery), ordered delivery and end to end flow control. The asynchronous connection-less service delivers data on a best-effort basis only, without any guarantees about delivery. The isochronous service provides deterministic delivery of information across the network. It employs isochronous scheduling – from static schedule table.
2.2.2.1 Interfaces from above The services provided by the sub-network independent layer are as follows: Asynchonous connection-oriented Priority based asynchronous communications Open a channel – with QoS parameters Close a channel Send a message Receive a message Features include: o Flow control
Time Critical Onboard Network Services Working Group 12 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
o Buffer management o Retry o Acknowledgement o Order preservation Asynchronous connection-less Priority based Send a datagram Receive a datagram Features include: o No need to set up a channel o No retry or flow control o If a receiver is not ready or does not have buffer space the packet is thrown away o No order preservation o All async connectionless datagrams have same QoS o But they can be prioritised? Isochronous Schedule table based o Communication channels assigned one or more slots in the schedule Schedule tables: o Static scheduling tables o Set in each node by network manager at initialisation time Send a datagram on a particular isochronous channel Receive a datagram Features include: o Limited buffering o Flow control through slot assignment? o Or receive datagram sets up a buffer for a particular channel o If receive buffer not set up then discard datagram?
Time Critical Onboard Network Services Working Group 13 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
o Deterministic e.g. delivery within 4 or 5 ms o Dependent layer and it will send whatever is asked o Time (tick) distribution (e.g. 1 s)
2.2.2.2 Interfaces to below The sub-network independent layer provides the following interfaces to the sub-network dependent layer: Asynchronous priority queues Isochronous packet to be sent on next slot(s): The dependent layer needs to tell independent layer the data rate it can support i.e. the amount of data per slot together with the slot size.
2.2.3 Sub-Network Dependent The sub-network dependent layer provides the parts of the network layer which are dependent upon the underlying bus/network, including: address translation from logical to physical addressed, fragmentation/de-fragmentation and retry for isochronous services.
2.2.3.1 Interface The interface to the sub-network dependent layer comprises the following primitives: Send PDU Receive PDU Link Status Link Control
2.2.3.2 Different types of service The sub-network dependent layer is not required to implement all the different types of service that is could provide. For example a sub-network dependent implementation could provide: Asynchronous services, Prioritised asynchronous services,
Time Critical Onboard Network Services Working Group 14 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Asynchronous services provided using slots in an isochronous bus, Isochronous services, or a combination of asynchronous and isochronous services.
2.2.4 Schedule table Thought was give by the group on which layer an isochronous schedule table should be in? If the schedule table is in the dependent layer then the schedule table becomes specific to each bus. For a router between two or more sub-networks there is the need to have multiple scheduling tables one for each sub-network, giving rise to the possibility of conflict. If the schedule table is in the independent layer it provides single scheduling table on each node covering several buses. For this reason it seems best to have the schedule table in the independent layer.
Schedule Table Predefined Managed
Tim e slots
Isoc. Channel 1 2 3 4 5 6 7 8 Channel Mapping
A SA,D A,SP ,DP
B
C
D
E
F
G
2.2.5 Retry and Redundancy The working group spent some time discussing approaches to retry and redundancy.
Time Critical Onboard Network Services Working Group 15 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
The asynchronous connection-less service does not care if a packet does not arrive. There is no retry. The asynchronous connection-oriented service keeps track of what data has been sent and received using acknowledgements. If no acknowledge is received within a timeout interval then the PDU is resent (retry). The dependent layer is responsible for failure detection, the independent layer performs the retry and a network manager is responsible for any the management of redundancy and any necessary reconfiguration. The isochronous service has to provide the retry is done in the dependent layer to ensure that the deterministic delivery time is met in the case of a packet being corrupted and a retry being necessary. Slot bandwidth must be allocated for retry a priori. An alternative approach to retry and redundancy is to provide some form of redundant transmission where the packet is sent simultaneously over two or more redundant links at the same time. In this case no retry is necessary since it is assumed that both links will not fail at the same time. The destination must sort out the duplicate packets and only pass one of them to the application.
2.2.6 Header size reduction Header size reduction was considered to make the transfer of small packets more efficient. This is particularly relevant to send small commands (e.g. 4 bytes) and reading individual sensor or status values. Address Field: One byte or two bytes 1st byte o Bits 6:0 ls bits of node address o Bit 7 flag when set indicates that there are two address bytes 2nd byte o Bits 7:0 ms bits of node address One byte address gives 128 addresses Two bytes give 32k addresses Channel ID Field: Use same scheme as for addressing to give 128 channels with one byte 32k channels with two bytes Length: Again use same scheme as for addressing to give
Time Critical Onboard Network Services Working Group 16 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
128 bytes packet length with one byte 32k bytes packet length with two bytes
2.2.7 Use Cases Potential use cases for evaluating the TCONS protocols were considered: Guaranteed message delivery Guaranteed message delivery with priority Non-guaranteed packet delivery Deterministic packet delivery Reserved bandwidth i.e. guaranteed bandwidth Getting data from a dumb unit
2.3 Wednesday 29/10/03 On Wednesday the group was slit with two members (Jane and Rick) attending the SEA meeting and the rest of the group continuing with the technical work. QoS was examined and then effort was spent on defining an initial set of PDU and SDU formats.
2.3.1 QoS Parameters Asynchronous connection-less Priority on send and receive? Asynchronous connection-oriented Priority Time-out, number of retries – only used for errors not flow control Depth of send queue Depth of receive queue Implied flow control Isochronous Schedule table o Bandwidth allocation o Deterministic delivery
Time Critical Onboard Network Services Working Group 17 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Depth of send queue, over-write policy (newest, oldest) Depth of receive queue, over-write policy (newest, oldest) Time-out, number of retries – only used for errors not flow control Note : Queues are in end points only, routers only buffer slots
2.3.2 PDU Format The main principal behind deriving the PDU format was to ease the packet handing. Fields in the header come in the order in which they are expected to be used. The PDU formats discussed are illustrated in figure xx. PDU Format
Async, Connection-Oriented, Guaranteed
ODA QoS OSA CH DATA CRC
Async, Connection-Less, Non-Guaranteed
ODA QoS OSA SP DP DATA CRC
Ma y be 4-bit 4-bit ODA QoS OSA SP DP DATA CRC
Isoc, Connection-Oriented, Guaranteed
ODA QoS OSA CH DATA CRC
The destination address (ODA) is needed by any intermediate routers so that the router knows where to forward the PDU. The QoS field is also needed by the routers so that they can provide the appropriate QoS. For example PDUs with high priority should be forwarded before those with low priority. The source address (OSA) and channel identifier (CH) or source port and destination port are needed to determine which process or which queue in the destination node the PDU is for.
2.3.3 SDU Formats Outline SDU formats were devised for each of the required services.
Time Critical Onboard Network Services Working Group 18 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
2.3.3.1 Async Connection-less Send
Receive
2.3.3.2 Async Connection-Oriented Open
Send
Receive
Close
2.3.3.3 Isochronous, Connection-Oriented Open
Send
Receive
Time Critical Onboard Network Services Working Group 19 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Close
IOCTL
2.3.4 QoS Fields Some consideration was given to the QoS fields needed in the PDU/SDUs. There are four classes of QoS:
QoS Class 00 Async, connection-less
01 Async, guaranteed 10 Isochronous, not guaranteed 11 Isochronous, guaranteed
The QoS fields are as follows:
Time Critical Onboard Network Services Working Group 20 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
QoS Fields QoS Class Priority NACK Retry
Async, connection-less QoS Class Priority 0 0 P P P P X X
Async, guaranteed QoS Class Priority NACK 0 1 P P P P N X
Isochronous QoS Class NACK Retry 1 X N R
Previously it had been intended that QoS would be negotiated when a communication channel was set up. It became apparent that this was overly complicated and required extensive QoS tables in each router (see appendix). It was decide that it would be more efficient to send the QoS field with the packets. This avoids complicating the routing tables with channel based QoS and means that the source, routers and destination can respond to the required QoS rapidly. QoS parameters fall into two types: End-to-end QoS Parameters. E.g. time-out, number of retries, which are held at the end-points only. Routers do not need to know about these QoS parameters. QoS Parameters Needed by Routers. E.g. priority, which are passed in packets and can be rapidly accessed and acted upon by each router.
2.3.5 Asynchronous channels Using a single byte for channel identification gives a maximum of 256 channels between source and destination address pair. If more are needed then it is possible to “multi- host”, i.e. have two or more addresses on a single node, but this is rather complex. Channel numbers only exist in end points. Channels effectively map source and destination ports into a single 8-bit number. Channel number 0 is reserved for network configuration information.
Time Critical Onboard Network Services Working Group 21 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
The diagram below shows an example network,
R1 End s ys tem (ES) End system (ES)
N1 Interm ediate Systems N2
DA/QoS DA/QoS/S A/CH PA/QoS PA/QoS R2
CH = source/des t port Routing Table DA Bus/Ph Addr
The rectangles represent nodes on the network which may be end points (N1 and N2) or routers (R1 and R2) or both. The lines connecting the nodes represent sub-networks. End point N1 is sending a message to end point N2. One the message has been prepared at N1, the driver in the sending node needs to know the destination address, and the QoS to apply (e.g. priority with which it should be sent). The destination address is translated into a physical address for the first sub-network. The information needed by the sending end point is represented underneath the rectangle (DA/QoS). When the packets arrive at the intermediate router (R2) the destination address has to be translated to select the sub-network/bus that it is to be forwarded on and the appropriate physical address for the destination node on that sub-network. This translation is done using a routing table in the router. The router also needs to know the QoS for the message so that is can assign the correct priority (for example) to processing and forwarding the packet. When the packet arrives at the destination node N2, it must be passed to the appropriate process on that node. This requires knowledge of the source address and channel number (source and destination ports). Consideration was given to whether it is appropriate to use channels or to use the source/destination port concept. This is still an open point.
Time Critical Onboard Network Services Working Group 22 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
2.4 Thursday 30/10/03 On Thursday time was spent with reporting back from the SEA meeting and closing presentations for all the SOIS groups. Some time was found to explore buffering schemes with the aim of implementing zero copy, for low packet processing overhead.
2.4.1 Driving Requirements The work during the meeting was driven by the QoS requirements: Asynchronous Priority driven datagram delivery Guaranteed, connection-oriented Non-guaranteed Isochronous Deterministic delivery Time critical Deterministic delivery Low overheads and efficient packet usage were also a prime consideration.
2.4.2 Buffer schemes To support efficient handling of packet transmission and reception, zero copy buffering schemes were explored and their impact on the TCONS SDU and PDU definitions considered. An approach using two sequence numbers (the message sequence number and the segment or packet sequence number) was considered to be a good candidate for TCONS.
Time Critical Onboard Network Services Working Group 23 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
3 Appendix – Diagrams exploring addressing and QoS
Source/Des tination Direct Address/Ports, Protocol (LODI)
IP etc
Packet Filter QoS Index SA DA SP DP Protocol 1 X X X X 1 X X X N X 2 … 3 … …
QoS Index
QoS MIB / Look Up Table 1 High priority, reliable 2 ow priority, reliable 3 … … …
Time Critical Onboard Network Services Working Group 24 1.1 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) Working Group Meeting Report
Source/Des tination Direct Address /Ports, Protocol (LODI) IP etc
IP Input Output SA DA SP DP Protocol OSA ODA Channel QoS Output link Node 1 X X X X 1 X X X Link 1,3 X X X N X X X X X Link 5
GAR Packet Filter QoS Index Output link OSA ODA Channel Router 1 X X 1 Link 1,3 X X X 2 Link 5 … 9 Link 2,8,12 … … … QoS Index QoS MIB / Look Up Table 1 High priority, reliable 2 ow priority, reliable 3 … … …
Source/Des tination Direct Address /Ports, Protocol (LODI) IP etc
IP Input Output SA DA SP DP Protocol OSA ODA Channel QoS Output link Node 1 X X X X 1 X X X Link 1,3 X X X N X X X X X Link 5
OSA, OD A, channel, QoS goes to/from dependent layer
Channel Output link X Link 1,3 Channel num ber X Link 5 provides possible links to use
Time Critical Onboard Network Services Working Group 25