[Sois-tcons] RE: [Sois-tcoa] Simplified TCONS ServicesReference Model

Mon Mar 14 14:08:33 EST 2005

Hi All,

The real issue seems to be the exposure of the TCONS networking service as 
a "public" service - giving other network services access to the bus.

Also, I think we need to talk compliance again.  If a Spacecraft runs NP/IP 
directly over SpaceWire is it SOIS compliant.  In some ways I do not want 
to answer this question yet but I think it is at the heart of what people 
are thinking.

If a mission is only using IP or NP and it is not using TCONS services or 
maybe even have the TCONS API implemented to work over IP or NP.  Is this 
mission SOIS compliant and how do we describe this compliancy.

Rick

Abhijit,

The services provided by SCPS-NP, and TP are very well defined since NP is 
a derivation of IP and TP is a derivation of TCP.  Unfortunately, people 
talk about NP and TP as if everyone knows what service they provide.  I can 
assure you people in the flight community, in general, do not.  For example 
the normal services for IP are a unreliable (Unacknowledged) data gram 
service and a reliable stream service.  The IP network services are 
basically source and destination address routing.

I think TP and NP provide the same basic services for SpaceLink (With some 
TCP enhancements in TP).  Now TCONS does not really have a stream service 
and TCONS does not support IP or NP addressing.  TCONS does support 
non-guaranteed, Guaranteed and synchronous delivery services for defined 
length SDU's PDU's using TCONS OSA and ODA 16 bit addressing.  Now I think 
SCPS NP actually has a 16 bit addressing mode.  If SCPS supports protocol 
multiplexing then running the scheduled service over SCPS-NP might be viable.

Again I implore upon you to make the first architecture picture a service 
only picture.  If you want to include SCPS-TP or NP please lets figure out 
what services they provide.  (Keith help me here).

The protocol view will be much easier if we have the service view done fist.
Rick

