[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 03:20:03 EDT 2013
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 IOP–3 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.
More information about the CESG
mailing list