[Sls-sea-dls] SDLS EP GVCID Issues

[Gian.Paolo.Calzolari at esa.int]

David,
        I am mot sure I fully capture your issue/doubts.
There are indeed different definitions sometimes coming ether from real 
difference (TM and AOS do not have MAPs) or from some different 
terminology for historical reasons.

The general definition is indeed GVCID = TFVN + SCID + VCID & GMAPID = 
TFVN + SCID + VCID + MAPID with the caveat that the MAP Identifies may not 
exist and that the total length depends on the applied standard.
Implementers need to implement it with some caution.

The mapping between USLP and Proximity is due - as far as I remember - 
that Proximity-1 never really defined a GVCID.

Greg & Matt, copied here, may add more comments.

Note also tat there a pending corrigendum (not yet on web but approved) 
for  CCSDS 320.0-M-7    CCSDS Spacecraft Identification Field Code 
Assignment Control Procedures. Magenta Book. Issue 7. November 2017.

Regards

Gian Paolo



From:   "David Koisser (external)" <David.Koisser at esa.int>
To:     "sls-sea-dls at mailman.ccsds.org"@esa.int
Cc:     "Lucas, John P.\(GSFC-5960\)" <john.p.lucas at nasa.gov>
Date:   15-07-19 10:21
Subject:        [Sls-sea-dls] SDLS EP GVCID Issues
Sent by:        "SLS-SEA-DLS" <sls-sea-dls-bounces at mailman.ccsds.org>



Hello everyone, 

We noticed some more issues regarding the GVCID / MAPID. After checking, 
it turns out different standards have very different interpretations. I 
attached screenshots of the regarding sections of the blue books for your 
convenience. 

The SDLS EP GVCID seems to be an aggregate of the longest defined versions 
of the respective fields. To my knowledge SDLS EP seems to be the only and 
first document, which specifically defines a (merged) GVCID. All other 
standards only define them as GVCID = TFVN + SCID + VCID & GMAPID = TFVN + 
SCID + VCID + MAPID (without sizes). In USLP the relation between old and 
new frames is defined, but only for Proximity-1 (see C1.1). I am not sure 
if this is more clearly explained somewhere else. 

In SDLS EP I see two problems. First, there is no explanation or 
justification for the lengths. Second, this may possibly lead to severe 
bugs, e.g. overflowing a TM VCID bigger than what fits in the defined 3 
bits, like 16 bits in USLP or worse, 6 bits in TC (with identical TFVN as 
TM). Improper sanity checks here may even lead to security critical bugs. 

Cheers, 
David 

This message is intended only for the recipient(s) named above. It may 
contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or 
dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies 
appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA 
Data Protection Officer (dpo at esa.int).
[attachment "USLP.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] 
[attachment "TM.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment 
"TC.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment 
"Segment.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "SDLS 
EP.PNG" deleted by Gian Paolo Calzolari/esoc/ESA] 
_______________________________________________
SLS-SEA-DLS mailing list
SLS-SEA-DLS at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-sea-dls



This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-sea-dls/attachments/20190715/788d482a/attachment.html>