At 04:53 PM 3/11/2005, Chris Plummer wrote:
>Abhijit, just to clarify, I'm not proposing that SCPS does not belong in our
>considerations, just that we can ignore it for the time being while we
>thrash out this prickly issue of the exposure of the OBL service interface
>and the question of scheduling (see below). Could you live with that
>position for the time being?
>
>Similarly, I'm not proposing to kick plug and play out. Rather I would like
>to identify the real issues with plug and play, and how they involve us,
>over the next few days. PnP box in or out is OK for me for now though.
>
>Now for the real question, which is based on Kieths' comments and on the
>answers I've seen coming out of TCONS....is it the network layer that
>entirely controls accesses to the underlying bus through this so called
>TCONS scheduling function?
>
>If the answer to that question is yes, then any other protocol that other
>users might want to run (SCPS, vanilla TCP/IP, whatever) must go through one
>or other of the TCONS services!
>
>If the answer is no, i.e. if access to the underlying medium is controlled
>in the data link layer, then the TCONS can merrily co-exist with virtually
>any other protocol that might be proposed!
>
>I have my convictions based on my trusty copy of ISO 7498 and a misspent
>early middle age playing with 1553 and CAN bus implementations, but we all
>need to be in agreement on this one. So guys, can we find a consensus on the
>answer to this question?
>
>Chris.
>
>
>
>-----Original Message-----
>From: sois-tcoa-bounces at mailman.ccsds.org
>[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Abhijit Sengupta
>Sent: 11 March 2005 19:10
>To: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
>Subject: Re: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS ServicesReference
>Model
>
>
>As usual, here are some in-line comments.
>
>Abhijit
>
>
>----- Original Message -----
>From: "Jane K. Marquart" <Jane.K.Marquart at nasa.gov>
>Date: Friday, March 11, 2005 5:09 am
>Subject: Re: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS Services
>Reference Model
>
> > Ok, how about this?
> > SCPS - TP etc. stack removed.  Isn't this protocol anyway?  Which
> > does not
>
>If we remove the SCPS-TP etc, then TCONS need to support the functionality
>of SCPS suite in "proximate spacecrafts" environment. If it does not (which
>I think is the case) then SOIS is not doing what it is expected to do
>according to charter - look into the charter - the SOIS is supposed to
>provide the communication between "proximate spacecrafts" (whatever that
>implies).
>
>By the way, when I drew the new version of the diagram I assumed that TCONS
>provide the TCP-UDP-IP kind of functionalities in addition to scheduled
>services. If not, we are back to square one.
>
> > belong in a services diagram.  Please let's stick with TCONs
> > services.....we can deal with protocols and how different ones fit
> > in the
> > TCONS model after we settle on this.
> > Removed the PnP app box per Chris request.
>
>We need to handlle the PnP application service at whatever level it is
>appropriate. Interestingly enough, we addressed it, discussed it and then
>swept under the rug without reaching an agreement (at least at a conceptual
>level) what, where and how PnP is included in SOIS.
>
>
> > Removed the address/translation in network services per Abjihit's
> > point.Replaced the "single sub-net" with a SAP, which I believe is
> > what we mean
> > anyway.  The original intent on the earliest TCONS diagrams was to
> > show
> > that a user could have access directly to the data link, i.e. the
> > way some
> > of today's 1553 implementations are.  I don't know when the text
> > for single
> > sub-network got put in there.......but now its gone.
> >
> > Any objections to these updates? (or is that a silly question?)
> >
> > Cheers, and I raise you a couple of beers,
> > Jane
> > At 11:02 AM 3/11/2005 +0100, you wrote:
> > >The diagram starts to look better. Abhijits' point about network
> > address>translation being a function and not a service is
> > absolutely correct...you
> > >might want to refer to ISO 7498-1:1994 clause 7.5.4.1.2 for absolute
> > >confirmation of this.
> > >
> > >TCONS starts to look comfortingly ISO like. One point that
> > remains to be
> > >clarified is the representation of the TCONS transport service
> > SAPs. As
> > >drawn there is only one SAP exposed at the top of the application
> > layer,>which is surely inaccurate. Could someone from TCONS fix
> > this please.
>
>This only SAP exposed implies the availability of all the boxes in transport
>layer of TCONS. The basic assumption was: whenever a SAP is opened from a
>box, all the topmost sub-boxes are accessible to the SAP. If some sub-boxes
>are not accessible, SAP is exposed from those sub-boxes that are accessible.
>Fortunately (thank goodness!!) that was not the case here.
>I apologize my error for not exposing SAP for the SCPS-TP side
>
>
> > >
> > >The SCPS stack doesn't look right to me either, because the
> > implication from
> > >the drawing is that I can't get to the onboard data link layer
> > using SCPS.
>
>Yes - you can. The only restriction being you cannot go to onboard data link
>layer through a router - you need to go through a processor that runs
>application to match the data rate and uncertainties of space links, which I
>thought was reasonable. Because if you are using a router - this needs to be
>a specialized router to bridge from spacelink to onboard. Whenever you do
>that, you are sacrificing encapsulation, reusability etc - what we were
>emphasizing on.
>
> > >Also, I'm not sure what a SOIS SpLink is. I would suggest that,
> > since we are
> > >trying to arrive at a model for SOIS, we just remove that left
> > hand SCPS
> > >stack.
> > >
>
>Please see my earlier comments on SCPS suite and charter stuff.
>
> > >Now to the thorny issue of the "Single sub-network bypass". Could
> > somebody>please explain to a simple minded ISOphile like myself
> > exactly what this is,
> > >and how it differs from the SAP provided by the OBL service? If
> > not could we
> > >please remove it from the diagram?
>
>I do not have any problem with the suggestion (personally I disliked the
>bypass right from start but had to bear with it)
>
> > >
> > >Last point for the moment...the Plug and Play service box. Right
> > now plug
> > >and play is not formally on our books, and having had discussions
> > with>several of you it seems clear that it will not be a "service"
> > as such
> > >anyway, rather plug and play will be supported through
> > capabilities provided
>
>I do not agree with this. PnP needs almost the same set of capabilities
>provided by other services as C&DA does (obviously using those capabilities
>in a different manner than C&DA does).
>
> > >by other services. In the interests of uncluttering the diagram
> > and moving
> > >slightly nearer to the Hrair limit, can we remove this box?
>
>I do not think so - perhaps we need people who can draw diagrams in a better
>way (I humbly aplogize not being one of them)
>
> > >
> > >Finally, Abhijit I hope I interpreted the phrase "let the firing
> > begin">correctly. I'd hate to thing of Patrick having to play the
> > part of Donald
> > >Trump in an Apprentice style show down.....although maybe.
> > >
> > >Cheers,
> > >         Chris.
> > >
> > >-----Original Message-----
> > >From: sois-tcoa-bounces at mailman.ccsds.org
> > >[sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Abhijit Sengupta
> > >Sent: 11 March 2005 03:02
> > >To: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
> > >Subject: Re: [Sois-tcoa] Simplified TCONS Services Reference Model
> > >
> > >
> > >I made some changes - the diagram looks uglier, but I thought
> > probably>correctness precedes beauty. So let us have further
> > discussions. The
> > >rationales are as follows:
> > >1. I am almost convinced from the discussion so far, that while
> > using space
> > >link, using TCONS is a not a good idea - moreover when SCPS-TP
> > exists, what
> > >is the defense of a new transport protocol.
> > >2. So after that comes the SCPS-NP as a natural service provider
> > to SCPS-TP.
> > >3. OBL abstraction service or adaptation layer need not be
> > concerned with
> > >Space Link (Rick must thank me for that)
> > >4. The address-link translation service is used only by network
> > service and
> > >interfaces with OBL abstraction service and no one else - why
> > call it a
> > >separate service - it is included in network service.
> > >
> > >And let the firing start!!!
> > >
> > >At 3/9/2005 05:18 AM, Jane K. Marquart wrote:
> > > >All,
> > > >
> > > >Here you go!  The following mods were made:
> > > >
> > > >1 - Consistency:  this is a SERVICES diagram only.  No
> > protocols mixes etc.
> > >
> > >That was a good idea.
> > >
> > > >2 - TCONs Layers:  lists the 3 types of transport services
> > provided.  Adds
> > > >clarity to what TCONS is/does/supports.
> > > >3 - Network Layer  - now includes an Address-to-link
> > translation service
> > > >-- the "official" name can be TBD but for now it describes the
> > service> >provided.  This is where the packet destination info is
> > translated into
> > > >the outgoing link by TCONS (and vice versa on receive),
> > providing a
> > > >generic service i/f to the OBL abstraction service.  See Rick's
> > charts on
> > > >OBL service i/f.
> > > >4 - Data link - instead of SNDCL, etc., this is much cleaner (and
> > > >clearer).  The OBL abstraction provides the "generic" or
> > independent> >service i/f.  Then OBL does it "dependent " thing,
> > according to the
> > > >provided "link".  The  "abstraction" service i/f can be exposed to
> > > >non-TCONS entities.
> > > >5 - The Physical layer is outside the SOIS domain, so while it
> > is still
> > > >included in the overall diagram, it is not part of SOIS.
> > Rather, it is
> > > >"driven" by other external standards.
> > > >
> > > >Let the discussion begin..........
> > > >
> > > >Jane
> > >
> > >I agree with most of it excepting notes at the beginning.
> > >
> > >Abhijit
> > >
> > >
> > >
> > >________________________________________________
> > >All personal and professional opinions in this email are my own
> > >and do not represent, in any way, the opinion or policy of JPL
> > >________________________________________________
> > >
> > >
> > >_______________________________________________
> > >Sois-tcons mailing list
> > >Sois-tcons at mailman.ccsds.org
> > >http://mailman.ccsds.org/mailman/listinfo/sois-tcons
> >
>
>
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons

Richard G Schnurr Jr
Chief Architect
Electrical Systems Center
Applied Engineering and Technology Directorate
NASA GSFC Code 560.0
Greenbelt MD 20771

(301)-286-1852