From greg.j.kazz at jpl.nasa.gov  Thu Jan 25 22:40:32 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Thu, 25 Jan 2018 22:40:32 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising
	SPP Blue Book
Message-ID: <3A82A9FC-F35B-46F3-AD40-790286255F81@jpl.nasa.gov>

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180125/8e7c429d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Response from Takahiro Yamada on 12.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 16489 bytes
Desc: Response from Takahiro Yamada on 12.docx
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180125/8e7c429d/attachment.docx>

From greg.j.kazz at jpl.nasa.gov  Fri Jan 26 21:36:15 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Fri, 26 Jan 2018 21:36:15 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <3A82A9FC-F35B-46F3-AD40-790286255F81@jpl.nasa.gov>
References: <3A82A9FC-F35B-46F3-AD40-790286255F81@jpl.nasa.gov>
Message-ID: <E4A1E455-486A-485C-A992-436A1E59A161@jpl.nasa.gov>

All,

Based upon the results of the Doodle Poll, the telecom will be held on Wed. Jan 31 from 7 to 8 AM Pacific Time.

Please see:

https://doodle.com/poll/mrwss8pab88eafq6

best regards,

Greg

From: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
Date: Thursday, January 25, 2018 at 2:40 PM
To: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180126/9c40af7c/attachment.html>

From john.pietras at gst.com  Sat Jan 27 15:20:59 2018
From: john.pietras at gst.com (John Pietras)
Date: Sat, 27 Jan 2018 15:20:59 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising	SPP Blue Book
In-Reply-To: <3A82A9FC-F35B-46F3-AD40-790286255F81@jpl.nasa.gov>
References: <3A82A9FC-F35B-46F3-AD40-790286255F81@jpl.nasa.gov>
Message-ID: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>

Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180127/7108af28/attachment.html>

From Gian.Paolo.Calzolari at esa.int  Sat Jan 27 19:00:24 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Sat, 27 Jan 2018 20:00:24 +0100
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising	SPP Blue Book
In-Reply-To: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
Message-ID: <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>

Good hint, John. 
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required. 
Regards
Gian Paolo

Sent from my iPhone

> On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com> wrote:
> 
> Members of the SLPWG,
> I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.
>  
> Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate. 
>  
> I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.
>  
> Best regards,
> John Pietras
>  
> From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
> Sent: Thursday, January 25, 2018 5:41 PM
> To: sls-slp at mailman.ccsds.org
> Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book
>  
> Dear SLP WG,
>  
> Happy New Year 2018 !
>  
> This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.
>  
> Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.
>  
> I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
> I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.
>  
> 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
>  

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180127/6bdd8b07/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Mon Jan 29 18:29:35 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Mon, 29 Jan 2018 18:29:35 +0000
Subject: [Sls-slp] SLP WG Telecon #1 on Revising SPP Blue Book Meet me
 Number is : +1 818-393 2747
Message-ID: <CEEBB0D5-1A37-4FE9-9D77-6BC22846BFD0@jpl.nasa.gov>

Dear All,

I’ve set up a meet me conference telephone line for all to dial into.

The number will be active on Jan 31, 2018 from 7 AM to 8 AM Pacific Time.

The number is:   +1  818-393 2747

Topic are the recommendations I made with comments by Takahiro and John Pietras concerning revising the current SPP blue book.

Hope to hear from you then,

Greg Kazz
Chairman CCSDS SLP WG

From: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
Date: Friday, January 26, 2018 at 1:36 PM
To: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Re: Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

All,

Based upon the results of the Doodle Poll, the telecom will be held on Wed. Jan 31 from 7 to 8 AM Pacific Time.

Please see:

https://doodle.com/poll/mrwss8pab88eafq6

best regards,

Greg

From: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
Date: Thursday, January 25, 2018 at 2:40 PM
To: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/48c6cf20/attachment.html>

From peter.m.shames at jpl.nasa.gov  Mon Jan 29 19:20:07 2018
From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (312B))
Date: Mon, 29 Jan 2018 19:20:07 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
	Revising	SPP Blue Book
In-Reply-To: <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>,
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
Message-ID: <2C028A59-4774-44F3-AB6F-A142AE7A7B88@jpl.nasa.gov>

I think John is right.  The distinction is between a “Space Packet Service “ that is a data encapsulation and multiplexing service within some “subnet”  and a Packet Transfer Service that is the way Space Packets are transferred over an SDL.  This does include the SPP muxing into an SDL VC.  SPP itself cannot assert responsibility for this since it has only virtual (or managed) knowledge of how the packets will be transferred over the subnet.

Regards, Peter

Sent from Peter's JPL iPhone 7

Everything should be made as simple as possible,
but not simpler.

~Albert Einstein

On Jan 27, 2018, at 11:00 AM, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>> wrote:

Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo

Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:

Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>


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<mailto:SLS-SLP at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/125638df/attachment.html>

From Gian.Paolo.Calzolari at esa.int  Mon Jan 29 19:28:52 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Mon, 29 Jan 2018 20:28:52 +0100
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising	SPP Blue Book
In-Reply-To: <2C028A59-4774-44F3-AB6F-A142AE7A7B88@jpl.nasa.gov>
Message-ID: <17264_1517254134_5A6F75F6_17264_91_1_OF6DCB134F.C003B5E0-ONC1258224.006B0338-1517254132565@esa.int>

Peter, i did not refer to VC multiplexing, fully defined in the soace data link protocols, but to the APID miltiplexing or similar issues. 
Ciao
Gian Paoli

Sent from my iPhone

> On 29. Jan 2018, at 20:20, Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov> wrote:
> 
> I think John is right.  The distinction is between a “Space Packet Service “ that is a data encapsulation and multiplexing service within some “subnet”  and a Packet Transfer Service that is the way Space Packets are transferred over an SDL.  This does include the SPP muxing into an SDL VC.  SPP itself cannot assert responsibility for this since it has only virtual (or managed) knowledge of how the packets will be transferred over the subnet.
> 
> Regards, Peter
> 
> Sent from Peter's JPL iPhone 7
> 
> Everything should be made as simple as possible, 
> but not simpler.  
> 
> ~Albert Einstein
> 
> On Jan 27, 2018, at 11:00 AM, "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int> wrote:
> 
>> Good hint, John. 
>> It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required. 
>> Regards
>> Gian Paolo
>> 
>> Sent from my iPhone
>> 
>> On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com> wrote:
>> 
>>> Members of the SLPWG,
>>> I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.
>>>  
>>> Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.
>>>  
>>> I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.
>>>  
>>> Best regards,
>>> John Pietras
>>>  
>>> From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
>>> Sent: Thursday, January 25, 2018 5:41 PM
>>> To: sls-slp at mailman.ccsds.org
>>> Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book
>>>  
>>> Dear SLP WG,
>>>  
>>> Happy New Year 2018 !
>>>  
>>> This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.
>>>  
>>> Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.
>>>  
>>> I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
>>> I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.
>>>  
>>> 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
>>>  
>> 
>> 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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/c5209f87/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Mon Jan 29 19:58:50 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Mon, 29 Jan 2018 19:58:50 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
Message-ID: <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>

John and Gian Paolo,

It is always worthwhile to ensure we are doing this update correctly.
But I think in this case, it is the SDLPs (AOS, TM, TC, and the emerging USLP, not Prox-1 because there are no services defined) that provide the Packet Service with the functionality of muxing/demuxing Packets with different APIDs PVNs into/out of a single VC and NOT the SPP Packet Service.

