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

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Thu Sep 7 09:46:37 EDT 2006


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
 > 




More information about the Sis-CSI mailing list