[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 2.2.2.3, 3.2.3.3, 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 3.2.3.1) such as to fit into a single packet. It must
have the the Packet Sequence Flags set to '11' (sec 4.1.2.4.2.3), 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 2.2.2.3.
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 2.2.2.1 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 1.6.1.1, 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 4.1.2.3.1.2). The header may be of variable
length, containing one or two variable length fields (sec 4.1.3.2).
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 4.1.3.2.1.2) 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 4.1.3.2.2.3 and
4.1.3.2.2.4 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 1.6.1.3 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
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0222.html
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
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0326.html
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
>
>http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-324
>
>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
>http://mailman.ccsds.org/mailman/listinfo/cesg
--
_______________________________________________________________
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