[Sis-csi] RE: networking details

[Keith Hogie]

Adrian,

   A major concern is what you mentioned below about Virtual Channels.
Those are a CCSDS data format that was developed 20 years ago and was
a fine solution for the time.  It sounds like you are proposing that
that VC data structure be maintained as the underlying format for civil
space programs for the next 20 years.  Does it make sense to
plan on extending the life of a 20 year old protocol format for
20 more years or is it time for an upgrade or replacement of
the VC format.

   During the last 20 years lots of protocols have come and gone and
been replaced by new ones that better suit users current needs.  The
commercial world primarily uses Frame Relay and DVB over thousands of 
satellite links supporting tens of thousands of users.  They have
created a very large commercial market of internationally
interoperable products with much better layering and function
support than the basic CCSDS VCDU.

   So it seems that a major question is whether the current VC
structure is the best structure to use for the future or is it
time to upgrade to more current solutions at that level?

   As far as future IP missions interoperating with future missions
that see no need for IP, that's fine but then they don't have any
plans to communicate with future IP missions anyway.  Ground stations
can still support both IP and non-IP formats as many do already.
The facilities, antennas, transmitters, and receivers still need
to do their jobs just the same.  The real question is whether the
bits coming off the space link go into a CCSDS specific box that
processes VCs or if the bits go into a commercial router.  This
is not a major change to the infrastructure.  Yes, it is a change,
but the communication world has changed drastically over the last
20 years and we need to decide if it is time for the civil space
community to catch up or if it wants to keep doing its own thing.

Keith


Adrian J. Hooke wrote:
> Maybe this is a good time to take stock of where we are. I think that it 
> is fair to say that there is broad international agreement that:
> 
> 1. We can see future requirements for the emergence of a more networked 
> approach to space communications.
> 2. Accordingly, we need to develop a migration strategy that leads us 
> towards more capable networking protocols.
> 3. IP has a role in that migration strategy.
> 
> Beyond those elements of consensus, it's not clear that there is much 
> agreement on how or when to initiate change.
> 
> At 06:09 AM 2/8/2007, Keith Hogie wrote:
>>   Moving to spacecraft using Internet protocols a change to the whole 
>> space communication concept.  
> 

snip

>> If we start launching some of our future systems with no routed IP, is 
>> there a clean path for them to "migrate" and be full participants in 
>> the future network. 
> 
> Turn that around. If we start launching *some* of our future systems 
> exclusively with routed IP, is there a clean path for them to be full 
> participants in the future international community of missions that see 
> no need for it?
> 
> Nobody's arguing that there won't be an increasing need for portions of 
> the international space mission support infrastructure to adopt more 
> powerful routing technologies. When you need IP and IP works, you should 
> use IP. But does that mean that *everything* has to become IP-based, all 
> at once? And yes, there's a migration path: it's called international 
> space standardization in general and in particular it's called a Virtual 
> Channel. It means that you can run part of your system using existing 
> infrastructure, in parallel with part of your system using IP-based 
> approaches. Change the mix of traffic on the VCs and you can migrate 
> with hardly any impact.
> 

----------------------------------------------------------------------
   Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
   Computer Sciences Corp.       office: 301-794-2999  fax: 301-794-9480
   7700 Hubble Dr.
   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
----------------------------------------------------------------------