From tyamada at pub.isas.ac.jp Tue Aug 12 11:47:42 2003 From: tyamada at pub.isas.ac.jp (Takahiro Yamada) Date: Tue, 12 Aug 2003 20:47:42 +0900 Subject: [Sls-slp] Draft Green Book on Space Packet Protocol Message-ID: <3F38D3DE.3080902@pub.isas.ac.jp> Dear CESG members, Space Packet Protocol WG members, and Space Link Protocols WG members: I have written a draft Green Book on the Space Packet Protocol, which can be found at http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-324 This book should have been written together with the Red Book on the same protocol, but unfortunately I couldn't find time to do so. I'd appreciate it very much if you could review it together with the Red Book, Issue 1A, which can be found in the same collection. I've found that this Green Book is listed as a deliverable of the Space Link Protocols WG, not of the Space Packet Protocol WG, but I think it should belong to the Space Packet Protocol WG. If you agree with me, please correct the charters accordingly. Since the Space Packet Protocol is one of the primary products of CCSDS, I'd like the draft Green Book to be reviewed by as many people as possible. I'd appreciate it if you could distribute the draft to any people who may be interested in reviewing it. I will write another Green Book on the Space Data Link Protocols in September. Best regards, Takahiro Yamada, ISAS. From peter.shames at jpl.nasa.gov Thu Aug 14 00:12:13 2003 From: peter.shames at jpl.nasa.gov (Peter Shames) Date: Wed, 13 Aug 2003 17:12:13 -0700 Subject: [Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol In-Reply-To: <3F38D3DE.3080902@pub.isas.ac.jp> References: <3F38D3DE.3080902@pub.isas.ac.jp> Message-ID: Dear Takahiro, I have read through your draft Green Book on the SPP (SPP-GB) and find it to be a quite clear and easily understood presentation of the concepts and use of the Space Packet Protocol (SPP). You have done a really good job of presenting the materials in an accessible form. There are a number of minor formatting and English usage issues that surfaced, but these are more editorial than anything else. I have an obvious bias, but I think that the use of the RASDS diagram approach helps with the presentation of the concepts. It will be interesting to hear how this is perceived by others. I have also now read the revised SPP Red Book (SPP-RB) and there are a few items in both documents that warrant further discussion. 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 realize that this is a legacy of the original specs that you drew from, but now might be a good time to rectify some of this. 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. 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. 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. 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. 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. 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. 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? 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? 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. Definition dbooth-1 http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0222.html Property of an interaction whose results are directly following the interaction. An interaction between an initiator and a respondent is synchronous if the initiator blocks some further processing while it waits for a corresponding action, response or acknowledgement from the respondent. ---- Definition walden-1 http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0326.html Synchronous, then, places a constraint on a response such that the response must be received within a strictly or loosely defined time quantum (strict vs lax synchrony), or else the exchange fails. Asynchronous differs in that no amount of elapsed time signals the failure of the exchange. 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. 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. 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. 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. 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. 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. 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 hope you find these comments useful. Please let me know if anything is unclear. Very best regards, Peter At 8:47 PM +0900 8/12/03, Takahiro Yamada wrote: >Dear CESG members, Space Packet Protocol WG members, and Space Link >Protocols WG members: > >I have written a draft Green Book on the Space Packet Protocol, >which can be found at > >http://www.ccsds.org/docu/dscgi/ds.py/View/Collection-324 > >This book should have been written together with the Red Book on the >same protocol, but unfortunately I couldn't find time to do so. > >I'd appreciate it very much if you could review it together with the >Red Book, Issue 1A, which can be found in the same collection. > >I've found that this Green Book is listed as a deliverable of the >Space Link Protocols WG, not of the Space Packet Protocol WG, but I >think it should belong to the Space Packet Protocol WG. If you >agree with me, please correct the charters accordingly. > >Since the Space Packet Protocol is one of the primary products of >CCSDS, I'd like the draft Green Book to be reviewed by as many >people as possible. I'd appreciate it if you could distribute the >draft to any people who may be interested in reviewing it. > >I will write another Green Book on the Space Data Link Protocols in September. > >Best regards, >Takahiro Yamada, ISAS. > > >_______________________________________________ >CESG mailing list >CESG at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/cesg -- _______________________________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyamada99 at yahoo.co.jp Fri Aug 15 20:54:59 2003 From: tyamada99 at yahoo.co.jp (Takahiro Yamada) Date: Sat, 16 Aug 2003 05:54:59 +0900 (JST) Subject: [Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol In-Reply-To: Message-ID: <20030815205459.9025.qmail@web605.mail.yahoo.co.jp> Peter, Thank you very much for your review of the books and detailed comments. I will respond to your comments gradually. Best regards, Takahiro Yamada, ISAS. __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/ From tyamada99 at yahoo.co.jp Wed Aug 20 02:38:37 2003 From: tyamada99 at yahoo.co.jp (Takahiro Yamada) Date: Wed, 20 Aug 2003 11:38:37 +0900 (JST) Subject: [Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol In-Reply-To: Message-ID: <20030820023837.16394.qmail@web2004.mail.yahoo.co.jp> 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/ From durst at mitre.org Wed Aug 20 14:48:26 2003 From: durst at mitre.org (Robert C. Durst) Date: Wed, 20 Aug 2003 10:48:26 -0400 Subject: [Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol References: <20030820023837.16394.qmail@web2004.mail.yahoo.co.jp> Message-ID: <3F438A3A.6C8AE8B4@mitre.org> > > > 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. In this and the duscussion that followed (deleted here), Takahiro is correct in his assertion that state machines are not essential to protocol definition. They, or something similarly unambiguous, are convenient means of describing the operation *of stateful protocols*, but SPP (and UDP) are essentially stateless -- there is no protocol exchange that alters the subsequent behavior of the protocol itself. (Documenting all the management functions that replace the in-line protocol is a different, and possibly stateful, issue, mut not the issue at hand here.) Regards, Bob Durst From peter.shames at jpl.nasa.gov Wed Aug 20 21:52:27 2003 From: peter.shames at jpl.nasa.gov (Peter Shames) Date: Wed, 20 Aug 2003 14:52:27 -0700 Subject: [Sls-slp] Re: [CESG] Draft Green Book on Space Packet Protocol In-Reply-To: <20030820023837.16394.qmail@web2004.mail.yahoo.co.jp> References: <20030820023837.16394.qmail@web2004.mail.yahoo.co.jp> Message-ID: 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 From tyamada99 at yahoo.co.jp Fri Aug 22 19:58:07 2003 From: tyamada99 at yahoo.co.jp (Takahiro Yamada) Date: Sat, 23 Aug 2003 04:58:07 +0900 (JST) Subject: [Sls-slp] Re: [Sis-spp] Re: [CESG] Draft Green Book on Space Packet Protocol In-Reply-To: Message-ID: <20030822195807.49043.qmail@web2003.mail.yahoo.co.jp> Peter, > 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. I basically agree with you, but there can be several different ways of doing store-and-forward delivery of Space Packets. Using the SLE Offline Transfer Services is one of them. I don't think it is practical to include all of them in the SPP-RB. What I think we should do is to include explanations on this issue, including pointers to appropriate documents, in the SPP-GB. Best regards, Takahiro Yamada, ISAS. __________________________________________________ Do You Yahoo!? Yahoo! BB is Broadband by Yahoo! http://bb.yahoo.co.jp/