[Sis-csi] RE: networking details

Thu Feb 8 15:51:16 EST 2007

But what I said was: "IPv4 and SCPS-NP packets can both be carried
natively in CCSDS data link layers."  And if you want lower overhead,
SCPS-NP has lower overhead than IP, certainly lower than IPv6,
especially if you touch IPSec tunnel mode.

Frequency, bandwidth, modulation, coding -- I'm not sure what impact
choices in any of these areas have on whether or not one can carry IP
traffic (until you get into issues of PLR).  There's a whole separate
CCSDS area that deals with space links services (SLS); if you've got
suggestions about better modulation, coding, etc., I'm sure they'd be
interested:

	Area Director: Mr. Jean-Luc Gerner
	ESA/European Space Technology Centre
	Postbus 299
	2200 A.G. Noordwijk
	The Netherlands  

	Telephone: +31 71 565 4473
	FAX: +31 71 565 4596 
	E-mail: Jean-Luc.Gerner at esa.int  

I specifically restricted cislunar's scope to 'above data link' to
avoid overlap with SLS.

What do you mean by: "we are very constrained on uplinks if we follow
standard CCSDS?"  What is it that we can't do?

I'm all for more symmetric links, but I would think that AOS would be
able to handle those.  Was the lack of a 'symmetric' data link layer
what you meant by restricted?

        --keith

________________________________

	From: Assi Friedman [mailto:afriedman at innoflight.com] 
	Sent: Thursday, February 08, 2007 3:38 PM
	To: Scott, Keith L.; 'Adrian J. Hooke'; 'CCSDS Cislunar Space
Internetworking WG'
	Subject: RE: [Sis-csi] RE: networking details

	You are correct, SCPS-NP had the foresight to recognize that IP
may play a role in future space communications! In that respect, I
think that non SCPS-NP IP should be considered as well, as overhead
costs performance, and throughout almost always becomes constrained. 

	My original comments targeted more of the physical layer
aspects of: frequency, bandwidth, modulation, encoding, FEC and such.
As is, we are very constrained on uplinks if we follow standard CCSDS.
Lower asymmetry ratio and different modulation schemes need to be
considered to come up to par with available RF technology.

	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: Scott, Keith L. [mailto:kscott at mitre.org] 
	Sent: Thursday, February 08, 2007 12:25 PM
	To: afriedman at innoflight.com; Adrian J. Hooke; CCSDS Cislunar
Space Internetworking WG
	Subject: RE: [Sis-csi] RE: networking details

	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/ba0fbd64/attachment-0001.htm