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

Abhijit Sengupta Abhijit.Sengupta at jpl.nasa.gov
Fri Mar 11 14:45:49 EST 2005 


----- Original Message -----
From: Richard Schnurr <Rick.Schnurr at nasa.gov>
Date: Friday, March 11, 2005 10:42 am
Subject: Re: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS Services  Reference Model

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

No I am not. SCPS suite does not define services - it defines a set of protocols. What I meant in my previous posting and diagram is: 
(1) SCPS-TP (or SCPS-NP) was used to represent the transport (or network) service of SCPS (I did not find any specific service specification - all I cvould is protocol specification) - it will fine if instead of SCPS-TP, the box is called SCPS Transport service - similar is for SCPS-NP
(2) I agree that it is a good idea to keep only the services in the diagram and not the protocol (keeping mind what each service box provides)


> 
> 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.

As I mentioned in my previous posting, to interface between radio and some other onboard link some application layer intervention would be needed, and justifiably so.

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

More information about the Sois-tcons mailing list