[Sls-slp] RE: Newest Version of USLP White Book on CWE as of Oct 22

Fri Oct 30 09:25:32 UTC 2015

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<mailto: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> [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<mailto:Tomaso.deCola at dlr.de>
Cc: sls-slp at mailman.ccsds.org<mailto: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<mailto:Tomaso.deCola at dlr.de>" <Tomaso.deCola at dlr.de<mailto:Tomaso.deCola at dlr.de>>
Date: Thursday, October 29, 2015 at 4:05 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: "sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>" <sls-slp at mailman.ccsds.org<mailto:sls-slp at mailman.ccsds.org>>
Subject: RE: 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<mailto: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> [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<mailto: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: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20151030/44ae9510/attachment.html>