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

Thu Sep 7 12:13:52 EDT 2006

Le 06-09-07 à 11:48, Scott, Keith L. a écrit :

> Marc,
>
> Hmmm....  The CCSDS data links are all point-to-point (even prox-1's
> 'hailing' mode is very point-to-point oriented, and the data transfers
> are certainly so).  If there are only two parties on the link, then we
> may have achieved both multicast and broadcast in so far as IPv6
> requires them for neighbor discovery.  Mapping an IPv6 multicast
> address down onto the data link address is an issue, but if the v6
> multicast maps to the data link address (spacecraft ID, etc.) of the
> other end of the link, that may be OK.
>
> IPv6 must deal with point-to-point links, like serial lines, right?

- ipv6 is defined for point-to-point links, obviously. And yes,  
typical p2p links are fine since multicasting to the other node is  
easy.  But some wording should say so by describing how the ND will  
be implemented in the stack. However, if the CCSDS data links are (to  
my knowledge) mostly unidirectional, then there might be some issues,  
or at least some wording, verification on what happens in this case.   
I think it should be looked at.
- another example: IPv6 within ND (Neighbor discovery) has a  
mechanism called DAD (duplicate address detection). DAD is mandatory  
unless there is a specification that address the issue, for example  
because the specificities of the link layer. That needs to be  
addressed too I think.
- now, addressing still needs to be looked at too.  ...

in IETF perspective, any new link-layer would have a document that  
describes the interaction of IPv6 over that link layer and the  
related specificities. For example, there are documents for IPv6 over  
Ethernet, Ipv6 over PPP, IPv6 over ATM, IPv6 over arcnet (!), IPv6  
over frame-relay, IPv6 over token-ring, IPv6 over 802.16 networks,  
etc...  One way to look at this is an IPv6 over CCSDS document that  
describes the behavior of IPv6 over those link(s).  While I don't  
really care myself about where it is published (I can help for both  
ways: in ietf or within ccsds), the information itself is important  
to be put in a document so the implementor will know what to do and  
that would really help CCSDS related market (agencies, etc...) to  
have conformant and interoperable implementations.

my 2 cents...

Marc.

> I
> think figuring out how it handles those and inserting some explanatory
> text into some document is a good idea.
>
> 		--keith
>
> -----Original Message-----
> From: Marc Blanchet [mailto:marc.blanchet at viagenie.ca]
> Sent: Thursday, September 07, 2006 10:18 AM
> To: gregory.menke at gsfc.nasa.gov
> Cc: Scott, Keith L.; sis-csi at mailman.ccsds.org
> Subject: Re: [Sis-csi] CCSDS Cislunar Telecon tomorrow, 7 Sept
>
> 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
>
>

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