[Sois-tcons] RE: [Sois-tcoa] Simplified TCONS ServicesReference Model

Mon Mar 14 20:32:05 EST 2005

At 3/11/2005 01:53 PM, Chris Plummer wrote:
>Abhijit, just to clarify, I'm not proposing that SCPS does not belong in our
>considerations, just that we can ignore it for the time being while we
>thrash out this prickly issue of the exposure of the OBL service interface
>and the question of scheduling (see below). Could you live with that
>position for the time being?

Of course!

>Similarly, I'm not proposing to kick plug and play out. Rather I would like
>to identify the real issues with plug and play, and how they involve us,
>over the next few days. PnP box in or out is OK for me for now though.

I agree - we need to settle that soon (whatever that implies).

>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?

I am having some problems with the scheduling function. Let me elaborate.
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. From the latest version of red book (that I got 
from Greg), the scheduling is done on the basis of time-slot allocation 
(some striking resemblance to 1394 isochronous service). My questions are 
as follows (before they are looked into as implementation details, 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):
(a) time-slot allocation on 1394 or 1553 kind of bus is straight forward, 
how to do it on other types of sub-network - like ethernet or spacewire 
(spacewire being a shared-path-switched network enforcing slotted behavior 
is non-trivial if doable)?
(b) since it is not known when a scheduled delivery will be asked for, data 
delivery in time slots might be mixed with non-slotted delivery (moreover 
CCSDS packet sizes are not fixed) - typical of 1394 transactions - how 
about other sub-networks (is it possible?)
(c) how do the routers between two sub-networks handle mixed slotted and 
non-slotted data?

2. The next question is why do we need the scheduling function anyway? The 
function was conceived, I guess, extending the 1394 concept of guaranteeing 
at least one slot in every cycle leading to a guarantee of sub-network 
bandwidth. Why not define a high priority in packet header to receive 
favored treatment in each router - if allowed highest priority, only 
another scheduled service can delay it - using a differentiated service 
among delayed scheduled service can compensate for it.

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.

>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!

 From other postings, I realize that tcons-best effort service is somewhat 
fairly close to UDP/IP and tcons-guaranteed-service is somewhat fairly 
close to TCP/IP (basically I mean that tcons-best effort or guaranteed 
services perhaps can be tweaked to talk to TCP-UDP suite). If the 
scheduled-service (though its service specification details do not appear 
in the red book I have) is the only one that is a significant addition, I 
would like to be sure that the priority and diffserv approach would not work.

Abhijit

