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

Fri Mar 11 13:42:00 EST 2005

Hi Abhijit,

I still think you are confusing services with protocols.  Lets keep 
protocols out of this diagram.

In reality for GSFC the proximate spacecraft service might be a AOS link or 
some other link.  The protocol on top might be Prox-1 and there might very 
well be a connection to the on board network (OBL or TCONS) of some sort 
between the radio and the application gateway.  Your picture does not 
support this because specific protocols with a specific layer structure are 
specified.

Please remove all protocols from the diagram and lets complete the service 
view.  If you want to add a proximate spacecraft service please do.  The 
protocols for the proximate spacecraft service should include AOS links 
with or without Prox-1, and SCPS-TP/NP over the Spacelink.  But this can be 
in the protocol view diagram.

I have talked with Jane this is the GSFC possition.

Rick

At 01:10 PM 3/11/2005, Abhijit Sengupta wrote:

>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
>_______________________________________________
>Sois-tcoa mailing list
>Sois-tcoa at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcoa

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