<font size=2 face="sans-serif">Peter, </font>
<br><font size=2 face="sans-serif"> a
few replies below.</font>
<br><font size=2 face="sans-serif">BTW, note that I missed a NOT and added
a ? too much; i.e. I meant: I am NOT sure I really
understand what you mean for </font><font size=2 face="Calibri"> "packet
/ file / frame plumbing"</font><font size=3 face="Times New Roman">.</font>
<br><font size=3 face="Times New Roman">Regards</font>
<br>
<br><font size=3 face="Times New Roman">Gippo</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Gian.Paolo.Calzolari@esa.int"
<Gian.Paolo.Calzolari@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"CCSDS Engineering
Steering Group - CESG Exec(cesg@mailman.ccsds.org)" <cesg@mailman.ccsds.org>,
"CESG" <cesg-bounces@mailman.ccsds.org>, "Nestor.Peccia@esa.int"
<Nestor.Peccia@esa.int></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">27/09/2016 18:15</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [CESG] IOAG:
Service Catalogue #1 / "packet / file / frame plumbing"</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Hi Gippo,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Please go look at the SCCS-ADD (or ARD)
which have carefully prepared (and reviewed) diagrams that show just exactly
what is involved in providing the F-Frame service and an ABA forward file
service built on top of it. You are quite right that "</font><font size=2 face="sans-serif">Space/Encapsulation
Packets, reliable/unreliable transfer, COP usage" </font><font size=2 face="Calibri">are
functions that will need to be built to operate the service and that it
will be necessary to also define and build the Service Management (SM)
capabilities that will allow these functions to be requested, managed,
and configured by the service user. But that is not all that will
be required.</font>
<br><font size=2 color=blue face="Calibri">GPC: I never said this is the
end of the story. My understand is that IOAG gives requirements (sometimes
with some warning) and CCSDS then does the full work.</font>
<br><font size=2 color=blue face="Calibri">Alternativekly you could say</font>
<br><font size=2 color=blue face="Calibri">IOAG = what</font>
<br><font size=2 color=blue face="Calibri">CCSDS = how</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">The more significant "plumbing"
that I was referencing includes: CFDP protocol processing, SPP packet creating,
frame creation (AOS or TC), frame merging & multiplexing into separate
VCs, and frame encoding. All of those functions are defined in the
ADD, some assigned to F-Frame (from frame creation down), as a re-usable
set of structures, and some to specific services (such as CFDP and SPP).
And all of those functions also need SM capabilities defined. Furthermore,
those functions, as defined in the F-Frame service description, are re-usable
and can support both ABA and SSI protocol stacks and end-to-end services.</font>
<br><font size=2 color=blue face="Calibri">GPC: It seems we are basically
matching about the idea of plumbing. Indeed IOAG states that some plumbing
(e.g. COP usage, reliable transfer) can drive to complex systems.</font>
<br><font size=2 color=blue face="Calibri">With respcet to the "</font><font size=2 face="Calibri">re-usable
set of structures</font><font size=2 color=blue face="Calibri">" I
think you even go beyond CCSDS unless you mean that part of that (future)
standard can be used for other standards. If you do not mean that and you
intend reusable software then you are into the implemenation domain (out
of CCSDS in principle)</font>
<br>
<br><font size=2 face="Calibri">To say that the "IOAG File services
suppose a file is passed from A to B" is to ignore all of the actual
plumbing that is required to make this happen. From a simplistic,
"top level", view this may be acceptable, but from a protocol
view we really need to understand and define the whole set of protocols
in the stack(s) and the gyrations that they go through. We cannot
ignore the plumbing. So, in order to define a set of services that
maximize functionality for the users and minimize the effort on the part
of the ESLT (and the users) we took the approach defined in the SCCS-ADD.
You were one of the reviewers and approvers of that document, I assumed
you were familiar with it.</font>
<br><font size=2 color=blue face="Calibri">GPC: To say that
the "IOAG File services suppose a file is passed from A to B"
is NOT to ignore all of the actual plumbing. It simply says that the splitting
of tasks is different and the related standards are different. Again, CCSDS
is the authority to determine the standardization details.</font>
<br>
<br><font size=2 face="Calibri">I hope you recall that the origins of this
F-Frame approach was in the IOAG SISG, in a sub-committee that you, Wolfgang,
and I participated in. The focus there was on space internetworking,
but the forward frame service we cooked up was a general one and entirely
suitable for the "plumbing" of even these sorts of ABA services.
And that is exactly what is described in the SCCS-ADD.</font>
<br><font size=2 color=blue face="Calibri">GPC: I do recall but you forgot
I was there working on many details of F-Frame :o) . However, as mention,
if Agency A wants to pass a file for uplink to Agency B, the work snd the
standards are different from those implied when Agency A wants to pass
frame for uplink to Agency B .</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">I think we should stick to the plan of
developing the F-Frame first, and building these other services on top
of that framework instead of developing another collection of "one-off"
SLE-like services.</font>
<br><font size=2 color=blue face="Calibri">GPC: What has this to
do with IOAG Catalogs. Catalog 1 and Catalog 2 define IOAG Services with
some envisaged components (e.g. Space Link Interface Standards & Ground
Link Interface Standards & Service Management Standards & Data
Format Standards). Out of the catalogs, IOAG define priorities and need
dates to which CCSDS react accordingly of even in disagreement.</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>Gian Paolo Calzolari <Gian.Paolo.Calzolari@esa.int><b><br>
Date: </b>Tuesday, September 27, 2016 at 8:53 AM<b><br>
To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><b><br>
Cc: </b>CCSDS Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org>,
CESG <cesg-bounces@mailman.ccsds.org>, Nestor Peccia <Nestor.Peccia@esa.int><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / "packet / file
/ frame plumbing"</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="sans-serif">Peter,</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
I am sure I really understand what you mean
for </font><font size=2 face="Calibri"> "packet / file / frame
plumbing"</font><font size=2 face="sans-serif">?</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
It looks to me that the description in Catalog 1 for the four files services
(two directions x two flavours) do underline that the service provide will
have to do quite some work (plumbing?) about Space/Encapsulation Packets,
reliable/unreliable transfer, COP usage,</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
You also say the CSTS F-Frame is supposed to provide most of this
plumbing but yor comment is ot about IOAG Catalog bu rather about the service
an agency should select.</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
In fact the IOAG File services suppose a file is passed from A to B, while
F-Frame supposes frames are passed fromA to B.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><br>
Regards</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="sans-serif"><br>
Gian Paolo</font><font size=3 face="Times New Roman"> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">"Shames,
Peter M (312B)" <peter.m.shames@jpl.nasa.gov></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"Nestor.Peccia@esa.int"
<Nestor.Peccia@esa.int>, "CCSDS Engineering Steering Group -
CESG Exec(cesg@mailman.ccsds.org)" <cesg@mailman.ccsds.org></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">26/09/2016
21:33</font><font size=3 face="Times New Roman"> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
[CESG] IOAG: Service Catalogue #1</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><font size=1 face="sans-serif">"CESG"
<cesg-bounces@mailman.ccsds.org></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Calibri"><br>
Nestor,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
I think this is a huge mistake and that we should push back on it.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
Here is the logic behind this:</font><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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."</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
3) 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><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
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.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
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><font size=3 face="Times New Roman">
</font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
Regards, Peter</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=3 face="Calibri"><b><br>
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><font size=3 face="Times New Roman">
<br>
</font><font size=2 color=red face="sans-serif"><u><br>
REMINDER</u></font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<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"> </font><font size=2 face="sans-serif"><br>
<br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
nestor</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
============================</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
Dear all,</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
<br>
Please find attached the Service Catalogue #1 that has been approved
by the IOAG. <br>
<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">
</font><font size=2 face="sans-serif"><br>
<br>
However, this version is good enough to be processed by the CESG.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><br>
<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] <br>
<br>
CESG will address this update during our next webex.</font><font size=3 face="Times New Roman">
</font><font size=2 face="sans-serif"><br>
<br>
Main changes are :</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
1. forward / return CFDP file over terrestrial
generic file</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
2. forward / return packet file service over
terrestrial generic file</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
3. Service Management functions</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="sans-serif"><br>
<br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2 face="sans-serif"><br>
nestor</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
This message and any attachments are intended for the use of the addressee
or addressees only.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
content is not permitted.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
If you received this message in error, please notify the sender and delete
it from your system.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Courier New"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Please consider the environment before printing this email._______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=2 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a>
<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>
<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>