[CESG] Last/First hop with CFDP over DTN: IOAG: Service Catalogue #1 / File Services warning (complete)
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Tue Sep 27 18:15:32 UTC 2016
Keith,
if I remember well the decision of using CFDP was due to the fact
that for First/Last Hop Services you do not need to move only frames.
FORWARD LAST HOP DELIVERY SERVICE assumed that "A standard file format is
assumed as the means for the user (i.e. the Control Center of the
spacecraft being the last node n) to transmit both the data to be
delivered and the metadata such as instructions about how to deliver it in
a consistent way, proximity-1 configuration, etc."
RETURN FIRST HOP DELIVERY SERVICE says that actually "Opposite to the case
of the forward direction there will be two files involved:
? the first file, traveling from the user to the Delivery Agent, contains
metadata needed by the Delivery Agent such as details about which data
shall be collected, configuration and delivery instructions;
? the second file, traveling from the Delivery Agent to user, contains the
requested data including Delivery Agent generated annotations."
Of course everything can be discussed and modified :o)
Ciao
Gian Paolo
From: "Scott, Keith L." <kscott at mitre.org>
To: "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>,
"Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>,
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "cesg-bounces at mailman.ccsds.org" <cesg-bounces at mailman.ccsds.org>,
"cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>
Date: 27/09/2016 19:52
Subject: Re: [CESG] IOAG: Service Catalogue #1 / File Services
warning (complete)
Peter,
OK, maybe my notion of co-opting the FF service over BP to implement fh/lh
was/is premature or insane.
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.
--keith
From: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, September 27, 2016 at 1:27 PM
To: Keith Scott <kscott at mitre.org>, "Tomaso.deCola at dlr.de"
<Tomaso.deCola at dlr.de>, Gian Calzolari <Gian.Paolo.Calzolari at esa.int>
Cc: "cesg-bounces at mailman.ccsds.org" <cesg-bounces at mailman.ccsds.org>,
CCSDS Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)
Hi Keith,
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:
- FH/LH PDU
o Meta data
o CCSDS frames (destined for the end node)
- Bundles (BP)
- LTP (probably)
- CCSDS space data link frames (for the relay node)
- And the usual space link coding, modulation, etc
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.
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.
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.
Regards, Peter
From: Keith Scott <kscott at mitre.org>
Date: Tuesday, September 27, 2016 at 10:08 AM
To: "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>, Peter Shames
<peter.m.shames at jpl.nasa.gov>, Gian Paolo Calzolari
<Gian.Paolo.Calzolari at esa.int>
Cc: "cesg-bounces at mailman.ccsds.org" <cesg-bounces at mailman.ccsds.org>,
CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)
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).
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.)
--keith
From: "Tomaso.deCola at dlr.de" <Tomaso.deCola at dlr.de>
Date: Tuesday, September 27, 2016 at 12:59 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Gian Calzolari
<Gian.Paolo.Calzolari at esa.int>, Keith Scott <kscott at mitre.org>
Cc: "cesg-bounces at mailman.ccsds.org" <cesg-bounces at mailman.ccsds.org>,
CCSDS Exec <cesg at mailman.ccsds.org>
Subject: RE: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)
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.
Tomaso
????????????????????????
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks |
Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax +49 8153 28-2844 |
tomaso.decola at dlr.de
http://www.dlr.de/kn/institut/abteilungen/san
From: CESG [mailto:cesg-bounces at mailman.ccsds.org] On Behalf Of Shames,
Peter M (312B)
Sent: Tuesday, September 27, 2016 6:35 PM
To: Gian.Paolo.Calzolari at esa.int; Scott, Keith L.
Cc: CESG; CCSDS Engineering Steering Group - CESG
Exec(cesg at mailman.ccsds.org)
Subject: Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)
Gotta say I agree with Gippo on the last part of this. I too found that "
forward frame service running over bundles" statement very confusing. Was
it a typo?
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.
Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, September 27, 2016 at 8:32 AM
To: Keith Scott <kscott at mitre.org>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>,
CESG <cesg-bounces at mailman.ccsds.org>, Nestor Peccia <
Nestor.Peccia at esa.int>, Peter Shames <peter.m.shames at jpl.nasa.gov>
Subject: Re: [CESG] IOAG: Service Catalogue #1 / File Services warning
(complete)
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.
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/d4f5cd0b/attachment.html>
More information about the CESG
mailing list