So I still agree with Takahiro, that CCSDS should delete the SPP Packet Service but keep all of the SDLP Packet Services as currently defined in the SDLP blue books. The additional benefit of removing the SPP Packet Service is removing the confusion of having “yet another Packet Service” as defined in SPP.

Below is my analysis:

Packet Service as defined in 3.3.1 Overview of Packet Service in SPP is:

The Packet Service shall transfer Space Packets, pre-formatted by the service user, intact through the LDP.
The service user must generate Space Packets according to the specification given in section 4 of this Recommendation.
Space Packets supplied by the service user shall be transferred by the service provider without further formatting.

*** N.B. There is no mention of muxing/demuxing Packets with different PVNs into/out of a single VC  … in the SPP document **


I reviewed the AOS SDLP. Below I have cut out a portion of Section 2.2.3.2 Virtual Channel Packet Service and 3.3.1 Overview of VCP Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

The exact same words are used in the TM SDLP, because the VCP Service is defined. See Sections 2.2.3.2 VCP Service and 3.3.1. Overview of VCP Service

A user of this service is a protocol entity that ends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

Very similar for TC SDLP; except for TC, we define the MAP Packet Service.  See 2.2.3.3 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity identified with the PVN and a GMAP ID (i.e., a
GVCID and a MAP ID) that sends or receives Packets with a single PVN. Different users
(i.e., Packets with different versions) can share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.

We define MAP Packet Service in USLP SDLP to be the same as the one in TC SDLP. See 2.2.3.2 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN and identified with the PVN and a GMAP ID.
Different users (i.e., Packets with different PVNs) may share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.


Regards,
Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Saturday, January 27, 2018 at 11:00 AM
To: John Pietras <john.pietras at gst.com>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo
Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:
Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>


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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/4869fea3/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Mon Jan 29 20:34:05 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Mon, 29 Jan 2018 20:34:05 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <17264_1517254134_5A6F75F6_17264_91_1_OF6DCB134F.C003B5E0-ONC1258224.006B0338-1517254132565@esa.int>
References: <2C028A59-4774-44F3-AB6F-A142AE7A7B88@jpl.nasa.gov>
 <17264_1517254134_5A6F75F6_17264_91_1_OF6DCB134F.C003B5E0-ONC1258224.006B0338-1517254132565@esa.int>
Message-ID: <C6621179-2887-4A56-B7E2-55E86F0601E9@jpl.nasa.gov>

The SPP “Packet Service” as currently defined lightly touches upon APID multiplexing within some “subnet”  in the actual primitives (Packet Request, Packet Indication) but not in the overview. It is very open ended and so much so that there is really no interoperability here.
Data Encapsulation Service for CCSDS Packets is defined in the separate Encapsulation Service Blue Book.
Multiplexing Packets with different PVNs into VCs is covered by the SDLPs except Prox-1.

We will further discuss this during the Telecon on Wed.
To me one of the questions is: Is there any merit in keeping the “APID Multiplexing within some subnet” Packet Service in SPP ?  Clearly the way it is defined today, no. Could it be redefined to be interoperable and useful ? Perhaps, but only if it is restricted to a single closed subnet within an A-B-A configuration.

Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Monday, January 29, 2018 at 11:28 AM
To: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Peter, i did not refer to VC multiplexing, fully defined in the soace data link protocols, but to the APID miltiplexing or similar issues.
Ciao
Gian Paoli
Sent from my iPhone

On 29. Jan 2018, at 20:20, Shames, Peter M (312B) <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>> wrote:
I think John is right.  The distinction is between a “Space Packet Service “ that is a data encapsulation and multiplexing service within some “subnet”  and a Packet Transfer Service that is the way Space Packets are transferred over an SDL.  This does include the SPP muxing into an SDL VC.  SPP itself cannot assert responsibility for this since it has only virtual (or managed) knowledge of how the packets will be transferred over the subnet.

Regards, Peter
Sent from Peter's JPL iPhone 7

Everything should be made as simple as possible,
but not simpler.

~Albert Einstein

On Jan 27, 2018, at 11:00 AM, "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>> wrote:
Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo
Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:
Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>


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<mailto: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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/3206d7d9/attachment.html>

From john.pietras at gst.com  Mon Jan 29 20:44:00 2018
From: john.pietras at gst.com (John Pietras)
Date: Mon, 29 Jan 2018 20:44:00 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
Message-ID: <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>

Greg,
Your first paragraph states my case exactly, where you strike out APIDs and put in PVNs. The SPP give the functionality of multiplexing by APIDs, which is *not* covered by the current AOS, TC, or TM SDLP books.

I have only paper copies of the AOS 701.0 Blue Books, so I can’t cut and paste all of the relevant sections from that document, but here’s section 2.4.1.5.b from 701.0-B-2 (Nov. 1992), which explains the gist of the capability that will lost if the SPP is scrapped: “Individual CCSDS Packets from multiple sources [underline mine]are concatenated together into a contiguous string of Packets, which is then broken into blocks whose length is arranged such that they may be loaded exactly into the fixed-length CVCDU Data Unit Zone. Several individual “Packet Channels” may thus concurrently share one VC using the [packet] Multiplexing functions. Each Packet Channel is locally identified using the “Application Process ID” (APID) field contained in the CCSDS Packet header [underline again mine].”

Looking past the “packet channel” and “subnet” terminology, the idea was that different applications (i.e., different APIDs) could share the same VC. E.g., several sources of low-rate, sporadic data could share the same VC. This is *different from* the PVN multiplexing that is in the current SDLP books, which to my understanding is there mainly to accommodate mixing version 1 and version 2 Space Packets with Encapsulation packets in a single VC.

Just to be clear -  I’m not insisting that muxing of different packet channels (APIDs) into a single VC has to be retained – there may be good reasons why no one would ever actually want to do it and/or it may never actually have been used. My only reason to bring this up is to point out that there *is*  a difference between the “APID muxing” provided by the SPP and the “PVN muxing” provided by the current SDLP books, and that the WG should consider whether they want to deprecate that capability (probably with clarification to eliminate implications of end-to-end “routing”, etc.). Also, you might want to check with ISS, since they implemented AOS even before it was completely Blue – they may very well have multiple APIDs carried in a single VC.

Unfortunately, I have a doctor’s appoint on Wednesday morning. I may get back in time to call into the telecon, and will do so if possible. But if I don’t, I think/hope that I’ve explained the situation well enough that the WG can deliberate on the merits of my observations (or lack thereof).

Best regards,
John

From: Kazz, Greg J (312B) [mailto:greg.j.kazz at jpl.nasa.gov]
Sent: Monday, January 29, 2018 2:59 PM
To: Gian.Paolo.Calzolari at esa.int; John Pietras
Cc: sls-slp at mailman.ccsds.org
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

John and Gian Paolo,

It is always worthwhile to ensure we are doing this update correctly.
But I think in this case, it is the SDLPs (AOS, TM, TC, and the emerging USLP, not Prox-1 because there are no services defined) that provide the Packet Service with the functionality of muxing/demuxing Packets with different APIDs PVNs into/out of a single VC and NOT the SPP Packet Service.

So I still agree with Takahiro, that CCSDS should delete the SPP Packet Service but keep all of the SDLP Packet Services as currently defined in the SDLP blue books. The additional benefit of removing the SPP Packet Service is removing the confusion of having “yet another Packet Service” as defined in SPP.

