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

Thu Sep 7 10:17:37 EDT 2006

Le 06-09-07 à 09:46, gregory.menke at gsfc.nasa.gov a écrit :

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

for me, got conflict with another meeting...

>
>
> 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.

Well, I'm aware of some of these issues with space links. The  
question is that IPv6, as specified, requires those functionalities  
to run properly. In essence, if one implements IPv6 and then use the  
"over CCSDS" spec for the data link, then it will not work, since  
some pieces will be missing. So there should be some text about how  
an IPv6 stack should behave given the missing pieces. This is my point.

Marc.

>
> 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
>>

=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca