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

[Jane K. Marquart]

Ok, how about this?
SCPS - TP etc. stack removed.  Isn't this protocol anyway?  Which does not 
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.
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.
>
>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.
>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.
>
>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?
>
>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
>by other services. In the interests of uncluttering the diagram and moving
>slightly nearer to the Hrair limit, can we remove this box?
>
>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
>[mailto: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 --------------
A non-text attachment was scrubbed...
Name: Ref_Model_Jane_rev2.doc
Type: application/msword
Size: 56832 bytes
Desc: not available
Url : http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050311/07d56bbf/Ref_Model_Jane_rev2-0001.doc
-------------- next part --------------