Below is my analysis:

Packet Service as defined in 3.3.1 Overview of Packet Service in SPP is:

The Packet Service shall transfer Space Packets, pre-formatted by the service user, intact through the LDP.
The service user must generate Space Packets according to the specification given in section 4 of this Recommendation.
Space Packets supplied by the service user shall be transferred by the service provider without further formatting.

*** N.B. There is no mention of muxing/demuxing Packets with different PVNs into/out of a single VC  … in the SPP document **


I reviewed the AOS SDLP. Below I have cut out a portion of Section 2.2.3.2 Virtual Channel Packet Service and 3.3.1 Overview of VCP Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

The exact same words are used in the TM SDLP, because the VCP Service is defined. See Sections 2.2.3.2 VCP Service and 3.3.1. Overview of VCP Service

A user of this service is a protocol entity that ends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

Very similar for TC SDLP; except for TC, we define the MAP Packet Service.  See 2.2.3.3 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity identified with the PVN and a GMAP ID (i.e., a
GVCID and a MAP ID) that sends or receives Packets with a single PVN. Different users
(i.e., Packets with different versions) can share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.

We define MAP Packet Service in USLP SDLP to be the same as the one in TC SDLP. See 2.2.3.2 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN and identified with the PVN and a GMAP ID.
Different users (i.e., Packets with different PVNs) may share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.


Regards,
Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Saturday, January 27, 2018 at 11:00 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo
Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:
Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>


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.



________________________________

Spam<https://filter.gst.com/canit/b.php?c=s&i=01V4jXOp8&m=1a3091b1c61c>
Not spam<https://filter.gst.com/canit/b.php?c=n&i=01V4jXOp8&m=1a3091b1c61c>
Forget previous vote<https://filter.gst.com/canit/b.php?c=f&i=01V4jXOp8&m=1a3091b1c61c>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/070ada1f/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Mon Jan 29 21:57:12 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Mon, 29 Jan 2018 21:57:12 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
Message-ID: <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>

John,

Thanks for this follow on explanation – it helps a lot.
I think the restructuring in 2000 removed that underlined bit of information you mentioned here. 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.

I know of many missions that assign different APIDs to a given VCID on the downlink. So I would never want to eliminate that capability. But given how the current SPP defines the SPP Packet Service, I have a very hard time understanding how to actually create an interoperable implementation.

Greg

From: John Pietras <john.pietras at gst.com>
Date: Monday, January 29, 2018 at 12:43 PM
To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: RE: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Greg,
Your first paragraph states my case exactly, where you strike out APIDs and put in PVNs. The SPP give the functionality of multiplexing by APIDs, which is *not* covered by the current AOS, TC, or TM SDLP books.

I have only paper copies of the AOS 701.0 Blue Books, so I can’t cut and paste all of the relevant sections from that document, but here’s section 2.4.1.5.b from 701.0-B-2 (Nov. 1992), which explains the gist of the capability that will lost if the SPP is scrapped: “Individual CCSDS Packets from multiple sources [underline mine]are concatenated together into a contiguous string of Packets, which is then broken into blocks whose length is arranged such that they may be loaded exactly into the fixed-length CVCDU Data Unit Zone. Several individual “Packet Channels” may thus concurrently share one VC using the [packet] Multiplexing functions. Each Packet Channel is locally identified using the “Application Process ID” (APID) field contained in the CCSDS Packet header [underline again mine].”

Looking past the “packet channel” and “subnet” terminology, the idea was that different applications (i.e., different APIDs) could share the same VC. E.g., several sources of low-rate, sporadic data could share the same VC. This is *different from* the PVN multiplexing that is in the current SDLP books, which to my understanding is there mainly to accommodate mixing version 1 and version 2 Space Packets with Encapsulation packets in a single VC.

Just to be clear -  I’m not insisting that muxing of different packet channels (APIDs) into a single VC has to be retained – there may be good reasons why no one would ever actually want to do it and/or it may never actually have been used. My only reason to bring this up is to point out that there *is*  a difference between the “APID muxing” provided by the SPP and the “PVN muxing” provided by the current SDLP books, and that the WG should consider whether they want to deprecate that capability (probably with clarification to eliminate implications of end-to-end “routing”, etc.). Also, you might want to check with ISS, since they implemented AOS even before it was completely Blue – they may very well have multiple APIDs carried in a single VC.

Unfortunately, I have a doctor’s appoint on Wednesday morning. I may get back in time to call into the telecon, and will do so if possible. But if I don’t, I think/hope that I’ve explained the situation well enough that the WG can deliberate on the merits of my observations (or lack thereof).

Best regards,
John

From: Kazz, Greg J (312B) [mailto:greg.j.kazz at jpl.nasa.gov]
Sent: Monday, January 29, 2018 2:59 PM
To: Gian.Paolo.Calzolari at esa.int; John Pietras
Cc: sls-slp at mailman.ccsds.org
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

John and Gian Paolo,

It is always worthwhile to ensure we are doing this update correctly.
But I think in this case, it is the SDLPs (AOS, TM, TC, and the emerging USLP, not Prox-1 because there are no services defined) that provide the Packet Service with the functionality of muxing/demuxing Packets with different APIDs PVNs into/out of a single VC and NOT the SPP Packet Service.

So I still agree with Takahiro, that CCSDS should delete the SPP Packet Service but keep all of the SDLP Packet Services as currently defined in the SDLP blue books. The additional benefit of removing the SPP Packet Service is removing the confusion of having “yet another Packet Service” as defined in SPP.

Below is my analysis:

Packet Service as defined in 3.3.1 Overview of Packet Service in SPP is:

The Packet Service shall transfer Space Packets, pre-formatted by the service user, intact through the LDP.
The service user must generate Space Packets according to the specification given in section 4 of this Recommendation.
Space Packets supplied by the service user shall be transferred by the service provider without further formatting.

*** N.B. There is no mention of muxing/demuxing Packets with different PVNs into/out of a single VC  … in the SPP document **


I reviewed the AOS SDLP. Below I have cut out a portion of Section 2.2.3.2 Virtual Channel Packet Service and 3.3.1 Overview of VCP Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

The exact same words are used in the TM SDLP, because the VCP Service is defined. See Sections 2.2.3.2 VCP Service and 3.3.1. Overview of VCP Service

A user of this service is a protocol entity that ends or receives Packets with a single PVN. A
user is identified with the PVN and a GVCID. Different users (i.e., Packets with different
versions) can share a single Virtual Channel, and if there are multiple users on a Virtual
Channel, the service provider multiplexes Packets of different versions to form a single
stream of Packets to be transferred on that Virtual Channel.

Very similar for TC SDLP; except for TC, we define the MAP Packet Service.  See 2.2.3.3 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity identified with the PVN and a GMAP ID (i.e., a
GVCID and a MAP ID) that sends or receives Packets with a single PVN. Different users
(i.e., Packets with different versions) can share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.

We define MAP Packet Service in USLP SDLP to be the same as the one in TC SDLP. See 2.2.3.2 and 3.3.1 Overview of MAP Packet Service

A user of this service is a protocol entity that sends or receives Packets with a single PVN and identified with the PVN and a GMAP ID.
Different users (i.e., Packets with different PVNs) may share a single MAP Channel, and if there are
multiple users on a MAP Channel, the service provider multiplexes Packets of different
versions to form a single stream of Packets to be transferred on that MAP Channel.


