<font size=2 face="sans-serif">Tomaso, </font>
<br><font size=2 face="sans-serif">        I
think the reason of using CFDP was to move a collection of data. So the
encapsulator was rather the file than CFDP.</font>
<br><font size=2 face="sans-serif">Ciao</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"><Tomaso.deCola@dlr.de></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif"><kscott@mitre.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif"><peter.m.shames@jpl.nasa.gov>,
<Gian.Paolo.Calzolari@esa.int>, <cesg-bounces@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">27/09/2016 20:13</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">Re: [CESG] IOAG:
Service Catalogue #1 / File Services warning (complete)</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=3>I also see the use of CFDP as encapsulator not so efficient.
Probably at the time it was conceived with 4 classes, core and extended
procedures, it could have made more sense. But now looking at future missions
we might want to consider something lighter and at the same time more efficient,
at least in my view.</font>
<br>
<br><font size=3>Tomaso<br>
<br>
Sent from my iPhone</font>
<br><font size=3><br>
On 27 Sep 2016, at 19:52, Scott, Keith L. <</font><a href=mailto:kscott@mitre.org><font size=3 color=blue><u>kscott@mitre.org</u></font></a><font size=3>>
wrote:<br>
</font>
<br><font size=2 face="Calibri">Peter,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">OK, maybe my notion of co-opting the FF
service over BP to implement fh/lh was/is premature or insane.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Gipo:  While service catalog 2 may
mention CFDP as an implementation mechanism for the FH/LH service I think
that’s the wrong way to go.  Since service catalog 2 is in the future
(as you point out) we (should) have the flexibility to change our minds
about how the implementation should work and not be tied to something that
got put there as a placeholder some number of years ago.  This argument
is of course predicated on my ability to convince you and others that a
fh/lh app over BP is “better than” (by some metric(s)) fh/lh over cfdp
over bp.</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=3 face="Calibri"><b>From: </b>Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 1:27 PM<b><br>
To: </b>Keith Scott <</font><a href=mailto:kscott@mitre.org><font size=3 color=blue face="Calibri"><u>kscott@mitre.org</u></font></a><font size=3 face="Calibri">>,
"</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">"
<</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">>,
Gian Calzolari <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=3 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>"</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>,
CCSDS Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Calibri">Hi Keith,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">I agree completely with your first paragraph.
 That is a very good description of the first hop / last hop service
and the motivation for it.  That service concept also came out of
the IOAG SISG work and is now in the SCCS ADD.  It is, as agreed,
marked as a [Future] service, one that I think you are now starting to
define.  I'll also point out that the stack of protocol PDUs that
would appear "on the wire" over a space link, would look like
this:</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri">-          </font><font size=2 face="Calibri">FH/LH
PDU</font>
<br><font size=3 face="Courier New">o   </font><font size=2 face="Calibri">Meta
data</font>
<br><font size=3 face="Courier New">o   </font><font size=2 face="Calibri">CCSDS
frames (destined for the end node)</font>
<br><font size=3 face="Calibri">-          </font><font size=2 face="Calibri">Bundles
(BP)</font>
<br><font size=3 face="Calibri">-          </font><font size=2 face="Calibri">LTP
(probably)</font>
<br><font size=3 face="Calibri">-          </font><font size=2 face="Calibri">CCSDS
space data link frames (for the relay node)</font>
<br><font size=3 face="Calibri">-          </font><font size=2 face="Calibri">And
the usual space link coding, modulation, etc</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">So that is a case of "CCSDS Link over
BP", but it is only for the express purpose of kick-starting an end
node that was in trouble, or for communicating with an end node that was
never BP enabled.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">In your second paragraph the first sentence
sounds fine, but in the last two sentences things sort of, from my point
of view, go off the rails. The F-Frame, as defined, is really quite different
from the LH/FH service.  I think that the SCCS-ADD makes those differences
quite clear so I won't try and re-describe them here.  In the current
deployed Internet, as used under SLE and CSTS, the protocols that are used
terrestrially are TCP/IP and that is what SLE and CSTS are predicated on.
 There's even a spec that describes what that stack looks like and
it says nothing about running SLE/CSTS over BP.  I will grant you,
however, that in some future we could be running DTN everywhere, terrestrially
and in space, and in that future CSTS could be run over BP instead of TCP/IP.
 </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">That said, even in that future state, it
