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

Marc Blanchet marc.blanchet at viagenie.ca
Thu Sep 7 12:50:16 EDT 2006


Le 06-09-07 à 12:39, Keith Hogie a écrit :

> Marc,
>
>   You raise some good points about IPv6 over serial links.  I think  
> one
> of the most relevant RFCs is RFC 2590 "Transmission of IPv6 Packets  
> over Frame Relay Networks".  For IPv4 in space we use RFC 2427 (STD  
> 55)
> "Multiprotocol Interconnect over Frame Relay".  I haven't read all of
> RFC 2590 but it looks like it addresses lots of the MTU and address
> discovery issues for IPv6 over serial links.

as I wrote, for most if not all link-layers, there is an RFC  
describing the interaction and the specifics of IPv6 over that link- 
layer.

a good starter is also the RFC on IPv6 over NBMA networks (RFC2491).

>
>   We may just want to mention these RFCs to point people at the  
> details
> of using IP over FR/HDLC over CCSDS links.  Running straight IPv6 over
> CCSDS would require adjustments similar to RFC 2590 to be mapped into
> CCSDS virtual circuits.

we are in strong agreement!

Currently, I see the following possibilities (from my point of view):
a) keep IP over CCSDS doc as is. not sure that is very good.
b) add text to point to other documents (ex: ipv6 over frame relay).  
not sure this is complete.
c) reference a future document to be written which describes the IPv6  
over CCSDS specifics. the current IP over CCSDS document would only  
cover the link layer basic stuff (for example, how to identify an  
IPv6 packet in the encap frame) and clearly state that there is  
another document describing the behavior of IPv6  over CCSDS links.
d) add text in the IP over CCSDS doc to cover all the topics for IPv6  
over CCSDS.

I see c) as the best path, but I'm new here in CCSDS...

Marc.

>
> Keith Hogie
>
>
> Marc Blanchet wrote:
>> 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
>> _______________________________________________
>> Sis-CSI mailing list
>> Sis-CSI at mailman.ccsds.org
>> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-csi
>
>
> -- 
> ----------------------------------------------------------------------
>   Keith Hogie                   e-mail: Keith.Hogie at gsfc.nasa.gov
>   Computer Sciences Corp.       office: 301-794-2999  fax:  
> 301-794-9480
>   7700 Hubble Dr.
>   Lanham-Seabrook, MD 20706  USA        301-286-3203 @ NASA/Goddard
> ----------------------------------------------------------------------



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






More information about the Sis-CSI mailing list