[Sis-csi] CCSDS Cislunar Telecon tomorrow, 7 Sept
Keith Hogie
Keith.Hogie at gsfc.nasa.gov
Thu Sep 7 12:39:24 EDT 2006
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.
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.
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
----------------------------------------------------------------------
More information about the Sis-CSI
mailing list