<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Greg, Takahiro, Dai, et al,<div><br></div><div>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.</div><div><br></div><div>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. <div><br></div><div>Here is my reasoning:</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><br></div><div>- 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.</div><div><div><br>- 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. </div><div><div><div><br>- 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. </div></div><br></div><div>- This all means that the APID Qualifier as defined is essentially useless for end to end routing over multiple hops and admin domains.</div><div><br></div></div><div>- 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 :</div><div><br></div><div><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2 PACKET RELAY FUNCTION </font></div></blockquote><br><blockquote type="cite" class=""> <div><font class="Apple-style-span" color="#000000">4.3.2.1 The Packet Relay Function shall be used to relay Space Packets to the next protocol </font></div> <div><font class="Apple-style-span" color="#000000">entity in the LDP of each Packet using services of the underlying subnetwork. </font></div> <div><font class="Apple-style-span" color="#000000">NOTE ń There is an instance of the Packet Relay Function in each intermediate system. </font></div> <div><font class="Apple-style-span" color="#000000"></font></div></blockquote><br><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2.2 The Packet Relay Function shall receive Space Packets from the underlying </font></div> <div><font class="Apple-style-span" color="#000000">subnetworks and shall put the Packets into a queue in an appropriate order that is set by </font></div> <div><font class="Apple-style-span" color="#000000">management. The algorithm to be used to order the Space Packets is not specified by </font></div> <div><font class="Apple-style-span" color="#000000">CCSDS, but shall be defined by project organizations considering factors such as priority, </font></div> <div><font class="Apple-style-span" color="#000000">release rate, etc. </font></div> <div><font class="Apple-style-span" color="#000000"></font></div></blockquote><br><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2.3 The Packet Relay Function, then, shall examine the Path ID of each Packet in the </font></div> <div><font class="Apple-style-span" color="#000000">queue to identify the next Packet Protocol Entity in the LDP of the Packet, and shall transfer </font></div> <div><font class="Apple-style-span" color="#000000">the Packet using a service of the underlying subnetwork. </font></div> <div><font class="Apple-style-span" color="#000000"></font></div></blockquote><br><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2.4 If the optional APID Qualifier is used, the APID Qualifier of each received Packet </font></div> <div><font class="Apple-style-span" color="#000000">shall be retrieved by a service of the subnetwork that carried the Packet. If the APID </font></div> <div><font class="Apple-style-span" color="#000000">Qualifier is not used, the Path ID is derived directly from the APID of the Packet. </font></div> <div><font class="Apple-style-span" color="#000000"></font></div></blockquote><br><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2.5 The Packet Relay Function may transfer the Packet to multiple protocol entities, </font></div> <div><font class="Apple-style-span" color="#000000">which are not necessarily on the same subnetwork; i.e., it may perform a multicast function. </font></div></blockquote><br></div><div><blockquote type="cite" class=""><div><font class="Apple-style-span" color="#000000">4.3.2.6 The Packet Relay Function may temporarily store Packets, using a storage service </font></div> <div><font class="Apple-style-span" color="#000000">provided by the Intermediate System, before they are transferred to the next Packet Protocol </font></div> <div><font class="Apple-style-span" color="#000000">Entity, in case immediate transfer is impossible or impractical for some reason. The </font></div> <div><font class="Apple-style-span" color="#000000">procedures for temporary storage of Packets are not specified by this Recommendation. </font></div></blockquote></div><div><div><div><div id="_com_1" language="JavaScript" onmouseover="msoCommentShow('_anchor_1','_com_1')" onmouseout="msoCommentHide('_com_1')"><div><br></div><div>- 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.</div></div></div></div><div apple-content-edited="true"><div><div><br></div><div>- 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.</div><div><br></div><div><div>- All of the relay functions within SPP is done "by management", routing, store & forward, multi-path, etc</div><div><br></div></div><div>- Contrast this with the sorts of specifications for routing or forwarding data that are found in the Internet or in CFDP.</div><div><br></div><div>- 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.</div><div><br></div><div>- All of this really means that <b><i>all</i></b> 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.</div><div><br></div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>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 <b><i>could</i></b> be defined, but it is stated as a real property of a pretty ordinary tagged data structure.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>With all due respect, Peter</div><div><br></div><br></div></div></div><div><div>On 16 Oct 2008, at 12:21 AM, Greg Kazz wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>All,<br><br>Please find attached Takahiro's final update to the SPP GB.<br><br>For review today.<br><br>Greg<br><br><blockquote type="cite">Date: Fri, 10 Oct 2008 22:47:21 +0900<br></blockquote><blockquote type="cite">From: Takahiro Yamada <<a href="mailto:tyamada@pub.isas.jaxa.jp">tyamada@pub.isas.jaxa.jp</a>><br></blockquote><blockquote type="cite">Reply-To: <a href="mailto:tyamada@pub.isas.jaxa.jp">tyamada@pub.isas.jaxa.jp</a><br></blockquote><blockquote type="cite">Organization: JAXA/ISAS<br></blockquote><blockquote type="cite">User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2<br></blockquote><blockquote type="cite">X-Accept-Language: en-us, en<br></blockquote><blockquote type="cite">To: Greg Kazz <<a href="mailto:greg.j.kazz@jpl.nasa.gov">greg.j.kazz@jpl.nasa.gov</a>><br></blockquote><blockquote type="cite">CC: <a href="mailto:tomg@aiaa.org">tomg@aiaa.org</a>, <a href="mailto:jean-Luc.Gerner@esa.int">jean-Luc.Gerner@esa.int</a><br></blockquote><blockquote type="cite">Subject: Re: Space Packet Protocol Green Book<br></blockquote><blockquote type="cite">X-MAIL: dam01.s.tksc.jaxa.jp m9ADlL7P029796<br></blockquote><blockquote type="cite">X-Source-IP: tkes52.tksc.jaxa.jp [133.56.0.40]<br></blockquote><blockquote type="cite">X-Source-Sender: <a href="mailto:tyamada@pub.isas.jaxa.jp">tyamada@pub.isas.jaxa.jp</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Greg,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Will you be able to provide us with an updated version of the Space Packet Protocol Green Book before the meeting in Berlin?<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">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.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Please let me know when we discuss it at Berlin.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I look forward to seeing you again there.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Best regards,<br></blockquote><blockquote type="cite">Takahiro Yamada.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><span><SPP_DGB5.doc></span>_______________________________________________<br>Sls-slp mailing list<br><a href="mailto:Sls-slp@mailman.ccsds.org">Sls-slp@mailman.ccsds.org</a><br><a href="http://mailman.ccsds.org/mailman/listinfo/sls-slp">http://mailman.ccsds.org/mailman/listinfo/sls-slp</a><br></div></blockquote></div><div><br></div><div><br></div></div><span></span></body></html>