[Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol

Peter Shames peter.shames at jpl.nasa.gov
Thu Aug 14 00:12:13 UTC 2003

Dear Takahiro,

I have read through your draft Green Book on the SPP (SPP-GB) and 
find it to be a quite clear and easily understood presentation of the 
concepts and use of the Space Packet Protocol (SPP).  You have done a 
really good job of presenting the materials in an accessible form. 
There are a number of minor formatting and English usage issues that 
surfaced, but these are more editorial than anything else.  I have an 
obvious bias, but I think that the use of the RASDS diagram approach 
helps with the presentation of the concepts.  It will be interesting 
to hear how this is perceived by others.

I have also now read the revised SPP Red Book (SPP-RB) and there are 
a few items in both documents that warrant further discussion.

Space Packet Protocol

The most fundamental question for me is "Is there really a Space 
Packet Protocol" or is there just a Space Packet Construction Rule 
and a set of loosely defined processes that describe things you might 
do with it?  In SPP-RB all that is really clearly defined are the 
packet construction rules. In this document there are some functional 
/ protocol views that describe how you might construct entities that 
participate in the transfer of these packets, and there is an 
abstract description of protocol entities, but these is no solid 
definition of the state machines that might exist within any of these 
entities nor of what procedures they follow.

I realize that this is a legacy of the original specs that you drew 
from, but now might be a good time to rectify some of this.

For instance, you could assert that these Space Packet Protocol 
Entities (SPP-RB, sec 2.1.1 and 2.3.2) do the following:

Octet string encapsulation and extraction
Packet mux and demux for multiple paths
End to end packet routing
Stream splitting (multi-path) and forwarding
Store & forward functions

These functions could be explicitly defined even though most of them 
are managed and configured by mechanisms that are outside of the 
entire protocol.  Since there are no protocol functions defined for 
any of this perhaps this all belongs in the SPP-GB rather than in the 
SPP-RB.  Alternatively, we could provide some simple state machine 
specs for how these entities are expected to operate and this might 
better clarify what is being done, where, and why.

Octet String Service

The Octet String Service (SPP-RB, sec,, and 3.4) 
needs to be further clarified.  As I am understanding it, this 
service accepts any arbitrary string of octets, of maximum size 65536 
octets (sec such as to fit into a single packet.  It must 
have the the Packet Sequence Flags set to '11' (sec, but 
this does not serve to distinguish that it is an Octet String.  The 
only way to know if it is an Octet String service is to determine it, 
by management, based upon the Path ID.  All of this is buried in the 
text, but it is never made quite this clear.  Perhaps it needs to be 
clarified in Sec

A string of octets longer than the max size may be transferred, but 
only if the application calling the Octet String service breaks it 
into a series of strings <= the maximum size and re-assembles it on 
arrival.  Since such an app is enjoined from using the Packet 
Sequence Flags it must develop some mechanisms of its own to do this. 
It is not clear why this should be required and why the Packet 
Sequence Flags could not be used here as well.

The reference in to Octet String service on the source end 
resulting in Packet Service on the destination end only adds to the 
confusion.  A reference to using the Path ID to disambiguate might 
help here too.

Storage of Data within Logical Data Path (LDP)

In the SPP-RB, sec 2.4.1 and 4.3.2, no mention is made of any storage 
functions that may be associated with either Packet Transfer or 
Packet Relaying functions, yet it is clear that some sort of data 
management and associated store & forward functionality may be a part 
of the operation of these functions.  Since the Packet Transfer 
service is explicitly defined to be asynch, out of order, no 
reliability, not timely, etc (sec 2.2.1)there is an implication that 
storage of data may take place at various points along the LDP.

In fact, in the SPP-GB, sec 2.1.2, pg 2-3, the document does mention 
that LDPs provide capability for temporarily storing Space Packets. 
But 2.2.3 says that the SPP does not have the capability of managing 
data units.  Sec 2.4.2, pg 2-8 then says that "Store and forward" 
operations are performed within the LDP. Sec 3.2 also talks of data 
storage functions within the SPP Gateway or Intermediate Node.  These 
statements within the SPP-GB, and between this document and the 
SPP-RB seem to be at odds.

It occurs to me that some of this ambiguity will be cleared up if we 
separate the protocol functions that Space Packet Protocol Entities 
carry out from the data storage functions that may be associated with 
operation of some of these entities.  Perhaps we need to make 
explicit, in both the SPP-RB and the SPP-GB that the functions of the 
LDP are performed by protocol entities and optional data storage 
entities.  These data storage entities may be queues, buffers, or 
longer term data storage (up to a week or more) that are used by the 
protocol entities as needed.  We ought to at least make sure that 
such store and forward functions ate treated uniformly throughout the 
document set.

Service Data Units (SDU)

The term Service Data Unit is introduced in SPP-RB, sec, but 
it not ever clearly defined.  This same term is used both to refer to 
an Octet String that is passed into the Packet Assembly function and 
to refer to the Space Packets themselves (sec 2.1.2, Table 2-1).  I 
found this usage confusing since it meant that SDUs (Space Packets) 
could encapsulate other SDUs (Octet Strings).  Since the SPP only 
transfers Space Packets perhaps the term SDU should be reserved for 
Space Packets themselves.  The descriptions for the Octet String 
service could then clarify that they are just input data units that 
are encapsulated to create SDUs.

Packet Secondary Header Length

The presence of a Packet Secondary Header (PSH) is indicated with a 
one bit flag  (sec  The header may be of variable 
length, containing one or two variable length fields (sec 
There appears to be no way to determine the size of the PSH, only a 
means to determine if one is present.  The implication is that the 
definition of the structure and content of the PSH is a local matter, 
set by management, and that it's form and structure can only be 
determined by examination of the Path ID and reference to some out of 
band information that management must provide.  This probably ought 
to be made explicit.  The fact that the PSH is mandatory if there is 
no User Data (sec only further serves to complicate the 
problem.  Why is this the case?

Time Code Field

The descriptions of time code choices in SPP-RB sec and seem to be inconsistent.  The first says that the 
selected time code shall be fixed for a given Path ID for all mission 
phases.  The second says that if the characteristics of the time code 
for a given Path ID are allowed to change that they have to obey some 
other rule.  Shouldn't it be one way or the other?

Definition of Synchronous

In SPP-RB, sec there is a definition for synchronous. This 
does not quite capture all of the usual semantics associated with 
this term.  Here are two other definitions that i found on-line, one 
addressing blocking, the other addressing timing constraints. 
Perhaps some combination of these is needed to clarify this.

Definition dbooth-1 
Property of an interaction whose results are directly following the
interaction. An interaction between an initiator and a respondent is
synchronous if the initiator blocks some further processing while it 
waits for a corresponding action, response or acknowledgement from 
the respondent.

Definition walden-1 
Synchronous, then, places a constraint on a response such that the 
response must be received within a strictly or loosely defined time 
quantum (strict vs lax synchrony), or else the exchange fails. 
Asynchronous differs in that no amount of elapsed time signals the 
failure of the exchange.

Other SPP-GB Issues

Sec 1.4, pg 1-2, Two different definitions for the term Space Packet 
Protocol, the second probably should be Space Packet Protocol Entity.

Sec 2.3.2, pg 2-5, pp 2, Probably ought to refer to the fact that 
other reliability mechanisms are also available at the link layer.

Sec 2.4.2, pg 2-7, pp 1, Not clear that it is useful to say that 
preprocessing may discard useless images.  Does not add to discussion 
at hand and may offend some readers.

Sec 3.2 and  3.3, pgs 3-2,3; Suggest altering or adding at least one 
diagram that explicitly shows a Data Store function being used to 
implement store and forward operations.

Sec 3.3, Pg 3-4, fig 3-4,5;  Not really clear what distinction you 
are trying to make with these two diagrams.  Fig 3-4 shows nodes in a 
Connectivity View. SAPs would not normally be shown on such a 
diagram, but PORTS might be (as in the typical Component / Connector 
diagram). Fig 3-5 shows Functions with the LDP shown as an abstract 
protocol function.  Here the SAPs make sense and they would probably 
correspond to the service primitives in SPP-RB, sec 3.3 and 3.4. 
They would be clearer if shown on some diagram like fig 2-3 or 2-5 
from the SPP-RB.

Sec 4.1, pg 4-1;  The SPP is really an application layer artifact in 
that it is used for end to end transmission of data between 
applications.  As noted in the first comment above, the most concrete 
parts of the spec are about data structure rather than anything else 
that would normally be thought of as a protocol / state machine.  If 
we are going to tighten up the definition of how the protocol 
entities operate, and provide anything like even a simple state 
machine descriptions, then this discussion would make more sense.

Here, and in sec 4.2, we could include some simple diagrams that 
would relate the packet protocol entities to different underlying 
transfer protocols, like paths on-board, TM/TC on the space link, and 
TCP/IP on the ground (with or without SLE).

I hope you find these comments useful.  Please let me know if 
anything is unclear.

Very best regards, Peter

At 8:47 PM +0900 8/12/03, Takahiro Yamada wrote:
>Dear CESG members, Space Packet Protocol WG members, and Space Link 
>Protocols WG members:
>I have written a draft Green Book on the Space Packet Protocol, 
>which can be found at
>This book should have been written together with the Red Book on the 
>same protocol, but unfortunately I couldn't find time to do so.
>I'd appreciate it very much if you could review it together with the 
>Red Book, Issue 1A, which can be found in the same collection.
>I've found that this Green Book is listed as a deliverable of the 
>Space Link Protocols WG, not of the Space Packet Protocol WG, but I 
>think it should belong to the Space Packet Protocol WG.  If you 
>agree with me, please correct the charters accordingly.
>Since the Space Packet Protocol is one of the primary products of 
>CCSDS, I'd like the draft Green Book to be reviewed by as many 
>people as possible.  I'd appreciate it if you could distribute the 
>draft to any people who may be interested in reviewing it.
>I will write another Green Book on the Space Data Link Protocols in September.
>Best regards,
>Takahiro Yamada, ISAS.
>CESG mailing list
>CESG at mailman.ccsds.org


Peter Shames
Manager - JPL Information Systems Standards Program
InterPlanetary Network and Information Systems Directorate
Jet Propulsion Laboratory, MS 301-265
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-1333

Internet:  Peter.Shames at jpl.nasa.gov
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first time"

T.S. Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20030813/5b132c8d/attachment.html>

More information about the SLS-SLP mailing list