[Sis-csi] RE: networking details

Thu Feb 8 15:24:37 EST 2007

CCSDS had this bit of foresight several years ago.  IPv4 and SCPS-NP
packets can both be carried natively in CCSDS data link layers, and
IPv6 packets only require a shim to support IPv6 Jumbograms.  This all
works now.

        --keith

________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Assi Friedman
	Sent: Thursday, February 08, 2007 3:04 PM
	To: 'Adrian J. Hooke'; 'CCSDS Cislunar Space Internetworking
WG'
	Subject: RE: [Sis-csi] RE: networking details

	I would like to point out that a lot of discussion needs to go
into the physical/link layers of this migration. CCSDS as-is is has its
history significantly influenced from the STDN era. This history does
not make it very conducive to IP in space. Migrating to IP will require
us to address the physical/link layers. As is, CCSDS had the foresight
to acknowledge that there will be a future need to readdress this, but
the future is now present. I try to start at the side closest to the
hardware, since protocol stacks can be reloaded, hardware boxes are
much harder to reload.

	Assi

	**************************** 
	 Assi Friedman - Innoflight Inc. 
	 5850 Oberlin Dr. Suite 340 
	 San Diego, CA 92121 
	 Tel: (858) 638-1580 X13 
	 Fax: (858) 638-1581 
	 Email: afriedman at innoflight.com 
	**************************** 

________________________________

	From: sis-csi-bounces at mailman.ccsds.org
[mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of Adrian J. Hooke
	Sent: Thursday, February 08, 2007 11:34 AM
	To: CCSDS Cislunar Space Internetworking WG
	Subject: Re: [Sis-csi] RE: networking details

	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.  

	No, it's not a change to the space communication *concept*;
it's a change to the space communication *infrastructure*. If we go
there in one big bang, it will certainly change a lot of
infrastructure. But is it change for the sake of change, or change
because we simply can't operate another day in space without an all-IP
system?

	Now we are changing the space end so that selected Internet
technologies and be used end-to-end.

	Why? There are plenty of cases where selected use of Internet
technologies is beneficial *without* using them end-to-end.

	If we accept that we want and need a routed infrastructure in
space in the future, why wouldn't we want to start putting it in place
with missions currently being built. 

	Well, cost ands risk *might* be among the reasons. Why do the
NASA Exploration vehicles currently being built look so much like
Apollo?

	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.

	Isn't it more beneficial to take this opportunity to deploy a
whole fleet of new systems and start the first systems with the
technologies we want to end up with.

	This far out, how do you know where you will end up? Isn't it
more beneficial to take the opportunity to deploy new systems that are
based on the technologies that we use now, which already have the
built-in capability to evolve towards IP or any other future routed
approach? 

	Starting new missions with IP technologies also means that they
can start benefiting from the greatly increased options for early
testing between various subsystems. Systems don't need to wait until
final integration and test to start doing interoperability tests.  With
IP interfaces built in, systems can start running basic interface and
functionality tests while they are still at their manufacturing
locations.  This can be done years earlier than normal I&T and find
	basic problems much earlier when they are easier and cheaper to
fix. 

	This claim is so sweeping that it deserves its own discussion
thread. Suffice to say that there are many people on this list who
strongly doubt that the impacts on the real world of space mission I&T
are anywhere near that rosy.

	I agree that we don't need to pin down all the details now, but
we do need to have some sort of plan on how things will roll out.  

	We all agree with that.

	We may not need all the network routing capabilities for 10
years but there seem to be lots of benefits from starting to make use
of end-to-end Internet technologies now.

	Of course: that's why we formed this Cislunar Space
Internetworking working group. But as an international standardization
working group, it should develop a pragmatic and consensus strategy for
how it proposes to move the international space community forward. We
need a clear picture - agreed by all partners - that shows why we need
to change, when we need to change and how we need to change.

	///adrian

	Adrian J. Hooke
	Chairman, CCSDS Engineering Steering Group (CESG)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20070208/5b5d3448/attachment-0001.html