[Sois-tcons] RE: [Sois-tcoa] Simplified TCONS Services Reference Model

[Abhijit Sengupta]

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
> 
-------------- next part --------------

-------------- next part --------------
_______________________________________________
Sois-tcons mailing list
Sois-tcons at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcons