[Sois-tcoa] [Sois-tcons] RE: reference model (2 levels ofSOIS-compliance)

[Keith Scott]

My apologies, I thought the sub-network dependent scheduler was actually in
OBL and the -independent part was in TCONS.  I don't think that materially
affects the previous discussion (desire for an agreed-upon set of timing
requirements, 'system config' that defines loading for tests, etc.)

If one were to try to design a system that could support TCONS and something
else, it would require (I think) that the lower-level interface of the TCONS
networking layer (the upper layer of the sub-network independent
(convergence?) function) be a well-defined interface that could support
multiple network layers.  That scheduler is going to have to have _some_
interface to the rest of TCONS.  If one could drop best-effort input into
(each) OBL data link (into the 'slots' not used by TCONS time-critical
traffic), then IP could run side-by-side with TCONS.

		--keith

> -----Original Message-----
> From: Richard Schnurr [mailto:Rick.Schnurr at nasa.gov] 
> Sent: Tuesday, March 08, 2005 5:58 PM
> To: gregory.menke at gsfc.nasa.gov; Keith Scott
> Cc: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
> Subject: RE: [Sois-tcoa] [Sois-tcons] RE: reference model (2 
> levels ofSOIS-compliance)
> 
> Hi All,
> 
> Don't know it this thread is dead  but I am sending out the 
> newly minted OBL executive summary to fuel more discussion.
> 
> Basically Greg is correct the OBL simply provides a nomalized 
> packet delivery service with a normalized address space, MTU 
> and link reliability.  The MTU is supported by Fragmentation 
> when necessary.  Link reliability is bus dependent: so some 
> normalization is required.
> 
> OBL has no schedule since many of the underlying bus do not 
> have schedules.  In reality the 1553 bus schedule can be done 
> by the HW or the real time operating system.
> 
> The work for OBL will now be to get prototypes moving for the 
> supported bus to support the specified service interface.
> 
> Keith you seemed to be under the impression the OBL would 
> provide some unifying force.  In reality OBL uses the TCONS 
> OSA, ODA 16 bit address 
> scheme.   If people decided that 32 bit IPv4 addresses were 
> better that 
> would be OK.  The real work for OBL is to convert some 
> uniform address into the address class and "next hop" address 
> for use by the underlying Data Link.
> 
> Personally you know that I am fond of IP and am not fond of 
> reinventing the wheel but I do agree with Greg that if IP is 
> used we will need some better stacks.  This will not be hard 
> since most stacks are built to multi-user environments where 
> they are trying to stay out of the way as opposed to a real 
> time environment where "network" activity drives the show.
> 
> In any event please provide comments and if you feel that OBL 
> is not providing the correct functionality let me know.
> 
> Cheers,
> Rick
> 
> PS Would have been fun to be in the the thread, in real time, 
> but I was away on vacation.
>