[CESG] Fw: Overlap identifications inputs

[Scott, Keith L.]

Below are my inputs on the overlaps issues:

Erik,

#1 (MOC v TTC Network Planning v SSI Planning): I wonder if there’s an overlap with SIS here, at least in the short term.  In the short term, SIS would like to know what the link schedule *is* (as provided to us by somebody), but we’re not developing any mechanisms to try to develop new schedules.  As a concrete example: the contact graph routing that’s part of the SSI will route bundles over the links it’s given, but it takes those links as axiomatic.  For there to be an overlap with (what I perceive) CSS and MOIMS are doing would require the SSI to try to ‘suggest’ a future link schedule (establishment of particular links).  We certainly might do that in the far term (i.e. consume information about the POSSIBLE connectivity information and suggest an ‘optimal’ (given the known traffic patterns) link schedule) – but even that would be something to be worked back into the spacecraft operations THROUGH MOIMS and/or CSS.  [The problem is in fact solvable if you have complete information, but it takes a really big linear program to do it.]

So in the short term I don’t think there’s an overlap.  In the long term (ideally) I think the SSI will want to be able to get at the set of possible connectivity and work *with* MOIMS / CSS to schedule links – but I think this is an area for future coordination and not an overlap (?).  There’s probably a world of complexity here by the time you mix in physics, spacecraft schedules (incl. science, thermal, vibration, etc.), …  The good thing (from our perspective) is that we’re patient – no connectivity now, no problem, we’ll wait.


#2 (Monitor and Control) I’d like to sit down with you and talk about the relationship between SIS network monitor and control and the others.  To a first order, SIS monitor and control looks like Simple Network Monitor Protocol (SNMP) with Management Information Bases (MIBs) for, e.g., the bundle protocol (how many bundles has a node sent, received, retransmitted, etc. – [eventually] insert a new contact graph entry XXXXX) LTP (how many [red|green] LTP segments has a node sent / received, retransmitted, etc.), security (how many BP security authentication failures of what types have occurred).  The DTN Management Protocol that’s being worked with AES moves information like the above via DTN bundles (so that it can go multiple hops through the SSI).  The JPL and JSC MOIMS folks are doing SM&C monitoring and control over an SSI stack, so I *think* there’s some harmony there.  A lot of the DTN MP work is in defining the MIBs (specific to the SSI services) and how to encode those values and pack them into bundles for transport.  In one sense I see all this as pretty orthogonal to SM&C; on the other, it is effecting monitor and control of some parts of the spacecraft.

What’s above applies to single node management.  If you think of scheduling all of the links in the SSI as a whole then there’s certainly an element of cross support there.  Not sure what to do about that.


#7 (Time Series Representations):  I think you’re right here about no direct overlap.  I’m all for some common way of defining time series -- tell us what it is and provide e.g. link contact information to SIS in that format and we’ll be happy.  We’ve certainly got things internally that represent time-related events (e.g. contact schedules) but I don’t think we’re working any efforts to standardize such.


#3 (File Transfer) This applies only to ground?  That’s why there’s no overlap with SIS?  Actually here I think there *is* overlap if the ‘file’ is going end-to-end (it should use CFDP/BP).  If this is defining a mechanism to e.g. ship a bunch of frames in a file from one place to another then I think it’s an application (running OVER a file transfer protocol).  If this really is just a registry of filetypes, fine.  [I’m unclear on / uneasy about where this ended up.]


#5 (Architectures vs. Reference Models) Yeah, this got a be a mess.  FWIW I think at least the CSS and SSI documents are consistent, but I also think we have way too many documents with ‘architecture’ in the title.

                        --keith


-----Original Message-----
From: cesg-bounces at mailman.ccsds.org [mailto:cesg-bounces at mailman.ccsds.org] On Behalf Of chris.taylor at esa.int
Sent: Monday, June 23, 2014 11:01 AM
To: Nestor.Peccia at esa.int
Cc: cesg-bounces at mailman.ccsds.org; cesg at mailman.ccsds.org
Subject: Re: [CESG] Fw: Overlap identifications inputs

Small update on wireless,
Regards,
//ct(See attached file: d1-OverlapIdentifications-19-Jun-2014+ct.xlsx)



From:	Nestor.Peccia at esa.int
To:	cesg at mailman.ccsds.org,
Date:	20/06/2014 09:46
Subject:	[CESG] Fw: Overlap identifications inputs
Sent by:	cesg-bounces at mailman.ccsds.org



Dear all
Please find below the excellent work done by Erik for our overlap discussion
next Mondy in the CESG webex
ciao
nestor

----- Forwarded by Nestor Peccia/esoc/ESA on 20/06/2014 09:38 -----

From:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:        "Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>,
Date:        20/06/2014 02:34
Subject:        Overlap identifications inputs



Nestor,

Attached please find the spreadsheet with the latest overlap identifications.
Note that this is a new spreadsheet to facilitate the focus on what I have
identified as just the current situation.  And even at that, as you will see,
technically, some of the overlaps do not exist because charters have yet to
be defined, but, in my estimation, I thought the potential overlap was worth
noting as it is probably easier to set the course properly to avoid the
overlap now rather than trying to untangle things after effort/money has been
expended on overlapping items.  And as you will also see it occurred to me
that we not only have overlaps but we also appear to have a gap with regard
to architecture definition.  At the end of the spreadsheet I also listed some
items that are not really overlaps in the sense of "competing”
recommendations but have to do with a commonality of approach with regard to
multiple working groups (for example, XML schema management).    The
questions in the spreadsheet are meant to spur discussion, provide some
indication of the nature of the overlap gap/commonality issue. They are not
recommendations. I look forward to a lively discussion at the CESG
teleconference on Monday.

Best regards,

-Erik


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.
[attachment "d1-OverlapIdentifications-19-Jun-2014.xlsx" 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.