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

[Abhijit Sengupta]

At 3/14/2005 11:08 AM, Richard Schnurr wrote:
>Hi All,
>
>The real issue seems to be the exposure of the TCONS networking service as 
>a "public" service - giving other network services access to the bus.

In my posting replying to posting by Chris, I expressed my opinion. To 
summarize, I do not see the  network layer services as "public" service. To 
support single sub-network, transport and network layers virtually do not 
do anything other than a "pass-through" entity.

>Also, I think we need to talk compliance again.  If a Spacecraft runs 
>NP/IP directly over SpaceWire is it SOIS compliant.  In some ways I do not 
>want to answer this question yet but I think it is at the heart of what 
>people are thinking.

Aahh the compliance again!!
In my opinion:
I view (I said this once before in one of my postings) the overall design 
as a hierarchic one - the overall design is a stack of layers where each 
layer offers a bunch of services and each services is provided by a bunch 
of protocols.
To be compliant, each implementation must have the following:
(1) all services in a layer are available (this implies at least one 
protocol implementing the service is available)
(2) all protocols providing the same service can talk to each other

Hence if we decide that onboard transport services are provided by both 
tcons-transport services and tcp, then tcons-transport services need to 
device a mechanism to talk to tcp, if that is not possible then either 
tcons-transport services or tcp, but not both, can provide the onboard 
transport service.


>If a mission is only using IP or NP and it is not using TCONS services or 
>maybe even have the TCONS API implemented to work over IP or NP.  Is this 
>mission SOIS compliant and how do we describe this compliancy.
>
>Rick
>
>Abhijit,
>
>The services provided by SCPS-NP, and TP are very well defined since NP is 
>a derivation of IP and

Yes, the services are defined on the basis of protocol definitions.

>TP is a derivation of TCP.  Unfortunately, people talk about NP and TP as 
>if everyone knows what service they provide.  I can assure you people in 
>the flight community, in general, do not.  For example

** no comments ***

>the normal services for IP are a unreliable (Unacknowledged) data gram 
>service and a reliable stream service.  The IP network services are 
>basically source and destination address routing.
>
>I think TP and NP provide the same basic services for SpaceLink (With some 
>TCP enhancements in TP).  Now TCONS does not really have a stream service 
>and TCONS does not support IP or NP addressing.  TCONS does support 
>non-guaranteed, Guaranteed and synchronous delivery services for defined 
>length SDU's PDU's using TCONS OSA and ODA 16 bit addressing.  Now I think 
>SCPS NP actually has a 16 bit addressing mode.  If SCPS supports protocol 
>multiplexing then running the scheduled service over SCPS-NP might be viable.
>
>Again I implore upon you to make the first architecture picture a service 
>only picture.  If you want to include SCPS-TP or NP please lets figure out 
>what services they provide.  (Keith help me here).

The last diagram that I sent was indeed service only diagram (the boxes 
that were marked SCPS-TP etc were meant to represent the services provided 
by them, because the service name was not defined)

>The protocol view will be much easier if we have the service view done fist.


I agree.

Abhijit


>Rick
>
>
>At 04:53 PM 3/11/2005, 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?
>>
>>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.
>>
>>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!
>>
>>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
>> >
>>
>>
>>_______________________________________________
>>Sois-tcons mailing list
>>Sois-tcons at mailman.ccsds.org
>>http://mailman.ccsds.org/mailman/listinfo/sois-tcons
>
>Richard G Schnurr Jr
>Chief Architect
>Electrical Systems Center
>Applied Engineering and Technology Directorate
>NASA GSFC Code 560.0
>Greenbelt MD 20771
>
>(301)-286-1852



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