Regards,
Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Saturday, January 27, 2018 at 11:00 AM
To: John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>, "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Good hint, John.
It looks as we shall carry out a good comparison of the the homonymous services and determine the real deltas. It may be that in SPP only a Space Packet Multiplexing is required.
Regards
Gian Paolo
Sent from my iPhone

On 27. Jan 2018, at 16:21, John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>> wrote:
Members of the SLPWG,
I have read through Greg’s summary of his conversation with  Takahiro regarding suggested simplifications of the SPP book. One of those suggested changes is the removal of the Packet Service, which the memo implied was redundant with this Packet Service provided by the Space Data Link Protocols. This is not quite true – the Packet Service that is provided by the SPP provides the additional functionality of muxing/demuxing Packets with different APIDs into/out of a single VC.

Admittedly, I have been away from the day-to-day considerations of space link protocols for many years, but having been a member of the Panel 1 F/G team that wrote the original AOS Blue Book I can attest to the fact that the  ability to flow multiple “packet channels”  through a single VC was an important aspect of the protocol stack, at least at the time (late 80s). Unless there is no longer a perceived need to do such packet channel muxing/demuxing, such a capability would have to be retained in the SPP book or re-integrated into the various SDLP books as appropriate.

I will agree that calling both the SPP “Packet Services” and the SLDP “Packet Services” by the same name is confusing and can lead to overlooking this additional functionality of the SPP flavor of the service. Perhaps a different name to distinguish them would be useful.

Best regards,
John Pietras

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B)
Sent: Thursday, January 25, 2018 5:41 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on Revising SPP Blue Book

Dear SLP WG,

Happy New Year 2018 !

This topic concerns the new project recently approved for revising the Space Packet Protocol (SPP) Blue book.

Please read the attached Word file that contains a discussion I had with Takahiro Yamada, the driving force in the CCSDS restructuring of the Packet Telemetry Blue Book. Parts of that book under Takahiro’s guidance became the Space Packet Protocol, SPP, which we are now tasked to revise and update.

I have made several suggestions about removing sections of the existing SPP document and I have asked Takahiro to give us his opinion about it.
I would like to hold a 1 hour telecon on this subject in the very near future. I will set up a doodle poll to determine when the best time will be to discuss this topic. Please look forward to the invitation. If you don’t see one, please let me know so that I can add you to the list, if I missed you.

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<mailto:greg.j.kazz at jpl.nasa.gov>


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.



________________________________

Spam<https://filter.gst.com/canit/b.php?c=s&i=01V4jXOp8&m=1a3091b1c61c>
Not spam<https://filter.gst.com/canit/b.php?c=n&i=01V4jXOp8&m=1a3091b1c61c>
Forget previous vote<https://filter.gst.com/canit/b.php?c=f&i=01V4jXOp8&m=1a3091b1c61c>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180129/41085227/attachment.html>

From Gian.Paolo.Calzolari at esa.int  Tue Jan 30 13:54:51 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Tue, 30 Jan 2018 14:54:51 +0100
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
 <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>
Message-ID: <826_1517320493_5A70792D_826_77_1_OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6F18@esa.int>

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/4eb667a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21544 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/4eb667a4/attachment.gif>

From Gian.Paolo.Calzolari at esa.int  Tue Jan 30 17:22:54 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Tue, 30 Jan 2018 18:22:54 +0100
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet
	Service
In-Reply-To: <OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6EE7@LocalDomain>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
 <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>
 <OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6EE7@LocalDomain>
Message-ID: <9201_1517332976_5A70A9EF_9201_1475_1_OF2778BE76.A477091B-ONC1258225.00567FD0-C1258225.005F7AFC@esa.int>

Dear Greg,
        first of all I think that a few years years we decided to rename 
the Packet Service in the Space Data Link Protocols books to Virtual 
Channel Packet (VCP) Service to avoid confusion wit the service defined in 
SPP.

We shall also keep in mind that almost often the SDLP books leave 
undefined some details of procedures left to "management". An example is 
AOS section 4.2.5 VIRTUAL CHANNEL MULTIPLEXING FUNCTION only says (among 
other things that
4.2.5.2 The Virtual Channel Multiplexing Function shall multiplex Transfer 
Frames received from the instances of the Virtual Channel Generation 
Function and, if present, the Virtual Channel Frame Service users, in an 
appropriate order that is set by management.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed 
Transfer Frames into a queue.
4.2.5.3 The algorithm used to order the Transfer Frames is not specified 
by CCSDS, but shall be defined by project organizations considering 
factors such as priority, release rate, isochronous timing requirements, 
etc.

The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION 
stating
4.3.6.2 The Virtual Channel Multiplexing Function shall multiplex Transfer 
Frames received from the instances of the Virtual Channel Generation 
Function and, if present, the Virtual Channel Frame Service users, in an 
appropriate order set by management.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed 
Transfer Frame  into a queue.
4.3.6.3 The algorithm to be used to order the Transfer Frames is not 
specified by CCSDS, but shall be defined by project organizations 
considering factors such as priority, release rate, isochronous timing 
requirements, etc.

However FSP -  had to be more specific and it includes many more details 
for VC multiplexing.
FSP also mention sets of APIDs assigned to VCs.

Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it 
is stated that 
A user of this service is a protocol entity that sends or receives Packets 
with a single PVN. A user is identified with the PVN and a GVCID.
In other words it looks fully correct that only one SPP user can provide 
packets (with SAP Address = GVCID + Packet Version Number) to an instance 
of the VCP Service 

On the other end we shall also make sure that we have consistency with 
CCSDS 133.1-B-2 that is the service able to create Space/Encapsulation 
Packets 

Another point that does show what we need to keep both services is given 
by the primitives.
In the Space Data Link Protocol (e.g. for AOS) we have that "At the 
sending end, the VCP Service user shall pass a VCP.request primitive to 
the service provider to request that a Packet be transferred to the user 
at the receiving end through the specified Virtual Channel." and "The 
VCP.request primitive shall provide parameters as follows: VCP.request 
(Packet, GVCID, Packet Version Number)"

Conversely in SPP  "The PACKET.request primitive shall provide parameters 
as follows: PACKET.request (Space Packet, APID, APID Qualifier (optional), 
QoS Requirement (optional))" and you see the difference for the parameters 
that the upper layer (SPP on top of SDLP / AP on top of SPP) shall 
provide.
Of course we also have the possibility that there is Encapsulation of top 
of SDLP.

Last question.
Do we want to rule out packets from Proximity-1 forever?
Of course there is nothing preventing a Proximity-1 frame from carrying 
one or more Packets and I think only spill over would be prohibited by the 
absence of a first header pointer in the Proximity-1 frame?

Regards

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/b98a449f/attachment.html>

From john.pietras at gst.com  Tue Jan 30 18:06:35 2018
From: john.pietras at gst.com (John Pietras)
Date: Tue, 30 Jan 2018 18:06:35 +0000
Subject: [Sls-slp] Results of Discussion with Takahiro Yamada on
 Revising SPP Blue Book
In-Reply-To: <826_1517320493_5A70792D_826_77_1_OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6F18@esa.int>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <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>
Message-ID: <BN6PR19MB1458AC7EA04BD93B3375FC3590E40@BN6PR19MB1458.namprd19.prod.outlook.com>

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.




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/88bfbff5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 21544 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/88bfbff5/attachment.gif>

From greg.j.kazz at jpl.nasa.gov  Tue Jan 30 18:11:54 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Tue, 30 Jan 2018 18:11:54 +0000
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet
 Service
In-Reply-To: <9201_1517332976_5A70A9EF_9201_1475_1_OF2778BE76.A477091B-ONC1258225.00567FD0-C1258225.005F7AFC@esa.int>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
 <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>
 <OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6EE7@LocalDomain>
 <9201_1517332976_5A70A9EF_9201_1475_1_OF2778BE76.A477091B-ONC1258225.00567FD0-C1258225.005F7AFC@esa.int>
Message-ID: <35F89FCA-6281-4985-BB81-AD9E6D9FA166@jpl.nasa.gov>

G.P.,

Thanks for the good forensic work.
I am aware of the differences between in the “Packet” primitives in the SDLP and SPP cases.
However, my problem with the SPP primitives as currently defined, is that they describe a kind of fantasy world in fact worse than that they are specious. They give the appearance that one can actually do something and achieve interoperability, but in reality it is not the case. In that sense, I say, if we cannot more concretely define these primitives (SPP Packet .request and .indication), then we are better off deleting them. For example, one problem is that APID Qualifier is totally left up to the user to define. This is part of the discussion Scott Burleigh, Jonathan Wilmot, Keith Scott, all, etc from SIS were discussing in the Haag. In reality, missions come up with their own ways of assigning APIDs to VCIDs. Maybe in SPP we simply need to acknowledge and document that these steps are done outside of CCSDS services. One way to consider at least.


Concerning your Prox-1 questions: Packets are defined data types in Prox-1. Prox-1 is like TC due to the variable frame length and the frame length field in the transfer frame header. I think the real solution is for missions to eventually migrate to USLP.

Greg

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, January 30, 2018 at 9:22 AM
To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP <sls-slp-bounces at mailman.ccsds.org>
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet Service

Dear Greg,
        first of all I think that a few years years we decided to rename the Packet Service in the Space Data Link Protocols books to Virtual Channel Packet (VCP) Service to avoid confusion wit the service defined in SPP.

We shall also keep in mind that almost often the SDLP books leave undefined some details of procedures left to "management". An example is AOS section 4.2.5 VIRTUAL CHANNEL MULTIPLEXING FUNCTION only says (among other things that
4.2.5.2 The Virtual Channel Multiplexing Function shall multiplex Transfer Frames received from the instances of the Virtual Channel Generation Function and, if present, the Virtual Channel Frame Service users, in an appropriate order that is set by management.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed Transfer Frames into a queue.
4.2.5.3 The algorithm used to order the Transfer Frames is not specified by CCSDS, but shall be defined by project organizations considering factors such as priority, release rate, isochronous timing requirements, etc.

The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION stating
4.3.6.2 The Virtual Channel Multiplexing Function shall multiplex Transfer Frames received from the instances of the Virtual Channel Generation Function and, if present, the Virtual Channel Frame Service users, in an appropriate order set by management.
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed Transfer Frame  into a queue.
4.3.6.3 The algorithm to be used to order the Transfer Frames is not specified by CCSDS, but shall be defined by project organizations considering factors such as priority, release rate, isochronous timing requirements, etc.

However FSP -  had to be more specific and it includes many more details for VC multiplexing.
FSP also mention sets of APIDs assigned to VCs.

Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it is stated that
A user of this service is a protocol entity that sends or receives Packets with a single PVN. A user is identified with the PVN and a GVCID.
In other words it looks fully correct that only one SPP user can provide packets (with SAP Address = GVCID + Packet Version Number) to an instance of the VCP Service

On the other end we shall also make sure that we have consistency with CCSDS 133.1-B-2 that is the service able to create Space/Encapsulation Packets

Another point that does show what we need to keep both services is given by the primitives.
In the Space Data Link Protocol (e.g. for AOS) we have that "At the sending end, the VCP Service user shall pass a VCP.request primitive to the service provider to request that a Packet be transferred to the user at the receiving end through the specified Virtual Channel." and "The VCP.request primitive shall provide parameters as follows: VCP.request (Packet, GVCID, Packet Version Number)"

Conversely in SPP  "The PACKET.request primitive shall provide parameters as follows: PACKET.request (Space Packet, APID, APID Qualifier (optional), QoS Requirement (optional))" and you see the difference for the parameters that the upper layer (SPP on top of SDLP / AP on top of SPP) shall provide.
Of course we also have the possibility that there is Encapsulation of top of SDLP.

Last question.
Do we want to rule out packets from Proximity-1 forever?
Of course there is nothing preventing a Proximity-1 frame from carrying one or more Packets and I think only spill over would be prohibited by the absence of a first header pointer in the Proximity-1 frame?

Regards

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180130/e7a70406/attachment.html>

From Gian.Paolo.Calzolari at esa.int  Wed Jan 31 11:31:11 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Wed, 31 Jan 2018 12:31:11 +0100
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet
	Service
In-Reply-To: <35F89FCA-6281-4985-BB81-AD9E6D9FA166@jpl.nasa.gov>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <66BDA24959FCC5498DA8CAC84DF25B15010C5CCB91@torvik-c.gst.com>
 <8C3BBBF6-EBEB-40AC-B0FD-405D9B86FBC7@jpl.nasa.gov>
 <OF1F8D186E.FBE4B093-ONC1258225.004B8626-C1258225.004C6EE7@LocalDomain>
 <9201_1517332976_5A70A9EF_9201_1475_1_OF2778BE76.A477091B-ONC1258225.00567FD0-C1258225.005F7AFC@esa.int>
 <35F89FCA-6281-4985-BB81-AD9E6D9FA166@jpl.nasa.gov>
Message-ID: <10561_1517398274_5A71A901_10561_178_1_OFF8F00412.6A977946-ONC1258226.0033E50F-C1258226.003F47E9@esa.int>

Greg,
        interoperability is one target but proper design is another one.

I disagree that we should delete the SPP primitives while I think we shall 
shed light on the unvcleear items of the phantasy world as required going 
back to what we know being reality.
The ECSS PUS  (ECSS-E-ST-70-41C) is fully based on the Space Packet and 
represent a good example for common design and , somehow, 
interoperability.
I think it is fully correct that "missions come up with their own ways of 
assigning APIDs to VCIDs".
There is no fixed rule in this (more than spacecraft architecture etc).

We shall remember the basic structure we shall describe in the SPP book; 
i.e. (with some additions with resect to what I wrote yesterday) 
There multiple sources generating packet contents and asking transmission 
of packets with a given APID (as per PACKET.request  primitive)
Those different APIDs shall be multiplexed to produce a single packet 
stream per VC
EACH single packet stream is then injected in in a VC by sending it to the 
instance of the Packet Processing Function for that Virtual Channel that 
carries Packets

[note that I removed the step "Those packets are created with different 
APIDs depending on the source " as I understand the complete space packet 
is passed from the requesting source application]
As far as I know nothing prevents a source application form asking two 
packets with the same APID to be transmitted over different VCs.

Basically we should refine the description (in 133.0-B) of the so called 
(in 132.0-B) "Packet Service User with PVN = SPP".

I do concur with you about the fact that " APID Qualifier is totally left 
up to the user to define." and looking at the VCP.request  primitive I 
think we have an opportunity for some clean up.
Basically we have the problem of identifying the SPP processing (by the 
PACKET TRANSFER FUNCTION defined in 4.2.3)  bridging between the following 
two primitives
PACKET.request  (Space Packet,   APID, APID Qualifier (optional), QoS 
Requirement (optional)) 
VCP.request                     (Packet,   GVCID, Packet Version Number) 

As I think that you are also right saying that "Maybe in SPP we simply 
need to acknowledge and document that these steps are done outside of 
CCSDS services." our opportunity can be to state that some behaviour are 
left to individual implementation (it would not be the first time in CCSDS 
:o).
In our case I think that we can mention that the GVCID that SPP shall put 
in the VCP.request can either be part of the APID Qualifier or managed 
(indeed in section 5.2 we have already the managed parameter "Packet 
Multiplexing Scheme".
An alternative may be looking at some harmonisation with the Encapsulation 
service defined in CCSDS 133.1-B-2 where the ENCAPSULATION.request 
actually contains the SDLP_Channel completely defined in section 3.2.2 
with respect to the individual packet services of the lower layer (VCP 
Service of TM/AOS/TC, MAPP Service of TC, Packet Service of Proximity-1) , 

In fact a user can ask to transmit a packet also with an 
ENCAPSULATION.request and we should make sure the involved processing is 
consistent.
This consistency check shall not be neglected.

I think that for the OCTET_STRING.request   with parameters   (Octet 
String, APID, APID Qualifier (optional), Secondary Header Indicator, QoS 
Requirement (optional))  we will just need to apply the same 
considerations as eventualy everything goes into the PACKET TRANSFER 
FUNCTION as shown in Figure 4-4:  Internal Organization of  Protocol 
Entity (Sending End).

Actually it looks as one main topic will be redefining clause "4.2.3.3 The 
Packet Transfer Function, then, shall examine the Path ID of each Packet 
in the queue  to  identify  the  next  protocol  entity  in  the  LDP  of 
the  Packet  and  shall  transfer  the  Packet  using  a  service  of  the 
 underlying  subnetwork.    The  Packet  Transfer  Function  may  transfer 
 the  Packet  to  multiple  protocol  entities  which  are  not 
necessarily  on  the  same  subnetwork; i.e., it may perform a multicast 
function. " to make clear that it shall generate a suitable VCP.request 
fore either TM, AOS or TC (the one with more parameters),
BTW for TC I see that the PACKET TRANSFER should be able to generate 
either a VCP.request or a MAPP.request.

Of course we should also include USLP where I see that the VCP Service is 
not used as only MAPP Service exist (with relevant MAPP.request). 

Regards

Gian Paolo





From:   "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:     "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP 
<sls-slp-bounces at mailman.ccsds.org>
Date:   30/01/2018 19:12
Subject:        Re: [Sls-slp] Virtual Channel Packet (VCP) Service vs 
(SPP) Packet Service
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>



G.P.,
 
Thanks for the good forensic work. 
I am aware of the differences between in the “Packet” primitives in the 
SDLP and SPP cases.
However, my problem with the SPP primitives as currently defined, is that 
they describe a kind of fantasy world in fact worse than that they are 
specious. They give the appearance that one can actually do something and 
achieve interoperability, but in reality it is not the case. In that 
sense, I say, if we cannot more concretely define these primitives (SPP 
Packet .request and .indication), then we are better off deleting them. 
For example, one problem is that APID Qualifier is totally left up to the 
user to define. This is part of the discussion Scott Burleigh, Jonathan 
Wilmot, Keith Scott, all, etc from SIS were discussing in the Haag. In 
reality, missions come up with their own ways of assigning APIDs to VCIDs. 
Maybe in SPP we simply need to acknowledge and document that these steps 
are done outside of CCSDS services. One way to consider at least.
 
 
Concerning your Prox-1 questions: Packets are defined data types in 
Prox-1. Prox-1 is like TC due to the variable frame length and the frame 
length field in the transfer frame header. I think the real solution is 
for missions to eventually migrate to USLP.
 
Greg
 
From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of 
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, January 30, 2018 at 9:22 AM
To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP 
<sls-slp-bounces at mailman.ccsds.org>
Subject: [Sls-slp] Virtual Channel Packet (VCP) Service vs (SPP) Packet 
Service
 
Dear Greg, 
        first of all I think that a few years years we decided to rename 
the Packet Service in the Space Data Link Protocols books to Virtual 
Channel Packet (VCP) Service to avoid confusion wit the service defined in 
SPP. 

We shall also keep in mind that almost often the SDLP books leave 
undefined some details of procedures left to "management". An example is 
AOS section 4.2.5 VIRTUAL CHANNEL MULTIPLEXING FUNCTION only says (among 
other things that 
4.2.5.2 The Virtual Channel Multiplexing Function shall multiplex Transfer 
Frames received from the instances of the Virtual Channel Generation 
Function and, if present, the Virtual Channel Frame Service users, in an 
appropriate order that is set by management. 
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed 
Transfer Frames into a queue. 
4.2.5.3 The algorithm used to order the Transfer Frames is not specified 
by CCSDS, but shall be defined by project organizations considering 
factors such as priority, release rate, isochronous timing requirements, 
etc. 

The same applies to TC section 4.3.6 VIRTUAL CHANNEL MULTIPLEXING FUNCTION 
stating 
4.3.6.2 The Virtual Channel Multiplexing Function shall multiplex Transfer 
Frames received from the instances of the Virtual Channel Generation 
Function and, if present, the Virtual Channel Frame Service users, in an 
appropriate order set by management. 
NOTE – The Virtual Channel Multiplexing Function may put the multiplexed 
Transfer Frame  into a queue. 
4.3.6.3 The algorithm to be used to order the Transfer Frames is not 
specified by CCSDS, but shall be defined by project organizations 
considering factors such as priority, release rate, isochronous timing 
requirements, etc. 

However FSP -  had to be more specific and it includes many more details 
for VC multiplexing. 
FSP also mention sets of APIDs assigned to VCs. 

Going back to AOS sectio 2.2.3.2 Virtual Channel Packet (VCP) Service, it 
is stated that 
A user of this service is a protocol entity that sends or receives Packets 
with a single PVN. A user is identified with the PVN and a GVCID. 
In other words it looks fully correct that only one SPP user can provide 
packets (with SAP Address = GVCID + Packet Version Number) to an instance 
of the VCP Service 

On the other end we shall also make sure that we have consistency with 
CCSDS 133.1-B-2 that is the service able to create Space/Encapsulation 
Packets 

Another point that does show what we need to keep both services is given 
by the primitives. 
In the Space Data Link Protocol (e.g. for AOS) we have that "At the 
sending end, the VCP Service user shall pass a VCP.request primitive to 
the service provider to request that a Packet be transferred to the user 
at the receiving end through the specified Virtual Channel." and "The 
VCP.request primitive shall provide parameters as follows: VCP.request 
(Packet, GVCID, Packet Version Number)" 

Conversely in SPP  "The PACKET.request primitive shall provide parameters 
as follows: PACKET.request (Space Packet, APID, APID Qualifier (optional), 
QoS Requirement (optional))" and you see the difference for the parameters 
that the upper layer (SPP on top of SDLP / AP on top of SPP) shall 
provide. 
Of course we also have the possibility that there is Encapsulation of top 
of SDLP. 

Last question. 
Do we want to rule out packets from Proximity-1 forever? 
Of course there is nothing preventing a Proximity-1 frame from carrying 
one or more Packets and I think only spill over would be prohibited by the 
absence of a first header pointer in the Proximity-1 frame? 

Regards 

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/e1540797/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 15546 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/e1540797/attachment.gif>

From Gian.Paolo.Calzolari at esa.int  Wed Jan 31 14:30:32 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Wed, 31 Jan 2018 15:30:32 +0100
Subject: [Sls-slp] Packet channel multiplexing no longer needed? : Results
 of Discussion with Takahiro Yamada on Revising SPP Blue Book
In-Reply-To: <BN6PR19MB1458AC7EA04BD93B3375FC3590E40@BN6PR19MB1458.namprd19.prod.outlook.com>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <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>
 <BN6PR19MB1458AC7EA04BD93B3375FC3590E40@BN6PR19MB1458.namprd19.prod.outlook.com>
Message-ID: <11476_1517409034_5A71D30A_11476_48_1_OFB2B19575.0982BDDD-ONC1258226.004F0BC0-C1258226.004FB32D@esa.int>

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 <john.pietras at gst.com>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
Cc:     "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP 
<sls-slp-bounces at mailman.ccsds.org>
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" <sls-slp-bounces at mailman.ccsds.org>



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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/1f44d7f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21544 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/1f44d7f9/attachment.gif>

From john.pietras at gst.com  Wed Jan 31 20:41:33 2018
From: john.pietras at gst.com (John Pietras)
Date: Wed, 31 Jan 2018 20:41:33 +0000
Subject: [Sls-slp] Idle Packet Idle Pattern
Message-ID: <BN6PR19MB145826E15B681E078ECF234490FB0@BN6PR19MB1458.namprd19.prod.outlook.com>

Dear All,
I'm sorry that I wasn't able to participate in today's telecon, due to a prior commitment. Having not participated, I don't know the final fate of the SPP book. But there is one other item that I came across that I'd like to bring to the WG's attention as something else to consider in the process of cleaning up (or replacing) the SPP book.

The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of "Idle Packet" is cross-referenced to the SPP book.

The SPP book states "If the Packet is an Idle Packet, the User Data Field shall contain Idle Data", and follows this with the NOTE "The bit pattern of Idle Data is not specified in this Recommendation." The trail goes cold there.

A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes are identified as Managed Parameters. Given that "Managed Parameters" is another way of saying "stuff that has to be configured that is not defined in the book itself", I suggest that the packet Idle Pattern also be treated as a Managed Parameter.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/8087f4de/attachment.html>

From kevan.l.moore at nasa.gov  Wed Jan 31 20:59:24 2018
From: kevan.l.moore at nasa.gov (Moore, Kevan L. (MSFC-HP27)[HOSC SERVICES CONTRACT])
Date: Wed, 31 Jan 2018 20:59:24 +0000
Subject: [Sls-slp] Idle Packet Idle Pattern
In-Reply-To: <BN6PR19MB145826E15B681E078ECF234490FB0@BN6PR19MB1458.namprd19.prod.outlook.com>
References: <BN6PR19MB145826E15B681E078ECF234490FB0@BN6PR19MB1458.namprd19.prod.outlook.com>
Message-ID: <86A82FEFF63F844391C5A7290E9F8FE715545222@NDMSMBX304.ndc.nasa.gov>

I came to the same conclusino as John and had already implemented a PHYSICAL_CHANNEL_OID_Frame_Content managed parameter.  The pattern repeats to fill the required space.

Happy to change to whatever the working group decides.

Just happy to finally get one right. :)

Kevan
MSFC

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Wednesday, January 31, 2018 2:42 PM
To: sls-slp at mailman.ccsds.org
Subject: [Sls-slp] Idle Packet Idle Pattern

Dear All,
I'm sorry that I wasn't able to participate in today's telecon, due to a prior commitment. Having not participated, I don't know the final fate of the SPP book. But there is one other item that I came across that I'd like to bring to the WG's attention as something else to consider in the process of cleaning up (or replacing) the SPP book.

The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of "Idle Packet" is cross-referenced to the SPP book.

The SPP book states "If the Packet is an Idle Packet, the User Data Field shall contain Idle Data", and follows this with the NOTE "The bit pattern of Idle Data is not specified in this Recommendation." The trail goes cold there.

A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes are identified as Managed Parameters. Given that "Managed Parameters" is another way of saying "stuff that has to be configured that is not defined in the book itself", I suggest that the packet Idle Pattern also be treated as a Managed Parameter.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/0fc2c791/attachment.html>

From Gian.Paolo.Calzolari at esa.int  Wed Jan 31 21:29:21 2018
From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int)
Date: Wed, 31 Jan 2018 22:29:21 +0100
Subject: [Sls-slp] Idle Packet Idle Pattern
In-Reply-To: <86A82FEFF63F844391C5A7290E9F8FE715545222@NDMSMBX304.ndc.nasa.gov>
Message-ID: <12240_1517434163_5A723532_12240_4435_1_OF6D76419B.A2DB0FA4-ONC1258226.00760AA6-1517434160981@esa.int>

Of course we shall not confuse OID frames with Idle Packets. 

Having said this, I have dome doubts about storing this as managed parameter (no matter for frames or packets) as we cannot be sure this will always be a fixed pattern. 

BTW in the C&S wg some time ago there was an issue with OID frames generating spectrum issues because of the constant pattern. 

Just my cent, but worth a discussion 

Gian Paolo

Sent from my iPhone

> On 31. Jan 2018, at 21:59, Moore, Kevan L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <kevan.l.moore at nasa.gov> wrote:
> 
> I came to the same conclusino as John and had already implemented a PHYSICAL_CHANNEL_OID_Frame_Content managed parameter.  The pattern repeats to fill the required space.
>  
> Happy to change to whatever the working group decides.
>  
> Just happy to finally get one right. :)
>  
> Kevan
> MSFC
>  
> From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of John Pietras
> Sent: Wednesday, January 31, 2018 2:42 PM
> To: sls-slp at mailman.ccsds.org
> Subject: [Sls-slp] Idle Packet Idle Pattern
>  
> Dear All,
> I’m sorry that I wasn’t able to participate in today’s telecon, due to a prior commitment. Having not participated, I don’t know the final fate of the SPP book. But there is one other item that I came across that I’d like to bring to the WG’s attention as something else to consider in the process of cleaning up (or replacing) the SPP book.
>  
> The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of “Idle Packet” is cross-referenced to the SPP book.
>  
> The SPP book states “If the Packet is an Idle Packet, the User Data Field shall contain Idle Data”, and follows this with the NOTE “The bit pattern of Idle Data is not specified in this Recommendation.” The trail goes cold there.
>  
> A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes are identified as Managed Parameters. Given that “Managed Parameters” is another way of saying “stuff that has to be configured that is not defined in the book itself”, I suggest that the packet Idle Pattern also be treated as a Managed Parameter.
>  
> Best regards,
> John

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/9a5563fb/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Wed Jan 31 21:32:59 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Wed, 31 Jan 2018 21:32:59 +0000
Subject: [Sls-slp] Idle Packet Idle Pattern
In-Reply-To: <12240_1517434163_5A723532_12240_4435_1_OF6D76419B.A2DB0FA4-ONC1258226.00760AA6-1517434160981@esa.int>
References: <86A82FEFF63F844391C5A7290E9F8FE715545222@NDMSMBX304.ndc.nasa.gov>
 <12240_1517434163_5A723532_12240_4435_1_OF6D76419B.A2DB0FA4-ONC1258226.00760AA6-1517434160981@esa.int>
Message-ID: <7A0826F1-3967-49BF-A851-A71C0C02EF95@jpl.nasa.gov>

I agree. Indeed, there have actually been missions who don’t use a fixed pattern in the OID frames nor Idle packets.

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org> on behalf of "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, January 31, 2018 at 1:29 PM
To: "Moore, Kevan L. (MSFC-HP27)[HOSC SERVICES CONTRACT]" <kevan.l.moore at nasa.gov>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Subject: Re: [Sls-slp] Idle Packet Idle Pattern

Of course we shall not confuse OID frames with Idle Packets.

Having said this, I have dome doubts about storing this as managed parameter (no matter for frames or packets) as we cannot be sure this will always be a fixed pattern.

BTW in the C&S wg some time ago there was an issue with OID frames generating spectrum issues because of the constant pattern.

Just my cent, but worth a discussion

Gian Paolo
Sent from my iPhone

On 31. Jan 2018, at 21:59, Moore, Kevan L. (MSFC-HP27)[HOSC SERVICES CONTRACT] <kevan.l.moore at nasa.gov<mailto:kevan.l.moore at nasa.gov>> wrote:
I came to the same conclusino as John and had already implemented a PHYSICAL_CHANNEL_OID_Frame_Content managed parameter.  The pattern repeats to fill the required space.

Happy to change to whatever the working group decides.

Just happy to finally get one right. :)

