From edward.greenberg at jpl.nasa.gov Thu Feb 1 06:17:01 2018 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Thu, 1 Feb 2018 06:17:01 +0000 Subject: [Sls-slp] Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book In-Reply-To: <493B9798-9A92-4BDB-98E4-D63A75F70F01@jpl.nasa.gov> References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com> <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int> <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com> <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov> <826_1517320493_5A70792D_826_77_1_OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6F18@esa.int> <11476_1517409034_5A71D30A_11476_48_1_OFB2B19575.0982BDDD-ONC1258226.004F0BC0-C1258226.004FB32D@esa.int> <493B9798-9A92-4BDB-98E4-D63A75F70F01@jpl.nasa.gov> Message-ID: <9010dc7245784a4290d03b4cf516bb89@jpl.nasa.gov> My comments are in red in the text below. From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, January 31, 2018 3:39 PM To: Gian.Paolo.Calzolari at esa.int; John Pietras Cc: sls-slp at mailman.ccsds.org Subject: Re: [Sls-slp] Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book All, Here is a follow on to the telecon that occurred today between myself, Gian-Paolo, Stefan Veit, and Ed Greenberg. We are searching for the right approach to revise the SPP. We are still in the brainstorming part of development. All inquiries and ideas are most invited! As we discussed in the Haag in Nov. 2017, the Space Packet provides a duality of functionality: It is both an Application Layer (AP) Data Structure and Format as well as a data link layer transport mechanism i.e. it is transported within the frame data field of CCSDS transfer frames. We all seem to agree that there should be no mention of multiple subnetworks and routing in the future SPP. These things are handled much better by DTN, IP, etc. We go back to the basic structure of what we shall describe in the SPP Blue Book: (This is where I would like to get consensus on first) 1. In the Application Layer, there are multiple users (data sources) including the SPP Packet Assembly Function (out of strings it makes packets) that request the transfer of Space Packets out of the Application Layer by supplying the APID, APID_Qualifier (optional), QoS Rqmt (optional) – as currently defined by the SPP. This is accomplished by generating the packet.request primitive in SPP. So multiple users are producing packets with different APIDs under management control and outside the purview of CCSDS. APID is already in the packet thus it need not be supplied externally. 2. In the Application Layer, those packets provided by those multiple users and SPP Packet Assembly Function, shall be multiplexed to produce a single packet stream in the appropriate order set by management whose algorithm is not specified by CCSDS – as currently defined by SPP. (SPP talks about a single Queue, but use of the term “stream” is better because it is implementation agnostic). There is a packet stream to each VC SAP. If there is only one packet stream then the transfer protocol must include the VCID along with the QoS desired. I don’t understand APID_Qualifier. 3. NOW HERE COMES SOME CONTENTION – Do we want the SPP to have the capability of forwarding data (not routing data) on-board (mostly envisioned for on-board the spacecraft) within a single closed subnetwork in an A-B-A configuration ? If the answer is yes (I think it is yes), then APID_Qualifier needs to be well and unambiguously defined for SPP. I can supply a use case from the ISS. For Telecommand, Space Station uses Logical Data Path – Endpoint as the APID_Qualifier (this field occurs in the packet 2nd Header, which is currently non-compliant with SPP because there is currently no standard packet 2nd header defined) to forward commands to user modules on-board the ISS. In this case, Logical Data Path is short circuited to be a Logical Data Path Endpoint. OR Gian Paolo contents that we should retire the concept of Logical Data Path completely, and only leave a historical note in SPP about its previous existence? I’m not quite sure what you mean by data forwarding. The Logical Data Path concept that was defined in the otiginal Source Packet sped was for a single link. That could be a local network addressing scheme or a remote addressing scheme across a single link. This later scheme is what is used almost totally by non-manned missions. The use of a standard set of labels within the secondary header is a fine use of the current packet format for multiple things but the current users use the secondary header flag for non-standard secondary headers. We may need to hold open the possibility of Logical Data Path Endpoint or something similar until we get clarification from all agencies and the SIS area about their desires for eventually modifying the SPP packet 2nd header in order to accomplish data forwarding on-board a spacecraft. Does this data forwarding function take place in the application layer ? We may not need to modify the current format if we set a few constraints(i.e. we could define a single APID in the packet header as a flag signaling the inclusion of standard labels in the secondary header. These standard labels could provide the true APID, APID_Qualifier( whatever this is), QoS Rqmt, time of generation, time to live, priority for delivery, global source and destination addresses, packet security parameters. Etc. This methodology would have little effect on today’s usage of the Packet Format and Link layer Packet service. 1. In the Data Link Layer, the transfer across the space link of those Space Packets is requested. Here an additional multiplexing step may take place, packets of multiple PVNs are multiplexed into the stream, before packets are placed into the transfer frame data fields of frames. Each single packet stream is then injected into the TF data field of a specific VC frame by sending it to the instance of the Packet Processing Function for that VC that transports packets as defined in the appropriate SDLP Packet Processing Function. The most generic way of expressing this primitive is to use Encapsulation.request (Data Unit, SDLP_Channel, PVN, EPI). Of course, one could also accomplish this transfer by using VCP.request (only for AOS or TM) or MAPP.request (TC) or (USLP) or Packet Service in Prox-1. Makes sense ? Thanks! Greg Chairman SLP WG From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, January 31, 2018 at 6:30 AM To: John Pietras > Cc: Greg Kazz >, "sls-slp at mailman.ccsds.org" > Subject: Packet channel multiplexing no longer needed? : [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book John, I think that Packet channel multiplexing is still needed and surely implemented by space agencies. The point is that those implementation are not exposed and I find this correct. Let's say that we should keep the same approach we have had in the past; i.e. SPP book shall mention that Packet channel multiplexing is to be performed but leaving the implementation to users as loong as there no for a commen service (either SLS or CSTS). If you think this is the same that happened with the TC standard and FSP. The TC Standard mentioned that TC Frames were multiplexed over VCs/MAPs but gave no definition. When SLE FSP was done it was realised that the TC Frame multiplexing required to be defined and in fact you have relevant clauses and an Annex in FSP. The same for TM frame, they are multiplexed over a Master Channel and their multiplexing is mentioned but not defined (specially because that multiplexing is normally done on board a spacecrat :o). Regards Gian Paolo From: John Pietras > To: "Gian.Paolo.Calzolari at esa.int" >, "Kazz, Greg J (312B)" > Cc: "sls-slp at mailman.ccsds.org" >, SLS-SLP > Date: 30/01/2018 19:06 Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book Sent by: "SLS-SLP" > ________________________________ All, In an earlier email in this thread, Greg commented that he understood that many missions multiplex different “packet channels” into the same VC, but that he did not see this happening in an interoperable way. I think that Greg has hit on the important factor here – what is exposed in an interoperable, cross-supported way? Back when we wrote the original AOS book, we had the notion that “cross support” users would be able to access individual packet channels via standard intefaces. This notion was formalized in the Cross Support Reference Model, Part 1 – Space Link Extension Services Blue Book (colloquially known as the “SLE Ref Model”), which envisioned two “flavors” of Forward Space Packet (TC and AOS) and one Return Space Packet service. Those services would have allowed multiple FSP instances to carry packete channels all destined for the same VC. As it turned out, only the TC flavor of the Forward Space Packet service was ever realized. Different instances of the (TC) FSP service are indeed capable of carrying different packet channels destined for the same VC. The FSP service uses MAP, so the necessary packet channel multiplexing into VCs is accomplished (indirectly) through MAP Multiplexing. But had the AOS FSP been realized, it *would* have required the packet channel muxing that currently resides in the SPP. But since it wasn’t realized, the main use case (that I know of) disappears, and perhaps packet channel multiplexing is indeed no longer needed at a cross-support interoperability level, which I agree with Greg is the important factor in considering whether to retain the specification in the SPP (or migrate it back into one or more of the SDLP books). Best regards, John From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Tuesday, January 30, 2018 8:55 AM To: Kazz, Greg J (312B) Cc: John Pietras; sls-slp at mailman.ccsds.org; SLS-SLP Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book Greg, what we have to be sure it captured in our CCSDS books is the following situation (e.g. for a TM/AOS link) * There multiple sources generating packet contents and asking creation of packets * Those packets are created with different APIDs depending on the source * Those different APIDs shall be multiplexed to produce a single packet stream: * This single packet stream is then injected in in a VC * It is then correct that "The current AOS SDLP version i.e., CCSDS 732.0-B-3 Sept 2015 is agnostic about “packet channels” and “Individual CCSDS packets from multiple sources” (implying multiple APIDs). It is really only concerned about multiplexing of packets with different PVNs onto VCs." In fact AOS would only see that single stream. All the rest shall be done above the SDLP. We shall check also what we lost with respect to CCSDS 103.0-B-2 (now silver) where there was a nice picture for which I attach a detail. Another document to be checked for losses is CCSDS 203.0-B-2 and even FSP that mention APID multiplexing if I remember well. Finally we shall verify all fits within the encapsulation service. Ciao Gian Paolo [cid:image001.gif at 01D399A9.B32BEF00] This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. _______________________________________________ SLS-SLP mailing list SLS-SLP at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 21545 bytes Desc: image001.gif URL: From Gian.Paolo.Calzolari at esa.int Thu Feb 1 14:43:14 2018 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Thu, 1 Feb 2018 15:43:14 +0100 Subject: [Sls-slp] Follow on to the SPP telecon / was: Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book In-Reply-To: <9010dc7245784a4290d03b4cf516bb89@jpl.nasa.gov> References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com> <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int> <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com> <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov> <826_1517320493_5A70792D_826_77_1_OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6F18@esa.int> <11476_1517409034_5A71D30A_11476_48_1_OFB2B19575.0982BDDD-ONC1258226.004F0BC0-C1258226.004FB32D@esa.int> <493B9798-9A92-4BDB-98E4-D63A75F70F01@jpl.nasa.gov> <9010dc7245784a4290d03b4cf516bb89@jpl.nasa.gov> Message-ID: <14895_1517496197_5A732784_14895_266_1_OF1C10FB28.DE81898D-ONC1258227.00500E70-C1258227.0050DCEF@esa.int> Dear All, in the attached file you find my considerations over Greg's input and Ed's comments (marked red). I converted Ed's e-mail below to a Word File to be able to use WinWord comments etc. If required I can provide the original WinWord file, while I attach here the pdf for easier reading. Comments are welcome. Regards Gian Paolo From: "Greenberg, Edward (312B)" To: "Kazz, Greg J (312B)" , "Gian.Paolo.Calzolari at esa.int" , John Pietras Cc: "sls-slp at mailman.ccsds.org" Date: 01/02/2018 07:17 Subject: Re: [Sls-slp] Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book Sent by: "SLS-SLP" My comments are in red in the text below. From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, January 31, 2018 3:39 PM To: Gian.Paolo.Calzolari at esa.int; John Pietras Cc: sls-slp at mailman.ccsds.org Subject: Re: [Sls-slp] Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book All, Here is a follow on to the telecon that occurred today between myself, Gian-Paolo, Stefan Veit, and Ed Greenberg. We are searching for the right approach to revise the SPP. We are still in the brainstorming part of development. All inquiries and ideas are most invited! As we discussed in the Haag in Nov. 2017, the Space Packet provides a duality of functionality: It is both an Application Layer (AP) Data Structure and Format as well as a data link layer transport mechanism i.e. it is transported within the frame data field of CCSDS transfer frames. We all seem to agree that there should be no mention of multiple subnetworks and routing in the future SPP. These things are handled much better by DTN, IP, etc. We go back to the basic structure of what we shall describe in the SPP Blue Book: (This is where I would like to get consensus on first) 1. In the Application Layer, there are multiple users (data sources) including the SPP Packet Assembly Function (out of strings it makes packets) that request the transfer of Space Packets out of the Application Layer by supplying the APID, APID_Qualifier (optional), QoS Rqmt (optional) – as currently defined by the SPP. This is accomplished by generating the packet.request primitive in SPP. So multiple users are producing packets with different APIDs under management control and outside the purview of CCSDS. APID is already in the packet thus it need not be supplied externally. 2. In the Application Layer, those packets provided by those multiple users and SPP Packet Assembly Function, shall be multiplexed to produce a single packet stream in the appropriate order set by management whose algorithm is not specified by CCSDS – as currently defined by SPP. (SPP talks about a single Queue, but use of the term “stream” is better because it is implementation agnostic). There is a packet stream to each VC SAP. If there is only one packet stream then the transfer protocol must include the VCID along with the QoS desired. I don’t understand APID_Qualifier. 3. NOW HERE COMES SOME CONTENTION – Do we want the SPP to have the capability of forwarding data (not routing data) on-board (mostly envisioned for on-board the spacecraft) within a single closed subnetwork in an A-B-A configuration ? If the answer is yes (I think it is yes), then APID_Qualifier needs to be well and unambiguously defined for SPP. I can supply a use case from the ISS. For Telecommand, Space Station uses Logical Data Path – Endpoint as the APID_Qualifier (this field occurs in the packet 2nd Header, which is currently non-compliant with SPP because there is currently no standard packet 2nd header defined) to forward commands to user modules on-board the ISS. In this case, Logical Data Path is short circuited to be a Logical Data Path Endpoint. OR Gian Paolo contents that we should retire the concept of Logical Data Path completely, and only leave a historical note in SPP about its previous existence? I’m not quite sure what you mean by data forwarding. The Logical Data Path concept that was defined in the otiginal Source Packet sped was for a single link. That could be a local network addressing scheme or a remote addressing scheme across a single link. This later scheme is what is used almost totally by non-manned missions. The use of a standard set of labels within the secondary header is a fine use of the current packet format for multiple things but the current users use the secondary header flag for non-standard secondary headers. We may need to hold open the possibility of Logical Data Path Endpoint or something similar until we get clarification from all agencies and the SIS area about their desires for eventually modifying the SPP packet 2nd header in order to accomplish data forwarding on-board a spacecraft. Does this data forwarding function take place in the application layer ? We may not need to modify the current format if we set a few constraints(i.e. we could define a single APID in the packet header as a flag signaling the inclusion of standard labels in the secondary header. These standard labels could provide the true APID, APID_Qualifier( whatever this is), QoS Rqmt, time of generation, time to live, priority for delivery, global source and destination addresses, packet security parameters. Etc. This methodology would have little effect on today’s usage of the Packet Format and Link layer Packet service. 4. In the Data Link Layer, the transfer across the space link of those Space Packets is requested. Here an additional multiplexing step may take place, packets of multiple PVNs are multiplexed into the stream, before packets are placed into the transfer frame data fields of frames. Each single packet stream is then injected into the TF data field of a specific VC frame by sending it to the instance of the Packet Processing Function for that VC that transports packets as defined in the appropriate SDLP Packet Processing Function. The most generic way of expressing this primitive is to use Encapsulation.request (Data Unit, SDLP_Channel, PVN, EPI). Of course, one could also accomplish this transfer by using VCP.request (only for AOS or TM) or MAPP.request (TC) or (USLP) or Packet Service in Prox-1. Makes sense ? Thanks! Greg Chairman SLP WG From: "Gian.Paolo.Calzolari at esa.int" Date: Wednesday, January 31, 2018 at 6:30 AM To: John Pietras Cc: Greg Kazz , "sls-slp at mailman.ccsds.org" < sls-slp at mailman.ccsds.org> Subject: Packet channel multiplexing no longer needed? : [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book John, I think that Packet channel multiplexing is still needed and surely implemented by space agencies. The point is that those implementation are not exposed and I find this correct. Let's say that we should keep the same approach we have had in the past; i.e. SPP book shall mention that Packet channel multiplexing is to be performed but leaving the implementation to users as loong as there no for a commen service (either SLS or CSTS). If you think this is the same that happened with the TC standard and FSP. The TC Standard mentioned that TC Frames were multiplexed over VCs/MAPs but gave no definition. When SLE FSP was done it was realised that the TC Frame multiplexing required to be defined and in fact you have relevant clauses and an Annex in FSP. The same for TM frame, they are multiplexed over a Master Channel and their multiplexing is mentioned but not defined (specially because that multiplexing is normally done on board a spacecrat :o). Regards Gian Paolo From: John Pietras To: "Gian.Paolo.Calzolari at esa.int" , "Kazz, Greg J (312B)" Cc: "sls-slp at mailman.ccsds.org" , SLS-SLP Date: 30/01/2018 19:06 Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book Sent by: "SLS-SLP" All, In an earlier email in this thread, Greg commented that he understood that many missions multiplex different “packet channels” into the same VC, but that he did not see this happening in an interoperable way. I think that Greg has hit on the important factor here – what is exposed in an interoperable, cross-supported way? Back when we wrote the original AOS book, we had the notion that “cross support” users would be able to access individual packet channels via standard intefaces. This notion was formalized in the Cross Support Reference Model, Part 1 – Space Link Extension Services Blue Book (colloquially known as the “SLE Ref Model”), which envisioned two “flavors” of Forward Space Packet (TC and AOS) and one Return Space Packet service. Those services would have allowed multiple FSP instances to carry packete channels all destined for the same VC. As it turned out, only the TC flavor of the Forward Space Packet service was ever realized. Different instances of the (TC) FSP service are indeed capable of carrying different packet channels destined for the same VC. The FSP service uses MAP, so the necessary packet channel multiplexing into VCs is accomplished (indirectly) through MAP Multiplexing. But had the AOS FSP been realized, it *would* have required the packet channel muxing that currently resides in the SPP. But since it wasn’t realized, the main use case (that I know of) disappears, and perhaps packet channel multiplexing is indeed no longer needed at a cross-support interoperability level, which I agree with Greg is the important factor in considering whether to retain the specification in the SPP (or migrate it back into one or more of the SDLP books). Best regards, John From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] Sent: Tuesday, January 30, 2018 8:55 AM To: Kazz, Greg J (312B) Cc: John Pietras; sls-slp at mailman.ccsds.org; SLS-SLP Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book Greg, what we have to be sure it captured in our CCSDS books is the following situation (e.g. for a TM/AOS link) There multiple sources generating packet contents and asking creation of packets Those packets are created with different APIDs depending on the source Those different APIDs shall be multiplexed to produce a single packet stream: This single packet stream is then injected in in a VC It is then correct that "The current AOS SDLP version i.e., CCSDS 732.0-B-3 Sept 2015 is agnostic about “packet channels” and “Individual CCSDS packets from multiple sources” (implying multiple APIDs). It is really only concerned about multiplexing of packets with different PVNs onto VCs." In fact AOS would only see that single stream. All the rest shall be done above the SDLP. We shall check also what we lost with respect to CCSDS 103.0-B-2 (now silver) where there was a nice picture for which I attach a detail. Another document to be checked for losses is CCSDS 203.0-B-2 and even FSP that mention APID multiplexing if I remember well. Finally we shall verify all fits within the encapsulation service. Ciao Gian Paolo This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. _______________________________________________ SLS-SLP mailing list SLS-SLP at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. _______________________________________________ SLS-SLP mailing list SLS-SLP at mailman.ccsds.org https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 21545 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 20180131.SPPwebexNotes.v0.2.pdf Type: application/octet-stream Size: 388635 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Tue Feb 13 23:51:45 2018 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 13 Feb 2018 23:51:45 +0000 Subject: [Sls-slp] Current Version of USLP RED book Feb 13 2018 Version Message-ID: Dear SLP WG, The current version of the USLP RED book with date of Feb 13, 2018 is now found at the URL below: http://tiny.cc/hk23qy Please let me know if you have any issues or questions regarding this material. It contains some minor updates since the release of the RED 3.1 version by the Secretariat, due to results of interoperability testing. The Sections that have changes are: 1. Overview of Services – A new diagram (based upon the SDU and PDU diagram that Marjorie DeLandelong developed for the CCSDS IP over CCSDS) has been inserted into Section 2.2 to introduce the topic of SDUs and PDUs as well as the reoccurring service primitives (.request, .indication, NOTIFY. Indication) along with a few short paragraphs of descriptive text thereafter. See pp. 2-6, 2-7. 2. Clean up of the following service diagrams (see text explaining the rationale for the update directly below – diagrams and Sections involved: Figures: 2-6, 4-6, 4-17, 4-24, 4-26 (MC_OCF Service moved from VC Reception Function to MC_Demux function), Text moved from 4.3.6 and moved to 4.3.8. Please note that Figure 2-6 is identical to Figure 4-17 and has always been duplicated in all of the SDLP blue books for ease of reference. First of all, the OCF_Flag tells us whether or not an OCF_SDU is or is not contained in any given transfer frame. In TM, within a Virtual Channel, the OCF_Flag is static. The difference between MC_OCF and VC_OCF service, in MC_OCF service the pick up of the OCF_SDU is from a MC_OCF service provider and the delivery of the OCF_SDU is to the MC_OCF service provider on the receive side. In VC_OCF service, there is an OCF Service provider for each VC that carries an OCF_SDU, which is picked up by that specific VC_OCF service provider and delivered to that VC_OCF service provider on the receive side. Now, because we only have fixed length frames in TM, the requirement in TM is that the OCF services are static i.e., the carrying of an OCF_SDU cannot be changed on a frame by frame basis. In USLP, in the general case, the OCF_Flag is dynamic meaning that the transfer of an OCF_SDU can change on a frame by frame basis. You asked , “Then, recalling that there is a OCF_Flag in the transfer frame header can the OCF be omitted (if desired) also for fixed length frames?” – Yes it can, however it would complicate the frame assembly process, since in this case we are dealing with a fixed length frame constraint. So most likely in a fixed length case, the USLP OCF_Flag will be static. But it is not mandatory. Note also In AOS there is only VC_OCF service. It is static in a VC and the VC_OCF service is managed because there is no OCF_Flag. In USLP, we only have a MC_OCF service. We looked at the MC_OCF service definition as described in Section 3 of TM and compared it to ours in USLP. There is no difference except for the OCF_Flag requirement i.e., that the flag is static for a mission phase in TM but dynamic (and controlled by the USLP VC Managed Parameters). In other words, USLP allows an OCF_SDU to be carried on a frame by frame basis and in TM, each frame in the VC would have to carry an OCF_SDU throughout the mission phase. So, does that mean we need to rename the OCF service in USLP ? We don’t think so, because we still have a MC_OCF service (as defined) that picks up the OCF_SDUs from one MC_OCF service provider and delivers all of the OCF_SDUs to one MC_OCF service provider on the receive side. The basics haven’t changed. We just removed the constraint on the OCF_Flag to allow it to be dynamic on a frame by frame basis, mostly because of the variable length frame nature of USLP which provides better efficiency in transferring OCFs across the link. Also OCF_SDU pick up and delivery are globally identifiable for MC_OCF service. Concerning figure 2-5 and 4-6, we believe the figures are correct as currently drawn. Recall that these figures are illustrations of a possible implementation. One can do it in many different ways. You have the current version but I have also attached it here as well. We have the MC_OCF Service injected into the VC Generation box on the sending side, because that is the function where all of the components of the VC come together except for Insert Zone (All Frames generation) and CRC (All Frames Generation). In the VC generation box is where the VC construction process picks up the OCF_SDU from the MC_OCF service for that participating VC and builds the VC frame. When the flag is set, the OCF_SDU is extracted and provided to the MC_OCF service within the MC Demultiplexing Function. If there are any issues with these updates, we will discuss them at the Spring 2018 meeting in Gaithersburg, MD, USA in early April. Best Regards, Greg Kazz Principal Engineer Technical Group Supervisor, Project Software and End-to-End Information Systems Engineering (312B) Jet Propulsion Laboratory 4800 Oak Grove Dr., M/S 301-490 Pasadena, CA 91109 1+(818)393 6529(voice) 1+(818)393 6871(fax) email: greg.j.kazz at jpl.nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Fri Feb 16 20:02:39 2018 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Fri, 16 Feb 2018 20:02:39 +0000 Subject: [Sls-slp] FW: [CCSDS-All] Spring 2018 Technical Meetings - Gaithersburg, Maryland, USA - Registration Now Open Message-ID: <701CBC96-95C4-45F0-A7F2-0B61159B5B16@jpl.nasa.gov> Dear SLS WG member, Please note that the registration for the Spring 2018 CCSDS meetings in Gaithersburg, MD, USA are now open! Best regards, Greg Kazz Chairman CCSDS SLS-SLP WG From: CCSDS-All on behalf of CCSDS-All Reply-To: "secretariat at mailman.ccsds.org" , "ccsds-all at mailman.ccsds.org" Date: Friday, February 16, 2018 at 11:46 AM To: "ccsds-all at mailman.ccsds.org" Subject: [CCSDS-All] Spring 2018 Technical Meetings - Gaithersburg, Maryland, USA - Registration Now Open SPRING 2018 TECHNICAL PLENARY MEETING Hosted by NASA, the CCSDS Spring 2018 meeting series will be held at the National Institute of Standards and Technology (NIST) in Gaithersburg, Maryland, USA. The main technical meeting series will be held 9-13 April 2018. [Note: This will be a five-day technical meeting.] The CESG Meeting will be held on 16 April 2018 also at NIST in Gaithersburg. The Spring CMC Meetings will be held on 14-17 May 2018 at NSSC in Beijing, China hosted by CNSA. For details and to register, https://cwe.ccsds.org/fm/ProfileSDL/My%20Profile.aspx All meeting attendees who are not US citizens will need to register with NIST on the NIST Conference Registration Website after completing registration on the CWE: https://appam.certain.com/profile/form/index.cfm?PKformID=0x41934abcd. All non-US citizens must register with NIST no later than 30 March 2018. This registration system takes the place of the NIST 1260 forms previously posted on the meeting information page. Even if you already submitted a NIST 1260 by fax, please still complete registration on the NIST Conference Registration Website. After you submit your information, you will receive a confirmation email. If you do not submit your information on NIST’s Conference Registration Website, you will not be allowed on campus and will be unable to take part in the meetings. Maps, hotel and other information are available at https://public.ccsds.org/meetings/2018Spring/default.aspx IMPORTANT: Please note the following instructions and process: 1) All Users must have a CWE login. If not, then you must request one: http://cwe.ccsds.org/ReqLogin.aspx. =Several of the links in this e-mail will prompt you for your CWE Login. 2) All Users should review their User Profile before Registering for the Spring 2018 Meetings. 3) After your meeting registration is submitted you will receive a confirmation e-mail, like in previous registrations, and you will also receive a URL which allows you to edit your registration. Registration will close on 30 March 2018, one week before the start of the technical meetings to provide sufficient time for final logistics planning at NIST. All attendees that require a Letter of Invitation for visa purposes should already have their letter. However, if you do not have a letter, please contact the Secretariat (Secretariat at mailman.ccsds.org) immediately so it can be arranged. Also, as always, dress for the Technical Plenary meeting is Business Casual. We look forward to seeing you in Gaithersburg, Maryland, USA. FALL 2018 TECHNICAL PLENARY MEETING The Fall 2018 technical plenary will be hosted by DLR in Berlin, Germany. The technical meetings will be held from 15-19 October 2018. The CESG Executive Committee will meet on Monday, 22 October 2018 also in Berlin. The CMC will meet separately on 22-24 October 2018 in Berlin, Germany, hosted by DLR. Some preliminary information will be available after the Spring meetings. If you need a visa letter to attend the Fall 2018 meeting, please inform the Secretariat (Secretariat at mailman.ccsds.org), or indicate this when registering online, so that one may be prepared. CCSDS MEMBERSHIP, PARTICIPATION, IMPLEMENTATIONS Here are some reminders that are important whether or not you or your organization is going to attend a CCSDS meeting. If you are from a government agency that is not yet a CCSDS Observer Agency, you should consider registering your organization as a CCSDS Observer. Information is here: http://public.ccsds.org/participation/observer_agencies.aspx If you are from private industry or an academic organization that is involved (or interested) in CCSDS, but is not yet an Associate, you should consider registering your organization as a CCSDS Associate. Information is here: http://public.ccsds.org/participation/associates.aspx If your team is looking for software implementations that are publicly available, you should visit this page: http://public.ccsds.org/implementations/software.aspx If your team has developed software implementations that are publicly available, you should notify the Secretariat with info to post it on that same page: http://public.ccsds.org/implementations/software.aspx If your team has CCSDS implementations commercially available, you can have information about it posted on the CCSDS website, here: https://public.ccsds.org/implementations/products/default.aspx If you are explaining CCSDS to your organization, there are overview resources available here: https://public.ccsds.org/outreach/overview.aspx If you have any questions or comments, please email secretariat at mailman.ccsds.org We look forward to seeing you in Gaithersburg. Best regards, Michael Blackwood CCSDS Secretariat W: 301-837-3901 | michael.blackwood at asrcfederal.com 7515 Mission Drive, Seabrook, MD 20706 ASRC Federal | Customer-Focused. Operationally Excellent. ________________________________ The preceding message (including attachments) is covered by the Electronic Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for the person or entity to which it is addressed, and may contain information that is confidential, protected by attorney-client or other privilege, or otherwise protected from disclosure by law. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error and destroy the original message and all copies. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001.txt URL: From greg.j.kazz at jpl.nasa.gov Tue Feb 20 16:59:16 2018 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 20 Feb 2018 16:59:16 +0000 Subject: [Sls-slp] NIST Registration required for non USA nationals Message-ID: Dear SLP WG members, (Per Gian Paolo’s email message to me) As per https://public.ccsds.org/meetings/2018Spring/default.aspx : All non-US citizens must register with NIST no later than 30 March 2018. If you do not submit your information on NIST's Conference Registration Website, you will not be allowed on campus and will be unable to take part in the meetings. In the past we have been able to register persons just a few days/hours before the meetings, but the additional NIST registration may prevent doing this for the Spring 2018 meetings. best regards, Greg Chairman CCSDS SLP WG Greg Kazz Principal Engineer Technical Group Supervisor, Project Software and End-to-End Information Systems Engineering (312B) Jet Propulsion Laboratory 4800 Oak Grove Dr., M/S 301-490 Pasadena, CA 91109 1+(818)393 6529(voice) 1+(818)393 6871(fax) email: greg.j.kazz at jpl.nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Feb 20 19:32:44 2018 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 20 Feb 2018 19:32:44 +0000 Subject: [Sls-slp] Technical Corrigenda for TC Message-ID: <1F4C9A01-5200-4A69-8E53-CFACF9E4E031@jpl.nasa.gov> Dear SLP WG members, Please see the following URL for a presentation by Gian Paolo Calzolari on technical corrigenda on the Telecommand Space Data Link Protocol (CCSDS 232.0-B-3) to be discussed at the Spring 2018 SLP WG meeting in Gaithersburg, MD. Please feel free to let me and the WG know if you have any questions or issues with this material. https://tinyurl.com/ydapl9re Best regards, Greg CCSDS SLP WG Chairman Greg Kazz Principal Engineer Technical Group Supervisor, Project Software and End-to-End Information Systems Engineering (312B) Jet Propulsion Laboratory 4800 Oak Grove Dr., M/S 301-490 Pasadena, CA 91109 1+(818)393 6529(voice) 1+(818)393 6871(fax) email: greg.j.kazz at jpl.nasa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: