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

[Richard Schnurr]

Hi Keith,

Yes,  Thus the idea put forward by Greg that IP could be carried in one of 
the TCONS services fits into your model.  In reality a spacecraft might 
even segment IP traffic between the three services depending on the 
requirements.  For example on one S/C UDP might be delivered using reliable 
unscheduled service while on another UDP might be delivered using the 
scheduled service.  Sorting by ports to different services depending on 
there time criticality would be another way to work it.  This is becoming 
less important with 100-200 Mbps links but in a few years we might fill 
them up.

I understand that this might generate more overhead in an implementation 
unless the underlying network PDU for TCONS can be made to "correspond" 
with the IP/UDP/TCP PDU.  Ultimately this is what I will propose.  IE there 
is some defined mapping between TCONS PDU's and IP PDU's.   This implies a 
mapping between the 16 bit OSA and ODA address space and IP address 
space.  That the TCONS ports map to IP ports and that any missing bits for 
TCP or UDP can at least be made up or generated on the fly from the TCONS PDU.

We have not gotten to this level of detail yet but personally I think a 
seemless interface to IP for TCONS is a requirement - if for no other 
reason that to support ground testing.

Rick

At 06:35 PM 3/8/2005, Keith Scott wrote:
>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.
> >

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