<font size=2 face="sans-serif">Keith, <br>
try to keep in mind that an IOAG Service is
indeed a collection of Space Link Interface Standards & Ground Link
Interface Standards. <br>
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).</font>
<br>
<br><font size=2 face="sans-serif">When you say "</font><font size=2 face="Calibri">
I understood the forward file service to have evolved into a mechanism/semantic
for zipping a bunch of stuff together (metadata, data, etc.) </font><font size=2 face="sans-serif">"
I think you refer to the Ground Link Interface Standard under development
in CSS; i.e. only to a part of the IOAG Serrvice.</font>
<br>
<br><font size=2 face="sans-serif">Last but not least I am very puzzled
by the statement "</font><font size=2 face="Calibri">forward frame
service running over bundles</font><font size=2 face="sans-serif">".
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.</font>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br>
<br><font size=2 face="sans-serif">Gian Paolo</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Scott, Keith
L." <kscott@mitre.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov>, "Nestor.Peccia@esa.int"
<Nestor.Peccia@esa.int>, "CCSDS Engineering Steering Group -
CESG Exec(cesg@mailman.ccsds.org)" <cesg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">26/09/2016 22:06</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [CESG] IOAG:
Service Catalogue #1</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Sent by:
</font><font size=1 face="sans-serif">"CESG"
<cesg-bounces@mailman.ccsds.org></font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Peter,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">
--keith</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>"cesg-bounces@mailman.ccsds.org"
<cesg-bounces@mailman.ccsds.org> on behalf of Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Date: </b>Monday, September 26, 2016 at 3:33 PM<b><br>
To: </b>Nestor Peccia <Nestor.Peccia@esa.int>, CCSDS Exec <cesg@mailman.ccsds.org><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Calibri">Nestor,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">I think this is a huge mistake and that
we should push back on it.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Here is the logic behind this:</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Times New Roman">1) </font><font size=2 face="Calibri">FF-CSTS
includes the key services and functions that are required for anything
like forward file, or forward packet, or forward DTN to work.</font>
<br><font size=3 face="Times New Roman">2) </font><font size=2 face="Calibri">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."</font>
<br><font size=3 face="Times New Roman">3) </font><font size=2 face="Calibri">In
order to implement a forward file or packet service all of these functions,
<b><i>plus</i></b> frame creation, must be present in the service provider.</font>
<br><font size=3 face="Times New Roman">4) </font><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Regards, Peter</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>CESG <cesg-bounces@mailman.ccsds.org>
on behalf of Nestor Peccia <Nestor.Peccia@esa.int><b><br>
Date: </b>Thursday, September 15, 2016 at 3:43 AM<b><br>
To: </b>CCSDS Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org><b><br>
Subject: </b>[CESG] IOAG: Service Catalogue #1</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 color=red><u>REMINDER</u></font><font size=3 face="Times New Roman">
<br>
</font><font size=2><br>
Please let me have your comments (in particular from the CSS Area) by 22nd
Sept 2016 cob.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2><br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2><br>
nestor</font><font size=3 face="Times New Roman"> <br>
</font><font size=2><br>
============================</font><font size=3 face="Times New Roman">
</font><font size=2><br>
Dear all,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2><br>
Please find attached the Service Catalogue #1 that has been approved
by the IOAG. </font><font size=3 face="Times New Roman"><br>
</font><font size=2><br>
You should be aware that the final approval regarding the editorial updates
from NASA is still pending. There is an on-going discussion </font><font size=2 face="Calibri">concerning
service management “function” vs. service management “service”.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2><br>
However, this version is good enough to be processed by the CESG.</font><font size=3 face="Times New Roman">
<br>
<br>
</font><font size=2><br>
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823.pdf"
deleted by Nestor Peccia/esoc/ESA] <br>
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823withBars.pdf"
deleted by Nestor Peccia/esoc/ESA] </font><font size=3 face="Times New Roman"><br>
</font><font size=2><br>
CESG will address this update during our next webex.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2><br>
Main changes are :</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="sans-serif">1. </font><font size=2>forward
/ return CFDP file over terrestrial generic file</font><font size=3 face="Times New Roman">
</font>
<br><font size=2 face="sans-serif">2. </font><font size=2>forward
/ return packet file service over terrestrial generic file</font><font size=3 face="Times New Roman">
</font>
<br><font size=2 face="sans-serif">3. </font><font size=2>Service
Management functions</font>
<br><font size=3 face="Times New Roman"><br>
</font><font size=2><br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2><br>
nestor</font><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font><tt><font size=2>_______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org<br>
</font></tt><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><tt><font size=2>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</font></tt></a><tt><font size=2><br>
</font></tt>
<br><PRE>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.
</PRE>