[Sls-slp] Re: Fig.2-1 and 2-2 (Encapsulation Packet) - Towards Issue 3 of CCSDS 130.0-G Overview of Space Communications Protocols - Green Book

[Kazz, Greg J (312G)]

G.P.,

I'm answering you directly in this email and not in the word file you sent me, because that word file was an older version. I did not include any of the comments made directly to the CCSDS editor. Note that Tom Gannett has the corrected figures which are not all included yet in the attached version.

Your Comment [8]
 For SCPS an historical note may be added (I would also put the old figure(s) in an informative Annex…). I am not sure replacement of IP references to IPoC is fully correct. The old figure showed that we could put directly IPv4 datagrams in frames, conversely IPoC runs over the Encapsulation service limited to the Encapsulation Packet. So IPoC should only be linked to the box labeled Encapsulation..

My Response [8]. I fixed Figure 2-1 and 2-2 to show this. Because the title of this figure 2-2 is "Some Possible Combinations of Space Comm Protocols", I don't think it is necessary to make this the place where we document the history of the SCPS protocols. The user can always go back to the previous version of this GB if a historical view is desired.

Your Comment [9]

1)     Add historical note?

2)     Old figure in Annex?

3)     Shall the links from IPoC to the SDL protocols be removed? If yes IPoC box should also be lifted.


My Response [9]. So I would not add the historical note. Same rationale for not adding the old figure into an Annex. Figure has now been corrected to incorporate item 3).

Your Comment [10]

More than requirement we missed implementation. Should we replace established with implemented?


My Response [10].

If I use the term, implemented, then it implies there were requirements for Prox-1 security, which hasn't happened, so I prefer to keep the term, no security requirements established for Proximity-1.


Comment [11] and Comment [12]

Huangwei - I think it may be better to replace ‘routing’  by ‘routing or forwarding.

Forwarding does not require any online exchange of control information with other nodes. That is the case of  SPP.


My Response [11] + [12]

I initially misread Huangwei's response. I replaced "routing" with "forwarding". However, "routing" needs to be replaced with "routing or forwarding".


Comment [13]

I think Encapsulation Service allows either Space Packet or Encapsulation Packet, so we may need to review this part.

Basically we have only one protocol developed by CCSDS and 2 types of packets.

TO BE DISCUSSED.


My Response [13]

It is true that Encapsulation Service allows data to be encapsulated either into Space Packets or Encapsulation packets. But what we have is two protocols (SPP, IPoC) and one service (Encapsulation) and two packet types (Space vs Encapsulation). I don't know what futher discussion would be necessary here. If you have something more profound to be discussed here please SLP WG know.


Comment [14]

UNRESOLVED COMMENT.

My Response [14]

I don't understand. What is the issue?


Comment [15]

Can you really consider this a different option? At the end it runs the Encapsulation Service using (only) the encapsulation packet.

Greg Kazz reply: It’s a different protocol, because of the shim byte and it specifically addresses how to transfer IP datagrams across CCSDS space links.

GPC: Yes it is a different protocol but not at the same level as IPoC runs over the Encapsulation service limited to the Encapsulation Packet. We cannot hide this difference.

 My Response [15]

Here are the options- 1) use SPP to transfer CCSDS space packets across the link. 2) Encapsulation Service is used to transfer data from other protocols except for IP datagrams across 3) IP over CCSDS is the only way to transfer IP datagrams across the CCSDS space link and it happens to use Encapsulation Packets underneath which is well explained in diagrams 2-1 and 2-2 and in 4-5.


Comment [16]

UNRESOLVED COMMENT.


My Response [16]

Please express what you mean here. I don't understand what you desire here.


Comments [17] and [18]

Mentioning SANA  is good for a Blue Book. For a green book I would rather list what is available at book’s writing time.


My Response [17-18]

I disagree fundamentally because by providing the current list of CCSDS recognized IP Datagrams in this book, this list will eventually be out of date and it will require resources to keep it current. Better to simply point the reader to the offical SANA registry as a URL, which I have now added to the book.


Comments [19-20]

HuangWei - Can RTP be added as an example?

My Response [19-20]

One could add it but it is not really relevant to CCSDS Agencies use, since they don't use this protocol. So we won't add it.


Comments [21]

I would say three (set of) standards or the following standards to get neutral

My Response [21]

Concur


Comments [25 – 35] concerning Table 3‑3:  Functions of Synchronization and Channel Coding Standards

My Response [25-35]

This is really a C&S WG issue how they want to express the information in Table 3-3. I would like them to take a shot at generating this table and making it a delivery to the SLP WG.

Comment [36]

This sentence is now disconnected from the rest, so it should be reworded to state e.g. that there is also an IPoC option on top of Encapsulation Packet….

My Response [36]

I disagree. It is a valid statement as it stands. It simply points out that IPoC only uses Encapsulation Packets. Note that the IPoC protocol is on top of the Encapsulation Service.

Comment [37]

Can we really put internet protocol data units in space packets?

My Response [37]

No, we eliminated that option in IPoC. This statement modified to say internet PDUs only carried via the Encapsulation packet.


Comment [38 & 39]

Huang-Wei Comment: I advise mentioning RTP as an example here. And unresolved comment (calzolari)

My Response [38 & 39]

No. Agencies don't use RTP so it doesn't provide much of an example here.


Comments [40 & 41]

Huang-Wei comment: I advise to replace ‘routing” with ‘routing or forwarding’

My Response [40 & 41]

Yes, you are correct. Both words are needed to be added, which I did now.


Comments [42]

“routing and forwarding” issue:

Should this be consistent with preceding paragraph?

Is option a)  really providing routing?


My Response [42]

Option a) SPP or Encapsulation Service might provide routing since Encap can handle CFDP traffic which can be above DTN. So it's OK.


Comments [44]

Lower case o to be used in IPoC

My Response [44]

Concur.


Comments [45-46]

HuangWei comment: I think it may be better to replace ‘IP over CCSDS’ by ‘IP’ in this figure, since routing is based on IP, not IPoC.

UNRESOLVED COMMENT. I think HuangWei is correct; i.e. in the first and fourth column IS is used rather that IPoC; in the second and third column the IPoC box should actually be split…. See ppt file.


My Response [45-46]

     Concur. I have fixed Figure 4-5 in response.

That is all the technical comments that I have found and now addressed. I will send to Tom the current version of the edits today which will be the baseline – 130x0g2masterDec6_2013gjk.docx

Best regards,

Greg Kazz
Chairman CCSDS SLS-SLP WG
From: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Thursday, December 5, 2013 10:13 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: Thomas Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>
Subject: Re: Fig.2-1 and 2-2 (Encapsulation Packet) - Towards Issue 3 of CCSDS 130.0-G Overview of Space Communications Protocols - Green Book

Thank you, Greg.
Indeed I was surprised by the many open points and as well I did remember we had some discussion in Bordeaux.
Please have anyway a look at the winword version I sent today as I guess some comments are still valid.
Thanks

Gian Paolo


-----"Kazz, Greg J (312G)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>> wrote: -----
To: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
From: "Kazz, Greg J (312G)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Date: 05/12/2013 17:39
Cc: Tom Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>
Subject: Re: Fig.2-1 and 2-2 (Encapsulation Packet) - Towards Issue 3 of CCSDS 130.0-G Overview of Space Communications Protocols - Green Book

Gian Paolo,

I send out a new email to the SLP WG informing them that I posted an older version of the GB by mistake. I have now uploaded the most recent version completed on May 7 which included some of the changes you are asking for in Figure 2.1, namily the "pink" lines are removed in the May 7 version. I recall we discussed those changes during our meeting in Bordeaux already.

I concur with the other changes you are recommending and I will send the updated figures to Tom for inclusion into the document.

Best regards,

Greg

From: "Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>" <Gian.Paolo.Calzolari at esa.int<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Thursday, December 5, 2013 8:01 AM
To: "Kazz, Greg J (313B)" <greg.j.kazz at jpl.nasa.gov<mailto:greg.j.kazz at jpl.nasa.gov>>
Cc: Tom Gannett <tomg at aiaa.org<mailto:tomg at aiaa.org>>
Subject: Fig.2-1 and 2-2 (Encapsulation Packet) - Towards Issue 3 of CCSDS 130.0-G Overview of Space Communications Protocols - Green Book

Greg,
        following the mail sent this (European) morning, I have tried to capture graphically comments for Figure 2-1 and 2-2.

I think Figure 2-2- is really wrong as some connections are to be deleted.
Moreover (also for consistency with a figure in IPoC) it would be good to lift the IPoC box.
This last suggestion applies also to Fig 2-1 that is not formally wrong but a little misleading.

Regards

Gian Paolo

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20131205/3848d1ab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 130x0g2_master_Dec6_2013gjk.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 12664098 bytes
Desc: 130x0g2_master_Dec6_2013gjk.docx
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20131205/3848d1ab/attachment.docx>