[Sis-csi] IP Header Compression

[Adrian J. Hooke]

>At 12:17 PM 9/7/2005, Krupiarz, Christopher wrote:
>... Could you elaborate a bit on how you would see commanding done in an 
>emergency situation without using an IP packet?  I probably got lost along 
>the way, but I made the assumption that in this architecture all packets 
>that a spacecraft received would be an IP packet.  The hardware decode 
>command (I think equivalent to our critical commands here) would just be a 
>bit string, but it would still be in an IP packet.
===================
At 08:32 AM 9/7/2005, Matthew Cosby wrote:
>In Europe we get around this problem with a Command Pulse Distribution 
>Unit (CPDU) installed in the Packet Telecommand Decoder (PTD -  "hunk of 
>hardware that doesn't rely on the correct operation of the flight 
>computer" ). This hardware commanding utilises the Multiplexed Access 
>Point (MAP) identifiers in the segmentation layer of the Telecommand Stack.
>
>I have attached a data sheet of PTD for you read - Section 4.5. The upshot 
>of it is you can send a command to the PTD (within the communications 
>system) that can toggle up to 256 lines, for resetting the flight 
>computer, switching antenna, etc without needing to worry about the high 
>level stuff on top.
===================

As Matt notes, there is extensive and well-tested standard infrastructure 
built around the concept of direct Link-layer "hardware" commanding. If you 
read section 4.3 of the PTD data sheet you will also see that command 
authentication is covered and if I remember correctly, bog standard CCSDS 
Link layer data protection has already been quite widely implemented in 
Europe for "asset"-class missions:

   -- Perhaps we can hear more about these capabilities from Matt and Dai?
   -- Howie; what's your take on the strength of the security that is 
provided by the PTD?

I'm not sure that the CSI architecture should assume (as Chris suggests) 
that *all* traffic is IP-based. Given where we are today, wouldn't it be 
reasonable to expect an evolutionary progression, with a mix of some 
services that are built directly on the Link layer and other services that 
are Network based?

Perhaps the CSI group should revisit the AOS architecture that is expressed 
in Figure 2-2 (page 2-5) of 
http://public.ccsds.org/publications/archive/701x0b3.pdf to see what 
possibilities exist? It should be noted that the AOS architecture is now 
~15 years old and that we are still waiting for any significant customers 
of space networking to emerge. Rather than starting over, one would hope 
that the CSI group would build on the internationally-agreed AOS framework 
and at the end of the day the group would be able to recommend a 
comprehensive update to the AOS service model (as defined in section 2 of 
the specification) and to the corresponding protocol specs. In particular, 
someone might want to at least propose a Pink Sheet to change the selection 
of the protocol that is currently recommended to implement the Internet 
service... :-\

///adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-csi/attachments/20050908/e201c353/attachment.html