Kevan
MSFC

From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Wednesday, January 31, 2018 2:42 PM
To: sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>
Subject: [Sls-slp] Idle Packet Idle Pattern

Dear All,
I’m sorry that I wasn’t able to participate in today’s telecon, due to a prior commitment. Having not participated, I don’t know the final fate of the SPP book. But there is one other item that I came across that I’d like to bring to the WG’s attention as something else to consider in the process of cleaning up (or replacing) the SPP book.

The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of “Idle Packet” is cross-referenced to the SPP book.

The SPP book states “If the Packet is an Idle Packet, the User Data Field shall contain Idle Data”, and follows this with the NOTE “The bit pattern of Idle Data is not specified in this Recommendation.” The trail goes cold there.

A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes are identified as Managed Parameters. Given that “Managed Parameters” is another way of saying “stuff that has to be configured that is not defined in the book itself”, I suggest that the packet Idle Pattern also be treated as a Managed Parameter.

Best regards,
John

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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/44c471d1/attachment.html>

From edward.greenberg at jpl.nasa.gov  Wed Jan 31 21:38:19 2018
From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B))
Date: Wed, 31 Jan 2018 21:38:19 +0000
Subject: [Sls-slp] Idle Packet Idle Pattern
Message-ID: <D6977198.25472%egreenbe@jpl.nasa.gov>

