[Sois-tcoa] [Sois-tcons] RE: reference model (2 levels of
gregory.menke at gsfc.nasa.gov
gregory.menke at gsfc.nasa.gov
Sat Mar 5 10:51:55 EST 2005
Abhijit Sengupta writes:
> At 3/4/2005 08:43 AM, you wrote:
> Of course. I do not see why anyone in their right mind would have two
> different protocols would existing in the same layer. The problem seems (at
> least to me) to originate from the fact that TCONS do not specify a
> protocol for transport layer and one for network layer. It seems to me
> (correct me if I am wrong) that TCONS is defining a package deal - take
There are network and transport layers, best
effort/guaranteed/scheduled are transports, on top of the network
layer that homogonizes the address space. Only transports enshrined
into TCONS get to talk to the network layer.
> both the protocols defined for transport layer and network layer or take
> none. If we look at it pragmatically, we need interoperability - otherwise
> no one will be interested no matter how sound or elegant the protocols are.
> In transport and network layers, for interoperability, we have two choices,
> (when I say TCP I mean TCP or UDP)
> (1) either we say TCONS provide the protocols and those are the only
> protocols that can be used for transport and network layers and nothing
> else - then we need to provide TCP and IP functionalities in them to
> justify that if any user is perfectly happy with TCP/IP, TCONS protocols
> provide that;
> (2) or user can choose TCONS transport protocol or TCP for transport layer
> and TCONS network protocol or IP for network layer. In this case, the TCONS
> transport layer at one end should be able to talk to TCP at the other end
> (similar is for network layer). If this does not happen, SOIS is highly
> likely to lose interest.
Please explain why someone would choose an IP network layer when
realtime, scheduled and guaranteed network performance is required.
Vanilla IP stacks <cannot> meet realtime flight network comms
requirements. You might be able to find one that sort of does and has
a pile of non-standard junk alongside to handle scheduling, but the
whole thing will be proprietary and probably unavailable for many
> This clearly brings in the old question what you asked before "what does
> SOIS-compliant mean?"
> SOIS-compliance (in my opinion) also includes interoperability. In the
> reference model, if we put a set of boxes box1, box2, ..., boxn in a layer,
> to me it implies that any of the boxes box1, box2, ...boxn can be used for
> the service in that layer and nothing else. These boxes should be able to
> talk to each other to preserve interoperability - if they cannot, there is
> lack of interoperability and hence lack of SOIS-compliance.
It means an implementation has a conformant API and implements
conformant on-wire protocols.
> >Now if there is the need of operating a TCP/IP-based application over a
> >fully-compliant SOIS stack (that is exposing the TCONS service interface and
> >implementing the TCONS Transport and Network protocols) than the data flow
> >generated by this application (i.e. IP datagrams) must be encapsulated within
> >the TCONS BEST-EFFORT service (or even directly within the TCONS Network
> >protocol ??) and not exist as a network data flow 'parallel' to TCONS. This
> >in order to guarantee complete control on the requirements of TCONS Transport
> I thought it should be other way round, where TCONS datagrams be
> encapsulated within IP datagrams because at IP level it wont be known how
> to handle TCONS datagrams.
Because IP cannot reasonably be considered a realtime networking
protocol. If realtime/bounded latency communications are not an
issue, then there is no reason to use TCONS.
More information about the Sois-tcons