[Sls-slp] Security, NGU and New TC services and there effect on COP-1

[Cosby Matthew]

Ed,

Just to confirm our conclusion:

We agreed that if you put the security layer before the COP it would not
technically cause problems with the operation of the COP/FARM as it is
defined. And the reason for putting the layer before the COP is if you
already have existing hardware TC processors which we do in Europe.
However, you would need to complete the security checks and then
re-package the frame to be processed by the ASICs. This means that you
are going up and down the stack on board the spacecraft. So this method
isn't pretty and CCSDS shouldn't standardise this way of operations as
it is only relevant for a specific implementation.  

Where we disagree is that the COP isn't "broken" if you put the security
afterwards and the security layer fails its checks. This comes back to
where the COP/FARM has finished its job (to guarantee delivery of
complete in sequence, error free commands). Our disagreement was that I
believe that the COP has finished when it hands the command to the next
process (whatever that is) - in this example it is the security layer.
You believe that the COP has not completing its job correctly if the
next process or processes throws the command away for another failure -
in this case if the security has failed.

I am happy to discuss this at the meeting in ESTEC as this covers one of
my actions. 

Cheers,

Matt.



-----Original Message-----
From: sls-slp-bounces at mailman.ccsds.org
[mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of Greenberg,
Edward (313B)
Sent: 13 October 2009 17:36
To: SLS-SLP WG
Cc: Shames, Peter M (3130); Howie Weiss
Subject: [Sls-slp] Security, NGU and New TC services and there effect on
COP-1

Last week Majorie De Lande Long posed the question as to how the new
security header and its placement in the TC frame would effect COP-1.
A few weeks ago Greg and I had a long discussion with Matt Cosby on this
very topic.  We concluded that if the security was processed prior to
the
COP there is no issue.  The only problem is that the FEC decoding should
be
performed before the security process.

This leads us to another item that can be put on the table.  The CCSDS
is in
the final phases of approving the LDPC codes and the new generation
uplink
team is investigating how to improve performance for commanding.  One of
the
things being considered is to use the LDPC code for all uplinks by
placing
it in the physical layer.  I this way the code would be put on
synchronously
to carry the synchronous bits required in the link but independent of
the
frames contain in the link.  Thus taking advantage of the 8 db gain
provided
by the coding without changing the link layer protocol.  One of the
benefits
of this approach is that the TC link layer protocol need not be modified
and
ESA's current flight command decoder implementation need not be changed.
The
only that that would be required on the flight side is an LDPC decoder
with
a security processor that outputs the TC frame as currently defined
(eliminating the inserted security data fields and decrypting the data
frame
data field.  

 


_______________________________________________
Sls-slp mailing list
Sls-slp at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sls-slp

The information contained in this E-Mail and any subsequent 
correspondence is private and is intended solely for the intended 
recipient(s).  The information in this communication may be 
confidential and/or legally privileged.  Nothing in this e-mail is 
intended to conclude a contract on behalf of QinetiQ or make QinetiQ 
subject to any other legally binding commitments, unless the e-mail 
contains an express statement to the contrary or incorporates a formal Purchase Order.

For those other than the recipient any disclosure, copying, 
distribution, or any action taken or omitted to be taken in reliance 
on such information is prohibited and may be unlawful.

Emails and other electronic communication with QinetiQ may be 
monitored and recorded for business purposes including security, audit 
and archival purposes.  Any response to this email indicates consent 
to this.

Telephone calls to QinetiQ may be monitored or recorded for quality 
control, security and other business purposes.

QinetiQ Limited
Registered in England & Wales: Company Number:3796233
Registered office: 85 Buckingham Gate, London SW1E 6PD, United Kingdom
Trading address: Cody Technology Park, Cody Building, Ively Road, Farnborough, Hampshire, GU14 0LX, United Kingdom 
http://www.qinetiq.com/home/notices/legal.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20091014/35237488/attachment.html>