[Sois-tcons] RE: reference model (2 levels of SOIS-compliance)

[gregory.menke at gsfc.nasa.gov]

Massimiliano.Ciccone at esa.int writes:
 > 
 > Dear all,
 > Sorry for the late answer but I got the flu and come back to work only today.
 > First of all I would like to remind you all to use the formal channels of
 > communication (i.e. ccsds mailing list) in order not to remain 'invisible' to
 > the secretariat.
 > Second, I noticed that the choice of the reference diagrram model raised some
 > very critical questions that have been dragged for long time.
 > One in particular, above all, is:
 > What does SOIS-compliance mean ?

That the implementation supplies the given service interface and
supports the given protocols.

If an implementation has a different service interface, but supports
the given protocols, then it is protocol conformant and not fully
SOIS-compliant.


 > In my view, I do not feel like precluding system designers the possibility of
 > experimenting different transport and network layer protocols for
 > implementing "the same" SOIS standard services; this is why I think that
 > TCP/UDP SCPS-TP IP etc. should be left in the diadram even if some minor
 > graphical changes are required (will explain later why).
 > The problem arises when we start to link protocol to service interfaces. I
 > doubt that TCP/IP can fullfill ALL the requierments of SOIS services.
 > In particular, how can TCP/IP guarantee a scheduled/time-constraint delivery
 > of data onboard the spacecraft ?

I don't understand why there is an issue with the relation of link
protocol to service interface- could you clarify that please?


 > In other words, TCONS wg is working on the reccommendation of a standard
 > service interface as well as the 'ideal' protocol definition for carring on
 > ALL such services in the best way possible (hopefully); if a system designer
 > decides not to use TCONS but other protocols instead, then the resulting
 > system will lose interoperability with other systems implementing TCONS but
 > it will still meet the requirements for being SOIS-compliant at the SERVICE
 > INTERFACE level.

I agree with Steve as well.  IMO, the TCONS network and transport
layers are fundamentally necessary to meet the qualities of service
that TCONS provides.  By putting the IP stack in as a peer protocol
directly exploiting OBL features, all you achieve is compromising the
benefits of TCONS; in this case the unification of disparate datalinks
into a single address space and per-frame guarantees of reliability
and timeliness.  If you're thinking about the expansion of TCONS
services, providing something new, then the new service should at
least be interfaced to the TCONS network layer if its somehow
infeasible to implement on top of one of the existing TCONS
transports.

I think a lot of this argument depends on what "not using TCONS"
means.  If it means the existing services aren't sufficient, then why
is it necessary to implement other stacks on top of the OBL layer?
Experimental protocols should be built on top of the best effort
service, the same way all sorts of protocols are built on top of UDP-
its a purposefully thin shim on top of the network layer intended to
make augmented transports easier to develop without masking or
distorting network layer properties.

If some new experiemental transport turned out to be something widely
useful, then I imagine it would be enshrined into TCONS as a new
service- with a well-defined relationship to the rest of the TCONS
transports.  When you put things like IP stacks in the pictures as
peers of the TCONS network and transport layers, I think it
oversimplifies the question and implications.

I believe we are also doing more than specifying an "ideal" protocol,
we are specifying THE protocols.



 > Furthermore, the protocols used within the TCONS box can be whatever
 > combination of TCONS, TCP/IP, UDP/IP, SCPS/TP or any X-PROTOCOL still to be
 > invented !!

All these protocols should be implemented on top of the best effort
service, as they (presumably) choose to handle reliablity and latency
themselves.  If they do not choose to do so, then they would be put on
the guaranteed or scheduled service.

Regards,

Greg