[Sois-sig1] Rough summary of prior sois-sig1 discussions
Peter Shames
peter.shames@jpl.nasa.gov
Thu, 4 Sep 2003 11:51:58 -0700
--============_-1149420973==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Dear SOIS - SIG1 members,
In response to this outpouring of discussion on the topics of
networking and internetworking in SOIS (and SIS) we have been asked
to form a SIG. Takahiro Yamada has agreed to chair this working
group and we propose having a one (1) day meeting dedicated to these
issues and other SEA / SOIS coordination on 29 Oct, as part of the
set of CCSDS meetings that are planned in the Washington DC area.
We will produce a draft agenda for this shortly, but the summary
topics would appear to be:
SOIS Time Critical services and drivers
SOIS Network and Internetwork services
Onboard busses and requirements
SIS Internetwork services
Off-board (overboard?) internetworking requirements
Their relationships
Please signal if you will be available for this discussion. Please
also indicate if you have other topics that relate to this discussion
that you wish to introduce (or some you wish to remove for any stated
reason).
Thanks, Peter Shames
PS - thanks to Adrian for creating a single (somewhat) coherent log
of the discussions to date.
At 1:39 PM -0700 8/22/03, Adrian J. Hooke wrote:
>BEGIN SUMMARY OF PRIOR DISCUSSIONS:
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>From: Joseph F. Smith [mailto:Joseph.F.Smith@jpl.nasa.gov]
>Sent: 29 July 2003 23:34
>
>For quite some time, Adrian Hooke has had a Powerpoint slide that
>shows the different CCSDS protocols, and how they inter-relate, sort
>of like a protocol stack.
>
>I've always liked this slide, but I've had some issues with the way
>that Adrian showed the SOIF protocols, that I couldn't quite put my
>finger on. The easiest way to address my issues, was to modify his
>slide. Having done that, I am attaching the modified Hooke slide
>for your comments.
>
>You'll see the SOIF protocols off to the left. Notice, that I put
>the Onboard Application Services above that, and the Time Constrained
>Applications Services above everything.
>
>So, how does this look. If this isn't quite right, that's OK. The
>reason to send this out is to get comments, so that its a better
>product.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>At 12:58 PM +0100 8/14/03, Steve Parkes wrote:
>Joe,
>
>What happened to the Time Critical Network Services from SOIF in your
>diagram?
>
>Please do not assume that these will be straight TCP/IP. There is a growing
>concern about using TCP/IP as an onboard transport/network protocol due to
>the overhead and recovery mechanisms. The Time Critical Network Services
>working group (GSFC and UoD) following the last SOIF meeting have been
>working towards a protocol set for onboard networks which is can carry
>TCP/IP and other protocols but which has significantly less overhead.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Thu, 14 Aug 2003 08:19:39 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>
>>At 04:58 AM 8/14/2003, Steve Parkes wrote:
>>Please do not assume that these will be straight TCP/IP. There is a
>>growing concern about using TCP/IP as an onboard transport/network
>>protocol due to the overhead and recovery mechanisms. The Time
>>Critical Network Services working group (GSFC and UoD) following
>>the last SOIF meeting have been working towards a protocol set for
>>onboard networks which is can carry TCP/IP and other protocols but
>>which has significantly less overhead.
>>
>
>I'm having trouble parsing your note. Is the problem the overhead of
>IP, or the recovery mechanisms and overhead of TCP, or all of the
>above, or something else? Somehow, encapsulating "TCP/IP and other
>protocols" in yet another protocol set does not seems to be a way to
>get "significantly less overhead".
>
>It does seem to me that here is a classic case of why we need
>cross-Area coordination. I've added Dai and Durst to this reply for
>their take on the issues.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>>At 07:55 AM 08/15/03, Joseph F. Smith wrote:
>>
>>> I thought that the TCP/IP and SCPS protocols were over on the
>>>right side of the diagram,
>>>
>
>Guys, could we please try to get the terminology right? To
>summarize, the "IP suite" maps as follows:
>
>Applications: Lots
>Transport: TCP/UDP
>Security: IPSec
>Network: IP
>
>The current SCPS profile of the IP suite is:
>
>Applications: FTP (the SCPS-FP *is* FTP)
>Transport: TCP/UDP (the SCPS-TP *is* TCP)
>Security: IPSec or SCPS-SP (the SCPS-SP maps to IPSec)
>Network: IP or SCPS-NP (the SCPS-NP maps to IP)
>
>So could someone please clarify what is meant by "TCP/IP and SCPS
>protocols", because to me they are one and the same thing? In
>reality, isn't the only discussion that's germane to onboard
>networking the discussion about whether to use IP or it's compressed
>version (NP) in a constrained environment?
>
>///adrian
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Fri, 15 Aug 2003 12:54:14 -0400
>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.2.20030815080316.025c3830@mail1.jpl.nasa.gov>
>
>I agree with your statement of the layers as far at it goes. All of
>what Steve and I are talking about are below the network layer. In
>general many link layers are considered sub-networks by some of us.
>For me this is based in years of using Ethernet, PCI, USB, 1553 and
>other bus sub networks to solve real world problems. Often the
>"quality of service issues" and fault tolerance issues must be
>solved at this level. The fact that IP can ride over any of these
>links or sub-networks is the beauty of agreeing on using IP in one
>of its forms as a unifying force. I completely agree that the SCPS
>suit is equivalent and can be used with appropriate gateway services
>and may provide benefits. However the onboard links/sub-networks
>need to meet "flight requirements".
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Mon, 18 Aug 2003 10:19:26 -0700
>From: Peter Shames <peter.shames@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.2.20030815080316.025c3830@mail1.jpl.nasa.gov>
>
>There's a real danger here, since I find myself agreeing with Adrian
>twice in the same one week period. As he correctly points out,
>there is a direct relationship and/or mapping between TCP/IP
>(standard Internet Protocol Suite or IPS) and SCPS. The main
>difference, for on-board purposes, is the ability to use compressed
>addresses, for a significant savings in overhead. The main
>different for link purposes is that SCPS comes tuned for space use
>with some valuable extensions beyond what basic IPS provides.
>
>There does seem to be another thing going on here, and that is an
>attempt to try and build some Spacewire specific network and
>transport services. At least that is how I read the comments from
>Steve Parkes and Rick Schnurr. There are, of course, a few issues
>here that need to be addressed. My summary is;
>
>- how does this relate to any of the existing standardized
>approaches (e.g. IPS or SCPS?
>- what advantages, if any, does it offer in terms of performance,
>reliability, overhead, implementation cost?
>- how do you achieve interoperability across any data link that is
>not Spacewire?
>- why aren't you being clear about this being new network layer and
>transport layer functionality instead of calling it parts of the
>Spacewire data link protocol?
>- how do you justify doing this instead of evaluating what already
>exists for suitability?
>
>In Rick's note he said the following;
>
>
>Honestly, I have not compared what we came up to with SCPS but in
>some ways SCPS and this transport layer are at different levels of
>the protocol stack. In reality this exchange shows that we still
>cannot come to grips with link layers providing transport services.
>Good examples include 1394/USB.
>
>It's not clear to me why anyone would go off and invent something
>new without looking at what has been done, and used successfully in
>space, first. And this issues of SCPS, which includes transport and
>this new "transport" layer being at different layers is just bogus.
>The term "transport" means something in ISO, as does the term
>"network". It is not useful to play fast and loose with these terms
>as it just confuses everyone. Link layers do not provide transport
>services. Specs like 1394 and USB are not just link layer specs.
>Instead, these specs include transport and application layer
>functionality like "plug and play". These are not link layer
>functions and it is specious to describe them as such.
>
>In the end we are either about trying to define the SOIF
>architecture, with its support for multiple protocols, busses,
>components, and applications or we are working as a Spacewire
>industry group. We are very interested in the former and will work
>to support standards that accomplish this. We will make use of
>Spacewire and other busses as they fit various mission goals, but
>have commitments to other bus standards as well. Developing specs
>that only work with one bus are antithetical to what i understood we
>were all trying to accomplish.
>
>Regards, Peter Shames
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Mon, 18 Aug 2003 11:01:56 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <p0521066dbb66b623d291@[128.149.8.95]>
>
>At 10:19 AM 8/18/2003, Peter Shames wrote:
>
>>It's not clear to me why anyone would go off and invent something
>>new without looking at what has been done, and used successfully in
>>space, first. And this issues of SCPS, which includes transport
>>and this new "transport" layer being at different layers is just
>>bogus. The term "transport" means something in ISO, as does the
>>term "network". It is not useful to play fast and loose with these
>>terms as it just confuses everyone. Link layers do not provide
>>transport services. Specs like 1394 and USB are not just link
>>layer specs. Instead, these specs include transport and
>>application layer functionality like "plug and play". These are
>>not link layer functions and it is specious to describe them as
>>such.
>>
>
>I too am trying to parse the [apparently loose] use of "Transport"
>and "Network". What I thought was going on was that:
>
>a) Onboard buses and LANs are at the Link layer.
>
>b) Onboard Applications may run over general purpose onboard
>Transport and Network Services, but in time constrained
>circumstances they may [for reasons that are both unclear and
>possibly undocumented] want to bypass these general purpose services
>and run directly over the bus/LAN Link layer.
>
>c) So what SOIS is trying to do is to write a universal convergence
>layer ("Kevin") that can allow time constrained Applications to
>interface directly with a variety of underlying buses/LANs and yet
>still get robust reliability and routing services.
>
>d) So the top side of "Kevin" is trying to provide very thin and
>robust special-purpose Transport and Network services that sit
>directly below the time constrained Application.
>
>e) The bottom-side of "Kevin" contains the bus/LAN-specific drivers
>that allow it to run over various technologies.
>
>If a) through e) are correct, then Kevin would in fact have
>Transport and Network capability, and it would be designed to run
>over more than just Spacewire. But what's missing here is an
>understanding of why general purpose "TCP-UDP/IP" reliability and
>routing won't work, and why special purpose capabilities must be
>designed. And in particular, if someone thinks that the Applications
>are running native TCP/IP and that this *then* gets encapsulated in
>"Kevin" to achieve performance, then someone needs to think about
>performance some more.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>At 05:48 PM 8/18/2003, David Stanton wrote:
>It would seem to me that the important thing to recognise is that
>the network and transport layers should be defined by their
>architectural significance rather than the functionality of typical
>protocols which inhabit these layers. Network layer provides
>homogeneous communications capability over a heterogeneous
>collection of subnets and, to accomplish this, exists in all data
>systems which are at subnet boundaries (it also needs to provide
>global means of, for instance, addressing routing and relaying which
>leads to the common functionality of typical network layers. The
>transport layer provides the communication service at the end
>systems and different functionalities are possible depending on
>whether reliability is required, the only common functioanlity being
>a multipexing one.
>
>If the functionalities required by SOIS are those of relaying (and
>maybe routing) through switching nodes in a subnetwork and providing
>reliability within a subnetwork, these functionailities can be
>embedded in the subnet and should not be termed network or transport
>layer functionailty. Respective examples are Bluetooth's piconet
>interconnectivity and our very own COP-1 and COP-P .
>
>If, however, the onboard systems have requirements at network layer
>and at transport layer which cannot be met by the existing globally
>adopted TCP/UDP/IP protocols then we have a different story.
>However, I'd be astonished if this was the case given the (in comms
>terms) benign nature of the onboard networking environment and its
>similarity to the terrestrial environment.
>
>I think I've just agreed with both Adrian and Peter. It's getting
>scary in here.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Mon, 18 Aug 2003 19:34:22 -0400
>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>Subject: Re: CCSDS Protocol Diagram
>In-reply-to: <002601c365d2$7daec890$0a01a8c0@keltik>
>
>Sorry to respond in pies meal. I agree with most of what you say.
>I will disagree with one point. The onboard network that runs the
>Spacecraft is not particularly like most ground networks. The
>spacecraft network has significant amounts of synchronous/scheduled
>traffic, mixed with scheduled periods of asynchronous data. The
>reliability of the synchronous data is usually assured using some
>form of bounded retries with timely notification. How one
>schedules/allocates the network is usually a significant problem:
>Mil-STD-1553, IEEE-1394, and USB all provide services to support
>such transfers but they are not uniform. Mapping to our application
>is rarely unique. If we have no agreed to mappings wire level
>compatibility cannot be achieved, one of our goals within SOIS. As
>stated in the previous E-Mail the SpaceWire is not encumbered by a
>pre-existing method of handling this so "we" are inventing one. I
>have no real desire to re-invent the wheel so help us not do that.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Tue, 19 Aug 2003 01:45:03 +0100
>From: David Stanton <dstanton@keltik.co.uk>
>Subject: Re: CCSDS Protocol Diagram
>
>I think we're probably in agreement. Your solution seems to be
>spacewire oriented and there is an obvious analogy with terrestrial
>high rate subnets such as ATM. The subnet serves both the packet
>(i.e IP) traffic which can support both anisochronous and
>isochronous traffic (though the latter only with RTP and a
>comfortable bandwidth margin) and circuit switched (with guaranteed
>isochronous capability) traffic. In the latter case we're not in the
>packet handling (with vocabulary defined by ISO 7498) universe and
>so the application plugs straight into the subnet, no need for
>network or transport references. Your case of a halfway house where
>the ephemeris of data means that there is a time limit on the the
>number of retries is interesting. I'm trying hard to think of a
>similar terrestrial analogy and I believe that looking at UDP/RTP
>might be appropriate (or even TCP/HTTP/404 :-))
>
>Interestingly, Gorrie Fairhust at York(?) has advocated limited
>retries in the space link subnet as a supplement to end-to-end TCP
>for some time. Durst does not agree.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Tue, 19 Aug 2003 08:28:00 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: Re: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.0.20030818191917.01ca70b8@pop500.gsfc.nasa.gov>
>
>At 04:34 PM 8/18/2003, Richard G. Schnurr wrote:
>
>>.... I agree with most of what you say. I will disagree with one
>>point. The onboard network that runs the Spacecraft is not
>>particularly like most ground networks. The spacecraft network has
>>significant amounts of synchronous/scheduled traffic, mixed with
>>scheduled periods of asynchronous data.
>>
>
>That's an interesting thought. A recognition that there is a
>difference in networking technology between spacecraft and ground
>network in the dimensions that you describe would appear to lead to
>the conclusion that the onboard networks are not purely IP-based. In
>fact, they seem to more closely resemble a process control
>environment, so perhaps the Neitzels of the world need to be brought
>into the "Kevin" discussion?
>
>But doesn't that recognition also run counter to the
>"all-IP-all-the-time" crowd, who advocate changing the whole
>end-to-end system to match their religion, no matter what the cost?
>
>///adrian
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Tue, 19 Aug 2003 20:26:53 +0200
>From: Chris Plummer <c.plummer@skynet.be>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.2.20030819080254.02489e60@mail1.jpl.nasa.gov>
>
>Yep, the "all-IP-all-the-time" paradigm hinges on the "no matter
>what the cost", and that cost is grossly underestimated for onboard
>systems. To meet the fairly modest hard real-time requirements of
>the synchronous data transfers on the onboard bus could conceivably
>be met using an all IP solution, but it would imply a prohibitive
>cost in terms of processing power and available bandwidth.
>
>To a certain extent, the fieldbus community swings too far the other
>way by ripping out all of the middle layers and planting
>applications straight on top of the data link. The tricky path that
>we will have to tread in the SOIF area is to allow the user
>community to use whatever is appropriate for each case, i.e. IP etc.
>when it makes sense, e.g. for non time critical asynchronous
>transfers, and lean-and-mean fieldbus type protocols when we are
>dealing with the synchronous or time critical command and control.
>
>One potential solution of course would be to use separate onboard
>buses for communication, and command and control functions. However,
>this is both a costly and limiting solution that doesn't scale well
>to different missions. Therefore, we are left with the problem of
>supporting this mixed traffic capability on a single bus. And I'm
>afraid that the "all-IP-all-the-time" advocates are going to have to
>listen to, and accept, the views of the onboard practitioners who
>have been dealing with this problem for many years.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Tue, 19 Aug 2003 12:53:00 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <p0521068fbb6827886de0@[128.149.8.95]>
>
>At 12:16 PM 8/19/2003, Peter Shames wrote:
>
>>In fact, i would (and have) argue that this is exactly why we ought
>>to be coming up with the right lean and mean MTS solution that can
>>run over all sorts of underlying busses (or queues), including over
>>IP if you happen to have it.
>>
>
>Yes, but doesn't this one go ... ahh ... offboard? If so, why
>discuss it in SOIS?
>
>>At 8:26 PM +0200 8/19/03, Chris Plummer wrote:
>>
>>>To a certain extent, the fieldbus community swings too far the
>>>other way by ripping out all of the middle layers and planting
>>>applications straight on top of the data link. The tricky path
>>>that we will have to tread in the SOIF area is to allow the user
>>>community to use whatever is appropriate for each case, i.e. IP
>>>etc. when it makes sense, e.g. for non time critical asynchronous
>>>transfers, and lean-and-mean fieldbus type protocols when we are
>>>dealing with the synchronous or time critical command and control.
>>>
>
>So how does "the right lean and mean MTS" differ from a
>"lean-and-mean fieldbus", when we are dealing with the synchronous
>or time critical command and control? [Which, after all, is what
>this thread is all about, isn't it?] And if it's an application
>planted straight on top of the data link, what plants it there? And
>how does it implement reliability? And why aren't we discussing this
>on a proper mailing list, so other people can share the joy?
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Wed, 20 Aug 2003 09:04:19 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <p0521066dbb66b623d291@[128.149.8.95]>
>
>At 10:19 AM 8/18/2003, Peter Shames wrote:
>
>>In the end we are either about trying to define the SOIF
>>architecture, with its support for multiple protocols, busses,
>>components, and applications or we are working as a Spacewire
>>industry group. We are very interested in the former and will work
>>to support standards that accomplish this. We will make use of
>>Spacewire and other busses as they fit various mission goals, but
>>have commitments to other bus standards as well. Developing specs
>>that only work with one bus are antithetical to what i understood
>>we were all trying to accomplish.
>>
>
>If one bus turned out to be able to meet the majority of mission
>needs, and was widely supported by industrial suppliers, would you
>still take that position?
>
>Has the SOIS team actually produced a document that compares the
>various candidates head-to-head in a nice clear format that anyone
>can understand? ["Ah, I see now, for this set of requirements I
>would probably select x and y"]. While "support for multiple
>protocols, busses, components, and applications" *may* be the
>inevitable conclusion, are we sure that we are there yet? Isn't
>standardization a quest for convergence?
>
>///adrian
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Wed, 20 Aug 2003 08:08:46 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <002101c3667f$772810a0$0424fea9@Cotec8>
>
>Since Rick said "forward this as you like", I'm sending this back to
>the rest of you for comment since there appear to be some
>differences at work here. Comments, people? I have one, which I will
>send separately.
>
>///adrian
>+++++++++
>
>>Date: Tue, 19 Aug 2003 17:31:17 -0400
>>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>>Subject: Re: CCSDS Protocol Diagram
>>To: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>>Cc: Jane Marquart <Jane.Marquart@gsfc.nasa.gov>
>>
>>Hi Adrian,
>>
>>I think we have converged. We do think we can use the IP/SCPS on
>>the long haul and many instrument applications. We also think we
>>can map certain IP/SCPS connections to underlying links that have
>>the appropriate properties to allow the spacecraft to function
>>using IP/SCPS (This has a big test advantage for us since we create
>>a custom box that performs this function repeatedly). We also
>>recognize that many links exist and some unifying standard must be
>>used when one is going from one link to another.
>>
>>I agree with the model where IP data traverses a ATM or another
>>packet switched network. One must have a preordained mapping of
>>connections and BW otherwise someone who is not paying very much
>>might use more of the connection than he/she is allowed. This same
>>model can be applied to spacecraft. In general our concept for the
>>onboard network would allow IP/SCPS networks/connections to be
>>pushed across the SpaceWire network much as IP is pushed across
>>ATM/Frame-Relay links. Yes other dedicated traffic might co-exist
>>on the link if needed.
>>
>>As far as the IP stuff goes maybe others noise has drowned my
>>personal position out so let me restate. I think all the
>>protocols/standards we come up with (above physical) should have a
>>standard mapping to IP. All of the protocol data units should be
>>self describing and all management commands and parameters should
>>be defined in terms of an XML markup. All gateway functions should
>>be fully defined and automatic.
>>
>>An example: if I open a UDP/TCP stream on the ground to an address
>>that exists on a spacecraft at the end point of a SpaceWire network
>>the data unit should be delivered and should be understood by that
>>end point.
>>
>>Conversely if the device at the end of a SpaceWire link sends a
>>packet intended for an address on another sub-net that packet
>>should reach its destination.
>>
>>None of this should interfere with the critical real time traffic
>>which might or might not be IP/SCPS based. IE the SpaceWire Bus
>>should allocate BW and perform retries on alternate networks to
>>insure seamless and timely delivery of time critical data.
>>
>>If this requires standard "Kevins" for the different data links
>>then so be it. For GPM we have no RT "kevin" on the Ethernet.
>>Thus we cannot mix time critical and non time critical data on the
>>Ethernet. Our solution: Keep a 1553 bus for the time critical
>>stuff and do all the asynchronous housekeeping and data traffic
>>over the Ethernet. Thus we eliminate the problem by segmenting our
>>data on two links. The 1553 real time link is not IP/SCPS but it
>>could be if the overhead were low enough and fault tolerance issues
>>were addressed. Its the segmentation of the traffic/reliability
>>classes which is of note (and is really the hard part in my view).
>>
>>The current baseline for the SpaceWire Packet switched network
>>assumes that the connections are split. If one is entirely within
>>the SpaceWire network one is free to use the channel number
>>directly. Otherwise this channel must be associated with some
>>higher level network/transport connection.
>>
>>Rick
>>
>>Forward this as you like.
>>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Wed, 20 Aug 2003 08:13:17 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: Re: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.0.20030819165022.01d379f8@pop500.gsfc.nasa.gov>
>
>At 02:31 PM 8/19/2003, Richard G. Schnurr wrote:
>
>>If this requires standard "Kevins" for the different data links
>>then so be it. For GPM we have no RT "kevin" on the Ethernet.
>>Thus we cannot mix time critical and non time critical data on the
>>Ethernet. Our solution: Keep a 1553 bus for the time critical
>>stuff and do all the asynchronous housekeeping and data traffic
>>over the Ethernet. Thus we eliminate the problem by segmenting our
>>data on two links.
>>
>
>At 11:26 AM 8/19/2003, Chris Plummer wrote:
>
>>One potential solution of course would be to use separate onboard
>>buses for communication, and command and control functions.
>>However, this is both a costly and limiting solution that doesn't
>>scale well to different missions. Therefore, we are left with the
>>problem of supporting this mixed traffic capability on a single bus.
>>
>
>Umm, there seems to be a strong difference of opinion here. Rick:
>the ESA folk seem to represent the "views of the onboard
>practitioners who have been dealing with this problem for many
>years". What would the GPM (Global Precipitation Mission) people
>have to say about the assertion that they may be adopting "a costly
>and limiting solution that doesn't scale well to different missions"?
>
>///adrian
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Wed, 20 Aug 2003 18:33:46 -0400
>From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov>
>Subject: Re: CCSDS Protocol Diagram
>In-reply-to: <5.1.0.14.2.20030820080323.024fb858@mail1.jpl.nasa.gov>
>
>We actually agree with Chris Plummer's position but as good little
>flight engineers we chose to walk before we run. Our goal is to
>develop a single seamless network that can be used for command and
>control and data. We think the SpaceWire network developed can
>support this. As far as any particular mission flying a costly bus
>everything is relative. On GPM we were going to fly SpaceWire and
>1553 for the Spacecraft bus. So a single Ethernet supporting both
>was actually less expensive.
>
>In any event we also wanted to avoid implementing something in this
>area for flight until we get agreement from the community. I think
>you can imagine that GSFC is capable of implementing something that
>might become a local de facto standard. We have no interest in
>doing so as it might not lead to the convergence we desire.
>
>I think Adrian is making with Adrian's point I think we should write
>down our requirements to make sure that any proposal can be
>objectively measured against some criteria.
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>Date: Wed, 20 Aug 2003 16:02:14 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: RE: CCSDS Protocol Diagram
>In-reply-to: <p052106adbb6945e390df@[128.149.8.95]>
>
>At 09:20 AM 8/20/2003, Peter Shames wrote:
>
>>(Rick)
>>
>>>>I think we have converged. We do think we can use the IP/SCPS on
>>>>the long haul and many instrument applications.
>>>>
>>(Peter)
>>We do not believe that you can use IP/SCPS on the "long haul" as we
>>understand that term. SCPS can be used on the "short haul" out to
>>Lunar distances, if the right options are chosen.
>>
>
>I still have NO IDEA what Rick means by "IP/SCPS". If you can take
>the hit of the overhead, you can run IP-over-CCSDS anywhere you
>want. If you want to run any flavor of TCP (including the SCPS
>flavor; repeat after me "SCPS-TP *is* TCP; SCPS-TP *is* TCP") over
>IP then as you note things get really goopy after about Lunar
>distance. The point is that the IP suite is primarily useful in low
>delay environments with rock solid connectivity.
>
>>As discussions in this thread have demonstrated, there are many who
>>do not believe that IP is of any use, onboard or otherwise. They
>>would rather run apps right down to the link layer,
>>
>
>Which is, as Dai pointed out, because all they want is point-point
>transfer across a single homogenous link. If you want to transfer
>across multiple and possibly heterogenous links then you need a
>networking protocol, which is what IP (and the SCPS-NP) is all about.
>
>>(Rick)
>>
>>>>An example: if I open a UDP/TCP stream on the ground to an
>>>>address that exists on a spacecraft at the end point of a
>>>>SpaceWire network the data unit should be delivered and should be
>>>>understood by that end point.
>>>>
>>(Peter)
>>This is an assertion about end to end delivery of data between
>>addressable end points within an IP domain. Where IP protocols
>>work (Lunar distances as less), and where network connectivity
>>makes sense, this is a reasonable assertion to make.
>>
>
>Again, let's be clear: it's not "IP protocols" that go toes-up
>beyond Lunar distances, it's the *chatty* protocols (like TCP) that
>sit on top of IP that get the vapors.
>
>>There are a number of open questions to be discussed here, like:
>>- is such end to end connectivity needed?
>>
>
>That continues to be the $64K question. If you ask an end user "Do
>you want to interface with the mission systems on the ground using
>the IP suite, and do you want your onboard instrument to interface
>with the spacecraft systems using the IP suite", you will probably
>get a "Yes". But translating that into a universal user demand to
>run the IP suite end-to-end really takes some mushrooms!
>
>///adrian
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>Date: Tue, 19 Aug 2003 14:19:07 -0700
>From: "Adrian J. Hooke" <Adrian.J.Hooke@jpl.nasa.gov>
>Subject: Re: CCSDS Protocol Diagram
>In-reply-to: <001201c36690$37e1bb10$0a01a8c0@keltik>
>
>At 01:26 PM 8/19/2003, David Stanton wrote:
>
>>Sounds like we need a joint SIS/SOIS session to thrash this stuff
>>out. Maybe the day before the CESG meeting in October?
>>
>--------------------------
>
>Yes, if the problem space involves Applications and end-to-end
>services and has any significance beyond the onboard system, the
>solution space clearly involves SOIS, SIS and MOIMS and so a
>cross-Area meeting seems in order. Perhaps Peter could convene it
>under the SES umbrella? Right now:
>- the MOIMS Area meetings are Oct 29 - Nov 3.
>- the SES Area meetings are Oct 23 - 29.
>- the SOIS Area meetings are Oct 27-29
>- the SIS Area does not plan to meet
>
>Sounds like Oct 26 would be a possibility, if Peter could yield some
>time? I think most of these meetings are clustered around the
>Goddard area.
>
>However, before firmly scheduling a meeting I would like to see an
>archived cross-Area mailing list set up right away to cover this
>Special Interest Group, technical discussions initiated on that list
>(including a summary of what's been discussed already on this ad-hoc
>group) and a draft agenda developed which identifies and frames the
>issues that cannot be resolved electronically.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>END SUMMARY OF PRIOR DISCUSSIONS.
--
_______________________________________________________________
Peter Shames
Manager - JPL Information Systems Standards Program
InterPlanetary Network and Information Systems Directorate
Jet Propulsion Laboratory, MS 301-265
California Institute of Technology
Pasadena, CA 91109 USA
Telephone: +1 818 354-5740, Fax: +1 818 393-1333
Internet: Peter.Shames@jpl.nasa.gov
_______________________________________________________________
"We shall not cease from exploration, and the end of all our exploring
will be to arrive at where we started, and know the place for the first time"
T.S. Eliot
--============_-1149420973==_ma============
Content-Type: text/html; charset="us-ascii"
<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>Re: [Sois-sig1] Rough summary of prior sois-sig1
discu</title></head><body>
<div>Dear SOIS - SIG1 members,</div>
<div><br></div>
<div>In response to this outpouring of discussion on the topics of
networking and internetworking in SOIS (and SIS) we have been asked to
form a SIG. Takahiro Yamada has agreed to chair this working
group and we propose having a one (1) day meeting dedicated to these
issues and other SEA / SOIS coordination on 29 Oct, as part of the set
of CCSDS meetings that are planned in the Washington DC area.</div>
<div><br></div>
<div>We will produce a draft agenda for this shortly, but the summary
topics would appear to be:</div>
<div><br></div>
<blockquote>SOIS Time Critical services and drivers</blockquote>
<blockquote>SOIS Network and Internetwork services</blockquote>
<blockquote>Onboard busses and requirements</blockquote>
<blockquote>SIS Internetwork services</blockquote>
<blockquote>Off-board (overboard?) internetworking
requirements</blockquote>
<blockquote>Their relationships</blockquote>
<blockquote><br></blockquote>
<div>Please signal if you will be available for this discussion.
Please also indicate if you have other topics that relate to this
discussion that you wish to introduce (or some you wish to remove for
any stated reason).</div>
<div><br></div>
<div>Thanks, Peter Shames</div>
<div><br></div>
<div><br></div>
<div>PS - thanks to Adrian for creating a single (somewhat) coherent
log of the discussions to date.</div>
<div><br></div>
<div><br></div>
<div>At 1:39 PM -0700 8/22/03, Adrian J. Hooke wrote:</div>
<blockquote type="cite" cite>BEGIN SUMMARY OF PRIOR DISCUSSIONS:<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
From: Joseph F. Smith [mailto:Joseph.F.Smith@jpl.nasa.gov]<br>
Sent: 29 July 2003 23:34<br>
<br>
For quite some time, Adrian Hooke has had a Powerpoint slide that<br>
shows the different CCSDS protocols, and how they inter-relate,
sort<br>
of like a protocol stack.<br>
<br>
I've always liked this slide, but I've had some issues with the
way<br>
that Adrian showed the SOIF protocols, that I couldn't quite put
my<br>
finger on. The easiest way to address my issues, was to modify
his<br>
slide. Having done that, I am attaching the modified Hooke
slide<br>
for your comments.<br>
<br>
You'll see the SOIF protocols off to the left. Notice, that I
put<br>
the Onboard Application Services above that, and the Time
Constrained<br>
Applications Services above everything.<br>
<br>
So, how does this look. If this isn't quite right, that's OK.
The<br>
reason to send this out is to get comments, so that its a better<br>
product.<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
At 12:58 PM +0100 8/14/03, Steve Parkes wrote:<br>
Joe,<br>
<br>
What happened to the Time Critical Network Services from SOIF in
your<br>
diagram?<br>
<br>
Please do not assume that these will be straight TCP/IP. There is a
growing<br>
concern about using TCP/IP as an onboard transport/network protocol
due to<br>
the overhead and recovery mechanisms. The Time Critical Network
Services<br>
working group (GSFC and UoD) following the last SOIF meeting have
been<br>
working towards a protocol set for onboard networks which is can
carry<br>
TCP/IP and other protocols but which has significantly less
overhead.<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Thu, 14 Aug 2003 08:19:39 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
<blockquote type="cite" cite>At 04:58 AM 8/14/2003, Steve Parkes
wrote:<br>
Please do not assume that these will be straight TCP/IP. There is a
growing concern about using TCP/IP as an onboard transport/network
protocol due to the overhead and recovery mechanisms. The Time
Critical Network Services working group (GSFC and UoD) following the
last SOIF meeting have been working towards a protocol set for onboard
networks which is can carry TCP/IP and other protocols but which has
significantly less overhead.</blockquote>
<blockquote type="cite" cite><br></blockquote>
</blockquote>
<blockquote type="cite" cite><br></blockquote>
<blockquote type="cite" cite>I'm having trouble parsing your note. Is
the problem the overhead of IP, or the recovery mechanisms and
overhead of TCP, or all of the above, or something else? Somehow,
encapsulating "TCP/IP and other protocols" in yet another
protocol set does not seems to be a way to get "significantly
less overhead".</blockquote>
<blockquote type="cite" cite><br>
It does seem to me that here is a classic case of why we need
cross-Area coordination. I've added Dai and Durst to this reply for
their take on the issues.<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<blockquote type="cite" cite>A<font color="#0000FF">t 07:55 AM
08/15/03, Joseph F. Smith wrote:</font><br>
<font color="#0000FF"></font>
<blockquote type="cite" cite><font color="#0000FF"> I thought
that the TCP/IP and SCPS protocols were over on the right side of the
diagram,</font><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
Guys, could we please try to get the terminology right? To summarize,
the "IP suite" maps as follows:<br>
<br>
Applications: Lots<br>
Transport: TCP/UDP<br>
Security: IPSec<br>
Network: IP<br>
<br>
The current SCPS profile of the IP suite is:<br>
<br>
Applications: FTP (the SCPS-FP *is* FTP)<br>
Transport: TCP/UDP (the SCPS-TP *is* TCP)<br>
Security: IPSec or SCPS-SP (the SCPS-SP maps
to IPSec)<br>
Network: IP or SCPS-NP (the SCPS-NP maps
to IP)<br>
<br>
So could someone please clarify what is meant by "TCP/IP and SCPS
protocols", because to me they are one and the same thing? In
reality, isn't the only discussion that's germane to onboard
networking the discussion about whether to use IP or it's compressed
version (NP) in a constrained environment?<br>
<br>
///adrian<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Fri, 15 Aug 2003 12:54:14 -0400<br>
From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.2.20030815080316.025c3830@mail1.jpl.nasa.gov><br>
<br>
I agree with your statement of the layers as far at it goes. All
of what Steve and I are talking about are below the network layer.
In general many link layers are considered sub-networks by some of
us. For me this is based in years of using Ethernet, PCI, USB,
1553 and other bus sub networks to solve real world problems.
Often the "quality of service issues" and fault tolerance
issues must be solved at this level. The fact that IP can ride
over any of these links or sub-networks is the beauty of agreeing on
using IP in one of its forms as a unifying force. I completely
agree that the SCPS suit is equivalent and can be used with
appropriate gateway services and may provide benefits. However
the onboard links/sub-networks need to meet "flight
requirements".<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Mon, 18 Aug 2003 10:19:26 -0700<br>
From: Peter Shames <peter.shames@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.2.20030815080316.025c3830@mail1.jpl.nasa.gov><br>
<br>
There's a real danger here, since I find myself agreeing with Adrian
twice in the same one week period. As he correctly points out,
there is a direct relationship and/or mapping between TCP/IP (standard
Internet Protocol Suite or IPS) and SCPS. The main difference,
for on-board purposes, is the ability to use compressed addresses, for
a significant savings in overhead. The main different for link
purposes is that SCPS comes tuned for space use with some valuable
extensions beyond what basic IPS provides.<br>
<br>
There does seem to be another thing going on here, and that is an
attempt to try and build some Spacewire specific network and transport
services. At least that is how I read the comments from Steve
Parkes and Rick Schnurr. There are, of course, a few issues here
that need to be addressed. My summary is;<br>
<br>
- how does this relate to any of the existing standardized approaches
(e.g. IPS or SCPS?<br>
- what advantages, if any, does it offer in terms of performance,
reliability, overhead, implementation cost?<br>
- how do you achieve interoperability across any data link that is not
Spacewire?<br>
- why aren't you being clear about this being new network layer and
transport layer functionality instead of calling it parts of the
Spacewire data link protocol?<br>
- how do you justify doing this instead of evaluating what already
exists for suitability?<br>
<br>
In Rick's note he said the following;<br>
<blockquote><font color="#0000FF"><br>
Honestly, I have not compared what we came up to with SCPS but in some
ways SCPS and this transport layer are at different levels of the
protocol stack. In reality this exchange shows that we still
cannot come to grips with link layers providing transport
services. Good examples include
1394/USB.</font></blockquote>
<blockquote><font color="#0000FF"><br></font></blockquote>
</blockquote>
<blockquote type="cite" cite>It's not clear to me why anyone would go
off and invent something new without looking at what has been done,
and used successfully in space, first. And this issues of SCPS,
which includes transport and this new "transport" layer
being at different layers is just bogus. The term
"transport" means something in ISO, as does the term
"network". It is not useful to play fast and loose
with these terms as it just confuses everyone. Link layers do
not provide transport services. Specs like 1394 and USB are not
just link layer specs. Instead, these specs include transport
and application layer functionality like "plug and play".
These are not link layer functions and it is specious to describe them
as such.<br>
<br>
In the end we are either about trying to define the SOIF architecture,
with its support for multiple protocols, busses, components, and
applications or we are working as a Spacewire industry group. We
are very interested in the former and will work to support standards
that accomplish this. We will make use of Spacewire and other
busses as they fit various mission goals, but have commitments to
other bus standards as well. Developing specs that only work
with one bus are antithetical to what i understood we were all trying
to accomplish.<br>
<br>
Regards, Peter Shames<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Mon, 18 Aug 2003 11:01:56 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to: <p0521066dbb66b623d291@[128.149.8.95]><br>
<br>
<font color="#0000FF">At 10:19 AM 8/18/2003, Peter Shames
wrote:</font><br>
<blockquote type="cite" cite>It's not clear to me why anyone would go
off and invent something new without looking at what has been done,
and used successfully in space, first. And this issues of SCPS,
which includes transport and this new "transport" layer
being at different layers is just bogus. The term
"transport" means something in ISO, as does the term
"network". It is not useful to play fast and loose
with these terms as it just confuses everyone. Link layers do
not provide transport services. Specs like 1394 and USB are not
just link layer specs. Instead, these specs include transport
and application layer functionality like "plug and play".
These are not link layer functions and it is specious to describe them
as such.<br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><br>
I too am trying to parse the [apparently loose] use of
"Transport" and "Network". What I thought was
going on was that:<br>
<br>
a) Onboard buses and LANs are at the Link layer.<br>
<br>
b) Onboard Applications may run over general purpose onboard Transport
and Network Services, but in time constrained circumstances they may
[for reasons that are both unclear and possibly undocumented] want to
bypass these general purpose services and run directly over the
bus/LAN Link layer.<br>
<br>
c) So what SOIS is trying to do is to write a universal convergence
layer ("Kevin") that can allow time constrained Applications
to interface directly with a variety of underlying buses/LANs and yet
still get robust reliability and routing services.<br>
<br>
d) So the top side of "Kevin" is trying to provide very thin
and robust special-purpose Transport and Network services that sit
directly below the time constrained Application.<br>
<br>
e) The bottom-side of "Kevin" contains the bus/LAN-specific
drivers that allow it to run over various technologies.<br>
<br>
If a) through e) are correct, then Kevin would in fact have Transport
and Network capability, and it would be designed to run over more than
just Spacewire. But what's missing here is an understanding of why
general purpose "TCP-UDP/IP" reliability and routing won't
work, and why special purpose capabilities must be designed. And in
particular, if someone thinks that the Applications are running native
TCP/IP and that this *then* gets encapsulated in "Kevin" to
achieve performance, then someone needs to think about performance
some more.<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
At 05:48 PM 8/18/2003, David Stanton wrote:<br>
<font face="Arial" size="-1">It would seem to me that the important
thing to recognise is that the network and transport layers should be
defined by their architectural significance rather than the
functionality of typical protocols which inhabit these layers. Network
layer provides homogeneous communications capability over a
heterogeneous collection of subnets and, to accomplish this, exists in
all data systems which are at subnet boundaries (it also needs to
provide global means of, for instance, addressing routing and relaying
which leads to the common functionality of typical network layers. The
transport layer provides the communication service at the end systems
and different functionalities are possible depending on whether
reliability is required, the only common functioanlity being a
multipexing one.</font></blockquote>
<blockquote type="cite" cite> <br>
<font face="Arial" size="-1">If the functionalities required by SOIS
are those of relaying (and maybe routing) through switching nodes in a
subnetwork and providing reliability within a subnetwork, these
functionailities can be embedded in the subnet and should not be
termed network or transport layer functionailty. Respective examples
are Bluetooth's piconet interconnectivity and our very own COP-1 and
COP-P .<br>
</font> <br>
<font face="Arial" size="-1">If, however, the onboard systems have
requirements at network layer and at transport layer which cannot be
met by the existing globally adopted TCP/UDP/IP protocols then we have
a different story. However, I'd be astonished if this was the case
given the (in comms terms) benign nature of the onboard networking
environment and its similarity to the terrestrial environment.<br>
</font> <br>
<font face="Arial" size="-1">I think I've just agreed with both Adrian
and Peter. It's getting scary in here.<br>
<br>
</font
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Mon, 18 Aug 2003 19:34:22 -0400<br>
From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
In-reply-to: <002601c365d2$7daec890$0a01a8c0@keltik><br>
<br>
Sorry to respond in pies meal. I agree with most of what you
say. I will disagree with one point. The onboard network
that runs the Spacecraft is not particularly like most ground
networks. The spacecraft network has significant amounts of
synchronous/scheduled traffic, mixed with scheduled periods of
asynchronous data. The reliability of the synchronous data
is usually assured using some form of bounded retries with timely
notification. How one schedules/allocates the network is usually
a significant problem: Mil-STD-1553, IEEE-1394, and USB all provide
services to support such transfers but they are not uniform.
Mapping to our application is rarely unique. If we have no
agreed to mappings wire level compatibility cannot be achieved, one of
our goals within SOIS. As stated in the previous E-Mail the
SpaceWire is not encumbered by a pre-existing method of handling this
so "we" are inventing one. I have no real desire to
re-invent the wheel so help us not do that.<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Tue, 19 Aug 2003 01:45:03 +0100<br>
From: David Stanton <dstanton@keltik.co.uk><br>
Subject: Re: CCSDS Protocol Diagram<br>
<br>
<font face="Arial" size="-1">I think we're probably in agreement. Your
solution seems to be spacewire oriented and there is an obvious
analogy with terrestrial high rate subnets such as ATM. The subnet
serves both the packet (i.e IP) traffic which can support both
anisochronous and isochronous traffic (though the latter only with RTP
and a comfortable bandwidth margin) and circuit switched (with
guaranteed isochronous capability) traffic. In the latter case we're
not in the packet handling (with vocabulary defined by ISO 7498)
universe and so the application plugs straight into the subnet, no
need for network or transport references. Your case of a halfway house
where the ephemeris of data means that there is a time limit on the
the number of retries is interesting. I'm trying hard to think of a
similar terrestrial analogy and I believe that looking at UDP/RTP
might be appropriate (or even TCP/HTTP/404 :-))<br>
</font> <br>
<font face="Arial" size="-1">Interestingly, Gorrie Fairhust at York(?)
has advocated limited retries in the space link subnet as a supplement
to end-to-end TCP for some time. Durst does not agree.<br>
</font> <br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Tue, 19 Aug 2003 08:28:00 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.0.20030818191917.01ca70b8@pop500.gsfc.nasa.gov><br>
<br>
<font color="#0000FF">At 04:34 PM 8/18/2003, Richard G. Schnurr
wrote:</font><br>
<font color="#0000FF"></font>
<blockquote type="cite" cite><font color="#0000FF">.... I agree with
most of what you say. I will disagree with one point. The
onboard network that runs the Spacecraft is not particularly like most
ground networks. The spacecraft network has significant amounts
of synchronous/scheduled traffic, mixed with scheduled periods of
asynchronous data. </font><br>
</blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#0000FF"><br>
That's an interesting thought. A recognition that there is a
difference in networking technology between spacecraft and ground
network in the dimensions that you describe would appear to lead to
the conclusion that the onboard networks are not purely IP-based. In
fact, they seem to more closely resemble a process control
environment, so perhaps the Neitzels of the world need to be brought
into the "Kevin" discussion?</font></blockquote>
<blockquote type="cite" cite><font color="#0000FF"><br>
But doesn't that recognition also run counter to the
"all-IP-all-the-time" crowd, who advocate changing the whole
end-to-end system to match their religion, no matter what the
cost?<br>
<br>
///adrian<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Tue, 19 Aug 2003 20:26:53 +0200<br>
From: Chris Plummer <c.plummer@skynet.be><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.2.20030819080254.02489e60@mail1.jpl.nasa.gov><br>
<br>
<font face="Arial" size="-1">Yep, the "all-IP-all-the-time"
paradigm hinges on the "no matter what the cost", and that
cost is grossly underestimated for onboard systems. To meet the fairly
modest hard real-time requirements of the synchronous data transfers
on the onboard bus could conceivably be met using an all IP solution,
but it would imply a prohibitive cost in terms of processing power and
available bandwidth.<br>
</font></font><font color="#0000FF"> <br>
<font face="Arial" size="-1">To a certain extent, the fieldbus
community swings too far the other way by ripping out all of the
middle layers and planting applications straight on top of the data
link. The tricky path that we will have to tread in the SOIF area is
to allow the user community to use whatever is appropriate for each
case, i.e. IP etc. when it makes sense, e.g. for non time critical
asynchronous transfers, and lean-and-mean fieldbus type protocols when
we are dealing with the synchronous or time critical command and
control.<br>
</font></font><font color="#0000FF"> <br>
<font face="Arial" size="-1">One potential solution of course would be
to use separate onboard buses for communication, and command and
control functions. However, this is both a costly and limiting
solution that doesn't scale well to different missions. Therefore, we
are left with the problem of supporting this mixed traffic capability
on a single bus. And I'm afraid that the "all-IP-all-the-time"
advocates are going to have to listen to, and accept, the views of the
onboard practitioners who have been dealing with this problem for many
years.<br>
</font></font><font color="#0000FF"> <br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Tue, 19 Aug 2003 12:53:00 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to: <p0521068fbb6827886de0@[128.149.8.95]><br>
<br>
</font><font color="#000080">At 12:16 PM 8/19/2003, Peter Shames
wrote:</font><br>
<font color="#000080"></font>
<blockquote type="cite" cite><font color="#000080">In fact, i would
(and have) argue that this is exactly why we ought to be coming up
with the right lean and mean MTS solution that can run over all sorts
of underlying busses (or queues), including over IP if you happen to
have it.</font><br>
<font color="#0000FF"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000080"><br>
Yes, but doesn't this one go ... ahh ... offboard? If so, why discuss
it in SOIS?</font><br>
<font color="#000080"></font>
<blockquote type="cite" cite><font color="#0000FF">At 8:26 PM +0200
8/19/03, Chris Plummer wrote:</font><br>
<font color="#000080"></font>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">To a certain extent, the fieldbus community swings too
far the other way by ripping out all of the middle layers and planting
applications straight on top of the data link. The tricky path that we
will have to tread in the SOIF area is to allow the user community to
use whatever is appropriate for each case, i.e. IP etc. when it makes
sense, e.g. for non time critical asynchronous transfers, and
lean-and-mean fieldbus type protocols when we are dealing with the
synchronous or time critical command and control.</font><br>
<font color="#000080"></font></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000080"><br>
So how does "the right lean and mean MTS" differ from a
"lean-and-mean fieldbus", when we are dealing with the
synchronous or time critical command and control? [Which, after all,
is what this thread is all about, isn't it?] And if it's an
application planted straight on top of the data link, what plants it
there? And how does it implement reliability? And why aren't we
discussing this on a proper mailing list, so other people can share
the joy?<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Wed, 20 Aug 2003 09:04:19 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to: <p0521066dbb66b623d291@[128.149.8.95]><br>
<br>
</font><font color="#0000FF">At 10:19 AM 8/18/2003, Peter Shames
wrote:</font><br>
<font color="#000080"></font>
<blockquote type="cite" cite><font color="#000080">In the end we are
either about trying to define the SOIF architecture, with its support
for multiple protocols, busses, components, and applications or we are
working as a Spacewire industry group. We are very interested in
the former and will work to support standards that accomplish this.
We will make use of Spacewire and other busses as they fit various
mission goals, but have commitments to other bus standards as well.
Developing specs that only work with one bus are antithetical to what
i understood we were all trying to accomplish.</font></blockquote>
<blockquote type="cite" cite><font
color="#000080"><br></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000080"><br>
If one bus turned out to be able to meet the majority of mission
needs, and was widely supported by industrial suppliers, would you
still take that position?<br>
<br>
Has the SOIS team actually produced a document that compares the
various candidates head-to-head in a nice clear format that anyone can
understand? ["Ah, I see now, for this set of requirements I would
probably select x and y"]. While "support for multiple
protocols, busses, components, and applications" *may* be the
inevitable conclusion, are we sure that we are there yet? Isn't
standardization a quest for convergence?<br>
<br>
///adrian<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Wed, 20 Aug 2003 08:08:46 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to: <002101c3667f$772810a0$0424fea9@Cotec8><br>
<br>
</font><font color="#0000FF">Since Rick said "forward this as you
like", I'm sending this back to the rest of you for comment since
there appear to be some differences at work here. Comments, people? I
have one, which I will send separately.<br>
<br>
///adrian<br>
+++++++++</font><br>
<font color="#0000FF"></font>
<blockquote type="cite" cite><font color="#000080">Date: Tue, 19 Aug
2003 17:31:17 -0400<br>
From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
To: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Cc: Jane Marquart <Jane.Marquart@gsfc.nasa.gov><br>
<br>
Hi Adrian,<br>
<br>
I think we have converged. We do think we can use the IP/SCPS on
the long haul and many instrument applications. We also think we
can map certain IP/SCPS connections to underlying links that have the
appropriate properties to allow the spacecraft to function using
IP/SCPS (This has a big test advantage for us since we create a custom
box that performs this function repeatedly). We also recognize
that many links exist and some unifying standard must be used when one
is going from one link to another.<br>
<br>
I agree with the model where IP data traverses a ATM or another packet
switched network. One must have a preordained mapping of
connections and BW otherwise someone who is not paying very much might
use more of the connection than he/she is allowed. This same
model can be applied to spacecraft. In general our concept for
the onboard network would allow IP/SCPS networks/connections to be
pushed across the SpaceWire network much as IP is pushed across
ATM/Frame-Relay links. Yes other dedicated traffic might
co-exist on the link if needed.<br>
<br>
As far as the IP stuff goes maybe others noise has drowned my personal
position out so let me restate. I think all the
protocols/standards we come up with (above physical) should have a
standard mapping to IP. All of the protocol data units should be
self describing and all management commands and parameters should be
defined in terms of an XML markup. All gateway functions should
be fully defined and automatic.<br>
<br>
An example: if I open a UDP/TCP stream on the ground to an address
that exists on a spacecraft at the end point of a SpaceWire network
the data unit should be delivered and should be understood by that end
point.<br>
<br>
Conversely if the device at the end of a SpaceWire link sends a packet
intended for an address on another sub-net that packet should reach
its destination.<br>
<br>
None of this should interfere with the critical real time traffic
which might or might not be IP/SCPS based. IE the SpaceWire Bus
should allocate BW and perform retries on alternate networks to insure
seamless and timely delivery of time critical data.<br>
<br>
If this requires standard "Kevins" for the different data
links then so be it. For GPM we have no RT "kevin"
on the Ethernet. Thus we cannot mix time critical and non time
critical data on the Ethernet. Our solution: Keep a 1553
bus for the time critical stuff and do all the asynchronous
housekeeping and data traffic over the Ethernet. Thus we
eliminate the problem by segmenting our data on two links. The
1553 real time link is not IP/SCPS but it could be if the overhead
were low enough and fault tolerance issues were addressed. Its
the segmentation of the traffic/reliability classes which is of note
(and is really the hard part in my view).<br>
<br>
The current baseline for the SpaceWire Packet switched network assumes
that the connections are split. If one is entirely within the
SpaceWire network one is free to use the channel number directly.
Otherwise this channel must be associated with some higher level
network/transport connection.</font></blockquote>
<blockquote type="cite" cite><font color="#000080"><br>
Rick<br>
<br>
Forward this as you like.</font><br>
<font color="#000080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#000080"><br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Wed, 20 Aug 2003 08:13:17 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.0.20030819165022.01d379f8@pop500.gsfc.nasa.gov><br>
<br>
</font><font color="#800080">At 02:31 PM 8/19/2003, Richard G. Schnurr
wrote:</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font color="#800080">If this requires
standard "Kevins" for the different data links then so be
it. For GPM we have no RT "kevin" on the
Ethernet. Thus we cannot mix time critical and non time critical
data on the Ethernet. <b> Our solution: Keep a 1553 bus for
the time critical stuff and do all the asynchronous housekeeping and
data traffic over the Ethernet.</b> Thus we eliminate the
problem by segmenting our data on two links. </font><br>
<font color="#000080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
</font><font color="#0000FF">At 11:26 AM 8/19/2003, Chris Plummer
wrote:</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">One potential solution of course would be to<b> use
separate onboard buses for communication, and command and control
functions. However, this is both a costly and limiting solution that
doesn't scale well to different missions.</b> Therefore, we are left
with the problem of supporting this mixed traffic capability on a
single bus.</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
Umm, there seems to be a strong difference of opinion here. Rick: the
ESA folk seem to represent the "views of the onboard
practitioners who have been dealing with this problem for many
years". What would the GPM (Global Precipitation Mission) people
have to say about the assertion that they may be adopting "a
costly and limiting solution that doesn't scale well to different
missions"?<br>
<br>
///adrian<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Wed, 20 Aug 2003 18:33:46 -0400<br>
From: "Richard G. Schnurr" <Rick.Schnurr@nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
In-reply-to:
<5.1.0.14.2.20030820080323.024fb858@mail1.jpl.nasa.gov><br>
<br>
We actually agree with Chris Plummer's position but as good little
flight engineers we chose to walk before we run. Our goal is to
develop a single seamless network that can be used for command and
control and data. We think the SpaceWire network developed can
support this. As far as any particular mission flying a costly
bus everything is relative. On GPM we were going to fly
SpaceWire and 1553 for the Spacecraft bus. So a single Ethernet
supporting both was actually less expensive.<br>
<br>
In any event we also wanted to avoid implementing something in this
area for flight until we get agreement from the community. I
think you can imagine that GSFC is capable of implementing something
that might become a local de facto standard. We have no interest
in doing so as it might not lead to the convergence we desire.<br>
<br>
I think Adrian is making with Adrian's point I think we should write
down our requirements to make sure that any proposal can be
objectively measured against some criteria.<br>
<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
Date: Wed, 20 Aug 2003 16:02:14 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: RE: CCSDS Protocol Diagram<br>
In-reply-to: <p052106adbb6945e390df@[128.149.8.95]><br>
<br>
</font><font color="#0000FF">At 09:20 AM 8/20/2003, Peter Shames
wrote:</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font color="#800080">(Rick)</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font color="#800080">I think we have
converged. We do think we can use the IP/SCPS on the long haul
and many instrument applications.</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#0000FF">(Peter)<br>
We do not believe that you can use IP/SCPS on the "long haul"
as we understand that term. SCPS can be used on the "short
haul" out to Lunar distances, if the right options are
chosen. </font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
I still have NO IDEA what Rick means by "IP/SCPS". If you
can take the hit of the overhead, you can run IP-over-CCSDS anywhere
you want. If you want to run any flavor of TCP (including the SCPS
flavor; repeat after me "SCPS-TP *is* TCP; SCPS-TP *is*
TCP") over IP then as you note things get really goopy after
about Lunar distance. The point is that the IP suite is primarily
useful in low delay environments with rock solid
connectivity.</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font color="#0000FF">As discussions in
this thread have demonstrated, there are many who do not believe that
IP is of any use, onboard or otherwise. They would rather run
apps right down to the link layer,</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
Which is, as Dai pointed out, because all they want is point-point
transfer across a single homogenous link. If you want to
transfer across multiple and possibly heterogenous links then you need
a networking protocol, which is what IP (and the SCPS-NP) is all
about.</font></blockquote>
<blockquote type="cite" cite><font color="#800080"><br></font>
<blockquote type="cite" cite><font color="#800080">(Rick)</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite>
<blockquote type="cite" cite><font color="#800080">An example: if I
open a UDP/TCP stream on the ground to an address that exists on a
spacecraft at the end point of a SpaceWire network the data unit
should be delivered and should be understood by that end
point.</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080">(Peter)<br>
</font><font color="#0000FF">This is an assertion about end to end
delivery of data between addressable end points within an IP domain.
Where IP protocols work (Lunar distances as less), and where network
connectivity makes sense, this is a reasonable assertion to
make. </font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
Again, let's be clear: it's not "IP protocols" that go
toes-up beyond Lunar distances, it's the *chatty* protocols (like TCP)
that sit on top of IP that get the vapors.</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font color="#0000FF">There are a number
of open questions to be discussed here, like:<br>
- is such end to end connectivity needed?</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font color="#800080"><br>
That continues to be the $64K question. If you ask an end user
"Do you want to interface with the mission systems on the ground
using the IP suite, and do you want your onboard instrument to
interface with the spacecraft systems using the IP suite", you
will probably get a "Yes". But translating that into a
universal user demand to run the IP suite end-to-end really takes some
mushrooms!<br>
<br>
///adrian<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
Date: Tue, 19 Aug 2003 14:19:07 -0700<br>
From: "Adrian J. Hooke"
<Adrian.J.Hooke@jpl.nasa.gov><br>
Subject: Re: CCSDS Protocol Diagram<br>
In-reply-to: <001201c36690$37e1bb10$0a01a8c0@keltik><br>
<br>
</font><font color="#0000FF">At 01:26 PM 8/19/2003, David Stanton
wrote:</font><br>
<font color="#800080"></font>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#0000FF">Sounds like we need a joint SIS/SOIS session to thrash
this stuff out. Maybe the day before the CESG meeting in
October?</font><br>
<font color="#800080"></font></blockquote>
</blockquote>
<blockquote type="cite" cite><font
color="#0000FF">--------------------------<br>
<br>
</font><font color="#800080">Yes, if the problem space involves
Applications and end-to-end services and has any significance beyond
the onboard system, the solution space clearly involves SOIS, SIS and
MOIMS and so a cross-Area meeting seems in order. Perhaps Peter could
convene it under the SES umbrella? Right now:</font></blockquote>
<blockquote type="cite" cite><tt><font color="#800080">- the MOIMS
Area meetings are Oct 29 - Nov 3.<br>
- the SES Area meetings are Oct 23 - 29.<br>
- the SOIS Area meetings are Oct 27-29</font></tt></blockquote>
<blockquote type="cite" cite><font color="#800080">- the SIS Area does
not plan to meet<br>
<br>
Sounds like Oct 26 would be a possibility, if Peter could yield some
time? I think most of these meetings are clustered around the Goddard
area.<br>
<br>
However, before firmly scheduling a meeting I would like to see an
archived cross-Area mailing list set up right away to cover this
Special Interest Group, technical discussions initiated on that list
(including a summary of what's been discussed already on this ad-hoc
group) and a draft agenda developed which identifies and frames the
issues that cannot be resolved electronically.<br>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<br>
<br>
END SUMMARY OF PRIOR DISCUSSIONS.</font></blockquote>
<div><br></div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div><font face="Geneva" size="-1"
color="#000000"
>_______________________________________________________________</font
><br>
<font face="Geneva" size="-1" color="#000000"></font></div>
<div><font face="Geneva" size="-1" color="#000000">Peter
Shames</font></div>
<div><font face="Geneva" size="-1" color="#000000">Manager - JPL
Information Systems Standards Program</font></div>
<div><font face="Geneva" size="-1" color="#000000">InterPlanetary
Network and Information Systems Directorate</font></div>
<div><font face="Geneva" size="-1" color="#000000">Jet Propulsion
Laboratory, MS 301-265<br>
California Institute of Technology<br>
Pasadena, CA 91109 USA</font><br>
<font face="Geneva" size="-1" color="#000000"></font></div>
<div><font face="Geneva" size="-1" color="#000000">Telephone: +1 818
354-5740, Fax: +1 818 393-1333<br>
<br>
Internet: Peter.Shames@jpl.nasa.gov<br>
___________________________________________________________</font><font
face="Geneva" size="+1" color="#000000">____</font></div>
<div><font face="Geneva" size="-1" color="#000000">"We shall not
cease from exploration, and the end of all our exploring</font></div>
<div><font face="Geneva" size="-1" color="#000000">will be to arrive
at where we started, and know the place for the first
time"</font></div>
<div><font face="Geneva" size="-1" color="#000000"><br></font></div>
<div><font face="Geneva" size="-1"
color="#000000"
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span
> <span
></span> T.S. Eliot</font></div>
</body>
</html>
--============_-1149420973==_ma============--