[CESG] Can we put a quick discussion of the SSI Architecture
Document on the agenda for the telecon?
Chris.Taylor at esa.int
Chris.Taylor at esa.int
Thu Oct 10 14:20:42 EDT 2013
Dear Peter, yes we are close enough, let's just make the minimum changes to
the existing document and publish.
For the hardware support, I think you have overestimated the flight
processing capabilities. We are not flying commercial laptops on ESA
spacecraft and all CFDP (similar functionality to DTN) implementations
(including JWST) require hardware acceleration.to reach the typical downlink
speeds. But this is another discussion and we should save it for another day,
Kind regards,
//ct
From: "Shames, Peter M (312G)" <peter.m.shames at jpl.nasa.gov>
To: "Chris.Taylor at esa.int" <Chris.Taylor at esa.int>,
Cc: "CCSDS Engineering Steering Group - CESG Exec
(cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org>,
"cesg-bounces at mailman.ccsds.org"
<cesg-bounces at mailman.ccsds.org>, "John.j.rush at nasa.gov"
<John.j.rush at nasa.gov>, "Scott, Keith L." <kscott at mitre.org>,
"Nestor Peccia (nestor.peccia at esa.int)" <nestor.peccia at esa.int>,
"Burleigh, Scott C (312G)" <scott.c.burleigh at jpl.nasa.gov>
Date: 10/10/2013 17:25
Subject: Re: [CESG] Can we put a quick discussion of the SSI Architecture
Document on the agenda for the telecon?
Hi Chris,
I think we are in agreement on a few things:
1) We need a complete enough and stable set of specs in order to engage
the missions and the space comm service providers. These are likely to be
rolled out in stages, as was the terrestrial Internet, but the core parts
must be there. The core parts of DTN (BP, LTP, BSP, UT layer, CGR) are
largely stable and available now.
2) Network management, routing updates, and schedule coordination can be
done manually for now, until the number of nodes grows, so the the more
advanced, automated, protocols to do this cn be staged later.
3) While missions can (and have) adopted DTN on their own, using manual
means to coordinate services, we really do need to provide the DTN
services as part of the space comm service provider suite of services on
the ground. This is the piece that was missing acknowldgement in the SSI
document.
4) As you point out, we will also need to have space comm service
providers in space, such as relay spacecraft, relay stations on other
planets (eventually) and hybrid relay / science spacecraft as interim
providers.
As for "unrealistic to think we can run the DTN protocols in software at
the required speed", I know that is not an issue. Perhaps for extremely
high performance communications we may need some added hardware support,
but the current software approaches already run at 2 Gbps speeds. The
current DTN software, which complies on Linux, Windows, RTEMS, and other
OS platforms, can run at 2 Gbps speeds on a normal, Linux, desktop
computer. There is no technical reason why this could not be ported today
to a co-processor in an SDR, and provide communications speeds that vastly
exceed the link speeds that most of our missions are presently capable of.
Regards, Peter
On 10/10/13 12:20 AM, "Chris.Taylor at esa.int" <Chris.Taylor at esa.int> wrote:
>Peter, l I have no problem with the rearrangement of the slides as I
>assume
>it is only a small change, but I find the term "space communications
>service
>providers" a little confusing. I guess this refers to the ground services,
>which is fine but ignores the changes required in the space segment? I do
>think that the most important way forward is to provide standard DTN
>services
>in the ground segment as only then will the space segment developers
>follow.
>It is unrealistic to think that missions will be willing to incur the
>cost/risk of both flight and ground segment updates.
>
>For the flight segment we need stable CCSDS specs and then a period of
>R&D to
>develop the required hardware support as it is unrealistic to think we can
>run the DTN protocols in software at the required speed.
>
>Regards,
>//ct
>
>
>
>From: "Shames, Peter M (312G)" <peter.m.shames at jpl.nasa.gov>
>To: "Scott, Keith L." <kscott at mitre.org>, "Nestor Peccia
> (nestor.peccia at esa.int)" <nestor.peccia at esa.int>,
>Cc: "Burleigh, Scott C \(312G\)" <scott.c.burleigh at jpl.nasa.gov>,
> "John.j.rush at nasa.gov" <John.j.rush at nasa.gov>, "CCSDS
>Engineering
> Steering Group - CESG Exec
\(cesg at mailman.ccsds.org\)"
> <cesg at mailman.ccsds.org>
>Date: 10/10/2013 01:54
>Subject: Re: [CESG] Can we put a quick discussion of the SSI
Architecture
> Document on the agenda for the telecon?
>Sent by: cesg-bounces at mailman.ccsds.org
>
>
>
>Dear colleagues,
>
>I realized after discussing this further that exactly what the issues are,
>and what I was proposing as a re-organization of the stages, might not
>have
>been sufficiently clear. In the attached revision of the PPT I have
>provided
>three pages:
> 1. The orginal high level description of the stages from the
IOP3
>report
> 2. An annotated version of the orginal stages showing what
was implied
>by
> some of the figures in terms of required functionality in the ground
> stations, along with references to the relevant figures
> 3. My revised version of the stages showing the shifted
allocation of
> functionality (and figures), and making explicit just what is
>required
> to be developed and deployed in each stage
>
>The motivation for this, as I noted before, is to make explicit that there
>are significant changes in the space communications service providers that
>are required, both in the SSI / networking layer and in the link layer
>services, requiring development and integration of new functionality.
>This
>topic was entirely overlooked in the original document, but it is crucial
>for
>understanding the viability of some of the original stage 1
>configurations.
>
>If Keith & Scott are OK with this, I think we can use just these three
>pages
>as a reference for the CESG discussion.
>
>Regards, Peter
>
>
>
>From: <Shames>, Peter Shames <peter.m.shames at jpl.nasa.gov>
>Date: Monday, October 7, 2013 11:56 AM
>To: Keith Scott <kscott at mitre.org>, Nestor Peccia <Nestor.Peccia at esa.int>
>Cc: Scott Burleigh <Scott.C.Burleigh at jpl.nasa.gov>, John Rush <
>john.j.rush at nasa.gov>, CCSDS Engineering Steering Group - CESG Exec <
>cesg at mailman.ccsds.org>
>Subject: Re: [CESG] Can we put a quick discussion of the SSI Architecture
>Document on the agenda for the telecon?
>
> Just for clarification. My proposal is to acknowledge that that
>there
> are significant changes and developments required in both the SSI /
> networking layer and in the link layer services and their
>integrations
> into the space communications service providers. What is required
>is
> a period for defining and deploying new CSTS forward frame protocols
> and also new networking protocols,. This approach also recognizes
> that transitioning from missions doing their own thing using
>existing
> space link services, to missions getting updated space link and
> internetworking services from the service providers is a more
> significant, and more natural, boundary between Stage 1 and Stage 2
> than just changes in SSI (network layer) protocol automation.
>
> Regards, Peter
>
>
>
> From: <Scott>, Keith Scott <kscott at mitre.org>
> Date: Monday, October 7, 2013 11:37 AM
> To: Nestor Peccia <Nestor.Peccia at esa.int>
> Cc: Scott Burleigh <Scott.C.Burleigh at jpl.nasa.gov>, John Rush <
> john.j.rush at nasa.gov>, CCSDS Engineering Steering Group - CESG Exec
><
> cesg at mailman.ccsds.org>
> Subject: [CESG] Can we put a quick discussion of the SSI
>Architecture
> Document on the agenda for the telecon?
>
> Nestor,
>
> SIS and SEA are trying to resolve the RIDS against the SSI
> architecture document from the SEA area. Peter¹s proposal is
>to
> redefine the Œstages¹ of the SSI architecture document around
> Œdegree of change to existing networks¹ rather than the
>current
> Œdegree of automation / cross-support¹. Resolving the RIDs
>would
> result in (I believe) significant changes in the document with
> respect to what was sent to and approved by SISG / IOP. I¹m
> concerned that large changes to the document at this point
>could
> be disruptive.
>
> Attached are the SEA RIDs and a document from Peter describing
> his proposed changes.
>
> I¹d like to discuss with the CESG what our options are for
>moving
> forward:
>
> 1) Go with Peter¹s proposal (change the document)
> 2) Reject Peter¹s RIDs and publish the document as-is
> 3) Consult with the SISG to determine their opinion
> 4) Other?
>
> Best Regards,
>
> --keith
>
>
> Dr. Keith Scott
> Office: +1.703.983.6547
> Principal Engineer, E535
> kscott at mitre.org
> The MITRE Corporation
> M/S H300
> 7515 Colshire Drive
> McLean, VA 22102
>
> Area Director,CCSDSSpace Internetworking Services
>
> MITRE self-signs its own certificates. Information about the
> MITRE PKI Certificate Chain is available from
> http://www.mitre.org/tech/mii/pki/
>
> [attachment "IOP-3 SISG proposal comparison - 9Oct13.pptx"
> deleted by Chris Taylor/estec/ESA]
> _______________________________________________
> CESG mailing list
> CESG at mailman.ccsds.org
> http://mailman.ccsds.org/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.
More information about the CESG
mailing list