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

[Richard Schnurr]

OK,  I agree with your assessment if the TCONS PDU is requirement.

Can you help us with the SCPS-NP and TP services.  Are they the same as IP 
and TCP?  Or are there some additional services.  I know SCPS-TP has 
options to improve performance and NP has fewer bits in the header but are 
there services I don't know about.

Does SCPS-TP have a UDP flavor or does one simply use UDP with SCPS-NP??

Rick

At 04:56 PM 3/14/2005, Scott,Keith L. wrote:
>Rick,
>
>The short answer might be:
>
>I think we agreed in Toulouse that we needed a 'next proto' field in the
>TCONS networking header to differentiate the Best Effort, Reliable, and
>Scheduled transport PDUs, right?  What if there were another type: 'IP', so
>that IP could run directly over TCONS networking (and subject to all the
>scheduling), and IP PDUs were treated like TCONS best-effor PDUs?  To IP,
>TCONS networking would look like a data link layer with 8 'extra' bytes of
>overhead (acknowledging that those 8 bytes give multi-network
>addressability).  To TCONS routers, IP PDUs would be treated exactly like
>TCONS Best-Effort PDUs, except that at the destination they would
>demultiplex to the IP process instead of to TCONS transport (and hence
>bypass having to carry 6 bytes of TCONS best-effort PDU header).
>
>This would require the TCONS networking service to expose another service
>access point, multiplexed/demultiplexed via the 'next proto' field in the
>TCONS networking header.  It would require (I think) minimal changes to
>TCONS, while allowing IP 'close' access to the underlying network, subject
>to conforming to the TCONS schedule.
>
>TCONS Transport Services           IP
>     |    |    |                     |
>     |    |    |                     |
>     +----+----+---------------------+
>          |
>          |
>+--------v-----------------------------------+   +-------------------
>|     {next proto}  TCONS Networking         |<--| TCONS scheduling
>+--------------------------------------------+   +-------------------
>|              OBL                           |
>+--------------------------------------------+
>|               BUS/LAN                      |
>+--------------------------------------------+
>
>The 'on-the-wire' format for IP packets would then look like:
>
>+--------------------+---------------+-----------+------------------
>| Underlying Network | TCONS Network | IP Header | TCP/UDP Header
>|   e.g. Ethernet    |               |           |
>+--------------------+---------------+-----------+------------------
>
>TCONS Network: {ODA, TTL, QoS/Type, OSA, Next Proto, HDR CHK, ...PDU...,
>CRC}
>
>
>                 --keith
>
>
> >-----Original Message-----
> >From: sois-tcons-bounces at mailman.ccsds.org
> >[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
> >Richard Schnurr
> >Sent: Monday, March 14, 2005 2:09 PM
> >To: Chris Plummer; 'Abhijit Sengupta';
> >sois-tcons at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
> >Subject: RE: [Sois-tcons] RE: [Sois-tcoa] Simplified TCONS
> >ServicesReference Model
> >
> >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.
> >
> >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.
> >
> >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 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
> >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 protocol view will be much easier if we have the service
> >view done fist.
> >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
> >
> >
> >_______________________________________________
> >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