[Sois-tcons] RE: Updated version of TCONS Red book on CWE

[Steve Parkes]

Keith,

The consensus in Athens was that "Time Critical" only makes sense over a
single sub-network and also that we wanted to support the SIS view of the
world (or maybe universe) and support TCP/IP etc. We did not believe that
TCP/IP would be able to provide appropriate time critical behaviour. The
focus thus was on sorting out an appropriate architecture, formulating
suitable QoS mechanisms and then providing the service interfaces. We are
about half way through this at the moment and are currently trying to sort
out a consistent QoS approach that can be applied to (almost) any underlying
bus/sub-network. 

For onboard applications we also thought that TCP/IP etc may not be the
final word and that we should provide mechanisms for handling other
protocols as well. This includes using the Intra-Network layer directly from
TCOAS and other applications.

The socket API approach was considered as the TCONS interface and is
certainly very attractive if only TCP/IP etc is being used. With support for
other protocols being considered too the socket API was not possible and Max
Ciccone is currently working on a draft red book for the Inter-Network
Service Interface.

I think that the rest of your interpretation is correct.

We are happy for SIS to take on the TCP/IP side of the standard definition.
In fact what we would like to do is to simply call up an existing CCSDS
standard. This would then be a box within TCONS rather than the full
transport and network layer, because we want to be able to handle other
onboard transport and network protocols.

As I have said our current focus is on the architecture and QoS approach.
The primary aim of our meetings in Atlanta is to get this finalised and out
for review. We would also like to discuss the architecture (and QoS) with
SIS so that our views of the universe can converge, and also to make a start
on some of the other red books that we have on our list. Can we arrange a
meeting with SIS to discuss the architecture?

Regards

Steve

------------------------------------------
Steve Parkes
Space Technology Centre
Applied Computing, University of Dundee
Dundee, DD1 4HN, Scotland, UK
Tel: +44 1382 345194
Fax: +44 1382 348838
Mobile: +44 784 138 3779
 

-----Original Message-----
From: sois-tcons-bounces at mailman.ccsds.org
[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of Scott,Keith L.
Sent: 29 August 2005 16:35
To: Jane K. Marquart; sois-tcons at mailman.ccsds.org;
Peter.Shames at jpl.nasa.gov; dstanton at keltik.co.uk
Subject: [Sois-tcons] RE: Updated version of TCONS Red book on CWE

Jane,

I have a question about figure 2-2 (TCONS/OBL Architecture).  There are
both Intra-Network and Inter-network layers shown, as well as a number
of different data link layers.  In Athens I thought the consensus was
that TCONS would provide time-critical services over a single
subnetwork.  Is this still the intent of the architecture, with TCONS
using TCP/UDP/IP to provide time-critical service, or is the intent to
attempt to provide time-critcal services over (between) heterogeneous
data links?

What about the paragraph in section 3.1: "The network layer is
responsible for routing datagrams across heterogeneous sub-networks,
from source address to destination address, delivering them to the
required destination."

If the thought is that TCONS networks will support networking protocols
(e.g. NP/IP), and that these networking protocols can be used to get
'out' of a TCONS (providing time-critical services) subnetwork and into
other subnets, I think that fits well with the SIS view of things.  The
red "Inter Network Service Interface" in Figure 2-2 then is then (or
maybe could be) a standard sockets interface, with time-critical
requirements managed by the TCONS API?  Reading it this way, an
application requiring time-critical services would use the TCONS API;
the TCONS API block would choose a transport service (TCP/UDP) and
interact with the QoS function to allocate slots, etc.  I don't think I
have any problems with this interpretation.

Using this interpretation, if TCONS is making use of TCP/UDP/IP, one
_could_ redraw figure 2-2 with the TCONS API as part of TCONS, the red
line from the TCONS API to the Intra-Network Service Interface as part
of TCONS, and the transport and network protocols as (IETF/adopted by
SIS) standards.  TCONS would also 'own' the Intra Network Service
Interface (which it must control in order to preserve/protect its
time-critical service), as well as the Intra-Network stuff.

Does this match the current TCONS thinking?

		--keith


>-----Original Message-----
>From: Jane K. Marquart [mailto:Jane.K.Marquart at nasa.gov] 
>Sent: Monday, August 29, 2005 10:50 AM
>To: sois-tcons at mailman.ccsds.org; Scott,Keith L.; 
>Peter.Shames at jpl.nasa.gov; dstanton at keltik.co.uk
>Subject: Updated version of TCONS Red book on CWE
>
>All,
>
>I've incorporated MOST comments into Version 2 of the TCONS 
>Architecture 
>Redbook and put on the CWE (also attached for convenience).  
>Please provide 
>feedback promptly.  There continues to be confusion as to what 
>and why of 
>the architecture.  Hopefully, the updates will help to 
>clarify.  Feedback 
>from SIS is especially requested so we don't have disconnects 
>and wind up 
>dealing with the same issues in Atlanta as we did in Athens.
>Thanks to all who have responded thus far.  I'll continue to try and 
>resolve any outstanding comments.
>

_______________________________________________
Sois-tcons mailing list
Sois-tcons at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcons