From greg.j.kazz at jpl.nasa.gov Tue Feb 2 18:47:31 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 2 Feb 2016 18:47:31 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs Message-ID: Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question – What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?” Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Tue Feb 2 22:41:23 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 2 Feb 2016 22:41:23 +0000 Subject: [Sls-slp] Meeting Minutes of USLP Telecon 2 - Feb 2, 2016 Message-ID: All, Attached please find in Word the meeting minutes of the Telecon #2 held this year on making further progress towards the USLP Blue book. Best regards, Greg Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Telecon2_minutes_feb2_2016.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 138631 bytes Desc: USLP Telecon2_minutes_feb2_2016.docx URL: From Gian.Paolo.Calzolari at esa.int Wed Feb 3 10:38:16 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 3 Feb 2016 11:38:16 +0100 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: References: Message-ID: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same as http://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "Shames, Peter M (312B)" Cc: "sls-slp at mailman.ccsds.org" Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question ? What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, ?Is a 13 bit PID name space sufficient for all agency needs ?? Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From Gian.Paolo.Calzolari at esa.int Wed Feb 3 10:41:41 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 3 Feb 2016 11:41:41 +0100 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> Message-ID: <26846_1454496104_56B1D968_26846_7_1_OF0560A868.CB2FFE8B-ONC1257F4E.003AA18E-C1257F4E.003ABF74@esa.int> Of course some values in http://sanaregistry.org/r/protocol_id/protocol_id.html and http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html may not be allowed in USLP (e.g. 000binary = Fill (the encapsulation data field, if present, contains no protocol data). From: Gian.Paolo.Calzolari at esa.int To: "Kazz, Greg J (312B)" Cc: "Shames, Peter M\(312B\)" , "SLS-SLP Mailing List" Date: 03/02/2016 11:39 Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same as http://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "Shames, Peter M (312B)" Cc: "sls-slp at mailman.ccsds.org" Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question ? What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, ?Is a 13 bit PID name space sufficient for all agency needs ?? Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From greg.j.kazz at jpl.nasa.gov Wed Feb 3 16:46:51 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 3 Feb 2016 16:46:51 +0000 Subject: [Sls-slp] Questions/Answers on Draft USLP White Book Message-ID: Dear SLP WG, Attached please find a series of questions from Gian Paolo and proposed solutions on the post telecon 1 version of the draft USLP White Book on the CWE. Please feel free to comment on any of these issues to the SLP WG so that we can come to consensus on them. My plan is to release a post telecon 2 version of the white book soon. Best regards, Greg Kazz Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Answers_to_Gian_Paolo_Feb1_2016.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 218833 bytes Desc: Answers_to_Gian_Paolo_Feb1_2016.docx URL: From greg.j.kazz at jpl.nasa.gov Wed Feb 3 17:03:10 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 3 Feb 2016 17:03:10 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> Message-ID: G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don’t see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html …aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" > Cc: "Shames, Peter M (312B)" >, SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same ashttp://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" > To: "Shames, Peter M (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question – What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?” Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From Gian.Paolo.Calzolari at esa.int Wed Feb 3 17:58:24 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 3 Feb 2016 18:58:24 +0100 Subject: [Sls-slp] Meeting Minutes of USLP Telecon 2 - Feb 2, 2016 In-Reply-To: References: Message-ID: <7420_1454522308_56B23FC4_7420_62_1_OF56FF4B5E.F806EB30-ONC1257F4E.0062A8DA-C1257F4E.0062BB02@esa.int> Greg, please find here a version with a few comments. Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "sls-slp at mailman.ccsds.org" Date: 02/02/2016 23:42 Subject: [Sls-slp] Meeting Minutes of USLP Telecon 2 - Feb 2, 2016 Sent by: sls-slp-bounces at mailman.ccsds.org All, Attached please find in Word the meeting minutes of the Telecon #2 held this year on making further progress towards the USLP Blue book. Best regards, Greg Chairman CCSDS SLP WG [attachment "USLP Telecon2_minutes_feb2_2016.docx" deleted by Gian Paolo Calzolari/esoc/ESA] _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Telecon2_minutes_feb2_2016+gpc.docx Type: application/octet-stream Size: 21713 bytes Desc: not available URL: From Gian.Paolo.Calzolari at esa.int Wed Feb 3 18:02:05 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 3 Feb 2016 19:02:05 +0100 Subject: [Sls-slp] USLP: Managed Parameter Sources Message-ID: <22524_1454522529_56B240A0_22524_2731_1_OFFCF857EF.741E8607-ONC1257F4E.0062D642-C1257F4E.0063115A@esa.int> Dear Greg, I made an exercise to find out which source we have for each Managed Parameter in USLP. The results are in the attached file. It may be good to have a discussion on this to check implication in the USLP main document as discussed at last telecon etc. Best 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP.ManagedParameterSources20160203.pdf Type: application/octet-stream Size: 58443 bytes Desc: not available URL: From Gian.Paolo.Calzolari at esa.int Wed Feb 3 18:18:22 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 3 Feb 2016 19:18:22 +0100 Subject: [Sls-slp] compelling reason to create a separate field just for COP in USLP In-Reply-To: References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> Message-ID: <22524_1454523505_56B24471_22524_3131_1_OFC58B0208.C7F4F6D9-ONC1257F4E.00636ADC-C1257F4E.00648F0D@esa.int> Greg, with respect to your comment about no compelling reason to create a separate field just for COP, I must say that mixing things is never a good idea. BTW, as COP in effect is a managed parameter you may need only one bit basically to replicate the behaviour of the Bypass and Control Flags in COP-1. In fact, as the Bypass Flag is already present in the USLP Frame Header, it is enough to define the Control Flag using the same approach from TC: Bypass and Control Flags. = 00 ==> AD Frame (Acceptance, Data) ==> use COP (either 1 or P depending on Managed Parameter) Bypass and Control Flags. = 10 ==> BD Frame (Bypass, Data) ==> Expedited Service Frame as per COP in effect Bypass and Control Flags. = 11 ==> BC Frame (Bypass, Control) ==>COP Directive Bypass and Control Flags. = 01 ==> AC Frame (Acceptance, Control) NOT ALLOWED in COP-1 ===? Could mean NO COP????? BTW, if you need a Control Flag, why not including it in the frame Header? Just for some brainstorming. Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "Gian.Paolo.Calzolari at esa.int" Cc: "Shames, Peter M (312B)" , "SLS-SLP Mailing List" Date: 03/02/2016 18:03 Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don?t see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ?aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" Cc: "Shames, Peter M (312B)" , SLS-SLP Mailing List Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same as http://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "Shames, Peter M (312B)" Cc: "sls-slp at mailman.ccsds.org" Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question ? What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, ?Is a 13 bit PID name space sufficient for all agency needs ?? Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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. 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: From greg.j.kazz at jpl.nasa.gov Wed Feb 3 18:30:19 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 3 Feb 2016 18:30:19 +0000 Subject: [Sls-slp] Latest Draft USLP Green Book available on CWE Message-ID: Dear SLP WG member, Please find the updated Draft USLP Green Book on the CWE under: http://tinyurl.com/hy5an9k Your comments are welcome! Best regards, Greg Kazz Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Wed Feb 3 18:45:29 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 3 Feb 2016 18:45:29 +0000 Subject: [Sls-slp] Amended minutes to USLP Draft White Book Telecon 2 Message-ID: Dear SLP WG, Attached please find the amended USLP Telecon #2 meeting minutes held yesterday. Best regards, Greg Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Telecon2_minutes_feb2_2016+gpc.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 21991 bytes Desc: USLP Telecon2_minutes_feb2_2016+gpc.docx URL: From Tomaso.deCola at dlr.de Thu Feb 4 09:31:49 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Thu, 4 Feb 2016 09:31:49 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> Greg, Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I'm wondering how USLP encapsulation works in the case of IPoC: do we still have the IPE header or is this somehow mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book. Thanks in advance for your comments on these thoughts. Best Regards, Tomaso ------------------------ Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, February 03, 2016 18:03 To: Gian.Paolo.Calzolari at esa.int Cc: Shames, Peter M (312B); SLS-SLP Mailing List Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don't see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ...aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" > Cc: "Shames, Peter M (312B)" >, SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same ashttp://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" > To: "Shames, Peter M (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question - What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, "Is a 13 bit PID name space sufficient for all agency needs ?" Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From edward.greenberg at jpl.nasa.gov Thu Feb 4 17:18:49 2016 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Thu, 4 Feb 2016 17:18:49 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> Message-ID: <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> I think that Tomaso's observation is accurate. The USLP PID field is 5 bits allowing 32 possible PIPs. I believe that that number is sufficient but we need to allow for our possible miscalculation so we specified one of those values to extend the PID field. It makes no sense to make the extension anything other than an octet. The question is how the contents of the extended field is interpreted. My recommendation is that we have 32 IDs in the 5 bit field and these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs would be reserved in the extension field. Thus the extension field provides an additional 256-32 PID and the value of the all PIDs can be a unique digital value. This gives us a maximum of 255 unique PIDs. From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de Sent: Thursday, February 04, 2016 1:32 AM To: Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Greg, Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I'm wondering how USLP encapsulation works in the case of IPoC: do we still have the IPE header or is this somehow mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book. Thanks in advance for your comments on these thoughts. Best Regards, Tomaso ------------------------ Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, February 03, 2016 18:03 To: Gian.Paolo.Calzolari at esa.int Cc: Shames, Peter M (312B); SLS-SLP Mailing List Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don't see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ...aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" > Cc: "Shames, Peter M (312B)" >, SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same ashttp://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" > To: "Shames, Peter M (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question - What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, "Is a 13 bit PID name space sufficient for all agency needs ?" Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From Tomaso.deCola at dlr.de Thu Feb 4 18:00:16 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Thu, 4 Feb 2016 18:00:16 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de>, <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> Hi Ed, So if I get it correctly, we'll have a unique field for the proto spanning 8 bits, where: 0-31: regular protocol id 32-255: extension protocol id Then probably the cases '0' and '255' could go reserved for special uses. Is my interpretation correct? ________________________________________ Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] Inviato: giovedì 4 febbraio 2016 18.18 A: Cola, Tomaso de; Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs I think that Tomaso’s observation is accurate. The USLP PID field is 5 bits allowing 32 possible PIPs. I believe that that number is sufficient but we need to allow for our possible miscalculation so we specified one of those values to extend the PID field. It makes no sense to make the extension anything other than an octet. The question is how the contents of the extended field is interpreted. My recommendation is that we have 32 IDs in the 5 bit field and these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs would be reserved in the extension field. Thus the extension field provides an additional 256-32 PID and the value of the all PIDs can be a unique digital value. This gives us a maximum of 255 unique PIDs. From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de Sent: Thursday, February 04, 2016 1:32 AM To: Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Greg, Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I’m wondering how USLP encapsulation works in the case of IPoC: do we still have the IPE header or is this somehow mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book. Thanks in advance for your comments on these thoughts. Best Regards, Tomaso ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, February 03, 2016 18:03 To: Gian.Paolo.Calzolari at esa.int Cc: Shames, Peter M (312B); SLS-SLP Mailing List Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don’t see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html …aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" > Cc: "Shames, Peter M (312B)" >, SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same ashttp://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" > To: "Shames, Peter M (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question – What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, “Is a 13 bit PID name space sufficient for all agency needs ?” Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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. From edward.greenberg at jpl.nasa.gov Thu Feb 4 22:23:54 2016 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Thu, 4 Feb 2016 22:23:54 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de>, <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> Message-ID: <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> I think so...Do you have a problem with that? -----Original Message----- From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] Sent: Thursday, February 04, 2016 10:00 AM To: Greenberg, Edward (312B); Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Hi Ed, So if I get it correctly, we'll have a unique field for the proto spanning 8 bits, where: 0-31: regular protocol id 32-255: extension protocol id Then probably the cases '0' and '255' could go reserved for special uses. Is my interpretation correct? ________________________________________ Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] Inviato: giovedì 4 febbraio 2016 18.18 A: Cola, Tomaso de; Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs I think that Tomaso's observation is accurate. The USLP PID field is 5 bits allowing 32 possible PIPs. I believe that that number is sufficient but we need to allow for our possible miscalculation so we specified one of those values to extend the PID field. It makes no sense to make the extension anything other than an octet. The question is how the contents of the extended field is interpreted. My recommendation is that we have 32 IDs in the 5 bit field and these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs would be reserved in the extension field. Thus the extension field provides an additional 256-32 PID and the value of the all PIDs can be a unique digital value. This gives us a maximum of 255 unique PIDs. From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de Sent: Thursday, February 04, 2016 1:32 AM To: Kazz, Greg J (312B) Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls-slp at mailman.ccsds.org Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Greg, Still coming back to the point of the PID size, I perfectly understand that it is better to have some margin to avoid problems coming up later. On the other hand, I notice that summing up PID+extensions we have 9 bits, which are even more than those made available with the Proto field (8 bits) in IPv4. So the question is, do we really need such large number? Or, said in different terms, what are the requirements we want to target with such setting? I would have expected that accommodating up to 64 protocol combinations would have been sufficient. Finally, I'm wondering how USLP encapsulation works in the case of IPoC: do we still have the IPE header or is this somehow mapped in the PID+extensions of USLP? In any case, I imagine these special cases (along with any others) will be properly illustrated in the green book. Thanks in advance for your comments on these thoughts. Best Regards, Tomaso ------------------------ Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Wednesday, February 03, 2016 18:03 To: Gian.Paolo.Calzolari at esa.int Cc: Shames, Peter M (312B); SLS-SLP Mailing List Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs G.P., We have learned through the lesson of IPoC that a 3 bit PID is too small and restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits also limited because the first 3 bits are used up by the TFDZ construction rules. I agree that the extended protocol ID field of 8 bits is too big so using the first 4 bits for the PID extension would give us 9 total bits or 512 combinations for PIDs. That would leave 4 bits of spares thereafter. I don't see any compelling reason to create a separate field just for COP. 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html .aslo can contain ipe_header values c2) Spare (4 bits, optional); d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) ). Regards, Greg From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, February 3, 2016 at 2:38 AM To: "Kazz, Greg J (313B)" > Cc: "Shames, Peter M (312B)" >, SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Greg, assuming that USLP will be able to carry 2**13 = 8192 different upper layers protocols look to me as thinking big. Though I like optimism I wonder whether this is appropriate. Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not really 2**7 = 128 different protocol as the construction allows 16 +6 protocols as some values are reserved (see http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). I there a good reason for thinking that USLP could carry 8192 different while Encapsulation Packet is limited to 22? If not please consider the following alternative definition (justified also by the current definition of the fields containing either a protocol ID or a COP directive indication): 4.1.4.2.1.2 The TFDF Header shall contain the following fields: a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, mandatory); b1) COP usage (2 bits, mandatory); ---> see below b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same ashttp://sanaregistry.org/r/protocol_id/protocol_id.html c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;---> same as http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? d) First Header Pointer or Last Valid Octet (16 bits, optional). COP usage (2 bits, mandatory); 00 = No directives 01 = COP-1 directives are contained within the TFDZ. 10 = COP-P directives are contained within the TFDZ 11 = reserved Regards Gian Paolo From: "Kazz, Greg J (312B)" > To: "Shames, Peter M (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Date: 02/02/2016 19:48 Subject: [Sls-slp] CCSDS definition of Protocol IDs Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Peter, USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol ID field in the Transfer Frame Data Field Header. Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed by an optional Protocol Extension Field of 8 bits for a total of 11 bits. There is a SANA registry for PIDs under http://sanaregistry.org/r/protocol_id/protocol_id.html IPoC also defines PIDs as well for the IPE header. See http://sanaregistry.org/r/ipe_header/ipe_header.html In this case, the smallest size IPE header is 8 bits, but it has a multiple octet extension capability beyond 1 octet. USLP currently in draft form, has defined the PID to be 5 bits long, followed by an optional Protocol Extension Field of 8 bits for a total of 13 bits. Below is an approach from Ed Greenberg, that shows that the Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email message below. Question - What does CCSDS, from an organization point of view, envision a need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it appropriate for USLP to define the term, Protocol ID and have it apply locally I.e., only to the USLP links ? In the review of USLP, we will address questions like, "Is a 13 bit PID name space sufficient for all agency needs ?" Your thoughts ? Thanks! Greg From: "Greenberg, Edward (312B)" > Date: Tuesday, February 2, 2016 at 9:53 AM To: "Kazz, Greg J (313B)" > Subject: PIDs Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when 5 bits =11111 Thus if we assume that the PIP space for Encap in 5 bit form we get 11xxx+xxxxxxxx The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or 10 don't map to Encap_______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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. From Tomaso.deCola at dlr.de Fri Feb 5 08:22:49 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Fri, 5 Feb 2016 08:22:49 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de>, <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> Personally I find this approach more efficient than what proposed in the book right now. One could wonder whether we could go for 6-bits instead of 8-bits so that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 extended protocol ids (as from your approach) are definitely too much, also considering the possible protocol evolution in the space domain in the next 10-20 years according to what we have seen in the last 10 years. For instance the extended protocol IDs in the encaps are all unassigned, meaning that from the time the protocol was designed there was no use. In this discussion, as mentioned in my previous e-mail, it would be also interesting to see how encapsulation of IP datagrams will be carried out: do we still use of IPoC or do we transport IP datagrams directly in USLP and we use the Proto ID field to transport the current IPE? Tomaso ------------------------ Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > -----Original Message----- > From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] > Sent: Thursday, February 04, 2016 23:24 > To: Cola, Tomaso de; Kazz, Greg J (312B) > Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > > I think so...Do you have a problem with that? > > -----Original Message----- > From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] > Sent: Thursday, February 04, 2016 10:00 AM > To: Greenberg, Edward (312B); Kazz, Greg J (312B) > Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > > Hi Ed, > > So if I get it correctly, we'll have a unique field for the proto spanning 8 bits, > where: > > 0-31: regular protocol id > 32-255: extension protocol id > > Then probably the cases '0' and '255' could go reserved for special uses. > > Is my interpretation correct? > ________________________________________ > Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] > Inviato: giovedì 4 febbraio 2016 18.18 > A: Cola, Tomaso de; Kazz, Greg J (312B) > Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs > > I think that Tomaso's observation is accurate. The USLP PID field is 5 bits > allowing 32 possible PIPs. I believe that that number is sufficient but we need > to allow for our possible miscalculation so we specified one of those values to > extend the PID field. It makes no sense to make the extension anything other > than an octet. The question is how the contents of the extended field is > interpreted. My recommendation is that we have 32 IDs in the 5 bit field and > these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs > would be reserved in the extension field. Thus the extension field provides an > additional 256-32 PID and the value of the all PIDs can be a unique digital > value. This gives us a maximum of 255 unique PIDs. > > From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- > bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de > Sent: Thursday, February 04, 2016 1:32 AM > To: Kazz, Greg J (312B) > Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > > Greg, > > Still coming back to the point of the PID size, I perfectly understand that it is > better to have some margin to avoid problems coming up later. On the other > hand, I notice that summing up PID+extensions we have 9 bits, which are even > more than those made available with the Proto field (8 bits) in IPv4. So the > question is, do we really need such large number? Or, said in different terms, > what are the requirements we want to target with such setting? I would have > expected that accommodating up to 64 protocol combinations would have been > sufficient. Finally, I'm wondering how USLP encapsulation works in the case of > IPoC: do we still have the IPE header or is this somehow mapped in the > PID+extensions of USLP? In any case, I imagine these special cases (along with > any others) will be properly illustrated in the green book. > > Thanks in advance for your comments on these thoughts. > > Best Regards, > > Tomaso > > ------------------------ > Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center > Institute of Communications and Navigation | Satellite Networks | > Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. > Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > tomaso.decola at dlr.de > http://www.dlr.de/kn/institut/abteilungen/san > > From: sls-slp-bounces at mailman.ccsds.org bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] On > Behalf Of Kazz, Greg J (312B) > Sent: Wednesday, February 03, 2016 18:03 > To: Gian.Paolo.Calzolari at esa.int > Cc: Shames, Peter M (312B); SLS-SLP Mailing List > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > G.P., > > We have learned through the lesson of IPoC that a 3 bit PID is too small and > restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits > also limited because the first 3 bits are used up by the TFDZ construction rules. > I agree that the extended protocol ID field of 8 bits is too big so using the first 4 > bits for the PID extension would give us 9 total bits or 512 combinations for > PIDs. That would leave 4 bits of spares thereafter. > I don't see any compelling reason to create a separate field just for COP. > > 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > mandatory); > b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); > c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;- > --> same as > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > .aslo can contain ipe_header values > c2) Spare (4 bits, optional); > d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) > ). > > Regards, > Greg > > From: "Gian.Paolo.Calzolari at esa.int" > > > Date: Wednesday, February 3, 2016 at 2:38 AM > To: "Kazz, Greg J (313B)" > > > Cc: "Shames, Peter M (312B)" > >, SLS- > SLP Mailing List slp at mailman.ccsds.org>> > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > Greg, > assuming that USLP will be able to carry 2**13 = 8192 different upper > layers protocols look to me as thinking big. > Though I like optimism I wonder whether this is appropriate. > > Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the > Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol > Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not > really 2**7 = 128 different protocol as the construction allows 16 +6 protocols > as some values are reserved (see > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). > I there a good reason for thinking that USLP could carry 8192 different while > Encapsulation Packet is limited to 22? > > If not please consider the following alternative definition (justified also by the > current definition of the fields containing either a protocol ID or a COP > directive indication): > 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > mandatory); > b1) COP usage (2 bits, mandatory); ---> see below > b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same > ashttp://sanaregistry.org/r/protocol_id/protocol_id.html > c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;- > --> same as > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? > d) First Header Pointer or Last Valid Octet (16 bits, optional). > > > COP usage (2 bits, mandatory); > 00 = No directives > 01 = COP-1 directives are contained within the TFDZ. > 10 = COP-P directives are contained within the TFDZ > 11 = reserved > > Regards > > Gian Paolo > > > > From: "Kazz, Greg J (312B)" > > > To: "Shames, Peter M (312B)" > > > Cc: "sls-slp at mailman.ccsds.org" slp at mailman.ccsds.org> > Date: 02/02/2016 19:48 > Subject: [Sls-slp] CCSDS definition of Protocol IDs > Sent by: sls-slp-bounces at mailman.ccsds.org bounces at mailman.ccsds.org> > ________________________________ > > > > Peter, > > USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol > ID field in the Transfer Frame Data Field Header. > Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed > by an optional Protocol Extension Field of 8 bits for a total of 11 bits. > There is a SANA registry for PIDs under > http://sanaregistry.org/r/protocol_id/protocol_id.html > > IPoC also defines PIDs as well for the IPE header. See > http://sanaregistry.org/r/ipe_header/ipe_header.html > In this case, the smallest size IPE header is 8 bits, but it has a multiple octet > extension capability beyond 1 octet. > > USLP currently in draft form, has defined the PID to be 5 bits long, followed by > an optional Protocol Extension Field of 8 bits for a total of 13 bits. > Below is an approach from Ed Greenberg, that shows that the Encapsulation > PIDs can indeed be a subset of the USLP PIDs. See email message below. > > Question - What does CCSDS, from an organization point of view, envision a > need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it > appropriate for USLP to define the term, Protocol ID and have it apply locally > I.e., only to the USLP links ? > In the review of USLP, we will address questions like, "Is a 13 bit PID name > space sufficient for all agency needs ?" > > Your thoughts ? > > Thanks! > Greg > > From: "Greenberg, Edward (312B)" > > > Date: Tuesday, February 2, 2016 at 9:53 AM > To: "Kazz, Greg J (313B)" > > > Subject: PIDs > > Encap uses 3 bits +8bits when 3bits=111 > USLP uses 5 bits +8 bits when 5 bits =11111 > > Thus if we assume that the PIP space for Encap in 5 bit form we get > 11xxx+xxxxxxxx > > > The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or > 10 don't map to > Encap_______________________________________________ > Sls-slp mailing list > Sls-slp at mailman.ccsds.org > http://mailman.ccsds.org/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. From kscott at mitre.org Fri Feb 5 12:34:08 2016 From: kscott at mitre.org (Scott, Keith L.) Date: Fri, 5 Feb 2016 12:34:08 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> Message-ID: <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> So what’s the motivation for saving two bits? The delta power / bandwidth needed is minimal, it requires more non-byte-aligned processing, and it sets us up for needing that 65th protocol that we just can’t quite get… Why not just go with an 8-bit field that is one thing (without the protocols and extensions distinction)? Is it that the extension field is optional (incurring more data-dependent header processing)? Sorry, but while optimizing bit field sizes down to sub-byte level seems like a useful thing, it also seems to have bitten us a number of times. —keith On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of Tomaso.deCola at dlr.de" wrote: >Personally I find this approach more efficient than what proposed in the book right now. One could wonder whether we could go for 6-bits instead of 8-bits so that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 extended protocol ids (as from your approach) are definitely too much, also considering the possible protocol evolution in the space domain in the next 10-20 years according to what we have seen in the last 10 years. For instance the extended protocol IDs in the encaps are all unassigned, meaning that from the time the protocol was designed there was no use. In this discussion, as mentioned in my previous e-mail, it would be also interesting to see how encapsulation of IP datagrams will be carried out: do we still use of IPoC or do we transport IP datagrams directly in USLP and we use the Proto ID field to transport the current IPE? > >Tomaso > >------------------------ >Deutsches Zentrum für Luft- und Raumfahrt (DLR) >German Aerospace Center >Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany >Tomaso de Cola, Ph.D. >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de >http://www.dlr.de/kn/institut/abteilungen/san > >> -----Original Message----- >> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] >> Sent: Thursday, February 04, 2016 23:24 >> To: Cola, Tomaso de; Kazz, Greg J (312B) >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- >> slp at mailman.ccsds.org >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs >> >> I think so...Do you have a problem with that? >> >> -----Original Message----- >> From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] >> Sent: Thursday, February 04, 2016 10:00 AM >> To: Greenberg, Edward (312B); Kazz, Greg J (312B) >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- >> slp at mailman.ccsds.org >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs >> >> Hi Ed, >> >> So if I get it correctly, we'll have a unique field for the proto spanning 8 bits, >> where: >> >> 0-31: regular protocol id >> 32-255: extension protocol id >> >> Then probably the cases '0' and '255' could go reserved for special uses. >> >> Is my interpretation correct? >> ________________________________________ >> Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] >> Inviato: giovedì 4 febbraio 2016 18.18 >> A: Cola, Tomaso de; Kazz, Greg J (312B) >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- >> slp at mailman.ccsds.org >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs >> >> I think that Tomaso's observation is accurate. The USLP PID field is 5 bits >> allowing 32 possible PIPs. I believe that that number is sufficient but we need >> to allow for our possible miscalculation so we specified one of those values to >> extend the PID field. It makes no sense to make the extension anything other >> than an octet. The question is how the contents of the extended field is >> interpreted. My recommendation is that we have 32 IDs in the 5 bit field and >> these should be interpreted as an 8 bit field with 3 leading zero. These 32 IDs >> would be reserved in the extension field. Thus the extension field provides an >> additional 256-32 PID and the value of the all PIDs can be a unique digital >> value. This gives us a maximum of 255 unique PIDs. >> >> From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- >> bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de >> Sent: Thursday, February 04, 2016 1:32 AM >> To: Kazz, Greg J (312B) >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- >> slp at mailman.ccsds.org >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs >> >> Greg, >> >> Still coming back to the point of the PID size, I perfectly understand that it is >> better to have some margin to avoid problems coming up later. On the other >> hand, I notice that summing up PID+extensions we have 9 bits, which are even >> more than those made available with the Proto field (8 bits) in IPv4. So the >> question is, do we really need such large number? Or, said in different terms, >> what are the requirements we want to target with such setting? I would have >> expected that accommodating up to 64 protocol combinations would have been >> sufficient. Finally, I'm wondering how USLP encapsulation works in the case of >> IPoC: do we still have the IPE header or is this somehow mapped in the >> PID+extensions of USLP? In any case, I imagine these special cases (along with >> any others) will be properly illustrated in the green book. >> >> Thanks in advance for your comments on these thoughts. >> >> Best Regards, >> >> Tomaso >> >> ------------------------ >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center >> Institute of Communications and Navigation | Satellite Networks | >> Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | >> tomaso.decola at dlr.de >> http://www.dlr.de/kn/institut/abteilungen/san >> >> From: sls-slp-bounces at mailman.ccsds.org> bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] On >> Behalf Of Kazz, Greg J (312B) >> Sent: Wednesday, February 03, 2016 18:03 >> To: Gian.Paolo.Calzolari at esa.int >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs >> >> G.P., >> >> We have learned through the lesson of IPoC that a 3 bit PID is too small and >> restrictive, so that is why in USLP we defined the PID to be bigger I.e., 5 bits >> also limited because the first 3 bits are used up by the TFDZ construction rules. >> I agree that the extended protocol ID field of 8 bits is too big so using the first 4 >> bits for the PID extension would give us 9 total bits or 512 combinations for >> PIDs. That would leave 4 bits of spares thereafter. >> I don't see any compelling reason to create a separate field just for COP. >> >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, >> mandatory); >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;- >> --> same as >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html >> .aslo can contain ipe_header values >> c2) Spare (4 bits, optional); >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, optional) >> ). >> >> Regards, >> Greg >> >> From: "Gian.Paolo.Calzolari at esa.int" >> > >> Date: Wednesday, February 3, 2016 at 2:38 AM >> To: "Kazz, Greg J (313B)" >> > >> Cc: "Shames, Peter M (312B)" >> >, SLS- >> SLP Mailing List > slp at mailman.ccsds.org>> >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs >> >> Greg, >> assuming that USLP will be able to carry 2**13 = 8192 different upper >> layers protocols look to me as thinking big. >> Though I like optimism I wonder whether this is appropriate. >> >> Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines the >> Protocol Identifier for Encapsulation Service over 3 bits with Extended Protocol >> Identifier for Encapsulation Service over 4 bits (i.e. a total of 7 bits but not >> really 2**7 = 128 different protocol as the construction allows 16 +6 protocols >> as some values are reserved (see >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). >> I there a good reason for thinking that USLP could carry 8192 different while >> Encapsulation Packet is limited to 22? >> >> If not please consider the following alternative definition (justified also by the >> current definition of the fields containing either a protocol ID or a COP >> directive indication): >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, >> mandatory); >> b1) COP usage (2 bits, mandatory); ---> see below >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> same >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, optional); ;- >> --> same as >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? >> d) First Header Pointer or Last Valid Octet (16 bits, optional). >> >> >> COP usage (2 bits, mandatory); >> 00 = No directives >> 01 = COP-1 directives are contained within the TFDZ. >> 10 = COP-P directives are contained within the TFDZ >> 11 = reserved >> >> Regards >> >> Gian Paolo >> >> >> >> From: "Kazz, Greg J (312B)" >> > >> To: "Shames, Peter M (312B)" >> > >> Cc: "sls-slp at mailman.ccsds.org" > slp at mailman.ccsds.org> >> Date: 02/02/2016 19:48 >> Subject: [Sls-slp] CCSDS definition of Protocol IDs >> Sent by: sls-slp-bounces at mailman.ccsds.org> bounces at mailman.ccsds.org> >> ________________________________ >> >> >> >> Peter, >> >> USLP is planning on defining a Protocol Id (PID) field and an Extended Protocol >> ID field in the Transfer Frame Data Field Header. >> Encapsulation Service currently defines Protocol ID to be a 3 bit field, followed >> by an optional Protocol Extension Field of 8 bits for a total of 11 bits. >> There is a SANA registry for PIDs under >> http://sanaregistry.org/r/protocol_id/protocol_id.html >> >> IPoC also defines PIDs as well for the IPE header. See >> http://sanaregistry.org/r/ipe_header/ipe_header.html >> In this case, the smallest size IPE header is 8 bits, but it has a multiple octet >> extension capability beyond 1 octet. >> >> USLP currently in draft form, has defined the PID to be 5 bits long, followed by >> an optional Protocol Extension Field of 8 bits for a total of 13 bits. >> Below is an approach from Ed Greenberg, that shows that the Encapsulation >> PIDs can indeed be a subset of the USLP PIDs. See email message below. >> >> Question - What does CCSDS, from an organization point of view, envision a >> need to define PIDs across all of CCSDS not just USLP or Encap service ? Or is it >> appropriate for USLP to define the term, Protocol ID and have it apply locally >> I.e., only to the USLP links ? >> In the review of USLP, we will address questions like, "Is a 13 bit PID name >> space sufficient for all agency needs ?" >> >> Your thoughts ? >> >> Thanks! >> Greg >> >> From: "Greenberg, Edward (312B)" >> > >> Date: Tuesday, February 2, 2016 at 9:53 AM >> To: "Kazz, Greg J (313B)" >> > >> Subject: PIDs >> >> Encap uses 3 bits +8bits when 3bits=111 >> USLP uses 5 bits +8 bits when 5 bits =11111 >> >> Thus if we assume that the PIP space for Encap in 5 bit form we get >> 11xxx+xxxxxxxx >> >> >> The only issue is that new PIDs for USLP that have their first 2 bits as 00, 01 or >> 10 don't map to >> Encap_______________________________________________ >> Sls-slp mailing list >> Sls-slp at mailman.ccsds.org >> http://mailman.ccsds.org/mailman/listinfo/sls-slp >> >> This message and any attachments are intended for the use of the addressee or >> addressees only. >> >> The unauthorised disclosure, use, dissemination or copying (either in whole or >> in part) of its >> >> content is not permitted. >> >> If you received this message in error, please notify the sender and delete it >> from your system. >> >> Emails can be altered and their integrity cannot be guaranteed by the sender. >> >> >> >> Please consider the environment before printing this email. > > >_______________________________________________ >Sls-slp mailing list >Sls-slp at mailman.ccsds.org >http://mailman.ccsds.org/mailman/listinfo/sls-slp From Tomaso.deCola at dlr.de Fri Feb 5 13:00:38 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Fri, 5 Feb 2016 13:00:38 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> Keith, I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it. Regards, Tomaso ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > -----Original Message----- > From: Scott, Keith L. [mailto:kscott at mitre.org] > Sent: Friday, February 05, 2016 13:34 > To: Cola, Tomaso de; edward.greenberg at jpl.nasa.gov; > greg.j.kazz at jpl.nasa.gov > Cc: peter.m.shames at jpl.nasa.gov; Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > So what’s the motivation for saving two bits? The delta power / bandwidth > needed is minimal, it requires more non-byte-aligned processing, and it sets us > up for needing that 65th protocol that we just can’t quite get… > > Why not just go with an 8-bit field that is one thing (without the protocols and > extensions distinction)? Is it that the extension field is optional (incurring more > data-dependent header processing)? > > Sorry, but while optimizing bit field sizes down to sub-byte level seems like a > useful thing, it also seems to have bitten us a number of times. > > —keith > > > > On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of > Tomaso.deCola at dlr.de" Tomaso.deCola at dlr.de> wrote: > > >Personally I find this approach more efficient than what proposed in the book > right now. One could wonder whether we could go for 6-bits instead of 8-bits so > that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 > extended protocol ids (as from your approach) are definitely too much, also > considering the possible protocol evolution in the space domain in the next 10- > 20 years according to what we have seen in the last 10 years. For instance the > extended protocol IDs in the encaps are all unassigned, meaning that from the > time the protocol was designed there was no use. In this discussion, as > mentioned in my previous e-mail, it would be also interesting to see how > encapsulation of IP datagrams will be carried out: do we still use of IPoC or do > we transport IP datagrams directly in USLP and we use the Proto ID field to > transport the current IPE? > > > >Tomaso > > > >------------------------ > >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center > >Institute of Communications and Navigation | Satellite Networks | > >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. > >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > > > >> -----Original Message----- > >> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] > >> Sent: Thursday, February 04, 2016 23:24 > >> To: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think so...Do you have a problem with that? > >> > >> -----Original Message----- > >> From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] > >> Sent: Thursday, February 04, 2016 10:00 AM > >> To: Greenberg, Edward (312B); Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Hi Ed, > >> > >> So if I get it correctly, we'll have a unique field for the proto > >> spanning 8 bits, > >> where: > >> > >> 0-31: regular protocol id > >> 32-255: extension protocol id > >> > >> Then probably the cases '0' and '255' could go reserved for special uses. > >> > >> Is my interpretation correct? > >> ________________________________________ > >> Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] > >> Inviato: giovedì 4 febbraio 2016 18.18 > >> A: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think that Tomaso's observation is accurate. The USLP PID field is > >> 5 bits allowing 32 possible PIPs. I believe that that number is > >> sufficient but we need to allow for our possible miscalculation so we > >> specified one of those values to extend the PID field. It makes no sense to > make the extension anything other > >> than an octet. The question is how the contents of the extended field is > >> interpreted. My recommendation is that we have 32 IDs in the 5 bit > >> field and these should be interpreted as an 8 bit field with 3 leading zero. > These 32 IDs > >> would be reserved in the extension field. Thus the extension field provides > an > >> additional 256-32 PID and the value of the all PIDs can be a unique > >> digital value. This gives us a maximum of 255 unique PIDs. > >> > >> From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- > >> bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de > >> Sent: Thursday, February 04, 2016 1:32 AM > >> To: Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> > >> Still coming back to the point of the PID size, I perfectly > >> understand that it is better to have some margin to avoid problems > >> coming up later. On the other hand, I notice that summing up > >> PID+extensions we have 9 bits, which are even more than those made > >> available with the Proto field (8 bits) in IPv4. So the question is, > >> do we really need such large number? Or, said in different terms, > >> what are the requirements we want to target with such setting? I > >> would have expected that accommodating up to 64 protocol combinations > >> would have been sufficient. Finally, I'm wondering how USLP > >> encapsulation works in the case of > >> IPoC: do we still have the IPE header or is this somehow mapped in > >> the > >> PID+extensions of USLP? In any case, I imagine these special cases > >> PID+(along with > >> any others) will be properly illustrated in the green book. > >> > >> Thanks in advance for your comments on these thoughts. > >> > >> Best Regards, > >> > >> Tomaso > >> > >> ------------------------ > >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace > >> Center Institute of Communications and Navigation | Satellite > >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, > Ph.D. > >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >> tomaso.decola at dlr.de > >> http://www.dlr.de/kn/institut/abteilungen/san > >> > >> From: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] > >> On Behalf Of Kazz, Greg J (312B) > >> Sent: Wednesday, February 03, 2016 18:03 > >> To: Gian.Paolo.Calzolari at esa.int > >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> G.P., > >> > >> We have learned through the lesson of IPoC that a 3 bit PID is too > >> small and restrictive, so that is why in USLP we defined the PID to > >> be bigger I.e., 5 bits also limited because the first 3 bits are used up by the > TFDZ construction rules. > >> I agree that the extended protocol ID field of 8 bits is too big so > >> using the first 4 bits for the PID extension would give us 9 total > >> bits or 512 combinations for PIDs. That would leave 4 bits of spares > thereafter. > >> I don't see any compelling reason to create a separate field just for COP. > >> > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h > >> tml > >> .aslo can contain ipe_header values > >> c2) Spare (4 bits, optional); > >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, > optional) > >> ). > >> > >> Regards, > >> Greg > >> > >> From: "Gian.Paolo.Calzolari at esa.int" > >> > > >> Date: Wednesday, February 3, 2016 at 2:38 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Cc: "Shames, Peter M (312B)" > >> >, > >> SLS- SLP Mailing List >> slp at mailman.ccsds.org>> > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> assuming that USLP will be able to carry 2**13 = 8192 > >> different upper layers protocols look to me as thinking big. > >> Though I like optimism I wonder whether this is appropriate. > >> > >> Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines > >> the Protocol Identifier for Encapsulation Service over 3 bits with > >> Extended Protocol Identifier for Encapsulation Service over 4 bits > >> (i.e. a total of 7 bits but not really 2**7 = 128 different protocol > >> as the construction allows 16 +6 protocols as some values are > >> reserved (see > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). > >> I there a good reason for thinking that USLP could carry 8192 > >> different while Encapsulation Packet is limited to 22? > >> > >> If not please consider the following alternative definition > >> (justified also by the current definition of the fields containing > >> either a protocol ID or a COP directive indication): > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b1) COP usage (2 bits, mandatory); ---> see below > >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> > same > >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? > >> d) First Header Pointer or Last Valid Octet (16 bits, optional). > >> > >> > >> COP usage (2 bits, mandatory); > >> 00 = No directives > >> 01 = COP-1 directives are contained within the TFDZ. > >> 10 = COP-P directives are contained within the TFDZ > >> 11 = reserved > >> > >> Regards > >> > >> Gian Paolo > >> > >> > >> > >> From: "Kazz, Greg J (312B)" > >> > > >> To: "Shames, Peter M (312B)" > >> > > >> Cc: "sls-slp at mailman.ccsds.org" > >> slp at mailman.ccsds.org> > >> Date: 02/02/2016 19:48 > >> Subject: [Sls-slp] CCSDS definition of Protocol IDs > >> Sent by: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> > >> ________________________________ > >> > >> > >> > >> Peter, > >> > >> USLP is planning on defining a Protocol Id (PID) field and an > >> Extended Protocol ID field in the Transfer Frame Data Field Header. > >> Encapsulation Service currently defines Protocol ID to be a 3 bit > >> field, followed by an optional Protocol Extension Field of 8 bits for a total of > 11 bits. > >> There is a SANA registry for PIDs under > >> http://sanaregistry.org/r/protocol_id/protocol_id.html > >> > >> IPoC also defines PIDs as well for the IPE header. See > >> http://sanaregistry.org/r/ipe_header/ipe_header.html > >> In this case, the smallest size IPE header is 8 bits, but it has a > >> multiple octet extension capability beyond 1 octet. > >> > >> USLP currently in draft form, has defined the PID to be 5 bits long, > >> followed by an optional Protocol Extension Field of 8 bits for a total of 13 > bits. > >> Below is an approach from Ed Greenberg, that shows that the > >> Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email > message below. > >> > >> Question - What does CCSDS, from an organization point of view, > >> envision a need to define PIDs across all of CCSDS not just USLP or > >> Encap service ? Or is it appropriate for USLP to define the term, > >> Protocol ID and have it apply locally I.e., only to the USLP links ? > >> In the review of USLP, we will address questions like, "Is a 13 bit > >> PID name space sufficient for all agency needs ?" > >> > >> Your thoughts ? > >> > >> Thanks! > >> Greg > >> > >> From: "Greenberg, Edward (312B)" > >> > > > >> Date: Tuesday, February 2, 2016 at 9:53 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Subject: PIDs > >> > >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when > >> 5 bits =11111 > >> > >> Thus if we assume that the PIP space for Encap in 5 bit form we get > >> 11xxx+xxxxxxxx > >> > >> > >> The only issue is that new PIDs for USLP that have their first 2 bits > >> as 00, 01 or > >> 10 don't map to > >> Encap_______________________________________________ > >> Sls-slp mailing list > >> Sls-slp at mailman.ccsds.org > >> http://mailman.ccsds.org/mailman/listinfo/sls-slp > >> > >> This message and any attachments are intended for the use of the > >> addressee or addressees only. > >> > >> The unauthorised disclosure, use, dissemination or copying (either in > >> whole or in part) of its > >> > >> content is not permitted. > >> > >> If you received this message in error, please notify the sender and > >> delete it from your system. > >> > >> Emails can be altered and their integrity cannot be guaranteed by the > sender. > >> > >> > >> > >> Please consider the environment before printing this email. > > > > > >_______________________________________________ > >Sls-slp mailing list > >Sls-slp at mailman.ccsds.org > >http://mailman.ccsds.org/mailman/listinfo/sls-slp From Gian.Paolo.Calzolari at esa.int Fri Feb 5 13:03:15 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Fri, 5 Feb 2016 14:03:15 +0100 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> Message-ID: <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Have a nice week end Gian Paolo From: To: , , Cc: , , Date: 05/02/2016 14:00 Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Keith, I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it. Regards, Tomaso ???????????????????????? Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > -----Original Message----- > From: Scott, Keith L. [mailto:kscott at mitre.org] > Sent: Friday, February 05, 2016 13:34 > To: Cola, Tomaso de; edward.greenberg at jpl.nasa.gov; > greg.j.kazz at jpl.nasa.gov > Cc: peter.m.shames at jpl.nasa.gov; Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > So what?s the motivation for saving two bits? The delta power / bandwidth > needed is minimal, it requires more non-byte-aligned processing, and it sets us > up for needing that 65th protocol that we just can?t quite get? > > Why not just go with an 8-bit field that is one thing (without the protocols and > extensions distinction)? Is it that the extension field is optional (incurring more > data-dependent header processing)? > > Sorry, but while optimizing bit field sizes down to sub-byte level seems like a > useful thing, it also seems to have bitten us a number of times. > > ?keith > > > > On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of > Tomaso.deCola at dlr.de" Tomaso.deCola at dlr.de> wrote: > > >Personally I find this approach more efficient than what proposed in the book > right now. One could wonder whether we could go for 6-bits instead of 8-bits so > that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 > extended protocol ids (as from your approach) are definitely too much, also > considering the possible protocol evolution in the space domain in the next 10- > 20 years according to what we have seen in the last 10 years. For instance the > extended protocol IDs in the encaps are all unassigned, meaning that from the > time the protocol was designed there was no use. In this discussion, as > mentioned in my previous e-mail, it would be also interesting to see how > encapsulation of IP datagrams will be carried out: do we still use of IPoC or do > we transport IP datagrams directly in USLP and we use the Proto ID field to > transport the current IPE? > > > >Tomaso > > > >------------------------ > >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center > >Institute of Communications and Navigation | Satellite Networks | > >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. > >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > > > >> -----Original Message----- > >> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] > >> Sent: Thursday, February 04, 2016 23:24 > >> To: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think so...Do you have a problem with that? > >> > >> -----Original Message----- > >> From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] > >> Sent: Thursday, February 04, 2016 10:00 AM > >> To: Greenberg, Edward (312B); Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Hi Ed, > >> > >> So if I get it correctly, we'll have a unique field for the proto > >> spanning 8 bits, > >> where: > >> > >> 0-31: regular protocol id > >> 32-255: extension protocol id > >> > >> Then probably the cases '0' and '255' could go reserved for special uses. > >> > >> Is my interpretation correct? > >> ________________________________________ > >> Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] > >> Inviato: giovedì 4 febbraio 2016 18.18 > >> A: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think that Tomaso's observation is accurate. The USLP PID field is > >> 5 bits allowing 32 possible PIPs. I believe that that number is > >> sufficient but we need to allow for our possible miscalculation so we > >> specified one of those values to extend the PID field. It makes no sense to > make the extension anything other > >> than an octet. The question is how the contents of the extended field is > >> interpreted. My recommendation is that we have 32 IDs in the 5 bit > >> field and these should be interpreted as an 8 bit field with 3 leading zero. > These 32 IDs > >> would be reserved in the extension field. Thus the extension field provides > an > >> additional 256-32 PID and the value of the all PIDs can be a unique > >> digital value. This gives us a maximum of 255 unique PIDs. > >> > >> From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- > >> bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de > >> Sent: Thursday, February 04, 2016 1:32 AM > >> To: Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> > >> Still coming back to the point of the PID size, I perfectly > >> understand that it is better to have some margin to avoid problems > >> coming up later. On the other hand, I notice that summing up > >> PID+extensions we have 9 bits, which are even more than those made > >> available with the Proto field (8 bits) in IPv4. So the question is, > >> do we really need such large number? Or, said in different terms, > >> what are the requirements we want to target with such setting? I > >> would have expected that accommodating up to 64 protocol combinations > >> would have been sufficient. Finally, I'm wondering how USLP > >> encapsulation works in the case of > >> IPoC: do we still have the IPE header or is this somehow mapped in > >> the > >> PID+extensions of USLP? In any case, I imagine these special cases > >> PID+(along with > >> any others) will be properly illustrated in the green book. > >> > >> Thanks in advance for your comments on these thoughts. > >> > >> Best Regards, > >> > >> Tomaso > >> > >> ------------------------ > >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace > >> Center Institute of Communications and Navigation | Satellite > >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, > Ph.D. > >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >> tomaso.decola at dlr.de > >> http://www.dlr.de/kn/institut/abteilungen/san > >> > >> From: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] > >> On Behalf Of Kazz, Greg J (312B) > >> Sent: Wednesday, February 03, 2016 18:03 > >> To: Gian.Paolo.Calzolari at esa.int > >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> G.P., > >> > >> We have learned through the lesson of IPoC that a 3 bit PID is too > >> small and restrictive, so that is why in USLP we defined the PID to > >> be bigger I.e., 5 bits also limited because the first 3 bits are used up by the > TFDZ construction rules. > >> I agree that the extended protocol ID field of 8 bits is too big so > >> using the first 4 bits for the PID extension would give us 9 total > >> bits or 512 combinations for PIDs. That would leave 4 bits of spares > thereafter. > >> I don't see any compelling reason to create a separate field just for COP. > >> > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h > >> tml > >> .aslo can contain ipe_header values > >> c2) Spare (4 bits, optional); > >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, > optional) > >> ). > >> > >> Regards, > >> Greg > >> > >> From: "Gian.Paolo.Calzolari at esa.int< mailto:Gian.Paolo.Calzolari at esa.int>" > >> > > >> Date: Wednesday, February 3, 2016 at 2:38 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Cc: "Shames, Peter M (312B)" > >> >, > >> SLS- SLP Mailing List >> slp at mailman.ccsds.org>> > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> assuming that USLP will be able to carry 2**13 = 8192 > >> different upper layers protocols look to me as thinking big. > >> Though I like optimism I wonder whether this is appropriate. > >> > >> Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines > >> the Protocol Identifier for Encapsulation Service over 3 bits with > >> Extended Protocol Identifier for Encapsulation Service over 4 bits > >> (i.e. a total of 7 bits but not really 2**7 = 128 different protocol > >> as the construction allows 16 +6 protocols as some values are > >> reserved (see > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). > >> I there a good reason for thinking that USLP could carry 8192 > >> different while Encapsulation Packet is limited to 22? > >> > >> If not please consider the following alternative definition > >> (justified also by the current definition of the fields containing > >> either a protocol ID or a COP directive indication): > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b1) COP usage (2 bits, mandatory); ---> see below > >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> > same > >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? > >> d) First Header Pointer or Last Valid Octet (16 bits, optional). > >> > >> > >> COP usage (2 bits, mandatory); > >> 00 = No directives > >> 01 = COP-1 directives are contained within the TFDZ. > >> 10 = COP-P directives are contained within the TFDZ > >> 11 = reserved > >> > >> Regards > >> > >> Gian Paolo > >> > >> > >> > >> From: "Kazz, Greg J (312B)" > >> > > >> To: "Shames, Peter M (312B)" > >> > > >> Cc: "sls-slp at mailman.ccsds.org< mailto:sls-slp at mailman.ccsds.org>" > >> slp at mailman.ccsds.org> > >> Date: 02/02/2016 19:48 > >> Subject: [Sls-slp] CCSDS definition of Protocol IDs > >> Sent by: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> > >> ________________________________ > >> > >> > >> > >> Peter, > >> > >> USLP is planning on defining a Protocol Id (PID) field and an > >> Extended Protocol ID field in the Transfer Frame Data Field Header. > >> Encapsulation Service currently defines Protocol ID to be a 3 bit > >> field, followed by an optional Protocol Extension Field of 8 bits for a total of > 11 bits. > >> There is a SANA registry for PIDs under > >> http://sanaregistry.org/r/protocol_id/protocol_id.html > >> > >> IPoC also defines PIDs as well for the IPE header. See > >> http://sanaregistry.org/r/ipe_header/ipe_header.html > >> In this case, the smallest size IPE header is 8 bits, but it has a > >> multiple octet extension capability beyond 1 octet. > >> > >> USLP currently in draft form, has defined the PID to be 5 bits long, > >> followed by an optional Protocol Extension Field of 8 bits for a total of 13 > bits. > >> Below is an approach from Ed Greenberg, that shows that the > >> Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email > message below. > >> > >> Question - What does CCSDS, from an organization point of view, > >> envision a need to define PIDs across all of CCSDS not just USLP or > >> Encap service ? Or is it appropriate for USLP to define the term, > >> Protocol ID and have it apply locally I.e., only to the USLP links ? > >> In the review of USLP, we will address questions like, "Is a 13 bit > >> PID name space sufficient for all agency needs ?" > >> > >> Your thoughts ? > >> > >> Thanks! > >> Greg > >> > >> From: "Greenberg, Edward (312B)" > >> > > > >> Date: Tuesday, February 2, 2016 at 9:53 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Subject: PIDs > >> > >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when > >> 5 bits =11111 > >> > >> Thus if we assume that the PIP space for Encap in 5 bit form we get > >> 11xxx+xxxxxxxx > >> > >> > >> The only issue is that new PIDs for USLP that have their first 2 bits > >> as 00, 01 or > >> 10 don't map to > >> Encap_______________________________________________ > >> Sls-slp mailing list > >> Sls-slp at mailman.ccsds.org > >> http://mailman.ccsds.org/mailman/listinfo/sls-slp > >> > >> This message and any attachments are intended for the use of the > >> addressee or addressees only. > >> > >> The unauthorised disclosure, use, dissemination or copying (either in > >> whole or in part) of its > >> > >> content is not permitted. > >> > >> If you received this message in error, please notify the sender and > >> delete it from your system. > >> > >> Emails can be altered and their integrity cannot be guaranteed by the > sender. > >> > >> > >> > >> Please consider the environment before printing this email. > > > > > >_______________________________________________ > >Sls-slp mailing list > >Sls-slp at mailman.ccsds.org > >http://mailman.ccsds.org/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: From kscott at mitre.org Fri Feb 5 14:39:14 2016 From: kscott at mitre.org (Scott, Keith L.) Date: Fri, 5 Feb 2016 14:39:14 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> Message-ID: Is there a reason people don’t like: TFDZ: 3 bits Reserved: 5 bits ProtoID: 8 bits First Header pointer: 16 bits ? From: Gian Calzolari > Date: Friday, February 5, 2016 at 8:03 AM To: "Tomaso.deCola at dlr.de" > Cc: Edward Greenberg >, Greg Kazz >, "Scott, Keith L." >, Peter Shames >, "sls-slp at mailman.ccsds.org" > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Fri Feb 5 14:48:56 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Fri, 5 Feb 2016 15:48:56 +0100 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> Message-ID: <29043_1454683739_56B4B65B_29043_665_1_OFE62C2D62.31394C87-ONC1257F50.00514FE2-C1257F50.0051626B@esa.int> Sorry Keith but I am quite puzzled as the mail you forward is not the mail I sent...... I just said: Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Regards Gian Paolo From: "Scott, Keith L." To: "Gian.Paolo.Calzolari at esa.int" , "Tomaso.deCola at dlr.de" Cc: "edward.greenberg at jpl.nasa.gov" , "greg.j.kazz at jpl.nasa.gov" , "peter.m.shames at jpl.nasa.gov" , "sls-slp at mailman.ccsds.org" Date: 05/02/2016 15:39 Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Is there a reason people don?t like: TFDZ: 3 bits Reserved: 5 bits ProtoID: 8 bits First Header pointer: 16 bits ? From: Gian Calzolari Date: Friday, February 5, 2016 at 8:03 AM To: "Tomaso.deCola at dlr.de" Cc: Edward Greenberg , Greg Kazz < greg.j.kazz at jpl.nasa.gov>, "Scott, Keith L." , Peter Shames , "sls-slp at mailman.ccsds.org" < sls-slp at mailman.ccsds.org> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. 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: From kscott at mitre.org Fri Feb 5 14:56:10 2016 From: kscott at mitre.org (Scott, Keith L.) Date: Fri, 5 Feb 2016 14:56:10 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> Message-ID: Sorry, this was more in response to Tomaso’s text: (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits. I think I’m agreeing with you. :) —keith From: Gian Calzolari > Date: Friday, February 5, 2016 at 9:48 AM To: "Scott, Keith L." > Cc: Edward Greenberg >, Greg Kazz >, Peter Shames >, "sls-slp at mailman.ccsds.org" >, "Tomaso.deCola at dlr.de" > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Sorry Keith but I am quite puzzled as the mail you forward is not the mail I sent...... I just said: Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Regards Gian Paolo From: "Scott, Keith L." > To: "Gian.Paolo.Calzolari at esa.int" >, "Tomaso.deCola at dlr.de" > Cc: "edward.greenberg at jpl.nasa.gov" >, "greg.j.kazz at jpl.nasa.gov" >, "peter.m.shames at jpl.nasa.gov" >, "sls-slp at mailman.ccsds.org" > Date: 05/02/2016 15:39 Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs ________________________________ From: Gian Calzolari > Date: Friday, February 5, 2016 at 8:03 AM To: "Tomaso.deCola at dlr.de" > Cc: Edward Greenberg >, Greg Kazz >, "Scott, Keith L." >, Peter Shames >, "sls-slp at mailman.ccsds.org" > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Have a nice week end Gian Paolo From: > To: >, >, > Cc: >, >, > Date: 05/02/2016 14:00 Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs ________________________________ Keith, I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it. Regards, Tomaso ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > -----Original Message----- > From: Scott, Keith L. [mailto:kscott at mitre.org] > Sent: Friday, February 05, 2016 13:34 > To: Cola, Tomaso de; edward.greenberg at jpl.nasa.gov; > greg.j.kazz at jpl.nasa.gov > Cc: peter.m.shames at jpl.nasa.gov; Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > So what’s the motivation for saving two bits? The delta power / bandwidth > needed is minimal, it requires more non-byte-aligned processing, and it sets us > up for needing that 65th protocol that we just can’t quite get… > > Why not just go with an 8-bit field that is one thing (without the protocols and > extensions distinction)? Is it that the extension field is optional (incurring more > data-dependent header processing)? > > Sorry, but while optimizing bit field sizes down to sub-byte level seems like a > useful thing, it also seems to have bitten us a number of times. > > —keith > > > > On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of > Tomaso.deCola at dlr.de" on behalf of > Tomaso.deCola at dlr.de> wrote: > > >Personally I find this approach more efficient than what proposed in the book > right now. One could wonder whether we could go for 6-bits instead of 8-bits so > that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 > extended protocol ids (as from your approach) are definitely too much, also > considering the possible protocol evolution in the space domain in the next 10- > 20 years according to what we have seen in the last 10 years. For instance the > extended protocol IDs in the encaps are all unassigned, meaning that from the > time the protocol was designed there was no use. In this discussion, as > mentioned in my previous e-mail, it would be also interesting to see how > encapsulation of IP datagrams will be carried out: do we still use of IPoC or do > we transport IP datagrams directly in USLP and we use the Proto ID field to > transport the current IPE? > > > >Tomaso > > > >------------------------ > >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center > >Institute of Communications and Navigation | Satellite Networks | > >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. > >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > > > >> -----Original Message----- > >> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] > >> Sent: Thursday, February 04, 2016 23:24 > >> To: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think so...Do you have a problem with that? > >> > >> -----Original Message----- > >> From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] > >> Sent: Thursday, February 04, 2016 10:00 AM > >> To: Greenberg, Edward (312B); Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Hi Ed, > >> > >> So if I get it correctly, we'll have a unique field for the proto > >> spanning 8 bits, > >> where: > >> > >> 0-31: regular protocol id > >> 32-255: extension protocol id > >> > >> Then probably the cases '0' and '255' could go reserved for special uses. > >> > >> Is my interpretation correct? > >> ________________________________________ > >> Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] > >> Inviato: giovedì 4 febbraio 2016 18.18 > >> A: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think that Tomaso's observation is accurate. The USLP PID field is > >> 5 bits allowing 32 possible PIPs. I believe that that number is > >> sufficient but we need to allow for our possible miscalculation so we > >> specified one of those values to extend the PID field. It makes no sense to > make the extension anything other > >> than an octet. The question is how the contents of the extended field is > >> interpreted. My recommendation is that we have 32 IDs in the 5 bit > >> field and these should be interpreted as an 8 bit field with 3 leading zero. > These 32 IDs > >> would be reserved in the extension field. Thus the extension field provides > an > >> additional 256-32 PID and the value of the all PIDs can be a unique > >> digital value. This gives us a maximum of 255 unique PIDs. > >> > >> From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- > >> bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de > >> Sent: Thursday, February 04, 2016 1:32 AM > >> To: Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> > >> Still coming back to the point of the PID size, I perfectly > >> understand that it is better to have some margin to avoid problems > >> coming up later. On the other hand, I notice that summing up > >> PID+extensions we have 9 bits, which are even more than those made > >> available with the Proto field (8 bits) in IPv4. So the question is, > >> do we really need such large number? Or, said in different terms, > >> what are the requirements we want to target with such setting? I > >> would have expected that accommodating up to 64 protocol combinations > >> would have been sufficient. Finally, I'm wondering how USLP > >> encapsulation works in the case of > >> IPoC: do we still have the IPE header or is this somehow mapped in > >> the > >> PID+extensions of USLP? In any case, I imagine these special cases > >> PID+(along with > >> any others) will be properly illustrated in the green book. > >> > >> Thanks in advance for your comments on these thoughts. > >> > >> Best Regards, > >> > >> Tomaso > >> > >> ------------------------ > >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace > >> Center Institute of Communications and Navigation | Satellite > >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, > Ph.D. > >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >> tomaso.decola at dlr.de > >> http://www.dlr.de/kn/institut/abteilungen/san > >> > >> From: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] > >> On Behalf Of Kazz, Greg J (312B) > >> Sent: Wednesday, February 03, 2016 18:03 > >> To: Gian.Paolo.Calzolari at esa.int > >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> G.P., > >> > >> We have learned through the lesson of IPoC that a 3 bit PID is too > >> small and restrictive, so that is why in USLP we defined the PID to > >> be bigger I.e., 5 bits also limited because the first 3 bits are used up by the > TFDZ construction rules. > >> I agree that the extended protocol ID field of 8 bits is too big so > >> using the first 4 bits for the PID extension would give us 9 total > >> bits or 512 combinations for PIDs. That would leave 4 bits of spares > thereafter. > >> I don't see any compelling reason to create a separate field just for COP. > >> > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h > >> tml > >> .aslo can contain ipe_header values > >> c2) Spare (4 bits, optional); > >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, > optional) > >> ). > >> > >> Regards, > >> Greg > >> > >> From: "Gian.Paolo.Calzolari at esa.int" > >> > > >> Date: Wednesday, February 3, 2016 at 2:38 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Cc: "Shames, Peter M (312B)" > >> >, > >> SLS- SLP Mailing List >> slp at mailman.ccsds.org>> > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> assuming that USLP will be able to carry 2**13 = 8192 > >> different upper layers protocols look to me as thinking big. > >> Though I like optimism I wonder whether this is appropriate. > >> > >> Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines > >> the Protocol Identifier for Encapsulation Service over 3 bits with > >> Extended Protocol Identifier for Encapsulation Service over 4 bits > >> (i.e. a total of 7 bits but not really 2**7 = 128 different protocol > >> as the construction allows 16 +6 protocols as some values are > >> reserved (see > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). > >> I there a good reason for thinking that USLP could carry 8192 > >> different while Encapsulation Packet is limited to 22? > >> > >> If not please consider the following alternative definition > >> (justified also by the current definition of the fields containing > >> either a protocol ID or a COP directive indication): > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b1) COP usage (2 bits, mandatory); ---> see below > >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> > same > >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? > >> d) First Header Pointer or Last Valid Octet (16 bits, optional). > >> > >> > >> COP usage (2 bits, mandatory); > >> 00 = No directives > >> 01 = COP-1 directives are contained within the TFDZ. > >> 10 = COP-P directives are contained within the TFDZ > >> 11 = reserved > >> > >> Regards > >> > >> Gian Paolo > >> > >> > >> > >> From: "Kazz, Greg J (312B)" > >> > > >> To: "Shames, Peter M (312B)" > >> > > >> Cc: "sls-slp at mailman.ccsds.org" > >> slp at mailman.ccsds.org> > >> Date: 02/02/2016 19:48 > >> Subject: [Sls-slp] CCSDS definition of Protocol IDs > >> Sent by: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> > >> ________________________________ > >> > >> > >> > >> Peter, > >> > >> USLP is planning on defining a Protocol Id (PID) field and an > >> Extended Protocol ID field in the Transfer Frame Data Field Header. > >> Encapsulation Service currently defines Protocol ID to be a 3 bit > >> field, followed by an optional Protocol Extension Field of 8 bits for a total of > 11 bits. > >> There is a SANA registry for PIDs under > >> http://sanaregistry.org/r/protocol_id/protocol_id.html > >> > >> IPoC also defines PIDs as well for the IPE header. See > >> http://sanaregistry.org/r/ipe_header/ipe_header.html > >> In this case, the smallest size IPE header is 8 bits, but it has a > >> multiple octet extension capability beyond 1 octet. > >> > >> USLP currently in draft form, has defined the PID to be 5 bits long, > >> followed by an optional Protocol Extension Field of 8 bits for a total of 13 > bits. > >> Below is an approach from Ed Greenberg, that shows that the > >> Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email > message below. > >> > >> Question - What does CCSDS, from an organization point of view, > >> envision a need to define PIDs across all of CCSDS not just USLP or > >> Encap service ? Or is it appropriate for USLP to define the term, > >> Protocol ID and have it apply locally I.e., only to the USLP links ? > >> In the review of USLP, we will address questions like, "Is a 13 bit > >> PID name space sufficient for all agency needs ?" > >> > >> Your thoughts ? > >> > >> Thanks! > >> Greg > >> > >> From: "Greenberg, Edward (312B)" > >> > > > >> Date: Tuesday, February 2, 2016 at 9:53 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Subject: PIDs > >> > >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when > >> 5 bits =11111 > >> > >> Thus if we assume that the PIP space for Encap in 5 bit form we get > >> 11xxx+xxxxxxxx > >> > >> > >> The only issue is that new PIDs for USLP that have their first 2 bits > >> as 00, 01 or > >> 10 don't map to > >> Encap_______________________________________________ > >> Sls-slp mailing list > >> Sls-slp at mailman.ccsds.org > >> http://mailman.ccsds.org/mailman/listinfo/sls-slp > >> > >> This message and any attachments are intended for the use of the > >> addressee or addressees only. > >> > >> The unauthorised disclosure, use, dissemination or copying (either in > >> whole or in part) of its > >> > >> content is not permitted. > >> > >> If you received this message in error, please notify the sender and > >> delete it from your system. > >> > >> Emails can be altered and their integrity cannot be guaranteed by the > sender. > >> > >> > >> > >> Please consider the environment before printing this email. > > > > > >_______________________________________________ > >Sls-slp mailing list > >Sls-slp at mailman.ccsds.org > >http://mailman.ccsds.org/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: From Tomaso.deCola at dlr.de Fri Feb 5 16:01:13 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Fri, 5 Feb 2016 16:01:13 +0000 Subject: [Sls-slp] CCSDS definition of Protocol IDs In-Reply-To: References: <27516_1454495898_56B1D89A_27516_157_1_OF537A6502.75623EA5-ONC1257F4E.0037D678-C1257F4E.003A6F55@esa.int> <1A39DCC13AF3C14B83CD74124D4DCFC3175C6741@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EBE5@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7119@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE5EC80@ap-embx-sp30.RES.AD.JPL> <1A39DCC13AF3C14B83CD74124D4DCFC3175C71FE@DLREXMBX01.intra.dlr.de> <52C2C1F4-4431-4C6D-AEA4-265EE99CC6B2@mitre.org> <1A39DCC13AF3C14B83CD74124D4DCFC3175C7395@DLREXMBX01.intra.dlr.de> <20996_1454677398_56B49D96_20996_198_1_OFA0D3D5C0.135B0CB3-ONC1257F50.0047900A-C1257F50.0047B566@esa.int> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C7458@DLREXMBX01.intra.dlr.de> Then I must agree with you all ☺ ….we keep the header length as it is now (i.e., 32 bits) but we use only 8 bits for the proto and the remaining 5 go reserved, as from Keith suggestion. Tomaso ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: Scott, Keith L. [mailto:kscott at mitre.org] Sent: Friday, February 05, 2016 15:56 To: Gian.Paolo.Calzolari at esa.int; Cola, Tomaso de Cc: edward.greenberg at jpl.nasa.gov; greg.j.kazz at jpl.nasa.gov; peter.m.shames at jpl.nasa.gov; sls-slp at mailman.ccsds.org Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Sorry, this was more in response to Tomaso’s text: (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits. I think I’m agreeing with you. :) —keith From: Gian Calzolari > Date: Friday, February 5, 2016 at 9:48 AM To: "Scott, Keith L." > Cc: Edward Greenberg >, Greg Kazz >, Peter Shames >, "sls-slp at mailman.ccsds.org" >, "Tomaso.deCola at dlr.de" > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs Sorry Keith but I am quite puzzled as the mail you forward is not the mail I sent...... I just said: Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Regards Gian Paolo From: "Scott, Keith L." > To: "Gian.Paolo.Calzolari at esa.int" >, "Tomaso.deCola at dlr.de" > Cc: "edward.greenberg at jpl.nasa.gov" >, "greg.j.kazz at jpl.nasa.gov" >, "peter.m.shames at jpl.nasa.gov" >, "sls-slp at mailman.ccsds.org" > Date: 05/02/2016 15:39 Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs ________________________________ From: Gian Calzolari > Date: Friday, February 5, 2016 at 8:03 AM To: "Tomaso.deCola at dlr.de" > Cc: Edward Greenberg >, Greg Kazz >, "Scott, Keith L." >, Peter Shames >, "sls-slp at mailman.ccsds.org" > Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs Also to be said that USLP is a little schizophrenic as sometimes it looks to saving bits and sometimes emphasises that USLP framers are so long that it is not worth saving bits :o) Have a nice week end Gian Paolo From: > To: >, >, > Cc: >, >, > Date: 05/02/2016 14:00 Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs ________________________________ Keith, I think you raised an important point: compactness vs. processing complexity. I think that however we should see this trade-off looking at the entire Transfer frame data field header, which contains the protocol field (s). At the moment it is 32-bit aligned (TFDZ:3 bits, ProtoID: 5 bits, Extended ProtoID: 8 bits, first header pointer: 16 bits) for a total of 32 bits, which is something always desirable. If we reduce the protocol IDs from a total of 13 down to 8, the header becomes of 27 bits. If we reduce from 13 to 6, it becomes 25 bits. I'm certainly fine with the 8 bits, I just wanted to avoid a large field (the initial 13 bits), which will be used only for very small extent of it. Regards, Tomaso ———————————————————————— Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > -----Original Message----- > From: Scott, Keith L. [mailto:kscott at mitre.org] > Sent: Friday, February 05, 2016 13:34 > To: Cola, Tomaso de; edward.greenberg at jpl.nasa.gov; > greg.j.kazz at jpl.nasa.gov > Cc: peter.m.shames at jpl.nasa.gov; Gian.Paolo.Calzolari at esa.int; sls- > slp at mailman.ccsds.org > Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > > So what’s the motivation for saving two bits? The delta power / bandwidth > needed is minimal, it requires more non-byte-aligned processing, and it sets us > up for needing that 65th protocol that we just can’t quite get… > > Why not just go with an 8-bit field that is one thing (without the protocols and > extensions distinction)? Is it that the extension field is optional (incurring more > data-dependent header processing)? > > Sorry, but while optimizing bit field sizes down to sub-byte level seems like a > useful thing, it also seems to have bitten us a number of times. > > —keith > > > > On 2/5/16, 3:22 AM, "sls-slp-bounces at mailman.ccsds.org on behalf of > Tomaso.deCola at dlr.de" on behalf of > Tomaso.deCola at dlr.de> wrote: > > >Personally I find this approach more efficient than what proposed in the book > right now. One could wonder whether we could go for 6-bits instead of 8-bits so > that we have 32 protocol IDs and 32 extensions, because I tend to think that 224 > extended protocol ids (as from your approach) are definitely too much, also > considering the possible protocol evolution in the space domain in the next 10- > 20 years according to what we have seen in the last 10 years. For instance the > extended protocol IDs in the encaps are all unassigned, meaning that from the > time the protocol was designed there was no use. In this discussion, as > mentioned in my previous e-mail, it would be also interesting to see how > encapsulation of IP datagrams will be carried out: do we still use of IPoC or do > we transport IP datagrams directly in USLP and we use the Proto ID field to > transport the current IPE? > > > >Tomaso > > > >------------------------ > >Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center > >Institute of Communications and Navigation | Satellite Networks | > >Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. > >Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san > > > >> -----Original Message----- > >> From: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] > >> Sent: Thursday, February 04, 2016 23:24 > >> To: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think so...Do you have a problem with that? > >> > >> -----Original Message----- > >> From: Tomaso.deCola at dlr.de [mailto:Tomaso.deCola at dlr.de] > >> Sent: Thursday, February 04, 2016 10:00 AM > >> To: Greenberg, Edward (312B); Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Hi Ed, > >> > >> So if I get it correctly, we'll have a unique field for the proto > >> spanning 8 bits, > >> where: > >> > >> 0-31: regular protocol id > >> 32-255: extension protocol id > >> > >> Then probably the cases '0' and '255' could go reserved for special uses. > >> > >> Is my interpretation correct? > >> ________________________________________ > >> Da: Greenberg, Edward (312B) [edward.greenberg at jpl.nasa.gov] > >> Inviato: giovedì 4 febbraio 2016 18.18 > >> A: Cola, Tomaso de; Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Oggetto: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> I think that Tomaso's observation is accurate. The USLP PID field is > >> 5 bits allowing 32 possible PIPs. I believe that that number is > >> sufficient but we need to allow for our possible miscalculation so we > >> specified one of those values to extend the PID field. It makes no sense to > make the extension anything other > >> than an octet. The question is how the contents of the extended field is > >> interpreted. My recommendation is that we have 32 IDs in the 5 bit > >> field and these should be interpreted as an 8 bit field with 3 leading zero. > These 32 IDs > >> would be reserved in the extension field. Thus the extension field provides > an > >> additional 256-32 PID and the value of the all PIDs can be a unique > >> digital value. This gives us a maximum of 255 unique PIDs. > >> > >> From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp- > >> bounces at mailman.ccsds.org] On Behalf Of Tomaso.deCola at dlr.de > >> Sent: Thursday, February 04, 2016 1:32 AM > >> To: Kazz, Greg J (312B) > >> Cc: Shames, Peter M (312B); Gian.Paolo.Calzolari at esa.int; sls- > >> slp at mailman.ccsds.org > >> Subject: RE: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> > >> Still coming back to the point of the PID size, I perfectly > >> understand that it is better to have some margin to avoid problems > >> coming up later. On the other hand, I notice that summing up > >> PID+extensions we have 9 bits, which are even more than those made > >> available with the Proto field (8 bits) in IPv4. So the question is, > >> do we really need such large number? Or, said in different terms, > >> what are the requirements we want to target with such setting? I > >> would have expected that accommodating up to 64 protocol combinations > >> would have been sufficient. Finally, I'm wondering how USLP > >> encapsulation works in the case of > >> IPoC: do we still have the IPE header or is this somehow mapped in > >> the > >> PID+extensions of USLP? In any case, I imagine these special cases > >> PID+(along with > >> any others) will be properly illustrated in the green book. > >> > >> Thanks in advance for your comments on these thoughts. > >> > >> Best Regards, > >> > >> Tomaso > >> > >> ------------------------ > >> Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace > >> Center Institute of Communications and Navigation | Satellite > >> Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, > Ph.D. > >> Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | > >> tomaso.decola at dlr.de > >> http://www.dlr.de/kn/institut/abteilungen/san > >> > >> From: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> [mailto:sls-slp-bounces at mailman.ccsds.org] > >> On Behalf Of Kazz, Greg J (312B) > >> Sent: Wednesday, February 03, 2016 18:03 > >> To: Gian.Paolo.Calzolari at esa.int > >> Cc: Shames, Peter M (312B); SLS-SLP Mailing List > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> G.P., > >> > >> We have learned through the lesson of IPoC that a 3 bit PID is too > >> small and restrictive, so that is why in USLP we defined the PID to > >> be bigger I.e., 5 bits also limited because the first 3 bits are used up by the > TFDZ construction rules. > >> I agree that the extended protocol ID field of 8 bits is too big so > >> using the first 4 bits for the PID extension would give us 9 total > >> bits or 512 combinations for PIDs. That would leave 4 bits of spares > thereafter. > >> I don't see any compelling reason to create a separate field just for COP. > >> > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b2) Protocol Identifier Within USLP Data Zone (5 bits, mandatory); > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.h > >> tml > >> .aslo can contain ipe_header values > >> c2) Spare (4 bits, optional); > >> d) Pointer Field (First Header Pointer or Last Valid Octet (16 bits, > optional) > >> ). > >> > >> Regards, > >> Greg > >> > >> From: "Gian.Paolo.Calzolari at esa.int" > >> > > >> Date: Wednesday, February 3, 2016 at 2:38 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Cc: "Shames, Peter M (312B)" > >> >, > >> SLS- SLP Mailing List >> slp at mailman.ccsds.org>> > >> Subject: Re: [Sls-slp] CCSDS definition of Protocol IDs > >> > >> Greg, > >> assuming that USLP will be able to carry 2**13 = 8192 > >> different upper layers protocols look to me as thinking big. > >> Though I like optimism I wonder whether this is appropriate. > >> > >> Indeed http://sanaregistry.org/r/protocol_id/protocol_id.html defines > >> the Protocol Identifier for Encapsulation Service over 3 bits with > >> Extended Protocol Identifier for Encapsulation Service over 4 bits > >> (i.e. a total of 7 bits but not really 2**7 = 128 different protocol > >> as the construction allows 16 +6 protocols as some values are > >> reserved (see > http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html ). > >> I there a good reason for thinking that USLP could carry 8192 > >> different while Encapsulation Packet is limited to 22? > >> > >> If not please consider the following alternative definition > >> (justified also by the current definition of the fields containing > >> either a protocol ID or a COP directive indication): > >> 4.1.4.2.1.2 The TFDF Header shall contain the following fields: > >> a) Transfer Frame Data Zone (TFDZ) Construction Rules (3 bits, > >> mandatory); > >> b1) COP usage (2 bits, mandatory); ---> see below > >> b2) Protocol Identifier Within USLP Data Zone (3 bits, mandatory);---> > same > >> ashttp://sanaregistry.org/r/protocol_id/protocol_id.html > >> c1) Protocol Identifier Extension Within USLP Data Zone (4 bits, > optional); ;- > >> --> same as > >> http://sanaregistry.org/r/extended_protocol_id/extended_protocol_id.html > >> c2) Spare (4 bits, optional); ;--> good for a link to IPoC????? > >> d) First Header Pointer or Last Valid Octet (16 bits, optional). > >> > >> > >> COP usage (2 bits, mandatory); > >> 00 = No directives > >> 01 = COP-1 directives are contained within the TFDZ. > >> 10 = COP-P directives are contained within the TFDZ > >> 11 = reserved > >> > >> Regards > >> > >> Gian Paolo > >> > >> > >> > >> From: "Kazz, Greg J (312B)" > >> > > >> To: "Shames, Peter M (312B)" > >> > > >> Cc: "sls-slp at mailman.ccsds.org" > >> slp at mailman.ccsds.org> > >> Date: 02/02/2016 19:48 > >> Subject: [Sls-slp] CCSDS definition of Protocol IDs > >> Sent by: sls-slp-bounces at mailman.ccsds.org >> bounces at mailman.ccsds.org> > >> ________________________________ > >> > >> > >> > >> Peter, > >> > >> USLP is planning on defining a Protocol Id (PID) field and an > >> Extended Protocol ID field in the Transfer Frame Data Field Header. > >> Encapsulation Service currently defines Protocol ID to be a 3 bit > >> field, followed by an optional Protocol Extension Field of 8 bits for a total of > 11 bits. > >> There is a SANA registry for PIDs under > >> http://sanaregistry.org/r/protocol_id/protocol_id.html > >> > >> IPoC also defines PIDs as well for the IPE header. See > >> http://sanaregistry.org/r/ipe_header/ipe_header.html > >> In this case, the smallest size IPE header is 8 bits, but it has a > >> multiple octet extension capability beyond 1 octet. > >> > >> USLP currently in draft form, has defined the PID to be 5 bits long, > >> followed by an optional Protocol Extension Field of 8 bits for a total of 13 > bits. > >> Below is an approach from Ed Greenberg, that shows that the > >> Encapsulation PIDs can indeed be a subset of the USLP PIDs. See email > message below. > >> > >> Question - What does CCSDS, from an organization point of view, > >> envision a need to define PIDs across all of CCSDS not just USLP or > >> Encap service ? Or is it appropriate for USLP to define the term, > >> Protocol ID and have it apply locally I.e., only to the USLP links ? > >> In the review of USLP, we will address questions like, "Is a 13 bit > >> PID name space sufficient for all agency needs ?" > >> > >> Your thoughts ? > >> > >> Thanks! > >> Greg > >> > >> From: "Greenberg, Edward (312B)" > >> > > > >> Date: Tuesday, February 2, 2016 at 9:53 AM > >> To: "Kazz, Greg J (313B)" > >> > > >> Subject: PIDs > >> > >> Encap uses 3 bits +8bits when 3bits=111 USLP uses 5 bits +8 bits when > >> 5 bits =11111 > >> > >> Thus if we assume that the PIP space for Encap in 5 bit form we get > >> 11xxx+xxxxxxxx > >> > >> > >> The only issue is that new PIDs for USLP that have their first 2 bits > >> as 00, 01 or > >> 10 don't map to > >> Encap_______________________________________________ > >> Sls-slp mailing list > >> Sls-slp at mailman.ccsds.org > >> http://mailman.ccsds.org/mailman/listinfo/sls-slp > >> > >> This message and any attachments are intended for the use of the > >> addressee or addressees only. > >> > >> The unauthorised disclosure, use, dissemination or copying (either in > >> whole or in part) of its > >> > >> content is not permitted. > >> > >> If you received this message in error, please notify the sender and > >> delete it from your system. > >> > >> Emails can be altered and their integrity cannot be guaranteed by the > sender. > >> > >> > >> > >> Please consider the environment before printing this email. > > > > > >_______________________________________________ > >Sls-slp mailing list > >Sls-slp at mailman.ccsds.org > >http://mailman.ccsds.org/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: From Gian.Paolo.Calzolari at esa.int Thu Feb 11 15:11:47 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Thu, 11 Feb 2016 16:11:47 +0100 Subject: [Sls-slp] [SLP] Some rewording for selected sections of Chapter 2 of the USLP draft Blue Book Message-ID: <23295_1455203510_56BCA4B6_23295_155_8_OF3E054434.EAD1A6F1-ONC1257F56.0052D013-C1257F56.00537A1B@esa.int> Dear Greg, can you please in the Agenda for the next USLP Telecon/Meeting the discussion of the the attached file containing Some rewording for selected sections of Chapter 2 of the USLP draft Blue Book? The comments included on the side try to explain the rational for the proposed rewording. I also think that two explicit questions shall be made to the SLP WG; i.e. 1) Shall USLP retain the TC Coding capability that a protocol data unit transferred can contain several frames? The fact that TC coding allows it does not exclude a possible limitation on the USLP side (e.g. SLE FSP explicitly forbids the option of including several TC frames in a CLTU). Note that I have no position on this topic, but we shall remeber that several frames in a CLTU do decrease performances. 2) Shall any reference to Proximity-1 coding be removed from the USLP Blue Book as long as there is no agreed adaptation for that blue book? Best 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Space Data Link Protocol_Jan_20_post_telecon1+codingReferences.pdf Type: application/octet-stream Size: 94676 bytes Desc: not available URL: From greg.j.kazz at jpl.nasa.gov Fri Feb 12 19:47:50 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Fri, 12 Feb 2016 19:47:50 +0000 Subject: [Sls-slp] Material to discuss during 3rd USLP Telecon Message-ID: Dear SLP WG, I will soon create a doodle poll for the 3rd USLP White Book telecon. The focus will be on Section 2 of the post telecon 2 white book as well as a trial balloon pitch for an additional type of Insert Zone service, called On-demand insert. You can find the latest version of the USLP white book post telecon 2 on the CWE under: http://tinyurl.com/jf9j6u3 It contains the date feb 9 and post telecon 2 in the word file name. Topic 1 (Section 2 review) is spearheaded by Gian Paolo whose comments you will find in the CWE under: http://tinyurl.com/jf9j6u3 At least two key questions need to be discussed by SLP WG concerning the review of Section 2. They are: 1) Shall USLP retain the TC Coding capability that a protocol data unit transferred can contain several frames? The fact that TC coding allows it does not exclude a possible limitation on the USLP side (e.g. SLE FSP explicitly forbids the option of including several TC frames in a CLTU). We shall remember that several frames in a CLTU does decrease performance. 2) Shall any reference to Proximity-1 coding be removed from the USLP Blue Book as long as there is no agreed adaptation for that blue book? Note: NASA has submitted an agenda item to the C&S WG chairman to describe changes to the CCSDS 211.2-B-2 (Prox-1 C&S Blue Book) including CWE project details to allow USLP transfer frames over the Proximity link. Topic 2 (On-demand Insert Service) is spearheaded by Ed Greenberg. The post telecon 2 white book contains trial sections describing and standardizing the two types of Insert Service. The concept is below: The concept of the two types of Insert Service follows: USLP provides two complementary types of Insert Service: a) Isochronous and b) On-demand. Only one Insert Service type is allowed on a Physical Channel at any given time. The Isochronous Insert Service provides transfer of private, fixed-length, octet-aligned service data units across a space link in a mode which efficiently utilizes the space link transmission resources at relatively low data rates. The service is unidirectional, periodic, and sequence-preserving. The service does not guarantee completeness, but may signal gaps in the sequence of service data units delivered to a receiving user. For a given service instance, only one user, identified with the Physical Channel Name of the Physical Channel, can use this service on a Physical Channel. Service data units from different users are not multiplexed together within one Physical Channel. The presence of the Insert Zone is signaled by Managed Parameters. The On-demand Insert Service provides the optional transfer of private, variable length, octet-aligned service data units across a space link in an episodic manner. The service is unidirectional, asynchronous, and non-sequence preserving. The Insert Zone length may vary between 1 and 255 octets and is specified in the first octet of the Insert Zone. The presence of the on-demand Insert Zone is signaled by the On-demand IZ flag in the TF header. Multiple users may use this on-demand Insert Service on a Master Channel, identified with the VCID of the frame which contains the On-demand IZ flag set to ‘1’. Best regards, Greg Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gian.Paolo.Calzolari at esa.int Mon Feb 15 15:43:22 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Mon, 15 Feb 2016 16:43:22 +0100 Subject: Not implemented in latest version of the USLP white book post telecon 2 : [Sls-slp] Material to discuss during 3rd USLP Telecon In-Reply-To: References: Message-ID: <14619_1455551006_56C1F21E_14619_877_1_OFF4FA1CE8.9F15138E-ONC1257F5A.004ED4FC-C1257F5A.00565E2A@esa.int> Greg, please note that the following comments were not implemented NOTES in 4.1.4.2.1.4 hide requirements. Is misleading (in fact some values are not protocol Id?s defined at http://sanaregistry.org/r/protocol_id/protocol_id.html ) and the first 3 notes are actually normative clauses. Agreed. Please convert/include the 3 notes to.into normative clause(s). Note 4 should actually become part of the clause from Note 3 to poiint to the (new) SANA registry. Moreover in telecon #2 "Greg Kazz and Ed Greenberg took the action to document how the Sending and Receiving side procedures (4.2 and 4.3) are affected if a fixed vs. a variable length transfer frame is used." and it would be nice if you could report about this at telecon #3. I think the list is going to be rather short.... Lat but not least, in the attached file you find a few remarks about the updated chapter 5 on Managed Parameters. It could be good discussing this at telecon #3 together with the remarks for "Not imported parameters" I sent within the file named USLP.ManagedParameterSources20160203.pdf Regards Gian Paolo From: "Kazz, Greg J (312B)" To: "SLS-SLP Mailing List" Date: 12/02/2016 20:48 Subject: [Sls-slp] Material to discuss during 3rd USLP Telecon Sent by: sls-slp-bounces at mailman.ccsds.org Dear SLP WG, I will soon create a doodle poll for the 3rd USLP White Book telecon. The focus will be on Section 2 of the post telecon 2 white book as well as a trial balloon pitch for an additional type of Insert Zone service, called On-demand insert. You can find the latest version of the USLP white book post telecon 2 on the CWE under: http://tinyurl.com/jf9j6u3 It contains the date feb 9 and post telecon 2 in the word file name. Topic 1 (Section 2 review) is spearheaded by Gian Paolo whose comments you will find in the CWE under: http://tinyurl.com/jf9j6u3 At least two key questions need to be discussed by SLP WG concerning the review of Section 2. They are: 1) Shall USLP retain the TC Coding capability that a protocol data unit transferred can contain several frames? The fact that TC coding allows it does not exclude a possible limitation on the USLP side (e.g. SLE FSP explicitly forbids the option of including several TC frames in a CLTU). We shall remember that several frames in a CLTU does decrease performance. 2) Shall any reference to Proximity-1 coding be removed from the USLP Blue Book as long as there is no agreed adaptation for that blue book? Note: NASA has submitted an agenda item to the C&S WG chairman to describe changes to the CCSDS 211.2-B-2 (Prox-1 C&S Blue Book) including CWE project details to allow USLP transfer frames over the Proximity link. Topic 2 (On-demand Insert Service) is spearheaded by Ed Greenberg. The post telecon 2 white book contains trial sections describing and standardizing the two types of Insert Service. The concept is below: The concept of the two types of Insert Service follows: USLP provides two complementary types of Insert Service: a) Isochronous and b) On-demand. Only one Insert Service type is allowed on a Physical Channel at any given time. The Isochronous Insert Service provides transfer of private, fixed-length, octet-aligned service data units across a space link in a mode which efficiently utilizes the space link transmission resources at relatively low data rates. The service is unidirectional, periodic, and sequence-preserving. The service does not guarantee completeness, but may signal gaps in the sequence of service data units delivered to a receiving user. For a given service instance, only one user, identified with the Physical Channel Name of the Physical Channel, can use this service on a Physical Channel. Service data units from different users are not multiplexed together within one Physical Channel. The presence of the Insert Zone is signaled by Managed Parameters. The On-demand Insert Service provides the optional transfer of private, variable length, octet-aligned service data units across a space link in an episodic manner. The service is unidirectional, asynchronous, and non-sequence preserving. The Insert Zone length may vary between 1 and 255 octets and is specified in the first octet of the Insert Zone. The presence of the on-demand Insert Zone is signaled by the On-demand IZ flag in the TF header. Multiple users may use this on-demand Insert Service on a Master Channel, identified with the VCID of the frame which contains the On-demand IZ flag set to ?1?. Best regards, Greg Chairman SLS-SLP WG _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/mailman/listinfo/sls-slp This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Space Data Link Protocol_Feb_9_post_telecon2-Ch5remarks.pdf Type: application/octet-stream Size: 76338 bytes Desc: not available URL: From Gian.Paolo.Calzolari at esa.int Wed Feb 17 10:30:12 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Wed, 17 Feb 2016 11:30:12 +0100 Subject: [Sls-slp] USLP_Issues_20160217.docx Message-ID: <5013_1455705015_56C44BB7_5013_947_1_OF2090BB5B.196F6940-ONC1257F5C.00397BDF-C1257F5C.0039B279@esa.int> Dear Greg, here is a revised version of the USLP issues. I think these short notes can be very effective in pointing out items to be discussed and the eventual WG agreement on each issue. Regards Gian Paolo PS The file is also on the CWE under: http://tinyurl.com/jf9j6u3 This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP_Issues_20160217.docx Type: application/octet-stream Size: 40102 bytes Desc: not available URL: From Tomaso.deCola at dlr.de Wed Feb 17 11:56:12 2016 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Wed, 17 Feb 2016 11:56:12 +0000 Subject: [Sls-slp] RE: Material to discuss during 3rd USLP Telecon In-Reply-To: References: Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175C93B8@DLREXMBX01.intra.dlr.de> Greg, Concerning next telco, could you please organise a webex session, so that it will be easier to share documents and run discussions? Thanks, Tomaso ------------------------ Deutsches Zentrum für Luft- und Raumfahrt (DLR) German Aerospace Center Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany Tomaso de Cola, Ph.D. Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 | tomaso.decola at dlr.de http://www.dlr.de/kn/institut/abteilungen/san From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Friday, February 12, 2016 20:48 To: SLS-SLP Mailing List Subject: [Sls-slp] Material to discuss during 3rd USLP Telecon Dear SLP WG, I will soon create a doodle poll for the 3rd USLP White Book telecon. The focus will be on Section 2 of the post telecon 2 white book as well as a trial balloon pitch for an additional type of Insert Zone service, called On-demand insert. You can find the latest version of the USLP white book post telecon 2 on the CWE under: http://tinyurl.com/jf9j6u3 It contains the date feb 9 and post telecon 2 in the word file name. Topic 1 (Section 2 review) is spearheaded by Gian Paolo whose comments you will find in the CWE under: http://tinyurl.com/jf9j6u3 At least two key questions need to be discussed by SLP WG concerning the review of Section 2. They are: 1) Shall USLP retain the TC Coding capability that a protocol data unit transferred can contain several frames? The fact that TC coding allows it does not exclude a possible limitation on the USLP side (e.g. SLE FSP explicitly forbids the option of including several TC frames in a CLTU). We shall remember that several frames in a CLTU does decrease performance. 2) Shall any reference to Proximity-1 coding be removed from the USLP Blue Book as long as there is no agreed adaptation for that blue book? Note: NASA has submitted an agenda item to the C&S WG chairman to describe changes to the CCSDS 211.2-B-2 (Prox-1 C&S Blue Book) including CWE project details to allow USLP transfer frames over the Proximity link. Topic 2 (On-demand Insert Service) is spearheaded by Ed Greenberg. The post telecon 2 white book contains trial sections describing and standardizing the two types of Insert Service. The concept is below: The concept of the two types of Insert Service follows: USLP provides two complementary types of Insert Service: a) Isochronous and b) On-demand. Only one Insert Service type is allowed on a Physical Channel at any given time. The Isochronous Insert Service provides transfer of private, fixed-length, octet-aligned service data units across a space link in a mode which efficiently utilizes the space link transmission resources at relatively low data rates. The service is unidirectional, periodic, and sequence-preserving. The service does not guarantee completeness, but may signal gaps in the sequence of service data units delivered to a receiving user. For a given service instance, only one user, identified with the Physical Channel Name of the Physical Channel, can use this service on a Physical Channel. Service data units from different users are not multiplexed together within one Physical Channel. The presence of the Insert Zone is signaled by Managed Parameters. The On-demand Insert Service provides the optional transfer of private, variable length, octet-aligned service data units across a space link in an episodic manner. The service is unidirectional, asynchronous, and non-sequence preserving. The Insert Zone length may vary between 1 and 255 octets and is specified in the first octet of the Insert Zone. The presence of the on-demand Insert Zone is signaled by the On-demand IZ flag in the TF header. Multiple users may use this on-demand Insert Service on a Master Channel, identified with the VCID of the frame which contains the On-demand IZ flag set to '1'. Best regards, Greg Chairman SLS-SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Thu Feb 25 19:59:37 2016 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Thu, 25 Feb 2016 19:59:37 +0000 Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes Message-ID: The attached describe the processes required to support within both the USLP Protocol sublayer and the C&S Sublayer. We would appreciate your review. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sending and receiving ends 6.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 184519 bytes Desc: sending and receiving ends 6.docx URL: From Marco.Rovatti at esa.int Fri Feb 26 13:05:57 2016 From: Marco.Rovatti at esa.int (Marco.Rovatti at esa.int) Date: Fri, 26 Feb 2016 14:05:57 +0100 Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes In-Reply-To: References: Message-ID: <32315_1456491959_56D04DB7_32315_8_1_OFD97C1AD5.12588FC9-ONC1257F65.00475855-C1257F65.0047F507@esa.int> Dear Greg and Ed, thank you for the submitted doc. Unfortunately it was not possible for many of us to review it on time for today telecon. I therefore propose to postpone the discussion on this section either to the next telecon or to the Spring meeting whichever suit you best. Best Regards Marco Rovatti _________________________________ Computer and Data Systems Engineer European Space Agency - ESTEC Tel. +31715655641 From: sls-slp-request at mailman.ccsds.org To: sls-slp at mailman.ccsds.org Date: 25/02/2016 21:02 Subject: Sls-slp Digest, Vol 123, Issue 20 Sent by: sls-slp-bounces at mailman.ccsds.org Send Sls-slp mailing list submissions to sls-slp at mailman.ccsds.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ccsds.org/mailman/listinfo/sls-slp or, via email, send a message with subject or body 'help' to sls-slp-request at mailman.ccsds.org You can reach the person managing the list at sls-slp-owner at mailman.ccsds.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sls-slp digest..." Today's Topics: 1. Protocol ans C&S procedures for all USLP Operational Modes (Greenberg, Edward (312B)) ----- Message from "Greenberg, Edward (312B)" on Thu, 25 Feb 2016 19:59:37 +0000 ----- To: "Kazz, Greg J (312B)" , "sls-slp at mailman.ccsds.org" Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes The attached describe the processes required to support within both the USLP Protocol sublayer and the C&S Sublayer. We would appreciate your review. [attachment "sending and receiving ends 6.docx" deleted by Marco Rovatti/estec/ESA] _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From Gian.Paolo.Calzolari at esa.int Fri Feb 26 17:14:20 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Fri, 26 Feb 2016 18:14:20 +0100 Subject: [Sls-slp] [SLP] USLP procedures defined in Chapter 4 impacted by TC Coding book actually used Message-ID: <4647_1456506864_56D087F0_4647_143_2_OFEB95FB01.CDDA21BC-ONC1257F65.005E5CFA-C1257F65.005EB227@esa.int> Greg, I tried to put here in a couple of slides what we discussed today about theUSLP procedures defined in Chapter 4 impacted by TC Coding book actually used. Now that the WG agree (TBC in Cleveland) not to use the TC feature allowing multiple frames in a CLTU, it looks as the impact is limited to OID Frames and to CRC insertion. Comments and a better analisys is of course welcome. Ciao Gian Paolo PS This file is also in CWE This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLPimpactedByCodingBook(fromUSLPvsCoding.AreaInput.v1)20160226.pdf Type: application/octet-stream Size: 225525 bytes Desc: not available URL: From Gian.Paolo.Calzolari at esa.int Fri Feb 26 17:30:21 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Fri, 26 Feb 2016 18:30:21 +0100 Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes In-Reply-To: References: Message-ID: <19739_1456507823_56D08BAF_19739_64_1_OF9DD555A3.38C0ED30-ONC1257F65.004C7F46-C1257F65.006029A5@esa.int> Ed, could you please make clear what is the expected destination of the text in the document you sent? If you think this document is needed, as you are touching more that one WG expertise, for appropriate discussion it looks appropriate splitting the document in two part and then submitting the first part to the SLP WG (i.e. first 4 pages) and the second part to the C&S WG (i.e. the last 5 pages including the C&S PROCEDURES FOR EACH SPACE LINK OPERATIONAL MODE). Regards Gian Paolo From: "Greenberg, Edward (312B)" To: "Kazz, Greg J (312B)" , "sls-slp at mailman.ccsds.org" Date: 25/02/2016 21:01 Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes Sent by: sls-slp-bounces at mailman.ccsds.org The attached describe the processes required to support within both the USLP Protocol sublayer and the C&S Sublayer. We would appreciate your review. [attachment "sending and receiving ends 6.docx" deleted by Gian Paolo Calzolari/esoc/ESA] _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From greg.j.kazz at jpl.nasa.gov Fri Feb 26 17:39:00 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Fri, 26 Feb 2016 17:39:00 +0000 Subject: [Sls-slp] Re: Protocol ans C&S procedures for all USLP Operational Modes In-Reply-To: <32315_1456491959_56D04DB7_32315_8_1_OFD97C1AD5.12588FC9-ONC1257F65.00475855-C1257F65.0047F507@esa.int> References: <32315_1456491959_56D04DB7_32315_8_1_OFD97C1AD5.12588FC9-ONC1257F65.00475855-C1257F65.0047F507@esa.int> Message-ID: Dear Marco, I agree with you. The intent was not to review it during Telecon #3 today. We received clarification from Gian Paolo today on how to proceed with it. Hope to hear from you at the next telecon which I plan to have before the Spring meeting in Cleveland. Best regards, Greg From: "Marco.Rovatti at esa.int" > Date: Friday, February 26, 2016 at 5:05 AM To: "Kazz, Greg J (313B)" >, "Greenberg, Edward (312B)" > Cc: "sls-slp at mailman.ccsds.org" > Subject: Protocol ans C&S procedures for all USLP Operational Modes Dear Greg and Ed, thank you for the submitted doc. Unfortunately it was not possible for many of us to review it on time for today telecon. I therefore propose to postpone the discussion on this section either to the next telecon or to the Spring meeting whichever suit you best. Best Regards Marco Rovatti _________________________________ Computer and Data Systems Engineer European Space Agency - ESTEC Tel. +31715655641 From: sls-slp-request at mailman.ccsds.org To: sls-slp at mailman.ccsds.org Date: 25/02/2016 21:02 Subject: Sls-slp Digest, Vol 123, Issue 20 Sent by: sls-slp-bounces at mailman.ccsds.org ________________________________ Send Sls-slp mailing list submissions to sls-slp at mailman.ccsds.org To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ccsds.org/mailman/listinfo/sls-slp or, via email, send a message with subject or body 'help' to sls-slp-request at mailman.ccsds.org You can reach the person managing the list at sls-slp-owner at mailman.ccsds.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Sls-slp digest..." Today's Topics: 1. Protocol ans C&S procedures for all USLP Operational Modes (Greenberg, Edward (312B)) ----- Message from "Greenberg, Edward (312B)" > on Thu, 25 Feb 2016 19:59:37 +0000 ----- To: "Kazz, Greg J (312B)" >, "sls-slp at mailman.ccsds.org" > Subject: [Sls-slp] Protocol ans C&S procedures for all USLP Operational Modes The attached describe the processes required to support within both the USLP Protocol sublayer and the C&S Sublayer. We would appreciate your review. [attachment "sending and receiving ends 6.docx" deleted by Marco Rovatti/estec/ESA] _______________________________________________ Sls-slp mailing list Sls-slp at mailman.ccsds.org http://mailman.ccsds.org/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: From greg.j.kazz at jpl.nasa.gov Fri Feb 26 22:27:34 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Fri, 26 Feb 2016 22:27:34 +0000 Subject: [Sls-slp] Results of USLP Telecon #3 Feb 26 2016 Message-ID: Dear SLP WG members, Attached please find and also in the URL below the minutes of Telecon #3 held today on the USLP White Book. We covered Section 2 Overview and also had a discussion on the proposed “On-demand” Insert Zone. As a result of that discussion, I am asking all agency representatives to poll their member agencies to generate a position on the “On-demand” insert zone. Please come prepared to discuss your agency’s position on whether or not the agency finds it worthwhile for the USLP data link protocol to include this service. Note that the Isochronous Insert Zone service identical to the one available in the AOS Space Data Link Protocol is still available through USLP. However, only one Insert Zone Service can occur over any USLP link. The updated USLP White book with the date of Feb 26 in the file name as well as these meeting minutes and the updated issues document is now all on the SLP CWE area under 2016 Cleveland meeting. Please see: http://tinyurl.com/jf9j6u3 Best regards, Greg Kazz CCSDS SLS-SLP WG Chairman -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: USLP Space Data Link Protocol_Feb_26_post_telecon3.docx Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document Size: 1253062 bytes Desc: USLP Space Data Link Protocol_Feb_26_post_telecon3.docx URL: From Gian.Paolo.Calzolari at esa.int Mon Feb 29 14:09:51 2016 From: Gian.Paolo.Calzolari at esa.int (Gian.Paolo.Calzolari at esa.int) Date: Mon, 29 Feb 2016 15:09:51 +0100 Subject: [Sls-slp] Comments to USLP_Issues_20160226 Message-ID: <13394_1456754992_56D45130_13394_57_21_OF9EBE1C23.88FCD41D-ONC1257F68.004BFA33-C1257F68.004DCE43@esa.int> Dear Greg, can you please check and fix the USLP_Issues_20160226 as per comments below. 1) The summary says Issue 2 Closed @ telecon #3 but no comment has been added to Issue 2 in the main body of the document and nothing is mentioned in Telcon #3 MoMs. Please clarify accordingly. 2) The summary says Issue 11 Closed @ telecon #3 but no comment has been added to Issue 2 in the main body of the document and nothing is mentioned in Telcon #3 MoMs. I think the conclusion is that the construction of the USLP frame is constrained by the choice of channel coding book as follows: a) references 3, 4 and 5 (TM, SCCC, DVB-S2) require fixed length frame and OID frames to be generated when no "valid" frame is available. b) some coding schemes of references 3, 4 and 5 (TM, SCCC, DVB-S2) require CRC-16 mandatorily present c) references 6 and 7 (TC, Proximity-1) allow variable length frame and OID frames shall not be generated. Moreover when reference 5 (TC) is used, the coding layer would accept several frames in a protocol data but is but it has been agreed that USLP will not allow this feature (see issue 15). Issue 11 description should be updated accordingly 3) Issue 12 should report also that some coding schemes of references 3, 4 and 5 (TM, SCCC, DVB-S2) require CRC-16 mandatorily present 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: From greg.j.kazz at jpl.nasa.gov Mon Feb 29 18:52:59 2016 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Mon, 29 Feb 2016 18:52:59 +0000 Subject: [Sls-slp] Telecon #3 Meeting Minutes and Issue File Update Message-ID: Dear SLS WG members, Please find the Meeting minutes to Telecon #3 now on the CWE along with an update of the Issues file for USLP at the URL: http://tinyurl.com/jf9j6u3 The meeting minutes have the filename “USLP Telecon 3 minutes “ and have been loaded to the CWE today. The updated Issues file is new and has the filename “ USLP_Issues_20160229" The changes made to the Issues file are: 1) The summary said that Issue 2 Closed @ telecon #3 but that was an error. It remains open. 2) The summary said Issue 11 Closed @ telecon #3 which is true. The following summary was added in the text portion of this file to summarize the conclusion: a) references 3, 4 and 5 (TM, SCCC, DVB-S2) require fixed length frame and OID frames to be generated when no "valid" frame is available. b) some coding schemes of references 3, 4 and 5 (TM, SCCC, DVB-S2) require CRC-16 mandatorily present c) references 6 and 7 (TC, Proximity-1) allow variable length frame and OID frames shall not be generated. Moreover when reference 5 (TC) is used, the coding layer would accept several frames in a protocol data but is but it has been agreed that USLP will not allow this feature (see issue 15). 3) Issue 12 text description was supplemented to say that some coding schemes of references 3, 4 and 5 (TM, SCCC, DVB-S2) require CRC-16 to be present. Best regards, Greg Kazz Chairman CCSDS SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: