[CESG] IOAG: Service Catalogue #1 / File Services warning (complete)

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Sep 27 15:32:38 UTC 2016


Keith, 
        try to keep in mind that an IOAG Service is indeed a collection of 
Space Link Interface Standards & Ground Link Interface Standards. 
Moreover, as Nestor underlined, Catalog 1 is for ABA configuration and the 
CFDP transmission only covers the single hop space to ground (or vice 
versa).

When you say "  I understood the forward file service to have evolved into 
a mechanism/semantic for zipping a bunch of stuff together (metadata, 
data, etc.) " I think you refer to the  Ground Link Interface Standard 
under development in CSS; i.e. only to a part of the IOAG Serrvice.

Last but not least I am very puzzled by the statement "forward frame 
service running over bundles". Catalog 2 states that <<The CSTS Forward 
Frame Services above is ?to be written?. It is assumed that this Service 
will provide a forward frame service for [AOS] and [TC-DLP] implementing 
multiplexing, frame fill and coding in the provider and implementing the 
full stack down to the physical layer>> so having AOS or TC frames running 
over bundles would reverse our CSCDS Stack where are bundles that - throug 
e.g. encapsulation service - run over AOS and TC frames.

Regards

Gian Paolo



From:   "Scott, Keith L." <kscott at mitre.org>
To:     "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, 
"Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, "CCSDS Engineering 
Steering Group - CESG Exec(cesg at mailman.ccsds.org)" 
<cesg at mailman.ccsds.org>
Date:   26/09/2016 22:06
Subject:        Re: [CESG] IOAG: Service Catalogue #1
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org>



Peter,
 
I think I agree with you.  My concern from the beginning has been that I 
do not want the forward file service to morph into a way to try to do 
multi-hop forwarding using file transfers as the ?data link? mechanism.  I 
understood the forward file service to have evolved into a 
mechanism/semantic for zipping a bunch of stuff together (metadata, data, 
etc.) to be used by the end system application (the receiver end of the 
data transfer), with possibly some application semantics layered on top.
 
In fact, if the forward-XXX services were generalized just a bit, I think 
they?d cover the DTN emergency command/telemetry case.  Or maybe the DTN 
emergency commanding service is the forward frame service running over 
bundles, I hadn?t thought of that until now but I like it.  If part of the 
CSTS forward-frame service states how to tunnel (in my case, FRAMES) to a 
remote location and then radiate them, and if it can be run over BP as a 
transport mechanism?   It would address an IOAG need, at least.
 
                                --keith
 
 
From: "cesg-bounces at mailman.ccsds.org" <cesg-bounces at mailman.ccsds.org> on 
behalf of Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Monday, September 26, 2016 at 3:33 PM
To: Nestor Peccia <Nestor.Peccia at esa.int>, CCSDS Exec 
<cesg at mailman.ccsds.org>
Subject: Re: [CESG] IOAG: Service Catalogue #1
 
Nestor,
 
I know that this is a late input, but after reading the IOAG Svc Cat #1 I 
have a very real concern that I think needs to be surfaced.  Four new 
services have been introduced, the "Forward/Return CFDP-File Service Type" 
and the "Forward/Return PACKETS-File Service Type".  In reading through 
the descriptions I find that they mention certain SM characteristics, but 
fail to acknowledge the required presence of a whole lot of "packet / file 
/ frame plumbing" that is missing in most of our current systems.  Of 
particular concern, from a standards and logistics point of view, is that 
these new standards require a lot of the "plumbing" that CSTS F-Frame is 
supposed to provide, but make no mention of that standard.  In fact, the 
precursor standards, "Forward Synchronous Encoded Frame Service Type" has 
been dropped, and what is left is just some sort of weak "forward 
reference" to a CSTS F-Frame service.
 
I think this is a huge mistake and that we should push back on it.
 
Here is the logic behind this:
 
1)      FF-CSTS includes the key services and functions that are required 
for anything like forward file, or forward packet, or forward DTN to work.
2)      These functions include, quoting from the report "Users shall be 
aware that IOAG Service Catalog 2 foresees a future CSTS Forward Frame 
Service that is assumed will provide a forward service for [AOS] and 
[TC-DLP] frames implementing multiplexing, frame fill and coding in the 
provider and implementing the full stack down to the physical layer."
3)      In order to implement a forward file or packet service all of 
these functions, plus frame creation, must be present in the service 
provider.
4)      It makes little technical sense to create forward file and forward 
packet services, as new separate services that embed all of these 
function, instead of creating the FF-CSTS service and then building CFDP 
and Packet service "plug-ins" on top of that which use this underlying 
service.
 
In fact, this approach is exactly how the forward file service is now 
described in the SCCS-ADD.  I draw your attention to CCSDS 901.1-M-1, sec 
5.2.2.2 and sec 6.2.2.2.  In fact, fig 6-4 shows the relationships among 
SM, CSTS F-Frame, the associated functions that are required, including 
ranging, and also SLE R-AF, and fig 6-8 (ABA ESLT Forward-File Protocol 
Building Blocks) shows how F-Frame and Fwd frame are designed to be 
integrated.  Any sort of forward packet service ought to just be a variant 
of this.
 
My recommendation is that CCSDS push back on this IOAG Cat 1 request for 
two new stand alone services and instead argue that CSTS F-Frame should be 
done first, and these other new service built upon that base.
 
Regards, Peter
 
 
 
From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Nestor Peccia 
<Nestor.Peccia at esa.int>
Date: Thursday, September 15, 2016 at 3:43 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: [CESG] IOAG: Service Catalogue #1
 
REMINDER 

Please let me have your comments (in particular from the CSS Area) by 22nd 
Sept 2016 cob. 

ciao 
nestor 

============================ 
Dear all, 

Please  find attached the Service Catalogue #1 that has been approved by 
the IOAG. 

You should be aware that the final approval regarding the editorial 
updates from NASA is still pending. There is an on-going discussion 
concerning service management ?function? vs. service management ?service?. 


However, this version is good enough to be processed by the CESG. 


[attachment "IOAG Service Catalog One.v2.0-Approved-20160823.pdf" deleted 
by Nestor Peccia/esoc/ESA] 
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823withBars.pdf" 
deleted by Nestor Peccia/esoc/ESA] 

CESG will address this update during our next webex. 

Main changes are : 
1.      forward / return CFDP file over terrestrial generic file 
2.      forward / return packet file service  over terrestrial generic 
file 
3.      Service Management functions


ciao 
nestor 
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.
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg


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/cesg/attachments/20160927/51459d3a/attachment.html>


More information about the CESG mailing list