From greg.j.kazz at jpl.nasa.gov Wed Oct 14 16:31:38 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 14 Oct 2015 16:31:38 +0000 Subject: [Sls-slp] Re: USLP Header options (brainstorming again) In-Reply-To: <3634_1444818804_561E2F74_3634_101_1_OFC023301B.5A17A540-ONC1257EDE.0039F274-C1257EDE.0039FAF8@esa.int> References: <3634_1444818804_561E2F74_3634_101_1_OFC023301B.5A17A540-ONC1257EDE.0039F274-C1257EDE.0039FAF8@esa.int> Message-ID: Hi G.P., I have my opinion of your suggestion but I don’t want to state it here, so others can think about it. Please SLP WG, please share your view with all, if you have one. Thanks! Greg Kazz Chairman CCSDS SLP WG From: "Gian.Paolo.Calzolari at esa.int" > Date: Wednesday, October 14, 2015 at 3:33 AM To: "Kazz, Greg J (313B)" > Subject: Fw: USLP Header options (brainstorming again) Any meditation about this? ----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 14/10/2015 12:32 ----- From: Gian Paolo Calzolari/esoc/ESA To: "Kazz, Greg J (313B)" >, Date: 21/09/2015 10:24 Subject: Re: USLP Header options (brainstorming again) ________________________________ Greg, after the brainstorming below I thought that an effort shall be made to keep contiguous the fields for version + SCID + VCID . Less important may be the MAP ID but worth discussing. If USLP would be allowed to use two frame version there could be a version with 12 bits SCID and a version with 20 bits SCID (actaullay 1 bit less if we use 5 bits for frame version; i.e. 4 bit + subversion). This is brainstorming again but it may be worthdiscussing it widely. Regards Gian Paolo From: Gian Paolo Calzolari/esoc/ESA To: "Kazz, Greg J (313B)" >, Date: 10/09/2015 10:19 Subject: USLP Header options ________________________________ Greg, can you consider an option like this below for the first octets of the USLP header? Clearly next fields would need to be rearranged. Just brainstorming...... Actually Transfer Frame sub Version Number bit 2 could be spared (==> short SCID = 11 bits, long = 19 bits) if two values are possible within the first 4 bits. Ciao Gian Paolo • Transfer Frame Version Number (4 bits, mandatory); • Transfer Frame sub Version Number bit 1 (1 bit, mandatory); frame length field --> 0= absent, 1 = present • Transfer Frame sub Version Number bit 2 (1 bit, mandatory); SCID length --> 0= 10 bits , 1 = 18 bits • Two MSbits of Spacecraft ID (SCID) (2 bits, mandatory); • Spacecraft ID (SCID)( 8 or 16 bits, mandatory); It depends on Transfer Frame sub Version Number bit 2 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 Oct 14 19:33:51 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Wed, 14 Oct 2015 19:33:51 +0000 Subject: [Sls-slp] Updated version of USLP Draft White Book Oct 14 2015 on CWE now Message-ID: Dear SLP WG I have updated the USLP draft White book to include most of the comments made to the last revision. Please find this update in two forms on the CWE site below. http://tinyurl.com/nuu9xt8 One file is the clean copy without Word revision feature – it includes the word “clean” and the date of Oct 14 in the file name. The other file with the Oct 14 date in the file name is the one containing all the redline changes using Word revision feature. Unless any new updates are made consider this Oct 14 version to be the one SLP WG will review in Darmstadt during the Fall CCSDS meeting on Monday Nov. 9. Thanks to all the contributors! Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Mon Oct 19 21:22:50 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Mon, 19 Oct 2015 21:22:50 +0000 Subject: [Sls-slp] Update to USLP White Book (protocol) Message-ID: Dear SLP members, Please find the lastest version of the USLP White book on the CWE under http://tinyurl.com/nuu9xt8 The new file name contains the word “Cleaner[1]”. It contains a slight update from the last version as follows: This version removes implemented comments . It replaces the version dated 14 October 2015. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Oct 22 20:25:29 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Thu, 22 Oct 2015 20:25:29 +0000 Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Message-ID: Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From kscott at mitre.org Fri Oct 23 16:18:28 2015 From: kscott at mitre.org (Scott, Keith L.) Date: Fri, 23 Oct 2015 16:18:28 +0000 Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Message-ID: <2BD744FF-859E-48C5-B317-655C953CBC0C@mitre.org> Some comments on the draft USLP book: Figure 2-1: Relationship with OSI Layers * The OSI stack has a Network Layer between Data Link and Transport, and I would argue that the CCSDS Layers do as well (that being either IP or BP). * I’d also like to make an argument for showing up to the application layer, since I think that a lot of CCSDS’ angst comes from not actually thinking that we HAVE applications. General: What the heck is the tunneling service? * If this really is intended to be tunneling frames across multiple links, we probably need to have a chat between SLP and DTN. We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. The receiving application would then extract the frames and instructions and emit them towards a destination. The motivation for this is to be able to send link-layer commands to a spacecraft with which you (as the ground, e.g.) do not have direct link-layer connectivity. A similar setup would work in the reverse direction, tunneling frames back from a spacecraft. We (in DTN) have always envisioned these as ‘emergency’ applications, since I’m not keen on what would be essentially extending CSTS across multiple space links! * The point is, if you really mean to tunnel across multiple links, it might be better to get the tunnel service from the network. * Didn’t seem to me that the description in the book was complete? 4.1.5.1.6 didn’t seem complete, but maybe it’s a nascent idea? SCIDs in General * To Gian Paolo’s comment about putting the SCID as early as possible in the frame: does putting the SCID early do any good unless you also have the Source/Destination indicator bit? * Not having the ability to put BOTH a source and destination address in the frame means that * When I receive transmissions to ME (Source/Destination bit indicates destination SCID in frame), I don’t know where they came from. Sure, this information may be implied, but what if I’m receiving from someone and there could be multiple senders (I’m thinking multiple rovers hearing from orbiters on Mars, or a similar situation on the Moon)? * Would the ability to include both source and destination addresses allow us to simplify the Mars hailing procedures? * This pretty much ensures that it would be really hard to use USLP for anything involving dynamic link discovery (I’m thinking mostly human spaceflight stuff), since dynamic discovery methods generally need both a broadcast address (which I suppose we could define) and the ability to know who transmitted. This might not be a problem — anything dynamic might be the realm of something that looks a lot more like an adaptation of a terrestrial data link protocol. 3.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is this heading title a misnomer? It seems like you’re mainly describing the TFDF Service Data Unit, which might CONTAIN a TFDF Tunneling Data Unit (?) 3.5 TFDF Tunneling Service * Same question here. The text seems to deal much more with a TFDF SDU than anything to do with tunneling. 6.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is Section 6 where section 3 went? Seems like section 6 (Annex) is a repeat of Section 3… TFDF Header Always Present? * Is the TFDF header always present whenever the length of the TFDF_SDU > 0? ==== —keith Dr. Keith Scott Office: +1.703.983.6547 Chief Engineer, J86A Fax: +1.703.983.7142 Communications Network Engineering & Analysis Email: kscott at mitre.org The MITRE Corporation M/S H300 7515 Colshire Drive McLean, VA 22102 Area Director, CCSDS Space Internetworking Services MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from http://www.mitre.org/tech/mii/pki/ [cid:62DF199A-3B64-4F9A-AA4D-FDB0DA4D46DC] From: > on behalf of Greg Kazz > Date: Thursday, October 22, 2015 at 4:25 PM To: "sls-slp at mailman.ccsds.org" > Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png Type: image/png Size: 2755 bytes Desc: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png URL: From peter.m.shames at jpl.nasa.gov Fri Oct 23 17:08:25 2015 From: peter.m.shames at jpl.nasa.gov (Shames, Peter M (312B)) Date: Fri, 23 Oct 2015 17:08:25 +0000 Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: <2BD744FF-859E-48C5-B317-655C953CBC0C@mitre.org> References: <2BD744FF-859E-48C5-B317-655C953CBC0C@mitre.org> Message-ID: Yikes!! I agree that there needs to be an OSI stack that shows a network / transport layer, but I do not think that every link layer doc needs to show this. All of the ABA configurations operate without a network / transport layer and will continue to do so. The SSI configs, however, do have such a network / transport layer. And note that the SCCS-ARD and the SLS OSLP both show how all of this stuff is intended to work together. We do not need to invent something new in this case, we need to finish what we started. I do agree that there is some “CCSDS angst” having to do with the existing application layer standards, like CFDP and AMS, and the relationship to other application layer standards like MOIMS apps and SOIS apps. That is a key subject on the current “CCSDS Reference Architecture” discussions that are really focussed upon MOIMS & SOIS and how they use underlying communications / transport services, including SLS, SIS and CSS. The position that has been agreed to date in the CESG and in the reference architetcure discussions is that MOIMS & SOIS rely upon these underlying layers. Having said that there are more than a few murky application layer corners where details will need to be worked out. My “Yikes” comment was directly prompted by this statement: We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. It will probably not come as a surprise to anyone if I point out that this is a total “layer violation”. I know you SIS guys just love to tunnel DTN over IP, so tunneling seems natural, but in this case I not only think this is a really bad idea, but that it violates what has been agreed to in IOAG and CCSDS and what has been documented in the SCCS-ARD. So think of this as the “layering police” blowing a whistle on this one. What has been agreed and documents, in no uncertain terms, is that DTN (preferentially) and IP (where feasible) would be used as the network / transport service for all SSI deployments. At the end nodes, and for emergency support, we defined a “Last Hop” and “First Hop” application layer service that would, based on meta-data instructions, accept data delivered over the forward path and squirt it out at link layer. It does the reverse in the return direction and also is to handle open loop and radiometric data. This is “tunneling” of a sort, but it is what has been defined and agreed to. These “last hop” and “first hop” services are documented in the IOAG SISG study report and in the SCCS-ARD/ADD. May I suggest that if SIS wants to develop an application layer tunneling service (that uses, bye the bye, CFDP and DTN) that you focus upon carefully defining these first hop and last hop services. You will find the architecture, services, and protocol stacks carefully documented in SCCS-ADD, CCSDS 901.0-G-1, in Sec 4.3.2, 4.4, and particularly in 6.5.3 and in the SCCS-ARD, CCSDS 901.1-M-1, in Sec 4.3.4 and 6.2.4. As for USLP and link layer multiplexing, far as I understand what USLP is trying to do it is to provide link layer “trunk” multiplexing. This is to multiplex several streams of link layer data, over a single hop, which would typically be between a single ground station and some sort of layer 2 space relay asset. The TDRS fleet is an example of this now and it works in that way. The new optical data link discussions also include such trunking for exactly the same sorts of relay spacecraft deployments. These data links may well carry SIS DTN (or IP) traffic, and it is in discusison as to whether or not these relay assets are also layer 3 routing nodes and not just layer 2 switching nodes. I personally think that developing layer 3 routing nodes makes a whole lot of sense if we are talking about routing nodes around distant planets, like Mars. As a final note, just as I recommend that you SIS guys should stay away from link layer tunneling, that I would say to the SLS guys that they should stick to services that make sense in their layer, which are data links over a single hop, and that when routing services are required that SIS services should be invoked. So, can we stick to what we have agreed and get the SIS guys to define these last hop & first hop services and not some new, “uncooked” link layer tunneling scheme? Thanks, Peter From: > on behalf of Keith Scott > Date: Friday, October 23, 2015 at 9:18 AM To: Greg Kazz >, "sls-slp at mailman.ccsds.org" > Cc: "sis-dtn-owner at mailman.ccsds.org" > Subject: Re: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Some comments on the draft USLP book: Figure 2-1: Relationship with OSI Layers * The OSI stack has a Network Layer between Data Link and Transport, and I would argue that the CCSDS Layers do as well (that being either IP or BP). * I’d also like to make an argument for showing up to the application layer, since I think that a lot of CCSDS’ angst comes from not actually thinking that we HAVE applications. General: What the heck is the tunneling service? * If this really is intended to be tunneling frames across multiple links, we probably need to have a chat between SLP and DTN. We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. The receiving application would then extract the frames and instructions and emit them towards a destination. The motivation for this is to be able to send link-layer commands to a spacecraft with which you (as the ground, e.g.) do not have direct link-layer connectivity. A similar setup would work in the reverse direction, tunneling frames back from a spacecraft. We (in DTN) have always envisioned these as ‘emergency’ applications, since I’m not keen on what would be essentially extending CSTS across multiple space links! * The point is, if you really mean to tunnel across multiple links, it might be better to get the tunnel service from the network. * Didn’t seem to me that the description in the book was complete? 4.1.5.1.6 didn’t seem complete, but maybe it’s a nascent idea? SCIDs in General * To Gian Paolo’s comment about putting the SCID as early as possible in the frame: does putting the SCID early do any good unless you also have the Source/Destination indicator bit? * Not having the ability to put BOTH a source and destination address in the frame means that * When I receive transmissions to ME (Source/Destination bit indicates destination SCID in frame), I don’t know where they came from. Sure, this information may be implied, but what if I’m receiving from someone and there could be multiple senders (I’m thinking multiple rovers hearing from orbiters on Mars, or a similar situation on the Moon)? * Would the ability to include both source and destination addresses allow us to simplify the Mars hailing procedures? * This pretty much ensures that it would be really hard to use USLP for anything involving dynamic link discovery (I’m thinking mostly human spaceflight stuff), since dynamic discovery methods generally need both a broadcast address (which I suppose we could define) and the ability to know who transmitted. This might not be a problem — anything dynamic might be the realm of something that looks a lot more like an adaptation of a terrestrial data link protocol. 3.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is this heading title a misnomer? It seems like you’re mainly describing the TFDF Service Data Unit, which might CONTAIN a TFDF Tunneling Data Unit (?) 3.5 TFDF Tunneling Service * Same question here. The text seems to deal much more with a TFDF SDU than anything to do with tunneling. 6.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is Section 6 where section 3 went? Seems like section 6 (Annex) is a repeat of Section 3… TFDF Header Always Present? * Is the TFDF header always present whenever the length of the TFDF_SDU > 0? ==== —keith Dr. Keith Scott Office: +1.703.983.6547 Chief Engineer, J86A Fax: +1.703.983.7142 Communications Network Engineering & AnalysisEmail: kscott at mitre.org The MITRE Corporation M/S H300 7515 Colshire Drive McLean, VA 22102 Area Director, CCSDS Space Internetworking Services MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from http://www.mitre.org/tech/mii/pki/ [cid:62DF199A-3B64-4F9A-AA4D-FDB0DA4D46DC] From: > on behalf of Greg Kazz > Date: Thursday, October 22, 2015 at 4:25 PM To: "sls-slp at mailman.ccsds.org" > Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png Type: image/png Size: 2755 bytes Desc: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png URL: From kscott at mitre.org Fri Oct 23 17:41:38 2015 From: kscott at mitre.org (Scott, Keith L.) Date: Fri, 23 Oct 2015 17:41:38 +0000 Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: References: <2BD744FF-859E-48C5-B317-655C953CBC0C@mitre.org> Message-ID: Peter, What I was trying to describe WAS the first hop / last hop service — did I fail in that regard? It’s just that I think of the ‘service’ as an ‘application’ that uses the underlying services of “RF Xmit / Recv” and “File | Bundle | whatever transport” rather than to try to define it as a service OF (built into) the BP layer. And I don’t think it’s a layer violation; taking the ‘forward’ (emergency commanding) service, it’s two applications, one at the ground and one on the penultimate spacecraft. The ground application receives a set of instructions (from a human, via some sort of interface), including the network-layer address of the penultimate spacecraft, information about what / how / when / whatever else (I said we hand’t entirely thought this through yet) to emit towards the (well-defined BP service ID — pronounced ‘port’) on the target spacecraft, and ships the info (probably in a bundle / set of bundles — I really don’t think this is CFDP). The receiving application on the penultimate spacecraft does what it’s told, which might result in handing a bunch of link-layer frames (either that it received in toto from the sending application, or that it somehow generated from information provided by the sending application — I’m thinking the former is simpler) towards the target. To define this service as part of BP would involve building all that (what I think of as application-layer) stuff into BP itself, which doesn’t seem like the right thing to do. And, keeping it separate keeps it modular. If I have a really teeeny spacecraft that can’t host the penultimate spacecraft last-hop/first-hop app then, well, you can’t do that there. I do think the approach I described is in the spirit of the SISG reports, and I think it’s cleaner overall. As I said before, I can sort of see the utility of such an application for ‘special’ situations, but I really do not want anyone trying to tunnel an actual space link [ANY, whether it’s to the ultimate spacecraft or anywhere else] over a possibly delayed / intermittently-connected network. That’s what scared me about how I read the USLP language (which I’m now thinking I didn’t fully understand — the tunneling bit anyway). So the tunneling language in the USLP document is trying to get at equivalent functionality to an Ethernet VLAN? What threw me was that it explicitly said ‘over a network’ which I interpreted as meaning multi-hop. I’ll go think about what I think about VLANs in space and get back to you on that. —keith From: Peter Shames > Date: Friday, October 23, 2015 at 1:08 PM To: "Scott, Keith L." >, Greg Kazz >, "sls-slp at mailman.ccsds.org" > Cc: "sis-dtn-owner at mailman.ccsds.org" > Subject: Re: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Yikes!! I agree that there needs to be an OSI stack that shows a network / transport layer, but I do not think that every link layer doc needs to show this. All of the ABA configurations operate without a network / transport layer and will continue to do so. The SSI configs, however, do have such a network / transport layer. And note that the SCCS-ARD and the SLS OSLP both show how all of this stuff is intended to work together. We do not need to invent something new in this case, we need to finish what we started. I do agree that there is some “CCSDS angst” having to do with the existing application layer standards, like CFDP and AMS, and the relationship to other application layer standards like MOIMS apps and SOIS apps. That is a key subject on the current “CCSDS Reference Architecture” discussions that are really focussed upon MOIMS & SOIS and how they use underlying communications / transport services, including SLS, SIS and CSS. The position that has been agreed to date in the CESG and in the reference architetcure discussions is that MOIMS & SOIS rely upon these underlying layers. Having said that there are more than a few murky application layer corners where details will need to be worked out. My “Yikes” comment was directly prompted by this statement: We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. It will probably not come as a surprise to anyone if I point out that this is a total “layer violation”. I know you SIS guys just love to tunnel DTN over IP, so tunneling seems natural, but in this case I not only think this is a really bad idea, but that it violates what has been agreed to in IOAG and CCSDS and what has been documented in the SCCS-ARD. So think of this as the “layering police” blowing a whistle on this one. What has been agreed and documents, in no uncertain terms, is that DTN (preferentially) and IP (where feasible) would be used as the network / transport service for all SSI deployments. At the end nodes, and for emergency support, we defined a “Last Hop” and “First Hop” application layer service that would, based on meta-data instructions, accept data delivered over the forward path and squirt it out at link layer. It does the reverse in the return direction and also is to handle open loop and radiometric data. This is “tunneling” of a sort, but it is what has been defined and agreed to. These “last hop” and “first hop” services are documented in the IOAG SISG study report and in the SCCS-ARD/ADD. May I suggest that if SIS wants to develop an application layer tunneling service (that uses, bye the bye, CFDP and DTN) that you focus upon carefully defining these first hop and last hop services. You will find the architecture, services, and protocol stacks carefully documented in SCCS-ADD, CCSDS 901.0-G-1, in Sec 4.3.2, 4.4, and particularly in 6.5.3 and in the SCCS-ARD, CCSDS 901.1-M-1, in Sec 4.3.4 and 6.2.4. As for USLP and link layer multiplexing, far as I understand what USLP is trying to do it is to provide link layer “trunk” multiplexing. This is to multiplex several streams of link layer data, over a single hop, which would typically be between a single ground station and some sort of layer 2 space relay asset. The TDRS fleet is an example of this now and it works in that way. The new optical data link discussions also include such trunking for exactly the same sorts of relay spacecraft deployments. These data links may well carry SIS DTN (or IP) traffic, and it is in discusison as to whether or not these relay assets are also layer 3 routing nodes and not just layer 2 switching nodes. I personally think that developing layer 3 routing nodes makes a whole lot of sense if we are talking about routing nodes around distant planets, like Mars. As a final note, just as I recommend that you SIS guys should stay away from link layer tunneling, that I would say to the SLS guys that they should stick to services that make sense in their layer, which are data links over a single hop, and that when routing services are required that SIS services should be invoked. So, can we stick to what we have agreed and get the SIS guys to define these last hop & first hop services and not some new, “uncooked” link layer tunneling scheme? Thanks, Peter From: > on behalf of Keith Scott > Date: Friday, October 23, 2015 at 9:18 AM To: Greg Kazz >, "sls-slp at mailman.ccsds.org" > Cc: "sis-dtn-owner at mailman.ccsds.org" > Subject: Re: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Some comments on the draft USLP book: Figure 2-1: Relationship with OSI Layers * The OSI stack has a Network Layer between Data Link and Transport, and I would argue that the CCSDS Layers do as well (that being either IP or BP). * I’d also like to make an argument for showing up to the application layer, since I think that a lot of CCSDS’ angst comes from not actually thinking that we HAVE applications. General: What the heck is the tunneling service? * If this really is intended to be tunneling frames across multiple links, we probably need to have a chat between SLP and DTN. We (DTN) have a NOTION (ok, haven’t done the definition yet) of a ‘standard application’ to tunnel frames (of possibly different kinds, but would presumably include USLP) across the layer-3 network and spit them out somewhere else. The receiving application would then extract the frames and instructions and emit them towards a destination. The motivation for this is to be able to send link-layer commands to a spacecraft with which you (as the ground, e.g.) do not have direct link-layer connectivity. A similar setup would work in the reverse direction, tunneling frames back from a spacecraft. We (in DTN) have always envisioned these as ‘emergency’ applications, since I’m not keen on what would be essentially extending CSTS across multiple space links! * The point is, if you really mean to tunnel across multiple links, it might be better to get the tunnel service from the network. * Didn’t seem to me that the description in the book was complete? 4.1.5.1.6 didn’t seem complete, but maybe it’s a nascent idea? SCIDs in General * To Gian Paolo’s comment about putting the SCID as early as possible in the frame: does putting the SCID early do any good unless you also have the Source/Destination indicator bit? * Not having the ability to put BOTH a source and destination address in the frame means that * When I receive transmissions to ME (Source/Destination bit indicates destination SCID in frame), I don’t know where they came from. Sure, this information may be implied, but what if I’m receiving from someone and there could be multiple senders (I’m thinking multiple rovers hearing from orbiters on Mars, or a similar situation on the Moon)? * Would the ability to include both source and destination addresses allow us to simplify the Mars hailing procedures? * This pretty much ensures that it would be really hard to use USLP for anything involving dynamic link discovery (I’m thinking mostly human spaceflight stuff), since dynamic discovery methods generally need both a broadcast address (which I suppose we could define) and the ability to know who transmitted. This might not be a problem — anything dynamic might be the realm of something that looks a lot more like an adaptation of a terrestrial data link protocol. 3.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is this heading title a misnomer? It seems like you’re mainly describing the TFDF Service Data Unit, which might CONTAIN a TFDF Tunneling Data Unit (?) 3.5 TFDF Tunneling Service * Same question here. The text seems to deal much more with a TFDF SDU than anything to do with tunneling. 6.2.2.5 TFDF TUNNELING DATA UNIT (TFDF_SDU) * Is Section 6 where section 3 went? Seems like section 6 (Annex) is a repeat of Section 3… TFDF Header Always Present? * Is the TFDF header always present whenever the length of the TFDF_SDU > 0? ==== —keith Dr. Keith Scott Office: +1.703.983.6547 Chief Engineer, J86A Fax: +1.703.983.7142 Communications Network Engineering & AnalysisEmail: kscott at mitre.org The MITRE Corporation M/S H300 7515 Colshire Drive McLean, VA 22102 Area Director, CCSDS Space Internetworking Services MITRE self-signs its own certificates. Information about the MITRE PKI Certificate Chain is available from http://www.mitre.org/tech/mii/pki/ [cid:62DF199A-3B64-4F9A-AA4D-FDB0DA4D46DC] From: > on behalf of Greg Kazz > Date: Thursday, October 22, 2015 at 4:25 PM To: "sls-slp at mailman.ccsds.org" > Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png Type: image/png Size: 2755 bytes Desc: 6B72C8A7-BF57-46DC-B33A-CAE20825E097[2].png URL: From greg.j.kazz at jpl.nasa.gov Tue Oct 27 21:02:21 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Tue, 27 Oct 2015 21:02:21 +0000 Subject: [Sls-slp] Updated agenda for SLP WG (SLS area) posted on Oct 27 Message-ID: Dear SLP WG, The Secretariat has now posted my more detailed agenda for the SLP WG. Please take the time to review it before the meeting. Thanks and safe journeys, Greg Kazz Chairman SLP WG From: ccsds techsupport > Date: Tuesday, October 27, 2015 at 1:57 PM To: "Kazz, Greg J (313B)" > Subject: Re: Updated agenda for SLP WG (SLS area) Posted On Oct 27, 2015, at 4:53 PM, Kazz, Greg J (312B) > wrote: Please post this new agenda to the Darmstadt meeting. Thanks! Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Thu Oct 29 11:05:22 2015 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Thu, 29 Oct 2015 11:05:22 +0000 Subject: [Sls-slp] RE: Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: References: Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> Dear Greg, I had a quick look at the document and reported some comments as follows: · Section 1.1. It is stated that "this specification describes the data flow the data link layer process that reside between physical and network layer". On the contrary, I think that this specification addresses only the data services sublayer, with no specification details about the C&S sublayer. · Section 1.3. In the rest of the document it is not clear how the mentioned three sublayers (data services, session operation management, and C&S) are interfaced and then positioned within the Data Link layer. In particular it is not clear to me whether SOM (also for how it is described in D) is actually a dedicated sublayer or a service. · Section 1.6. For what concerns ordering of the annexes, if I'm not wrong, you should first have all normative annexes and then informative, whereas Annex F is normative. · Section 1.7.2. I've the impression that some of the definitions are the result of merging from definitions contained in the existing TM, Prox-1, and TC books. Hence, the wording can be improved. In particular, return and forward link definition is unclear. Furthermore, it is later stated (section 2.1.1) that this book addresses also space-to-space links. In this regard, I've some troubles in seeing the application of the provided definitions for forward and return links. Moreover, these definitions refer to caller and responders, which by definition are concerned only in proximity links. · Section 2.1.1. Protocol Data Unit (PDU) is referred here but not considered in the sections devoted to the terms defined in ISO/OSI (section 1.7.1.1). At the end, there is a reference to B4, which currently does not contain any indications about USLP and I'm not aware of any project defined to update that book. Figure 2.1 is quite controversial. As stated by Keith, OSI protocol stack should contain the network layer and probably it would be worth going up to the application layer (then also including the presentation layer to be coherent with OSI protocol stack). I've also some problems with the CCSDS protocols stack. In particular, the data services sublayer contains protocols and also functions (frame delimiting and validation): this should be harmonized. On the other hand, the C&S sublayer only contains channel coding techniques, with no mention of sync functions. Another point is the fact that presently LTP cannot work on top of TM, AOS, Proximity, or TC, but it needs to be transported by the CCSDS encapsulation service, which is also missing in this figure. Finally, other protocols potentially running above the CCSDS Data Link layer are not depicted at all, such as IP, Space Packet, etc. · Section 2.2.2. The last sentence contains "shall". Section 2 of CCSDS blue books is an informative section (as far as I know) and therefore no requirements can be stated in there. · Section 2.2.3.7. It is quite unclear what the TFDF tunneling service is. Also in the rest of the document, I can't see the difference with respect to the packet service. I was wondering whether this has to do with a kind of L2 switching, but still far from my understanding of tunneling concepts. · Section 2.3.1, bullet point at the end. If my understanding is correct, it is stated that retransmission function is available. I'm fine with COP-1 that is coming from the TC; the text however is not clear about the scope of its application. It is limited only to the uplink forward or also to the return downlink (this would be new with respect to the COP-1 specification)? · Section 3.2.2. Differently from what depicted in Figure 2.1., it is stated that service data units are PDU of the network layer protocol. Please harmonise. · Section 4.1.1. It is stated that the transfer frame header should be 7 or 14 octets, whereas figure 4-1 shows '7-14'. According to the description proposed in 4.1.2, I think 7-14 is correct, whereas '7 or 14' is not. · Section 4.1.2. Frame length is 2 octets, I'd better say 16 bits, as done for the SCID. · Section 4.1.5.1 What is data structuring rules (figure 4-4)? In section .4.1.5.1.1 segmentation rules is addressed instead. Harmonisation of the terminology is necessary. · Section 5.1. In Table 5.1, for the FEC code, I think it is better to explicitly state which codes and related bit pattern should be used. · Section 5.2, Table 5.2. It is not clear to me how I can put an integer value for the variable length. For example in the TC specification, one can indicate the maximum frame length acceptable. Similar comment for Tables 5.3 and 5.4. · Annex F: I would see this part directly in the core of the document. Section 6.3.3 introduces as parameter 'QoS', which is however not properly defined in the rest of the document. In TC for instance 'service type' was defined with clear explanation in the rest of that book. In section 6.4.2, GMAP is indicated as parameter, but actually the considered primitives use instead GVCID. In section 6.5.2, the primitives contain the parameter PID, which is however not included in the parameters discussion some paragraphs above. Furthermore the indication primitive contain the QoS parameter, which is not present in the request primitive: is it correct? · Annex G: I guess it should be DVB-S2 instead of DVB2. Sorry for providing these inputs so late, but I think they should be taken into account during the discussion in Darmstadt. It can also be that some of these comments have been already recorded by other colleagues in the most recent version of the USLP white book. 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: Thursday, October 22, 2015 22:25 To: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg.j.kazz at jpl.nasa.gov Thu Oct 29 18:05:33 2015 From: greg.j.kazz at jpl.nasa.gov (Kazz, Greg J (312B)) Date: Thu, 29 Oct 2015 18:05:33 +0000 Subject: [Sls-slp] Re: Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> References: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> Message-ID: Tomaso, Thank you very much for taking the time to comment on this draft USLP White book. My answers below. G From: "Tomaso.deCola at dlr.de" > Date: Thursday, October 29, 2015 at 4:05 AM To: "Kazz, Greg J (313B)" > Cc: "sls-slp at mailman.ccsds.org" > Subject: RE: Newest Version of USLP White Book on CWE as of Oct 22 Dear Greg, I had a quick look at the document and reported some comments as follows: · Section 1.1. It is stated that “this specification describes the data flow the data link layer process that reside between physical and network layer”. On the contrary, I think that this specification addresses only the data services sublayer, with no specification details about the C&S sublayer. ** For the most part this is true. Except the Data Services Sublayer has an interface to be expressed above it and below it. Note that in all of the previous CCSDS link layer documents, there has always been a section devoted to at least “Services provided from the lower layers”. I consider that a detail that needs to be expressed later in Section 2 ** · Section 1.3. In the rest of the document it is not clear how the mentioned three sublayers (data services, session operation management, and C&S) are interfaced and then positioned within the Data Link layer. In particular it is not clear to me whether SOM (also for how it is described in D) is actually a dedicated sublayer or a service. ** We will work out with C&S WG the USLP Data services with them on Monday PM in Darmstadt. We have created utilization profiles to describe this. I will email them to you after I finish this email. The SOM is a joint meeting topic on Thursday ** · Section 1.6. For what concerns ordering of the annexes, if I’m not wrong, you should first have all normative annexes and then informative, whereas Annex F is normative. ** OK. I have now left a note for Tom Gannett to update if necessary ** · Section 1.7.2. I’ve the impression that some of the definitions are the result of merging from definitions contained in the existing TM, Prox-1, and TC books. Hence, the wording can be improved. In particular, return and forward link definition is unclear. Furthermore, it is later stated (section 2.1.1) that this book addresses also space-to-space links. In this regard, I’ve some troubles in seeing the application of the provided definitions for forward and return links. Moreover, these definitions refer to caller and responders, which by definition are concerned only in proximity links. ** Please offer us some suggestions on how to change or augment the “return” and “forward” link definitions. ** · Section 2.1.1. Protocol Data Unit (PDU) is referred here but not considered in the sections devoted to the terms defined in ISO/OSI (section 1.7.1.1). At the end, there is a reference to B4, which currently does not contain any indications about USLP and I’m not aware of any project defined to update that book. Figure 2.1 is quite controversial. As stated by Keith, OSI protocol stack should contain the network layer and probably it would be worth going up to the application layer (then also including the presentation layer to be coherent with OSI protocol stack). I’ve also some problems with the CCSDS protocols stack. In particular, the data services sublayer contains protocols and also functions (frame delimiting and validation): this should be harmonized. On the other hand, the C&S sublayer only contains channel coding techniques, with no mention of sync functions. Another point is the fact that presently LTP cannot work on top of TM, AOS, Proximity, or TC, but it needs to be transported by the CCSDS encapsulation service, which is also missing in this figure. Finally, other protocols potentially running above the CCSDS Data Link layer are not depicted at all, such as IP, Space Packet, etc. ** LTP can run directly under USLP, because USLP does not require Encapsulation Service. It provides direct insertion of PDUs. Agree that C&S sublayer does provide Code Synchronization Function but not frame synchronization function. We put the functions there just for discussion purposes and not for final diagram. You are correct that Space DAta Link Protocols GB will need to be updated once we agree on USLP fundamentals ** · Section 2.2.2. The last sentence contains “shall”. Section 2 of CCSDS blue books is an informative section (as far as I know) and therefore no requirements can be stated in there. ** I have adjusted it ** · Section 2.2.3.7. It is quite unclear what the TFDF tunneling service is. Also in the rest of the document, I can’t see the difference with respect to the packet service. I was wondering whether this has to do with a kind of L2 switching, but still far from my understanding of tunneling concepts. ** We realize that this topic is controversial but left it in to see if agencies find value in it or not. We will expound on it at the meetings ** · Section 2.3.1, bullet point at the end. If my understanding is correct, it is stated that retransmission function is available. I’m fine with COP-1 that is coming from the TC; the text however is not clear about the scope of its application. It is limited only to the uplink forward or also to the return downlink (this would be new with respect to the COP-1 specification)? ** I will get back to you on this one ** · Section 3.2.2. Differently from what depicted in Figure 2.1., it is stated that service data units are PDU of the network layer protocol. Please harmonise. ** aren’t packets typically a network layer PDU ? We stay that they are primarily but not exclusively from the network layer ** · Section 4.1.1. It is stated that the transfer frame header should be 7 or 14 octets, whereas figure 4-1 shows ‘7-14’. According to the description proposed in 4.1.2, I think 7-14 is correct, whereas ‘7 or 14’ is not. ** We will adjust to say 7 to 14 ** · Section 4.1.2. Frame length is 2 octets, I’d better say 16 bits, as done for the SCID. * OK* · Section 4.1.5.1 What is data structuring rules (figure 4-4)? In section .4.1.5.1.1 segmentation rules is addressed instead. Harmonisation of the terminology is necessary. * We eliminated the duality of terms* · Section 5.1. In Table 5.1, for the FEC code, I think it is better to explicitly state which codes * OK *and related bit pattern should be used. * not sure about specifying bit pattern in this document* · Section 5.2, Table 5.2. It is not clear to me how I can put an integer value for the variable length. For example in the TC specification, one can indicate the maximum frame length acceptable. Similar comment for Tables 5.3 and 5.4. ** Agree. Will use Fixed or Maximum Frame Length Acceptable ** · Annex F: I would see this part directly in the core of the document. Section 6.3.3 introduces as parameter ‘QoS’, which is however not properly defined in the rest of the document. In TC for instance ‘service type’ was defined with clear explanation in the rest of that book. In section 6.4.2, GMAP is indicated as parameter, but actually the considered primitives use instead GVCID. * GVCID will be replaced with GMAP ID in this annex F * In section 6.5.2, the primitives contain the parameter PID, which is however not included in the parameters discussion some paragraphs above. Furthermore the indication primitive contain the QoS parameter, which is not present in the request primitive: is it correct? ** This annex F requires extra work. We found the number of primatives to be too overwhelming to put them directly into Section 3, so we moved them to a normative annex instead ** · Annex G: I guess it should be DVB-S2 instead of DVB2. ** Yes, we will fix ** Sorry for providing these inputs so late, but I think they should be taken into account during the discussion in Darmstadt. It can also be that some of these comments have been already recorded by other colleagues in the most recent version of the USLP white book. 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: Thursday, October 22, 2015 22:25 To: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.greenberg at jpl.nasa.gov Thu Oct 29 21:40:11 2015 From: edward.greenberg at jpl.nasa.gov (Greenberg, Edward (312B)) Date: Thu, 29 Oct 2015 21:40:11 +0000 Subject: [Sls-slp] RE: Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: References: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> Message-ID: <4EF9F303214ADB458948F9AD7A608EB31BE3054D@ap-embx-sp30.RES.AD.JPL> I would like to that Tomaso for his thorough review of the White Book. I believe that we tried to produce a book that has its roots in the current CCSDS link layer books. I personally would have proposed that we produce the Link Layer Data Services (Protocol ) sublayer book without the baggage required for use in each link. I believe that USLP as a link layer protocol can be used in any space link (up-down or sideways). The older books were written for a single application, on a single link, and the books carry artifacts of how the protocol is used on those links. In the Proximity book, aside from defining the protocol we define the operational aspects for its use on the link. I personally believe that we should have a clean Protocol book. The SOM for example is a layer five item, it defines how the session is established, operated and dissolved. The Protocol book should provide the tools that can enable the SOM just as it provides the tools to do command and telemetry. I know that his comments will be reviewed and incorporated in an effort to bring this White Book to red status. The only question that Tomaso asked that Greg didn't answer directly was on the application of COP-1 to other than TC. The functionality of COP-1 is current incorporated in the Proximity Blue book. I personally can see the COP functionality be included for critical data in telemetry for near earth high rate missions just as it is for Proximity. Having a low rate sequence controlled VC could simplify the process of getting complete critical data by performing the task at layer 2 rather than layer 4. From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Thursday, October 29, 2015 11:06 AM To: Tomaso.deCola at dlr.de Cc: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Re: Newest Version of USLP White Book on CWE as of Oct 22 Tomaso, Thank you very much for taking the time to comment on this draft USLP White book. My answers below. G From: "Tomaso.deCola at dlr.de" > Date: Thursday, October 29, 2015 at 4:05 AM To: "Kazz, Greg J (313B)" > Cc: "sls-slp at mailman.ccsds.org" > Subject: RE: Newest Version of USLP White Book on CWE as of Oct 22 Dear Greg, I had a quick look at the document and reported some comments as follows: Section 1.1. It is stated that "this specification describes the data flow the data link layer process that reside between physical and network layer". On the contrary, I think that this specification addresses only the data services sublayer, with no specification details about the C&S sublayer. ** For the most part this is true. Except the Data Services Sublayer has an interface to be expressed above it and below it. Note that in all of the previous CCSDS link layer documents, there has always been a section devoted to at least "Services provided from the lower layers". I consider that a detail that needs to be expressed later in Section 2 ** Section 1.3. In the rest of the document it is not clear how the mentioned three sublayers (data services, session operation management, and C&S) are interfaced and then positioned within the Data Link layer. In particular it is not clear to me whether SOM (also for how it is described in D) is actually a dedicated sublayer or a service. ** We will work out with C&S WG the USLP Data services with them on Monday PM in Darmstadt. We have created utilization profiles to describe this. I will email them to you after I finish this email. The SOM is a joint meeting topic on Thursday ** Section 1.6. For what concerns ordering of the annexes, if I'm not wrong, you should first have all normative annexes and then informative, whereas Annex F is normative. ** OK. I have now left a note for Tom Gannett to update if necessary ** Section 1.7.2. I've the impression that some of the definitions are the result of merging from definitions contained in the existing TM, Prox-1, and TC books. Hence, the wording can be improved. In particular, return and forward link definition is unclear. Furthermore, it is later stated (section 2.1.1) that this book addresses also space-to-space links. In this regard, I've some troubles in seeing the application of the provided definitions for forward and return links. Moreover, these definitions refer to caller and responders, which by definition are concerned only in proximity links. ** Please offer us some suggestions on how to change or augment the "return" and "forward" link definitions. ** Section 2.1.1. Protocol Data Unit (PDU) is referred here but not considered in the sections devoted to the terms defined in ISO/OSI (section 1.7.1.1). At the end, there is a reference to B4, which currently does not contain any indications about USLP and I'm not aware of any project defined to update that book. Figure 2.1 is quite controversial. As stated by Keith, OSI protocol stack should contain the network layer and probably it would be worth going up to the application layer (then also including the presentation layer to be coherent with OSI protocol stack). I've also some problems with the CCSDS protocols stack. In particular, the data services sublayer contains protocols and also functions (frame delimiting and validation): this should be harmonized. On the other hand, the C&S sublayer only contains channel coding techniques, with no mention of sync functions. Another point is the fact that presently LTP cannot work on top of TM, AOS, Proximity, or TC, but it needs to be transported by the CCSDS encapsulation service, which is also missing in this figure. Finally, other protocols potentially running above the CCSDS Data Link layer are not depicted at all, such as IP, Space Packet, etc. ** LTP can run directly under USLP, because USLP does not require Encapsulation Service. It provides direct insertion of PDUs. Agree that C&S sublayer does provide Code Synchronization Function but not frame synchronization function. We put the functions there just for discussion purposes and not for final diagram. You are correct that Space DAta Link Protocols GB will need to be updated once we agree on USLP fundamentals ** Section 2.2.2. The last sentence contains "shall". Section 2 of CCSDS blue books is an informative section (as far as I know) and therefore no requirements can be stated in there. ** I have adjusted it ** Section 2.2.3.7. It is quite unclear what the TFDF tunneling service is. Also in the rest of the document, I can't see the difference with respect to the packet service. I was wondering whether this has to do with a kind of L2 switching, but still far from my understanding of tunneling concepts. ** We realize that this topic is controversial but left it in to see if agencies find value in it or not. We will expound on it at the meetings ** Section 2.3.1, bullet point at the end. If my understanding is correct, it is stated that retransmission function is available. I'm fine with COP-1 that is coming from the TC; the text however is not clear about the scope of its application. It is limited only to the uplink forward or also to the return downlink (this would be new with respect to the COP-1 specification)? ** I will get back to you on this one ** Section 3.2.2. Differently from what depicted in Figure 2.1., it is stated that service data units are PDU of the network layer protocol. Please harmonise. ** aren't packets typically a network layer PDU ? We stay that they are primarily but not exclusively from the network layer ** Section 4.1.1. It is stated that the transfer frame header should be 7 or 14 octets, whereas figure 4-1 shows '7-14'. According to the description proposed in 4.1.2, I think 7-14 is correct, whereas '7 or 14' is not. ** We will adjust to say 7 to 14 ** Section 4.1.2. Frame length is 2 octets, I'd better say 16 bits, as done for the SCID. * OK* Section 4.1.5.1 What is data structuring rules (figure 4-4)? In section .4.1.5.1.1 segmentation rules is addressed instead. Harmonisation of the terminology is necessary. * We eliminated the duality of terms* Section 5.1. In Table 5.1, for the FEC code, I think it is better to explicitly state which codes * OK *and related bit pattern should be used. * not sure about specifying bit pattern in this document* Section 5.2, Table 5.2. It is not clear to me how I can put an integer value for the variable length. For example in the TC specification, one can indicate the maximum frame length acceptable. Similar comment for Tables 5.3 and 5.4. ** Agree. Will use Fixed or Maximum Frame Length Acceptable ** Annex F: I would see this part directly in the core of the document. Section 6.3.3 introduces as parameter 'QoS', which is however not properly defined in the rest of the document. In TC for instance 'service type' was defined with clear explanation in the rest of that book. In section 6.4.2, GMAP is indicated as parameter, but actually the considered primitives use instead GVCID. * GVCID will be replaced with GMAP ID in this annex F * In section 6.5.2, the primitives contain the parameter PID, which is however not included in the parameters discussion some paragraphs above. Furthermore the indication primitive contain the QoS parameter, which is not present in the request primitive: is it correct? ** This annex F requires extra work. We found the number of primatives to be too overwhelming to put them directly into Section 3, so we moved them to a normative annex instead ** Annex G: I guess it should be DVB-S2 instead of DVB2. ** Yes, we will fix ** Sorry for providing these inputs so late, but I think they should be taken into account during the discussion in Darmstadt. It can also be that some of these comments have been already recorded by other colleagues in the most recent version of the USLP white book. 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: Thursday, October 22, 2015 22:25 To: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Fri Oct 30 09:08:56 2015 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Fri, 30 Oct 2015 09:08:56 +0000 Subject: [Sls-slp] RE: Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: References: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC317571B2F@DLREXMBX01.intra.dlr.de> Dear Greg, Thanks for your clarifications, on which we'll certainly iterate during the meeting also according to the comments also provided by the other agencies. Concerning my point about the fact the USLP cannot encapsulate network layer PDUs it was only a remark with respect to what shown in Figure 2.1, where actually USLP operates beneath the transport layer, the network layer missing from that picture. As mentioned in one of my comments, improving the picture should solve the issue. Besides that, my point (still about Figure 2.1) that CCSDS Data Service protocol cannot directly encapsulate LTP PDU certainly does not apply to USLP, since the TFDF implements an header, which actually defines the main functionalities from the CCSDS encapsulation service. On the other hand, the other protocols which stay together with USLP (e.g., TM, TC, AOS, and Prox-1) cannot directly encapsulate LTP PDUs and need the use of the CCSDS encapsulation service for this purpose. In general, I think that we should discuss what kind of information has to be contained in Figure 2.1 also in relation to the architecture details which will be further addressed in the rest of the book. 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: Kazz, Greg J (312B) [mailto:greg.j.kazz at jpl.nasa.gov] Sent: Thursday, October 29, 2015 19:06 To: Cola, Tomaso de Cc: sls-slp at mailman.ccsds.org Subject: Re: Newest Version of USLP White Book on CWE as of Oct 22 Tomaso, Thank you very much for taking the time to comment on this draft USLP White book. My answers below. G From: "Tomaso.deCola at dlr.de" > Date: Thursday, October 29, 2015 at 4:05 AM To: "Kazz, Greg J (313B)" > Cc: "sls-slp at mailman.ccsds.org" > Subject: RE: Newest Version of USLP White Book on CWE as of Oct 22 Dear Greg, I had a quick look at the document and reported some comments as follows: Section 1.1. It is stated that "this specification describes the data flow the data link layer process that reside between physical and network layer". On the contrary, I think that this specification addresses only the data services sublayer, with no specification details about the C&S sublayer. ** For the most part this is true. Except the Data Services Sublayer has an interface to be expressed above it and below it. Note that in all of the previous CCSDS link layer documents, there has always been a section devoted to at least "Services provided from the lower layers". I consider that a detail that needs to be expressed later in Section 2 ** Section 1.3. In the rest of the document it is not clear how the mentioned three sublayers (data services, session operation management, and C&S) are interfaced and then positioned within the Data Link layer. In particular it is not clear to me whether SOM (also for how it is described in D) is actually a dedicated sublayer or a service. ** We will work out with C&S WG the USLP Data services with them on Monday PM in Darmstadt. We have created utilization profiles to describe this. I will email them to you after I finish this email. The SOM is a joint meeting topic on Thursday ** Section 1.6. For what concerns ordering of the annexes, if I'm not wrong, you should first have all normative annexes and then informative, whereas Annex F is normative. ** OK. I have now left a note for Tom Gannett to update if necessary ** Section 1.7.2. I've the impression that some of the definitions are the result of merging from definitions contained in the existing TM, Prox-1, and TC books. Hence, the wording can be improved. In particular, return and forward link definition is unclear. Furthermore, it is later stated (section 2.1.1) that this book addresses also space-to-space links. In this regard, I've some troubles in seeing the application of the provided definitions for forward and return links. Moreover, these definitions refer to caller and responders, which by definition are concerned only in proximity links. ** Please offer us some suggestions on how to change or augment the "return" and "forward" link definitions. ** Section 2.1.1. Protocol Data Unit (PDU) is referred here but not considered in the sections devoted to the terms defined in ISO/OSI (section 1.7.1.1). At the end, there is a reference to B4, which currently does not contain any indications about USLP and I'm not aware of any project defined to update that book. Figure 2.1 is quite controversial. As stated by Keith, OSI protocol stack should contain the network layer and probably it would be worth going up to the application layer (then also including the presentation layer to be coherent with OSI protocol stack). I've also some problems with the CCSDS protocols stack. In particular, the data services sublayer contains protocols and also functions (frame delimiting and validation): this should be harmonized. On the other hand, the C&S sublayer only contains channel coding techniques, with no mention of sync functions. Another point is the fact that presently LTP cannot work on top of TM, AOS, Proximity, or TC, but it needs to be transported by the CCSDS encapsulation service, which is also missing in this figure. Finally, other protocols potentially running above the CCSDS Data Link layer are not depicted at all, such as IP, Space Packet, etc. ** LTP can run directly under USLP, because USLP does not require Encapsulation Service. It provides direct insertion of PDUs. Agree that C&S sublayer does provide Code Synchronization Function but not frame synchronization function. We put the functions there just for discussion purposes and not for final diagram. You are correct that Space DAta Link Protocols GB will need to be updated once we agree on USLP fundamentals ** Section 2.2.2. The last sentence contains "shall". Section 2 of CCSDS blue books is an informative section (as far as I know) and therefore no requirements can be stated in there. ** I have adjusted it ** Section 2.2.3.7. It is quite unclear what the TFDF tunneling service is. Also in the rest of the document, I can't see the difference with respect to the packet service. I was wondering whether this has to do with a kind of L2 switching, but still far from my understanding of tunneling concepts. ** We realize that this topic is controversial but left it in to see if agencies find value in it or not. We will expound on it at the meetings ** Section 2.3.1, bullet point at the end. If my understanding is correct, it is stated that retransmission function is available. I'm fine with COP-1 that is coming from the TC; the text however is not clear about the scope of its application. It is limited only to the uplink forward or also to the return downlink (this would be new with respect to the COP-1 specification)? ** I will get back to you on this one ** Section 3.2.2. Differently from what depicted in Figure 2.1., it is stated that service data units are PDU of the network layer protocol. Please harmonise. ** aren't packets typically a network layer PDU ? We stay that they are primarily but not exclusively from the network layer ** Section 4.1.1. It is stated that the transfer frame header should be 7 or 14 octets, whereas figure 4-1 shows '7-14'. According to the description proposed in 4.1.2, I think 7-14 is correct, whereas '7 or 14' is not. ** We will adjust to say 7 to 14 ** Section 4.1.2. Frame length is 2 octets, I'd better say 16 bits, as done for the SCID. * OK* Section 4.1.5.1 What is data structuring rules (figure 4-4)? In section .4.1.5.1.1 segmentation rules is addressed instead. Harmonisation of the terminology is necessary. * We eliminated the duality of terms* Section 5.1. In Table 5.1, for the FEC code, I think it is better to explicitly state which codes * OK *and related bit pattern should be used. * not sure about specifying bit pattern in this document* Section 5.2, Table 5.2. It is not clear to me how I can put an integer value for the variable length. For example in the TC specification, one can indicate the maximum frame length acceptable. Similar comment for Tables 5.3 and 5.4. ** Agree. Will use Fixed or Maximum Frame Length Acceptable ** Annex F: I would see this part directly in the core of the document. Section 6.3.3 introduces as parameter 'QoS', which is however not properly defined in the rest of the document. In TC for instance 'service type' was defined with clear explanation in the rest of that book. In section 6.4.2, GMAP is indicated as parameter, but actually the considered primitives use instead GVCID. * GVCID will be replaced with GMAP ID in this annex F * In section 6.5.2, the primitives contain the parameter PID, which is however not included in the parameters discussion some paragraphs above. Furthermore the indication primitive contain the QoS parameter, which is not present in the request primitive: is it correct? ** This annex F requires extra work. We found the number of primatives to be too overwhelming to put them directly into Section 3, so we moved them to a normative annex instead ** Annex G: I guess it should be DVB-S2 instead of DVB2. ** Yes, we will fix ** Sorry for providing these inputs so late, but I think they should be taken into account during the discussion in Darmstadt. It can also be that some of these comments have been already recorded by other colleagues in the most recent version of the USLP white book. 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: Thursday, October 22, 2015 22:25 To: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tomaso.deCola at dlr.de Fri Oct 30 09:25:32 2015 From: Tomaso.deCola at dlr.de (Tomaso.deCola at dlr.de) Date: Fri, 30 Oct 2015 09:25:32 +0000 Subject: [Sls-slp] RE: Newest Version of USLP White Book on CWE as of Oct 22 In-Reply-To: <4EF9F303214ADB458948F9AD7A608EB31BE3054D@ap-embx-sp30.RES.AD.JPL> References: <1A39DCC13AF3C14B83CD74124D4DCFC3175695C4@DLREXMBX01.intra.dlr.de> <4EF9F303214ADB458948F9AD7A608EB31BE3054D@ap-embx-sp30.RES.AD.JPL> Message-ID: <1A39DCC13AF3C14B83CD74124D4DCFC317571B5D@DLREXMBX01.intra.dlr.de> Dear Ed, Thanks for your explanation about the possible use of COP-1 (or COP-1 like) also for the telemetry link. If this is the direction we want to go for, we should also discuss the possible (bad) interaction with the ARQ scheme provided by LTP in case of red parts. If I'm not wrong, current DTN/BP specification is such that based on eCOS setting, it is automatically decided whether LTP-red part or -green part should be used. If the former, this could create some problems with the ARQ loop also provided by COP-1. On the other hand, it could be interesting to see if there are specific cases (small telemetry messages?), where the use of COP could be preferred, then decided at mission planning and eventually encoded in the system configuration through managed parameters. 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: Greenberg, Edward (312B) [mailto:edward.greenberg at jpl.nasa.gov] Sent: Thursday, October 29, 2015 22:40 To: Kazz, Greg J (312B); Cola, Tomaso de Cc: sls-slp at mailman.ccsds.org Subject: RE: Newest Version of USLP White Book on CWE as of Oct 22 I would like to that Tomaso for his thorough review of the White Book. I believe that we tried to produce a book that has its roots in the current CCSDS link layer books. I personally would have proposed that we produce the Link Layer Data Services (Protocol ) sublayer book without the baggage required for use in each link. I believe that USLP as a link layer protocol can be used in any space link (up-down or sideways). The older books were written for a single application, on a single link, and the books carry artifacts of how the protocol is used on those links. In the Proximity book, aside from defining the protocol we define the operational aspects for its use on the link. I personally believe that we should have a clean Protocol book. The SOM for example is a layer five item, it defines how the session is established, operated and dissolved. The Protocol book should provide the tools that can enable the SOM just as it provides the tools to do command and telemetry. I know that his comments will be reviewed and incorporated in an effort to bring this White Book to red status. The only question that Tomaso asked that Greg didn't answer directly was on the application of COP-1 to other than TC. The functionality of COP-1 is current incorporated in the Proximity Blue book. I personally can see the COP functionality be included for critical data in telemetry for near earth high rate missions just as it is for Proximity. Having a low rate sequence controlled VC could simplify the process of getting complete critical data by performing the task at layer 2 rather than layer 4. From: sls-slp-bounces at mailman.ccsds.org [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Kazz, Greg J (312B) Sent: Thursday, October 29, 2015 11:06 AM To: Tomaso.deCola at dlr.de Cc: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Re: Newest Version of USLP White Book on CWE as of Oct 22 Tomaso, Thank you very much for taking the time to comment on this draft USLP White book. My answers below. G From: "Tomaso.deCola at dlr.de" > Date: Thursday, October 29, 2015 at 4:05 AM To: "Kazz, Greg J (313B)" > Cc: "sls-slp at mailman.ccsds.org" > Subject: RE: Newest Version of USLP White Book on CWE as of Oct 22 Dear Greg, I had a quick look at the document and reported some comments as follows: Section 1.1. It is stated that "this specification describes the data flow the data link layer process that reside between physical and network layer". On the contrary, I think that this specification addresses only the data services sublayer, with no specification details about the C&S sublayer. ** For the most part this is true. Except the Data Services Sublayer has an interface to be expressed above it and below it. Note that in all of the previous CCSDS link layer documents, there has always been a section devoted to at least "Services provided from the lower layers". I consider that a detail that needs to be expressed later in Section 2 ** Section 1.3. In the rest of the document it is not clear how the mentioned three sublayers (data services, session operation management, and C&S) are interfaced and then positioned within the Data Link layer. In particular it is not clear to me whether SOM (also for how it is described in D) is actually a dedicated sublayer or a service. ** We will work out with C&S WG the USLP Data services with them on Monday PM in Darmstadt. We have created utilization profiles to describe this. I will email them to you after I finish this email. The SOM is a joint meeting topic on Thursday ** Section 1.6. For what concerns ordering of the annexes, if I'm not wrong, you should first have all normative annexes and then informative, whereas Annex F is normative. ** OK. I have now left a note for Tom Gannett to update if necessary ** Section 1.7.2. I've the impression that some of the definitions are the result of merging from definitions contained in the existing TM, Prox-1, and TC books. Hence, the wording can be improved. In particular, return and forward link definition is unclear. Furthermore, it is later stated (section 2.1.1) that this book addresses also space-to-space links. In this regard, I've some troubles in seeing the application of the provided definitions for forward and return links. Moreover, these definitions refer to caller and responders, which by definition are concerned only in proximity links. ** Please offer us some suggestions on how to change or augment the "return" and "forward" link definitions. ** Section 2.1.1. Protocol Data Unit (PDU) is referred here but not considered in the sections devoted to the terms defined in ISO/OSI (section 1.7.1.1). At the end, there is a reference to B4, which currently does not contain any indications about USLP and I'm not aware of any project defined to update that book. Figure 2.1 is quite controversial. As stated by Keith, OSI protocol stack should contain the network layer and probably it would be worth going up to the application layer (then also including the presentation layer to be coherent with OSI protocol stack). I've also some problems with the CCSDS protocols stack. In particular, the data services sublayer contains protocols and also functions (frame delimiting and validation): this should be harmonized. On the other hand, the C&S sublayer only contains channel coding techniques, with no mention of sync functions. Another point is the fact that presently LTP cannot work on top of TM, AOS, Proximity, or TC, but it needs to be transported by the CCSDS encapsulation service, which is also missing in this figure. Finally, other protocols potentially running above the CCSDS Data Link layer are not depicted at all, such as IP, Space Packet, etc. ** LTP can run directly under USLP, because USLP does not require Encapsulation Service. It provides direct insertion of PDUs. Agree that C&S sublayer does provide Code Synchronization Function but not frame synchronization function. We put the functions there just for discussion purposes and not for final diagram. You are correct that Space DAta Link Protocols GB will need to be updated once we agree on USLP fundamentals ** Section 2.2.2. The last sentence contains "shall". Section 2 of CCSDS blue books is an informative section (as far as I know) and therefore no requirements can be stated in there. ** I have adjusted it ** Section 2.2.3.7. It is quite unclear what the TFDF tunneling service is. Also in the rest of the document, I can't see the difference with respect to the packet service. I was wondering whether this has to do with a kind of L2 switching, but still far from my understanding of tunneling concepts. ** We realize that this topic is controversial but left it in to see if agencies find value in it or not. We will expound on it at the meetings ** Section 2.3.1, bullet point at the end. If my understanding is correct, it is stated that retransmission function is available. I'm fine with COP-1 that is coming from the TC; the text however is not clear about the scope of its application. It is limited only to the uplink forward or also to the return downlink (this would be new with respect to the COP-1 specification)? ** I will get back to you on this one ** Section 3.2.2. Differently from what depicted in Figure 2.1., it is stated that service data units are PDU of the network layer protocol. Please harmonise. ** aren't packets typically a network layer PDU ? We stay that they are primarily but not exclusively from the network layer ** Section 4.1.1. It is stated that the transfer frame header should be 7 or 14 octets, whereas figure 4-1 shows '7-14'. According to the description proposed in 4.1.2, I think 7-14 is correct, whereas '7 or 14' is not. ** We will adjust to say 7 to 14 ** Section 4.1.2. Frame length is 2 octets, I'd better say 16 bits, as done for the SCID. * OK* Section 4.1.5.1 What is data structuring rules (figure 4-4)? In section .4.1.5.1.1 segmentation rules is addressed instead. Harmonisation of the terminology is necessary. * We eliminated the duality of terms* Section 5.1. In Table 5.1, for the FEC code, I think it is better to explicitly state which codes * OK *and related bit pattern should be used. * not sure about specifying bit pattern in this document* Section 5.2, Table 5.2. It is not clear to me how I can put an integer value for the variable length. For example in the TC specification, one can indicate the maximum frame length acceptable. Similar comment for Tables 5.3 and 5.4. ** Agree. Will use Fixed or Maximum Frame Length Acceptable ** Annex F: I would see this part directly in the core of the document. Section 6.3.3 introduces as parameter 'QoS', which is however not properly defined in the rest of the document. In TC for instance 'service type' was defined with clear explanation in the rest of that book. In section 6.4.2, GMAP is indicated as parameter, but actually the considered primitives use instead GVCID. * GVCID will be replaced with GMAP ID in this annex F * In section 6.5.2, the primitives contain the parameter PID, which is however not included in the parameters discussion some paragraphs above. Furthermore the indication primitive contain the QoS parameter, which is not present in the request primitive: is it correct? ** This annex F requires extra work. We found the number of primatives to be too overwhelming to put them directly into Section 3, so we moved them to a normative annex instead ** Annex G: I guess it should be DVB-S2 instead of DVB2. ** Yes, we will fix ** Sorry for providing these inputs so late, but I think they should be taken into account during the discussion in Darmstadt. It can also be that some of these comments have been already recorded by other colleagues in the most recent version of the USLP white book. 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: Thursday, October 22, 2015 22:25 To: sls-slp at mailman.ccsds.org Subject: [Sls-slp] Newest Version of USLP White Book on CWE as of Oct 22 Dear SLP members, The lastest version which we plan to review at the SLP WG meeting in Darmstadt on Nov 9 and 10 is now in the CWE under the following URL: http://tiny.cc/goc14x Note that the filename contains the date of: 10-22-15gk_clean2 However, the latest changes using the Word tracking feature are there. Also note that Section 3 has been put back into this version. I cannot explain how it disappeared during the previous revision. Also we have tried to be more consistent with the outlines followed by TC, TM, and AOS where applicable. Best regards, Greg Chairman SLP WG -------------- next part -------------- An HTML attachment was scrubbed... URL: