[Sls-slp] Fwd: Re: Space Packet Protocol Green Book

Peter Shames peter.shames at jpl.nasa.gov
Fri Oct 31 15:52:03 UTC 2008


Greg, Takahiro, Dai, et al,

My apologies for not being able to be present when this Green Book was  
discussed in Berlin, but my schedule during the week was just crazed.   
I hope you had a fruitful discussion of the draft document.   During  
my plane ride back to the US I took the time to read this draft Green  
Book and also the SPP that it relates from.  While reading the draft  
GB I had to go back and re-acquaint myself with the SPP itself because  
many of the features attributed to this Space Packet Protocol in the  
GB seemed to me to not really be firmly routed in my recollections of  
the capabilities of the actual SPP.  This re-reading of the SPP has  
caused me to also take the time to carefully review the Pink Sheets,  
which are being addressed separately.

I understand from talking to both JAXA and ESA representatives in the  
past that there is a great fondness for the SPP because of its  
"economy" and that there is also a strong desire to use it to do all  
sorts of things, foremost being to use it as a modest end to end  
routing protocol for application data.  The SPP is also used in some  
unique ways by our own Mars missions.   There has been a long standing  
discussion of whether the SPP is a "network" layer data object or an  
"application layer" data object.  After re-reading these documents I  
am convinced that it is really only an application layer data object,  
not a protocol in any formal sense, and that all of the properties  
ascribed to it re "routing", "data management", "end-to-end flows",  
multi-cast, etc are not firmly grounded in any solid technical  
capability or behavior that is defined in the SPP "protocol" itself.

Here is my reasoning:

- The SPP "protocol" is really only a data structure with a "tag"  
field, called the APID, as defined on pg 4-2 of the CCSDS 133.0-B-1  
Blue Book.

- The described behavior of the end nodes and intermediate nodes vis a  
vis routing and data transfer operations is at best a "sketch", it  
says assemble and multiplex packets and then "transfer Space Packets  
to the next protocol entity in the LDP using services of the  
underlying subnetwork. "  That is the essence of the whole "behavior"  
spec.

- The SPP itself contains only the APID as a unique identifying field  
that can be used to drive any of these so called "protocol"  
operations.  The optional "packet name" is as ambiguous as the APID in  
terms of end to end routing utility.

- In order to be useful the APID must retain meaning across all end  
elements and "intermediate nodes" .  However, the APID is stated as  
only being unique within the management domain in which it is  
defined.  For routing in the general case the packet may transit  
multiple domains, so this is a dis-connect that must be dealt with as  
collisions may easily occur between APID assignments in two different  
management domains.

- The "APID Qualifier" might offer some help but there is confusion in  
these two docs as to what the APID Qualifier is (SCID or MCID) and  
there is no clear statement in the SPP about what to do with it.

-  Since either of these APID Qualifiers (whichever it really is) are  
only relevant within the underlying link protocol of a "subnet",  
therefore there is no other unique field associated with an SPP end-to- 
end aside from the APID.

- This all means that the APID Qualifier as defined is essentially  
useless for end to end routing over multiple hops and admin domains.

- There is no clear protocol definition of how to do routing,  
forwarding, or store & forward operations, the whole "protocol" for  
intermediate nodes that are assigned this Relay (routing) function  
consists of these statements in CCSDS 133.0-B-1 :

> 4.3.2 PACKET RELAY FUNCTION

> 4.3.2.1 The Packet Relay Function shall be used to relay Space  
> Packets to the next protocol
> entity in the LDP of each Packet using services of the underlying  
> subnetwork.
> NOTE ñ There is an instance of the Packet Relay Function in each  
> intermediate system.

> 4.3.2.2 The Packet Relay Function shall receive Space Packets from  
> the underlying
> subnetworks and shall put the Packets into a queue in an appropriate  
> order that is set by
> management.  The algorithm to be used to order the Space Packets is  
> not specified by
> CCSDS, but shall be defined by project organizations considering  
> factors such as priority,
> release rate, etc.

> 4.3.2.3 The Packet Relay Function, then, shall examine the Path ID  
> of each Packet in the
> queue to identify the next Packet Protocol Entity in the LDP of the  
> Packet, and shall transfer
> the Packet using a service of the underlying subnetwork.

> 4.3.2.4 If the optional APID Qualifier is used, the APID Qualifier  
> of each received Packet
> shall be retrieved by a service of the subnetwork that carried the  
> Packet.  If the APID
> Qualifier is not used, the Path ID is derived directly from the APID  
> of the Packet.

> 4.3.2.5 The Packet Relay Function may transfer the Packet to  
> multiple protocol entities,
> which are not necessarily on the same subnetwork; i.e., it may  
> perform a multicast function.

> 4.3.2.6 The Packet Relay Function may temporarily store Packets,  
> using a storage service
> provided by the Intermediate System, before they are transferred to  
> the next Packet Protocol
> Entity, in case immediate transfer is impossible or impractical for  
> some reason.  The
> procedures for temporary storage of Packets are not specified by  
> this Recommendation.


- This is the heart of the “packet routing” function, but it says  
nothing about how to handle packets from different spacecraft, sort  
packets by path ID, identify paths based on Path ID, or direct packets  
to the correct paths.  It also does not say what to do with the APID  
Qualifier if this is relevant, just that it should be retrieved.

- This basically says "if a routing node gets a packet it sends it  
somewhere, somehow", but how it makes this decision, whether it stores  
the packet before sending it, where it gets the routing information  
from, how it is managed, how it determines whether a packet is "multi- 
cast", and how it even determines what to do w/ SPPs from someone  
else's system if there are APID collisions is all left up to  
"management".  This in essence says "It is someone else's problem" and  
nowhere in SPP or the GB elsewhere in CCSDS is it defined.

