[Sois-tcons] RE: [Sois-tcoa] Simplified TCONS
Services Reference Model
Richard Schnurr
Rick.Schnurr at nasa.gov
Fri Mar 11 11:40:03 EST 2005
Hi Keith,
The access point for IP/NP to the scheduled service, at this point, is the
TCONS scheduled service interface.
Yes, there is a buried service a the top of TCONS networking which makes
sure the best effort and guaranteed service do not conflict with the
scheduled service. One could think of this as an arbitration although it
is a multi thread, multi-platform arbitration, if multiple sub-networks are
available. Once this is better defined it might be appropriate to expose
it as a service for public use. In reality if one exposes the TCONS
network service this buried arbitration is exposed since the SDU's from
another service like IP must be coordinated with the TCONS scheduled
service SDU's.
So it is imperative that all the services that will be exposed to the world
be marked with at red dot. Otherwise the drawing is not complete enough to
argue over and I for one would like to complete the arguments on the
drawing before the meeting.
If TCONS is not implemented on a S/C then IP/NP could go direct to the OBL
abstraction layer and an implementation would be free to implement whatever
priority/scheduling were appropriate. So we are back to the real question
of how should IP and TCONS/SOIS interact. Personally I think IP/NP packets
should use one of the transport services of TCONS or go direct to the OBL
abstraction layer if TCONS is not implemented. (My opinion, Fire me if
you like).
One thing that is not mentioned is the scheduled service for TCONS is not
defined and we have not completed a prototype of a traditionally scheduled
bus like 1553. So some of this will likely change anyway.
Deciding how IP/NP packets will be transported in SOIS is not imperative
right now since multiple answers exist. Lets work on the problems we don't
have answerers for. Personally I think the programs will decide this
question anyway. The Internet supports multiple solutions like: IP
directly on Ethernet, IP mobility tunnels, IP tunneled over ssh, IP
tunneled through a GRE tunnel, and two flavors of IPSEC tunneling not to
mention the strangeness of PPOE (now this one is ugly but I use it every
day). What makes us think SOIS network will be any different. I personally
use 3 of these IP tunneling mechanisms every day. There will be multiple
ways of implementing tunneling and direct connect using SOIS we should not
imagine that we can dictate the correct solution. Many of us think that IP
mobility combined with IPSEC (or flight versions of the same) are the right
model for the far future so if we are going to talk about how to get IP
from space to ground we should include discussion of Mobility security and
tunneling to the MOCC and SOC. I think all these discussions are outside
the SOIS scope.
Cheers,
Rick
At 09:35 AM 3/11/2005, Keith Scott wrote:
>OK, I'll bite. The TCONS scheduling services [sub-network
>dependent/independent] are not shown (and hence neither are their service
>interfaces). Are these accessible to other elements or are they entirely
>internal to TCONS networking? If one were to want to run IP 'beside' TCONS
>networking, it (IP) would need access to the scheduling services in order to
>gain access to the link, right?
>
> --keith
>
> > -----Original Message-----
> > From: sois-tcons-bounces at mailman.ccsds.org
> > [mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
> > Jane K. Marquart
> > Sent: Friday, March 11, 2005 8:09 AM
> > To: Chris Plummer; sois-tcons at mailman.ccsds.org;
> > sois-tcoa at mailman.ccsds.org
> > 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 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
> >
>
>
>
>
>_______________________________________________
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcons
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