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

[Chris Plummer]

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
>