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

[Takahiro Yamada]

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.

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

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

It is explained indirectly using the concept of SAP
(Service Access Point) in sec 2.2.2.1, and the concept of
SAP is explained earlier in sec 2.2.1. Instances of most
of the CCSDS space link services are identified with an ID
of some kind and I used the concept of SAP for explaining
it in all of the books that I edited. However, there may
be a better way of explaining it. I will think about it.

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

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

I agree.

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

I fully agree with your analysis and suggestion. In fact,
most Space Packets are stored at one or two places in some
form before they are delivered to the final destination,
but no CCSDS document explains or mentions it (except for
the case of SLE Offline Services). I will make necessary
changes in SPP-RB and SPP-GB as you suggest.

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

The term Service Data Unit is not defined in SPP-RB
because it is defined in the OSI Reference Model. It is a
common practice in CCSDS documents to list (not define)
terms that are already defined somewhere else. Sec 1.6.1.1
is a list of terms that are defined in the OSI Reference
Model.

The usage of the term SDU may look confusing because it is
very rare to use the PDU of a protocol (in this case,
Space Packet) also as an SDU.

The following are the SDUs and PDUs used by SPP and I
believe the explanation of them in SPP-RB is correct.

                            SDU           PDU
Packet Service         Space Packet   Space Packet
Octet String Service   Octet String   Space Packet

Maybe I should put the above table at the end of sec
2.1.2.

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

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

The spec in SPP-RB is correct. A time code can have
multiple characteristics by using the P-field (see CCSDS
301.0-B-2).

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

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

You are right.

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

Agreed.

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

You are right. What I meant was that the sender can
determine what images to be downlinked and with what
resolutions. Some of our spacecraft actually do this. This
is an example of using the asynchronous-ness of SPP. I
should explain it much better so that readers will not
misunderstand. 

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

Agreed.

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

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

As I said above, I think SPP is a protocol, although it is
very simple. I don't think there exits a rule that any
protocol must have state machines. 

> 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 agree. The examples you mention are exactly what I
wanted to show in sec 3.4, which is vacant now. I will
generate some diagrams there and refer to them in section
4.

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.


__________________________________________________
Do You Yahoo!?
Yahoo! BB is Broadband by Yahoo!
http://bb.yahoo.co.jp/