[Sois-tcons] Network layer scheduling

[Chris Plummer]

Guys, let's kick off a new, more specific thread to discuss this question of
network layer scheduling because this is clearly a major sticking point in
our discussions at the moment. To get the ball rolling, I've pulled out a
couple of Abhijits' comments from the reference model discussion, together
with a question I posed a few days ago. To try to balance things up I've
also reproduced some statements relating to scheduled service from the TCONS
tutorial (BTW Steve, when are you planning to talk us through this
tutorial?).

 

[Abhijits' comments] 

I am having some problems with the scheduling function.

1. As I understand, the idea of the scheduling function is to have scheduled
access to underlying sub-networks (bus or spacewire or ethernet) and the
scheduling is over the entire network covering several sub-networks, in
general... I want to be sure that the scheduling function (essentially a
service) is not conceived as a service on an infrastructure that cannot
support it.

 

2. The next question is why do we need the scheduling function anyway?

 

3. I fail to see the need of one big network layer controlling the
underlying sub-network as well. If we assume (just for the sake of

argument) that network layer services are defined that way - this implies
separate network layer functionalities and services for each class of
sub-network. I feel uncomfortable with the scalability of the design.

 

[The question I posed a few days ago]

Now for the real question, which is based on Kieths' comments and on the
answers I've seen coming out of TCONS....is it the network layer that
entirely controls accesses to the underlying bus through this so called
TCONS scheduling function?

 

If the answer to that question is yes, then any other protocol that other
users might want to run (SCPS, vanilla TCP/IP, whatever) must go through one
or other of the TCONS services!

 

If the answer is no, i.e. if access to the underlying medium is controlled
in the data link layer, then the TCONS can merrily co-exist with virtually
any other protocol that might be proposed!

 

[Statements from the TCONS tutorial slides]

Time Critical?

.          TCONS must be able to support real-time applications

.          Delivery time of less than 1 ms must be supported

.          Priority based media access

.          Deterministic delivery

 

.                      Scheduled Delivery Service

-         Delivers TCONS Service Data Units to a destination, in sequence,
without error or duplication, and with deterministic end-to-end delay

-         Data is transferred across the network according to a predefined
schedule

 

OK, I think that is enough to start the discussion. Can we answer the
questions above? Can we assuage Abhijits' concerns? Can we refute or endorse
the TCONS requirements?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050315/15ad93e8/attachment.html