- All of the relay functions within SPP is done "by management",  
routing, store & forward, multi-path, etc

- Contrast this with the sorts of specifications for routing or  
forwarding data that are found in the Internet or in CFDP.

- We know that how some current spacecraft deal with the APID inter- 
management domain ambiguity is to use approaches like "packet in a  
packet" encapsulation such as is done by ESA for Mars relay data.  But  
note that this is not even mentioned as a strategy for handling APID  
collisions or intermediate node transfers in these docs.

- All of this really means that all of the hard work that needs to be  
done to make SPP work as a "network layer protocol" is done only by  
local arrangement, implementation choices, out of band signals and  
agreements, and therefore that there is no "standard" for doing this,  
thus interoperability cannot be possible in any general sense.

- The end result is that while APIDs may (and have been) useful within  
systems that all belong to the same administrative domain, and while  
it is pretty safe to rely on the SCID and a simple spacecraft to SLE  
end node path, or vice-versa, within one domain, there is not really  
any mechanism in the SPP that will adequately, without much tweaking  
and additional design, offer anything like a general purpose routing  
function.  EVERYTHING that is ascribed to SPP in this GB is done by  
out of band implementation, signaling, and management choices.

In the final analysis this Green Book, or the final version of it,  
must be clear about this.  My apologies, but the current draft of the  
GB reads like a fantasy where all sorts of magic properties are  
ascribed to the SPP, but all of them exist only as possibilities to be  
defined and managed as a local matter by the implementers.  The GB  
even talks about prioritization, reliability, retransmission, data  
management, and other topics that the SPP standard itself is truly  
silent about.

This is not to say that instances of systems using the SPP, by  
associating special meanings to certain assignments of the APID, can't  
be created to exhibit these properties, but neither the SPP standard  
itself, nor any other existing CCSDS document I know, of says how to  
do this in an interoperable fashion.   It makes me really  
uncomfortable to have all of this assertive language about the  
wonderful properties of the SPP floating around when in reality it is  
just fiction in terms of a real standard.  It is a description of some  
higher order behaviors that could be defined, but it is stated as a  
real property of a pretty ordinary tagged data structure.

The SPP is useful and has useful properties, and it can be adapted and  
configured to do a lot of things, but this description of what the SPP  
"does" does not really appear to be useful or accurate in its present  
form.   I took the liberty of trying to edit the document into a form  
that I believe more closely approximates the real properties of the  
SPP as can be found in the Blue Book.  I did leave in a lot of the  
possible uses of the SPP that had been described, but put in what I  
believe are necessary and essential caveats re its use.   We do not  
want to mislead our users about what this simple protocol is capable  
of, that would do them, and CCSDS, a disservice.

I suggest that the WG take a serious look at these comments and that  
we engage in some dialogue about it.  It may well be that the WG  
wishes to embark upon a careful definition of all of the necessary  
behavioral, routing, multi-cast and management specifications that  
would be needed to truly turn the SPP into a network layer routing  
protocol.  However, I doubt that it is worth the investment of time  
given the lack of any spare bits in the SPP that could be used for  
signaling, and the availability of CFDP and the in process DTN  
standards that do have routing and behavior well defined.

And please, if I have somehow, in my quick re-reading of the SPP Blue  
Book, overlooked some essential feature of the SPP that actually gives  
it all of these ascribed properties, do not hesitate to let me know  
what I have missed or misunderstood.

With all due respect, Peter


On 16 Oct 2008, at 12:21 AM, Greg Kazz wrote:

> All,
>
> Please find attached Takahiro's final update to the SPP GB.
>
> For review today.
>
> Greg
>
>> Date: Fri, 10 Oct 2008 22:47:21 +0900
>> From: Takahiro Yamada <tyamada at pub.isas.jaxa.jp>
>> Reply-To: tyamada at pub.isas.jaxa.jp
>> Organization: JAXA/ISAS
>> User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;  
>> rv:1.7.2) Gecko/20040804 Netscape/7.2
>> X-Accept-Language: en-us, en
>> To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
>> CC: tomg at aiaa.org, jean-Luc.Gerner at esa.int
>> Subject: Re: Space Packet Protocol Green Book
>> X-MAIL: dam01.s.tksc.jaxa.jp m9ADlL7P029796
>> X-Source-IP: tkes52.tksc.jaxa.jp [133.56.0.40]
>> X-Source-Sender: tyamada at pub.isas.jaxa.jp
>>
>> Greg,
>>
>>> Will you be able to provide us with an updated version of the  
>>> Space Packet Protocol Green Book before the meeting in Berlin?
>>
>> I'm very sorry for this last minute submission, but here it is. It  
>> is consistent with the Pink Sheets on the Space Packet Protocol  
>> provided by Tom.
>>
>> Please let me know when we discuss it at Berlin.
>>
>> I look forward to seeing you again there.
>>
>> Best regards,
>> Takahiro Yamada.
>>
>>
>>
> <SPP_DGB5.doc>_______________________________________________
> Sls-slp mailing list
> Sls-slp at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sls-slp






_______________________________________________________

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

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

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/20081031/1f273c89/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SPP_DGB5-ps-16Oct08.doc
Type: application/msword
Size: 515072 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081031/1f273c89/attachment.doc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20081031/1f273c89/attachment-0001.html>


More information about the SLS-SLP mailing list