would still have to be the case that the transport of BP bundles, over
the space link, would be done over the usual sort of space link protocol
(USLP would be my choice) and over some sort of suitable coding and modulation,
with some sort of suitable ranging signals.  These could be RF or
optical, where "suitable" depends on distances, data rates, require
coding gain, etc.   I do not think it would ever be accurate to say
that we would carry "space link over BP" in that future except
in the FH/LH circumstance, or something like it.</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=3 face="Calibri"><b>From: </b>Keith Scott <</font><a href=mailto:kscott@mitre.org><font size=3 color=blue face="Calibri"><u>kscott@mitre.org</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 10:08 AM<b><br>
To: </b>"</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">"
<</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">>,
Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">>,
Gian Paolo Calzolari <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=3 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>"</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>,
CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Calibri">Right, this is the notion in the ICPA of
what Chris Taylor referred to as ‘first-hop / last-hop’ services.  If
you’ve got a spacecraft that is otherwise SSI-aware but is now in trouble,
it might not HAVE DTE capability and the only way to get emergency link-layer
commands to it (assuming it was built to do that, which seems reasonable)
would be to ship a bunch of frames to some SSI-enabled spacecraft NEAR
the troubled one, then blast those frames at the troubled one.  My
notion is that this is a standardized application that could be present
on all (ok, many) SSI-enabled spacecraft, and the standardization bit is
in how to express the ‘here’s what to send and here’s how to send it’
part.  The content (data + instructions) is shipped to the functioning
spacecraft over one of the the SSI networking protocols (BP or IP).</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">My understanding is that the FF service
takes frames, moves them somewhere, combines them with other stuff and/or
does whatever needs to be done to form a transmittable serialized stream
of bits, and hands that stream off for radiation.  If that understanding
is correct, if I use bundles as the shipment mechanism, FF service is pretty
much a description of the SSI first hop / last hop service.  And,
I hope that unless there’s a need to be more specific, the forward frame
service could use any number of underlying mechanisms for shipment (e.g.
TCP/IP suite, BP, etc.)</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=3 face="Calibri"><b>From: </b>"</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">"
<</font><a href=mailto:Tomaso.deCola@dlr.de><font size=3 color=blue face="Calibri"><u>Tomaso.deCola@dlr.de</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 12:59 PM<b><br>
To: </b>Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">>,
Gian Calzolari <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=3 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=3 face="Calibri">>,
Keith Scott <</font><a href=mailto:kscott@mitre.org><font size=3 color=blue face="Calibri"><u>kscott@mitre.org</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>"</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>,
CCSDS Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>RE: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 color=#004080 face="Calibri">If I don’t misinterpret
Keith’s statement, I think it is about exploiting tunneling capabilities
of the bundle protocol so that is able to transport “blindly” CCSDS frames.
Obviously we don’t want to flip the CCSDS protocol stack.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Tomaso </font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#5f5f5f face="Arial">————————————————————————</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#5f5f5f face="Arial"><b><br>
Deutsches Zentrum für Luft- und Raumfahrt</b> (DLR)</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#5f5f5f face="Arial"><br>
German Aerospace Center</font><font size=3 color=#004080 face="Times New Roman">
</font><font size=2 color=#5f5f5f face="Arial"><br>
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen
| 82234 Wessling | Germany</font><font size=3 color=#004080 face="Times New Roman">
</font>
<br><font size=2 color=#5f5f5f face="Arial"><b>Tomaso de Cola, Ph.D.</b></font><font size=2 color=#004080 face="Calibri">
</font><font size=2 color=#5f5f5f face="Arial"><br>
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 |</font><font size=2 color=#004080 face="Arial">
</font><a href=mailto:tomaso.decola@dlr.de><font size=2 color=blue face="Arial"><u>tomaso.decola@dlr.de</u></font></a><font size=2 color=#004080 face="Calibri">
</font><font size=2 color=blue face="Arial"><u><br>
</u></font><a href=http://www.dlr.de/kn/institut/abteilungen/san><font size=2 color=blue face="Arial"><u>http://www.dlr.de/kn/institut/abteilungen/san</u></font></a><font size=2 color=#004080 face="Calibri">
</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Tahoma"><b>From:</b> CESG [</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=2 color=blue face="Tahoma"><u>mailto:cesg-bounces@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">]
<b>On Behalf Of </b>Shames, Peter M (312B)<b><br>
Sent:</b> Tuesday, September 27, 2016 6:35 PM<b><br>
To:</b> </font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Tahoma"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Tahoma">;
Scott, Keith L.<b><br>
Cc:</b> CESG; CCSDS Engineering Steering Group - CESG Exec(</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Tahoma"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Tahoma">)<b><br>
Subject:</b> Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Calibri">Gotta say I agree with Gippo on the last
part of this.  I too found that </font><font size=2 face="Arial">"</font><font size=2 face="Calibri">forward
frame service running over bundles</font><font size=2 face="Arial">"
statement </font><font size=2 face="Calibri">very confusing.  Was
it a typo?</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">The operating assumption, as documented
in SCCS-ADD, is that DTN bundles run on top of CCSDS frames and thus on
top of CSTS services, not underneath them.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Peter</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 <</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=3 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Tuesday, September 27, 2016 at 8:32 AM<b><br>
To: </b>Keith Scott <</font><a href=mailto:kscott@mitre.org><font size=3 color=blue face="Calibri"><u>kscott@mitre.org</u></font></a><font size=3 face="Calibri">><b><br>
Cc: </b>CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>,
CESG <</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>,
Nestor Peccia <</font><a href=mailto:Nestor.Peccia@esa.int><font size=3 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=3 face="Calibri">>,
Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Arial">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><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
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="Arial">"
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><font size=3 face="Times New Roman">
</font><font size=3 color=red face="Times New Roman"><br>
</font><font size=2 color=red face="Arial"><br>
Last but not least I am very puzzled by the statement "</font><font size=2 color=red face="Calibri">forward
frame service running over bundles</font><font size=2 color=red face="Arial">".
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><font size=3 color=red face="Times New Roman">
</font><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Arial"><br>
Regards</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Gian Paolo</font><font size=3 face="Times New Roman"> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="Arial"><br>
From:        </font><font size=1 face="Arial">"Scott,
Keith L." <</font><a href=mailto:kscott@mitre.org><font size=1 color=blue face="Arial"><u>kscott@mitre.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
To:        </font><font size=1 face="Arial">"Shames,
Peter M (312B)" <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=1 color=blue face="Arial"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=1 face="Arial">>,
"</font><a href=mailto:Nestor.Peccia@esa.int><font size=1 color=blue face="Arial"><u>Nestor.Peccia@esa.int</u></font></a><font size=1 face="Arial">"
<</font><a href=mailto:Nestor.Peccia@esa.int><font size=1 color=blue face="Arial"><u>Nestor.Peccia@esa.int</u></font></a><font size=1 face="Arial">>,
"CCSDS Engineering Steering Group - CESG Exec(</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">)"
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Date:        </font><font size=1 face="Arial">26/09/2016
22:06</font><font size=3 face="Times New Roman"> </font><font size=1 color=#5f5f5f face="Arial"><br>
Subject:        </font><font size=1 face="Arial">Re:
[CESG] IOAG: Service Catalogue #1</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Sent by:        </font><font size=1 face="Arial">"CESG"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=1 color=blue face="Arial"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></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>
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>
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><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, 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><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>
                    
           --keith</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>"</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>