>I have my convictions based on my trusty copy of ISO 7498 and a misspent
>early middle age playing with 1553 and CAN bus implementations, but we all
>need to be in agreement on this one. So guys, can we find a consensus on the
>answer to this question?
>
>Chris.
>
>
>
>-----Original Message-----
>From: sois-tcoa-bounces at mailman.ccsds.org
>[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Abhijit Sengupta
>Sent: 11 March 2005 19:10
>To: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
>Subject: Re: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS ServicesReference
>Model
>
>
>As usual, here are some in-line comments.
>
>Abhijit
>
>
>----- Original Message -----
>From: "Jane K. Marquart" <Jane.K.Marquart at nasa.gov>
>Date: Friday, March 11, 2005 5:09 am
>Subject: Re: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS Services
>Reference Model
>
> > Ok, how about this?
> > SCPS - TP etc. stack removed.  Isn't this protocol anyway?  Which
> > does not
>
>If we remove the SCPS-TP etc, then TCONS need to support the functionality
>of SCPS suite in "proximate spacecrafts" environment. If it does not (which
>I think is the case) then SOIS is not doing what it is expected to do
>according to charter - look into the charter - the SOIS is supposed to
>provide the communication between "proximate spacecrafts" (whatever that
>implies).
>
>By the way, when I drew the new version of the diagram I assumed that TCONS
>provide the TCP-UDP-IP kind of functionalities in addition to scheduled
>services. If not, we are back to square one.
>
> > belong in a services diagram.  Please let's stick with TCONs
> > services.....we can deal with protocols and how different ones fit
> > in the
> > TCONS model after we settle on this.
> > Removed the PnP app box per Chris request.
>
>We need to handlle the PnP application service at whatever level it is
>appropriate. Interestingly enough, we addressed it, discussed it and then
>swept under the rug without reaching an agreement (at least at a conceptual
>level) what, where and how PnP is included in SOIS.
>
>
> > Removed the address/translation in network services per Abjihit's
> > point.Replaced the "single sub-net" with a SAP, which I believe is
> > what we mean
> > anyway.  The original intent on the earliest TCONS diagrams was to
> > show
> > that a user could have access directly to the data link, i.e. the
> > way some
> > of today's 1553 implementations are.  I don't know when the text
> > for single
> > sub-network got put in there.......but now its gone.
> >
> > Any objections to these updates? (or is that a silly question?)
> >
> > Cheers, and I raise you a couple of beers,
> > Jane
> > At 11:02 AM 3/11/2005 +0100, you wrote:
> > >The diagram starts to look better. Abhijits' point about network
> > address>translation being a function and not a service is
> > absolutely correct...you
> > >might want to refer to ISO 7498-1:1994 clause 7.5.4.1.2 for absolute
> > >confirmation of this.
> > >
> > >TCONS starts to look comfortingly ISO like. One point that
> > remains to be
> > >clarified is the representation of the TCONS transport service
> > SAPs. As
> > >drawn there is only one SAP exposed at the top of the application
> > layer,>which is surely inaccurate. Could someone from TCONS fix
> > this please.
>
>This only SAP exposed implies the availability of all the boxes in transport
>layer of TCONS. The basic assumption was: whenever a SAP is opened from a
>box, all the topmost sub-boxes are accessible to the SAP. If some sub-boxes
>are not accessible, SAP is exposed from those sub-boxes that are accessible.
>Fortunately (thank goodness!!) that was not the case here.
>I apologize my error for not exposing SAP for the SCPS-TP side
>
>
> > >
> > >The SCPS stack doesn't look right to me either, because the
> > implication from
> > >the drawing is that I can't get to the onboard data link layer
> > using SCPS.
>
>Yes - you can. The only restriction being you cannot go to onboard data link
>layer through a router - you need to go through a processor that runs
>application to match the data rate and uncertainties of space links, which I
>thought was reasonable. Because if you are using a router - this needs to be
>a specialized router to bridge from spacelink to onboard. Whenever you do
>that, you are sacrificing encapsulation, reusability etc - what we were
>emphasizing on.
>
> > >Also, I'm not sure what a SOIS SpLink is. I would suggest that,
> > since we are
> > >trying to arrive at a model for SOIS, we just remove that left
> > hand SCPS
> > >stack.
> > >
>
>Please see my earlier comments on SCPS suite and charter stuff.
>
> > >Now to the thorny issue of the "Single sub-network bypass". Could
> > somebody>please explain to a simple minded ISOphile like myself
> > exactly what this is,
> > >and how it differs from the SAP provided by the OBL service? If
> > not could we
> > >please remove it from the diagram?
>
>I do not have any problem with the suggestion (personally I disliked the
>bypass right from start but had to bear with it)
>
> > >
> > >Last point for the moment...the Plug and Play service box. Right
> > now plug
> > >and play is not formally on our books, and having had discussions
> > with>several of you it seems clear that it will not be a "service"
> > as such
> > >anyway, rather plug and play will be supported through
> > capabilities provided
>
>I do not agree with this. PnP needs almost the same set of capabilities
>provided by other services as C&DA does (obviously using those capabilities
>in a different manner than C&DA does).
>
> > >by other services. In the interests of uncluttering the diagram
> > and moving
> > >slightly nearer to the Hrair limit, can we remove this box?
>
>I do not think so - perhaps we need people who can draw diagrams in a better
>way (I humbly aplogize not being one of them)
>
> > >
> > >Finally, Abhijit I hope I interpreted the phrase "let the firing
> > begin">correctly. I'd hate to thing of Patrick having to play the
> > part of Donald
> > >Trump in an Apprentice style show down.....although maybe.
> > >
> > >Cheers,
> > >         Chris.
> > >
> > >-----Original Message-----
> > >From: sois-tcoa-bounces at mailman.ccsds.org
> > >[sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Abhijit Sengupta
> > >Sent: 11 March 2005 03:02
> > >To: sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
> > >Subject: Re: [Sois-tcoa] Simplified TCONS Services Reference Model
> > >
> > >
> > >I made some changes - the diagram looks uglier, but I thought
> > probably>correctness precedes beauty. So let us have further
> > discussions. The
> > >rationales are as follows:
> > >1. I am almost convinced from the discussion so far, that while
> > using space
> > >link, using TCONS is a not a good idea - moreover when SCPS-TP
> > exists, what
> > >is the defense of a new transport protocol.
> > >2. So after that comes the SCPS-NP as a natural service provider
> > to SCPS-TP.
> > >3. OBL abstraction service or adaptation layer need not be
> > concerned with
> > >Space Link (Rick must thank me for that)
> > >4. The address-link translation service is used only by network
> > service and
> > >interfaces with OBL abstraction service and no one else - why
> > call it a
> > >separate service - it is included in network service.
> > >
> > >And let the firing start!!!
> > >
> > >At 3/9/2005 05:18 AM, Jane K. Marquart wrote:
> > > >All,
> > > >
> > > >Here you go!  The following mods were made:
> > > >
> > > >1 - Consistency:  this is a SERVICES diagram only.  No
> > protocols mixes etc.
> > >
> > >That was a good idea.
> > >
> > > >2 - TCONs Layers:  lists the 3 types of transport services
> > provided.  Adds
> > > >clarity to what TCONS is/does/supports.
> > > >3 - Network Layer  - now includes an Address-to-link
> > translation service
> > > >-- the "official" name can be TBD but for now it describes the
> > service> >provided.  This is where the packet destination info is
> > translated into
> > > >the outgoing link by TCONS (and vice versa on receive),
> > providing a
> > > >generic service i/f to the OBL abstraction service.  See Rick's
> > charts on
> > > >OBL service i/f.
> > > >4 - Data link - instead of SNDCL, etc., this is much cleaner (and
> > > >clearer).  The OBL abstraction provides the "generic" or
> > independent> >service i/f.  Then OBL does it "dependent " thing,
> > according to the
> > > >provided "link".  The  "abstraction" service i/f can be exposed to
> > > >non-TCONS entities.
> > > >5 - The Physical layer is outside the SOIS domain, so while it
> > is still
> > > >included in the overall diagram, it is not part of SOIS.
> > Rather, it is
> > > >"driven" by other external standards.
> > > >
> > > >Let the discussion begin..........
> > > >
> > > >Jane
> > >
> > >I agree with most of it excepting notes at the beginning.
> > >
> > >Abhijit
> > >
> > >
> > >
> > >________________________________________________
> > >All personal and professional opinions in this email are my own
> > >and do not represent, in any way, the opinion or policy of JPL
> > >________________________________________________
> > >
> > >
> > >_______________________________________________
> > >Sois-tcons mailing list
> > >Sois-tcons at mailman.ccsds.org
> > >http://mailman.ccsds.org/mailman/listinfo/sois-tcons
> >

________________________________________________
All personal and professional opinions in this email are my own
and do not represent, in any way, the opinion or policy of JPL
________________________________________________