[Sois-tcons] RE: [Sois-tcoa] Simplified TCONS ServicesReference
Model
Scott,Keith L.
kscott at mitre.org
Mon Mar 14 16:56:27 EST 2005
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
>
More information about the Sois-tcons
mailing list