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

[Tomaso.deCola at 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<mailto: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<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/7b45d4a6/attachment.html>