[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