[Sis-csi] CCSDS Cislunar Telecon tomorrow, 7 Sept

Thu Sep 7 10:37:31 EDT 2006

On the topic of all traffic passing the MOC (MCC or whatever)...  After the ISS experience, there is a stronger desire in the manned operations community to allow multiple facilities to connect through the ground station to the spacecraft.  There were major constraints on operations capabilities (especially during Hurricane Rita) that would have been alleviated if WSGT could have been reconfigured easily to connect to a US-based backup MCC.  I know that there are traditional ways to do that (AOS VCs) without placing a router/IP gateway at the ground station.  But there is a perception in some corridors that going IP based from the ground station out gives a needed capability to deal with contingencies, and allows low-cost reconfigurations when ops concepts change.  Of course, everyone knows this would more security measures at the ground terminal, including the ones that Greg points out below.  

I'm not advocating one approach or the other myself, just trying to shed light on one source of the interest in the customer base.  I understand the Constellation C3I team is working through this trade right now.  It will be interesting to see which way they swing.  

In any case, I think we should assume that different missions will have different policies and implementations.  The Cislunar architecture should accommodate either philosophy (terminate at the ground station or MOC).  The question is what architecture approaches accommodate both, and simultaneously support interoperability between programs/agencies.  Can one architecture fit all?  

   -=- Mike

Mike Kearney

NASA MSFC EO-01

256-544-2029

-----Original Message-----
From: sis-csi-bounces at mailman.ccsds.org [mailto:sis-csi-bounces at mailman.ccsds.org] On Behalf Of gregory.menke at gsfc.nasa.gov
Sent: Thursday, September 07, 2006 8:47 AM
To: Marc Blanchet
Cc: Scott, Keith L.; sis-csi at mailman.ccsds.org
Subject: Re: [Sis-csi] CCSDS Cislunar Telecon tomorrow, 7 Sept

Tried to make this telecon but got stuck in traffic.. sorry.

It may be impossible to implement some things like multicast or neighbor
discovery in some cases- and in fact such features may be specifically
disabled when running IP over space links.  This isn't just to be
perverse but because of the operational controls imposed on the links.

I agree that for general purpose IP over CCSDS support for such features
may be desirable, but I don't think IP over CCSDS should be predicated
upon their support, nor should there be an assumption that all aspects
of IPv4 or v6 datalink mappings will always be present.

Wrt MTU, the end-to-end effective MTU may be considerably less than 1280
bytes, in fact imposed by systems engineering policy.  The rationale for
engineering policy would include onboard network scheduling factors in
addition to link utilization and buffering capabilities.  The upshot is
the link layer may be capable of the minimum 1280 or something more but
systems policy forbids the use of packets larger than something less
than 1280 bytes so end-to-end segmentation for TCP traffic will have to
be specifically configured instead of discovered.  Another operative
requirement is likely to be that no packets fragment.

C3I wants to transport IP over CCSDS by putting IP into HDLC and then
using the AOS bitstream service- this handles the MTU issue at least but
I think they may be forced into virtual channels at some point because
they also want to support traditional commanding; CCSDS pkts in AOS.
Assuming this is so, I think moving IP right into the AOS frame in the
specified VC is a natural next step.

The following is somewhat off topic as it involves IP over CCSDS as
related to the MOC but it does illustrate what is likely to show up in
end-to-end IP missions.

There will probably be requirements that <all> space link traffic
traverses the MOC.  THis provides access control at the mission ops
center and allows all traffic to be monitored & recorded- it also gives
the MOC full control over the space link utilization, which is
fundamentally necessary.  This architecture allows the mission to choose
(and it is their choice) how IP is handled over the link; either return
link traffic goes IP at the ground station & is tunneled back to the MOC
or SLE brings the AOS frames back to the MOC where they are routed.

Any outgoing IP traffic is probably going to be routed from the MOC, not
at the ground station.  Likewise, traffic bound for the forward link is
likely going through the MOC and very likely through at least a protocol
gateway; ie no TCP connections from a PI's workstation to the
spacecraft.  Specially configured PEP's might be the way to handle it,
even something like SOCKS is a start.  Such external routing thru the
MOC is probably going to carry with it some IPSec policy not to mention
firewall controls.

Greg

Marc Blanchet writes:
 > Scott,
 >   I'm not sure I will be able to attend, since the time change is  
 > conflicting with another meeting. I'll try hard to move things around  
 > tomorrow morning.
 > 
 > As some of you know, I'm more an IP protocol engineer than a CCSDS  
 > expert. So please excuse me if I'm off. About the IP over CCSDS draft:
 > 
 > IPv6 over some data link have some requirements: the link-layer  
 > should support multicast for neighbor discovery (if no support for  
 > multicast/broadcast at the link layer, a specification must be  
 > defined on how to handle neighbor discovery functionality on that  
 > layer), the link-layer should support 1280 MTU (if link-layer does  
 > not support 1280 MTU, then some encapsulation between the link-layer  
 > and IPv6 should be used and defined) and the some text should be  
 > provided on the link-layer addressing when using autoconfiguration.  
 > None of these topics are addressed in this document, maybe a bit of  
 > the MTU is discussed, but not clear for me. So I'm not sure if these  
 > considerations are addressed elsewhere or not yet addressed, or ....
 > 
 > Marc.
 > 
 > Le 06-09-06 à 14:10, Scott, Keith L. a écrit :
 > 
 > > Let's tag up briefly tomorrow to talk about the IP-over-CCSDS draft:
 > >
 > > 9am Eastern (I got bumped out of the 10am slot, will try to get  
 > > that back...)
 > > 703.983.1550
 > > meeting ID: 55555
 > >
 > >         --keith
 > >
 > > _______________________________________________
 > > Sis-CSI mailing list
 > > Sis-CSI at mailman.ccsds.org
 > > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
 > 
 > 
 > 
 > =========
 > IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
 > 
 > 
 > 
 > 
 > _______________________________________________
 > Sis-CSI mailing list
 > Sis-CSI at mailman.ccsds.org
 > http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
 > 

_______________________________________________
Sis-CSI mailing list
Sis-CSI at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi