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

[Peter Shames]

Takahiro and Bob,

Thanks for the thoughtful responses.  It seems that we have pretty 
good agreement on the issues that I raised with the exception of the 
one that I still believe is fundamental, i.e. just what is the SPP 
protocol?

Bob mentioned that both SPP and UDP are stateless, but this is really 
only so with UDP.  Here datagrams are transferred, end to end, and 
discarded, duplicated, or delivered based upon the characteristics of 
the underlying IP layer.  The IP layer provides all of the needed 
functions for routing and forwarding and its ancillary functions, 
also described as protocols deal with name/address resolution, 
routing table updates, etc.

In SPP there is a set of packet construction rules, and what amounts 
to a collections of notes that describe the operations of the 
protocol entities.  These protocol entities do the stuff I identified 
in my second comments:

>  >
>>  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

Store and forward functions are inherently stateful, even though 
there is no ack/nack protocol or other signalling associated with the 
provision of tis function.  There is no set of specs that describe 
how any of this is to be done to make the SPP work.  These functions 
are essential to the proper operations of the end to end protocol and 
they must be implemented within the protocol entities.  However, the 
spec is largely silent on this and it is up to the reader to 
interpret, from several pieces of separate information, what is 
really required and how it is intended to operate.

I believe that we can do this better and perhaps the SPP-GB is the 
best place to do it.  We could, alternatively, augment the SPP-RB to 
describe these functions in more detail, whether state machine or 
some other description of your choosing.  Maybe this could go in an 
Appendix to the SPP-RB, but I believe the document would be better 
for its inclusion.

Regards, Peter


At 11:38 AM +0900 8/20/03, Takahiro Yamada wrote:
>Peter,
>
>Thank you for your detailed analysis and comments on the
>Space Packet Protocol Green Book (SPP-GB) and Red Book
>(SPP-RB). Here are my responses to your comments.
>
>>  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 think what a protocol specifies is a set of rules to be
>used by both sender and receiver to perform
>communications. I don't think all protocols must have
>state machines. For example, UDP doesn't. But both SPP and
>UDP define a set of rules to be used by both sender and
>receiver to perform communications. So I think they are
>still protocols, although they are very simple ones.

But UDP depends upon IP to do its routing and upon other functions to 
do its routing table updates, name resolution, management, etc.  SPP 
protocol entities must implement this themselves.

>  > 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.
>
>Section 2 of SPP-RB is just an overview section and I
>think it should be a concise section. The functions you
>listed (except for Store & forward functions) are
>mentioned in sections 4.2 through 4.4 of SPP-RB.

Yes, leaving sec 2 as a concise introduction is appropriate..  But 
there are implicit requirements to do these within the SPP protocol 
entities and this probably ought to be made explicit, perhaps in sec 
4 as you suggest.

>  > 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.
>
>I have the same feeling as yours but it has been an spec
>for years and I didn't change it because changing a spec
>is more than restructuring.

Yes.  Perhaps this is something we should think about including in 
any future update to this document.  Perhaps one of the original 
authors can explain why this was done this way?

>
>>  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?
>
>About the structure and content of the PSH, I agree with
>your comment and will add a sentence or two in 4.1.3.2.1
>of SPP-RB.
>
>About the fact that the PSH is mandatory if there is no
>User Data, it has been a spec for years, and I don't know
>why it is so. We could alternatively have a rule that User
>Data must exist if there is no PSH. (The length of PSH +
>User Data must be greater than 0).

Perhaps one of the original authors can explain why this was done this way?

>
>>  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.
>
>The definition of synchronous used in CCSDS documents was
>specially developed to explain the features of some of the
>services provided by the TM and AOS Space Data Link
>Protocols. Historically, this definition was first used in
>the Packet Telemetry Services Recommendation. For example,
>the Operational Control Field is transferred synchronized
>with the release of Transfer Frames of a Master or Virtual
>Channel regardless of the timing at which the sending user
>provides data. This kind of synchronous-ness is very
>unique to CCSDS protocols and that's why CCSDS developed a
>special definition.
>
>If we adopted an existing definition, we would not be able
>to explain the features of our protocols precisely. And I
>don't think CCSDS needs to capture all of the usual
>semantics associated with this term.

I will need to think about this.

>
>>  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.
>
>I'm not sure if we should include this discussion here,
>but there are two different ways of using SPP, and we
>(ISAS) actually use these two ways in our data systems.
>
>On the ground, we distribute to end users a software
>library to receive Space Packets. The users only need to
>understand the API of this library and need not know
>anything about the protocols (SPP or underlying protocols
>like SLE/TCP/IP). In this case, the API is the
>user-to-infrastructure interface. This way of using SPP
>corresponds to fig 3-5.
>
>Most users use the library mentioned above, but some users
>prefer to implement the protocols themselves without using
>the library. In this case, the Node-to-Node interface is
>the user-to-infrastructure interface and APIs are a local
>matter. This way of using SPP corresponds to fig 3-4.
>
>I think the distinction between these two ways of using an
>infrastructure is universal and worth mentioning in this
>document. But I'd like to hear opinions of people who
>actually use SPP.

I understand the distinction and agree that both implementation 
approaches are used.  I wonder if showing these as two different 
diagrams is the best way to get this point across or if it would be 
better to just have two versions of one diagram showing the 
availability (or lack) of a standard API.

>Thank you again for your productive comments. I will wait
>for some more comments to come and distribute revised
>documents in September.
>
>Best regards,
>Takahiro Yamada, ISAS.
>


Best regards, Peter


-- 
_______________________________________________________________

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