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

Richard Schnurr Rick.Schnurr at nasa.gov
Fri Mar 11 13:18:11 EST 2005 

Hi Kieth,

I think some projects might implement a monolithic architecture and some 
might implement a dual stack with a gateway.

The service interfaces we have support both if the TCONS network is an 
exposed service and the scheduling is done at the top of the network 
service.  Indeed this is required by the current picture since the 
scheduled service, best effort service, etc must be moderated onto the OBL.

So I say again and I think I am in agreement with you that we must support 
three possibilities:

         1) No TCONS: IP directly to OBL abstraction
         2) IP to the top of the TCONS network service.
         3) IP to the top of the TCONS transport.

Options 1 and 3 are already on the diagram.  I think adding a service 
access point to the TCONS network implements 2 on paper.  The prototypes 
the Agencies/industries choose to build will determine what actually gets 
supported.  Remember this is a service diagram.  In reality a little camera 
at the end of a CAN subnet may not implement much of this at all.  For 
example it might only implement OBL and need the help of the C&DH to 
gateway into a full stack.

Another mission might only implement the Best effort another only the 
guaranteed service.  Another might only implement the scheduled 
service.  If only one service is implemented then the no additional 
overhead needs to be present.

I think you are correct Keith it is time to start looking at the 
protocol/PDU view of the world.  This is where your additional overhead 
argument would be won.

My next Email will assume we are starting a new diagram showing the SOIS 
protocol view.  IE lets start arguing over what is actually included in the 
OBL abstraction layer and TCONS network layer protocol 
descriptions.  PDU's, logical interfaces, packet formats over specific bus 
like spaceWire.

Rick

At 12:31 PM 3/11/2005, Keith Scott wrote:
>If one were to run IP over TCONS, I think it would make more sense to do so
>over the best effort service, but that's not the point.
>
>The real point is that if the TCONS architecture requires all other network
>layers (all other communications, actually) to go through the TCONS service
>interface, then it effectively imposes an overhead tax on those
>communications.  In this sense TCONS is not really a layered architecture,
>in that it's monolithic from data link through transport.  What this means
>is that if a spacecraft has _any_ real-time requirements that need the TCONS
>scheduled service, then ALL communications must go through TCONS (network
>plus transport), since TCONS will own the links involved (at least, all the
>links over which real-time data might flow).
>
>Deciding how IP/NP can be supported in conjunction with TCONS is is NOT a
>question that can be resolved later; it's directly related to the services
>that TCONS provides to other entities.  If TCONS does not present a way for
>other network layers to get access to the bus, then we're done.  This is a
>choice we may want to make, but I want to make sure that we understand that
>we're making it and what the implications are.
>
>We touched on this in Montreal, and it may be time to reconsider and to push
>a TCONS position through SOIS/SIS that support for IP over TCONS-controlled
>links runs is that it runs over the TCONS best-effort transport service.
>
>
>
>Other comments inline.
>
>                 --keith
>
> > -----Original Message-----
> > From: Richard Schnurr [mailto:Rick.Schnurr at nasa.gov]
> > Sent: Friday, March 11, 2005 11:40 AM
> > To: Keith Scott; 'Jane K. Marquart'; '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
> >
> > 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.
>
>Yes, exactly.
>
> > 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.
>
>OK, I propose that we should consider whether or not there should be a red
>dot around layer 2.5 that allows best-effort traffic access to the OBL
>without having to run over the TCONS transport service.
>
> > 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).
>
>What is the position of the TCONS working group (and SOIS) on this?  If we
>can get an answer on this and push it up through SOIS/SIS, we can be done
>with this.
>
> > 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.
> >
>
>If the programs decide that the TCP/IP suite can solve all of their problems
>EXCEPT time-critical operations, all of the IP-based services will incur the
>overhead tax of running through the TCONS transport service.
>
> > 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
> >
> >

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