Idle patterns have always been at the users discretion.  Some patterns are better than others for different coding.  Since the data is discarded the spec specifiers decided not to define a specific pattern and leave it up to the mission people to decide what patter they wanted to use.

I would like to get your opinion on this proposal.   The SPP has gone adrift but it would be nice to maintain the packet format.  I am not interested in the way "service" is described because it is an implementation that is currently not used and mandatory.  The main change that I would like to see is to allow for the inclusion of standard labels in the secondary header.  But there are issues:
    1.  Some mission use the secondary header flag for non-standard headers
    2.  The missions have the prerogative to assign APIDs and ESA has established there own usage in the PUS
 I think that we need to maintain compatibility  with current use so I would suggest the following:

  1.  Assign a specific APID that informs the system that the secondary header contains standard labels
  2.  Identify a version mechanism for labels and a mechanism for identifying a succession of labels
  3.  Create a book to contain standard labels that are register in SANA:
     *   Identity label with desired APID and possibly other info like Quality of Service and maybe format ID
     *   Security label for security sequence number etal
     *   Routing label with source and destination addresses for short relaying (I.e. lander to orbiter to lander) (direct or multicast)

This way the current implementation with all the current management aspects are not affected.

From: SLS-SLP <sls-slp-bounces at mailman.ccsds.org<mailto:sls-slp-bounces at mailman.ccsds.org>> on behalf of John Pietras <john.pietras at gst.com<mailto:john.pietras at gst.com>>
Date: Wednesday, January 31, 2018 at 12:41 PM
To: SLS-SLP WG <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: [Sls-slp] Idle Packet Idle Pattern

Dear All,
I’m sorry that I wasn’t able to participate in today’s telecon, due to a prior commitment. Having not participated, I don’t know the final fate of the SPP book. But there is one other item that I came across that I’d like to bring to the WG’s attention as something else to consider in the process of cleaning up (or replacing) the SPP book.

The Packet Processing function of the AOS SDLP includes generation of Idle Packets when no packets containing user data are available. The definition of “Idle Packet” is cross-referenced to the SPP book.

The SPP book states “If the Packet is an Idle Packet, the User Data Field shall contain Idle Data”, and follows this with the NOTE “The bit pattern of Idle Data is not specified in this Recommendation.” The trail goes cold there.

A similar situation exists for the multiplexing schemes for VCs and MCs (that is they are not defined by the SDLP Recommended Standards), but in those cases the multiplexing schemes are identified as Managed Parameters. Given that “Managed Parameters” is another way of saying “stuff that has to be configured that is not defined in the book itself”, I suggest that the packet Idle Pattern also be treated as a Managed Parameter.

Best regards,
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/ba0647de/attachment.html>

From greg.j.kazz at jpl.nasa.gov  Wed Jan 31 23:38:42 2018
From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B))
Date: Wed, 31 Jan 2018 23:38:42 +0000
Subject: [Sls-slp] Packet channel multiplexing no longer needed? :
 Results of Discussion with Takahiro Yamada on Revising SPP Blue Book
In-Reply-To: <11476_1517409034_5A71D30A_11476_48_1_OFB2B19575.0982BDDD-ONC1258226.004F0BC0-C1258226.004FB32D@esa.int>
References: <66BDA24959FCC5498DA8CAC84DF25B15010C4FFC0E@torvik-c.gst.com>
 <25486_1517079626_5A6CCC4A_25486_9410_1_OF5E01FF86.81F86F9C-ONC1258222.006867DA-1517079623802@esa.int>
 <DC8731D4-7C2C-4D59-8A1A-EE3B3D6EED5E@jpl.nasa.gov>
 <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>
 <BN6PR19MB1458AC7EA04BD93B3375FC3590E40@BN6PR19MB1458.namprd19.prod.outlook.com>
 <11476_1517409034_5A71D30A_11476_48_1_OFB2B19575.0982BDDD-ONC1258226.004F0BC0-C1258226.004FB32D@esa.int>
Message-ID: <493B9798-9A92-4BDB-98E4-D63A75F70F01@jpl.nasa.gov>

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.
  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)
  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?

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 ?

  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" <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, January 31, 2018 at 6:30 AM
To: John Pietras <john.pietras at gst.com>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "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 <john.pietras at gst.com>
To:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
Cc:        "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>, SLS-SLP <sls-slp-bounces at mailman.ccsds.org>
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" <sls-slp-bounces at mailman.ccsds.org>
________________________________


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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/a4636ff8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 21545 bytes
Desc: image001.gif
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180131/a4636ff8/attachment.gif>