on behalf of Peter Shames <</font><a href=mailto:peter.m.shames@jpl.nasa.gov><font size=3 color=blue face="Calibri"><u>peter.m.shames@jpl.nasa.gov</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Monday, September 26, 2016 at 3:33 PM<b><br>
To: </b>Nestor Peccia <</font><a href=mailto:Nestor.Peccia@esa.int><font size=3 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=3 face="Calibri">>,
CCSDS Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><b><br>
Subject: </b>Re: [CESG] IOAG: Service Catalogue #1</font><font size=3 face="Times New Roman">
<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"> <br>
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><font size=3 face="Times New Roman">
<br>
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><font size=3 face="Times New Roman">
<br>
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><font size=3 face="Times New Roman">
<br>
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><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 <</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=3 color=blue face="Calibri"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">>
on behalf of Nestor Peccia <</font><a href=mailto:Nestor.Peccia@esa.int><font size=3 color=blue face="Calibri"><u>Nestor.Peccia@esa.int</u></font></a><font size=3 face="Calibri">><b><br>
Date: </b>Thursday, September 15, 2016 at 3:43 AM<b><br>
To: </b>CCSDS Engineering Steering Group - CESG Exec <</font><a href=mailto:cesg@mailman.ccsds.org><font size=3 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=3 face="Calibri">><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="Times New Roman"><u><br>
REMINDER</u></font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><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="Times New Roman"><br>
<br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
nestor</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><br>
<br>
============================</font><font size=3 face="Times New Roman">
</font><font size=2 face="Times New Roman"><br>
Dear all,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><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="Times New Roman"><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="Times New Roman"><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="Times New Roman"><br>
<br>
Main changes are :</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
1.        </font><font size=2 face="Times New Roman">forward
/ return CFDP file over terrestrial generic file</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
2.        </font><font size=2 face="Times New Roman">forward
/ return packet file service  over terrestrial generic file</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
3.        </font><font size=2 face="Times New Roman">Service
Management functions</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Times New Roman"><br>
<br>
ciao</font><font size=3 face="Times New Roman"> </font><font size=2 face="Times New Roman"><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</font><font size=2 color=blue face="Courier New"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=2 color=blue face="Courier New"><u>CESG@mailman.ccsds.org</u></font></a><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>