<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:#1F497D;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:22485272;
mso-list-template-ids:-827964428;}
@list l0:level1
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:31418771;
mso-list-type:hybrid;
mso-list-template-ids:1155583688 1539335638 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:55.2pt;
text-indent:-19.2pt;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:1.25in;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:1.75in;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.25in;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:2.75in;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:3.25in;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:3.75in;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:4.25in;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
margin-left:4.75in;
text-indent:-9.0pt;}
@list l2
{mso-list-id:627929658;
mso-list-template-ids:-436289182;}
@list l2:level1
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:862783250;
mso-list-template-ids:-769226372;}
@list l3:level1
{mso-level-start-at:2;
mso-level-number-format:alpha-upper;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4
{mso-list-id:1492790718;
mso-list-template-ids:926855578;}
@list l4:level1
{mso-level-start-at:2;
mso-level-number-format:alpha-upper;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level2
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level3
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level4
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level5
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level6
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level7
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level8
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level9
{mso-level-number-format:alpha-upper;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:1786384680;
mso-list-type:hybrid;
mso-list-template-ids:-1458941476 -966498902 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l5:level1
{mso-level-start-at:2;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:73.2pt;
text-indent:-.25in;
font-family:Symbol;
mso-fareast-font-family:Calibri;
mso-bidi-font-family:Calibri;}
@list l5:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:109.2pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:145.2pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:181.2pt;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:217.2pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:253.2pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l5:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:289.2pt;
text-indent:-.25in;
font-family:Symbol;}
@list l5:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:325.2pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l5:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:361.2pt;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#212121">All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">The SLS review of the proposed SLE Blue Book updates resulted in several PIDs that focused on the presence of FSRs in Operational Control Fields (OCFs). The CSTSWG will be taking up these PIDs next week.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">In order for the WG to have the best understanding of the concerns, I sent an email to several of you on 13 October containing several questions about the intended use of FSRs in the context of the SLE services.
I received comments from Greg Kazz (GK) on 14 October and from Craig Biggerstaff (CTB) on 18 October. I had a follow-up conversation with Craig on Tuesday (19 October).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">Following is the compilation of the original message, Greg’s comments (</span><span style="color:red">2021-10-14 GK</span><span style="color:#212121">), Craig’s comments (</span><span style="color:red">2021-10-18
CTB</span><span style="color:#212121">), and a summary of my conversation with Craig (</span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">2021-10-19 CTB & JP</span><span style="color:#212121">).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">-------------------------------------<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121">The FSR-related PIDs involve both the SLE Return OCF (ROCF) and SLE Forward-CLTU (FCLTU) services.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#212121"> <o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="A">
<li class="MsoNormal" style="color:#212121;mso-list:l0 level1 lfo3">With respect to the ROCF service, PIDs ROCF-02 (GK-13) through ROCF-05 (GK-16) all deal with various instances where the document identifies CLCWs but not FSPs as the “payload” of the OCF.
<o:p></o:p></li></ol>
<p class="MsoListParagraph" style="margin-left:55.2pt;text-indent:-19.2pt;mso-list:l1 level1 lfo5">
<![if !supportLists]><span style="color:red"><span style="mso-list:Ignore">1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#212121">The RIDs are all along the lines of “the use of FSRs needs to be addressed”, but no specific changes are identified. What different processing or filtering of the OCFs when they contain FSRs needs
to be performed? If it is simply a matter of sending every FSP to the user of the ROCF service instance, that is essentially present in the current ROCF specification. If some sort of FSR-specific filtering/selection is required or desired, the CSTSWG needs
to know what those filtering criteria are. For example, when the OCF payload is a CLCW, the ROCF service instance can be configured to deliver the OCF/CLCWs for either a single TC VCID or for all TC VCIDs.
</span><span style="color:#1F497D"><br>
<br>
</span><span style="color:red">2021-10-14 GK: FSRs are generated on a VCID basis. Some VCs will have them and some possibly won’t. So it makes sense to be able to filter on VCID i.e., one or more VCIDs which make up an SLS Security Association.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:55.2pt"><span style="color:red">2021-10-18 CTB: Not having ever actually used the ROCF service, it seems logical to deliver all OCFs arriving on the requested VCID(s). The recipient always has the option of discarding
extraneous data. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:73.2pt;text-indent:-.25in;mso-list:l5 level1 lfo7">
<![if !supportLists]><span style="font-family:Symbol;color:red"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:red">It would be possible to modify the ROCF API to specify requested OCF type(s) – CLCW/FSR/both. I don’t know the potential benefit of making that change, much less the impact of perturbing what exists now.
It’s as likely that CLCW subscribers would like the ability to filter out the ‘noise’ of FSRs, as the reverse.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:73.2pt;text-indent:-.25in;mso-list:l5 level1 lfo7">
<![if !supportLists]><span style="font-family:Symbol;color:red"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:red">The only use case for filtering FSRs by VCID would be the scenario where multiple sources (e.g. MOC vs. POC) multiplex frames into the same master channel for uplink.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:73.2pt"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:55.2pt"><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">2021-10-19 CTB & JP: Some
</span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">additional information about the ROCF service is helpful here. As described in the following bullet (2), the original motivation for the ROCF service
was to provide a means for returning the CLCWs to the MOC so that COP could be closed. Related to the COP, the CLCW contains the VCID of the forward link VC through which the COP is operating. The COP model that the ROCF service is based on assumes that the
space vehicle is designed to receive AD frames on one or more forward link VCs, and send the corresponding CLCWs on a specific return link VC or MC. Depending on the number of return link VCs and their relative frequency of transmission, the CLCWs may be able
to be sent on a single VC or may have to be sent on all frames of an MC. Also, the CLCWs for multiple forward link VCs, may be returned on the same VC or MC or different VCs or MCs, depending on the design of the spacecraft data system.
<br>
<br>
To accommodate these various possibilities, when a given ROCF service instance is configured, the configuration information for that service instance includes (1) whether the service instance is *<b>permitted</b>* to return Type 0 (CLCWs), Type 1 (“other”,
which includes FSRs) OCFs, or both types (2) the set of return link VCs or MCs from which OCFs are *<b>permitted</b>* to be extracted, and (3) the set of forward link VCIDs (as presented in the CLCW) for which the service instance is *<b>permitted</b>* to
return the CLCWs (applies only when CLCWs are being returned). Then, when each ROCF service instance is STARTed, the START invocation identifies (a) which of the permitted OCF types is to be returned, (b) which of the permitted return link VCs or MCs to extract
the OCFs from, and (c) for CLCWs only, which of the permitted forward link VCID the OCFs are to be returned (this can be set to ‘null’, which returns the CLCWs regardless of the VCID the appears in the CLCW).
<br>
<br>
In using the ROCF service to return FSRs, each ROCF service instance can be configured to extract OCFs from one or more VCs or MCs. However, there is no static information identifying the forward link source of the secured data in the FSR that is comparable
to the VCID field of the CLCW. I had considered that </span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">the
</span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">Security Parameter Index</span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"> (SPI) field
of the FSR could be used to identify the Security Association (SA), but Craig explained to me that the SA (and therefore the SPI) will very possibly (and maybe likely) change during the course of the contact.
<br>
<br>
Craig and I concurred that if the ROCF service is used to transfer the FSRs, it should be sufficient for the FSR user of the ROCF service to get all FSRs that are returned on a given return link VC or MC. This is exactly what the ROCF service already supports,
under the “other” option for OCF selection. There is no need to change the technical aspects of the ROCF service. However, we agreed that it would be appropriate to add *<b>informational</b>* content (e.g., NOTEs) that address the use of the ROCF service to
transfer FSRs.<br>
</span><span style="color:#212121"><br>
<br>
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:55.2pt;text-indent:-19.2pt;mso-list:l1 level1 lfo5">
<![if !supportLists]><span style="color:red"><span style="mso-list:Ignore">2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:#212121">The original motivation for the ROCF service was to provide a means for returning the CLCWs to the MOC so that COP could be closed in situations where there was terrestrial bandwidth for returning
the downlink frames to the MOC was significantly less than the space-to-ground link BW, or even when the transfer frames were being recorded for subsequent off-line delivery. Does such a use case exist for FSRs? That is to say, will there be anticipated cases
where *<b>only</b>* the FSRs will be delivered, and not the whole frames? Alternatively, might there be a use case where the FSRs need to be delivered to somewhere other than the recipient of the return link transfer frames (which would be another justification
for the use of the ROCF service to deliver FSRs)? If neither is a use case, then the ROCF may not be a candidate for FSR delivery. Just because the ROCF service *<b>can</b>* deliver anything that is contained in an OCF does not necessarily mean that any particular
use of the OCF is a reasonable use of the ROCF service. </span><span style="color:#1F497D"><br>
<br>
</span><span style="color:red">2021-10-14 GK: NASA/JPL for example does not use the ROCF service because we don’t have that severe of a ground station to MOC BW issue – not sure of other agency or NASA center limitations.<br>
<br>
<o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:55.2pt"><span style="color:red">2021-10-18 CTB: The purpose of the FSR is to report errors encountered by the receiving end of an uplink. The intended recipient of downlink FSRs is the same location that originated
those uplink frames. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:73.2pt;text-indent:-.25in;mso-list:l5 level1 lfo7">
<![if !supportLists]><span style="font-family:Symbol;color:red"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:red">The FSR is associated with one and only one uplink channel. It doesn’t make sense to return the FSR using a downlink channel other than the one corresponding to that uplink. E.g. a downlink-only payload
channel would have no need of FSRs.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:73.2pt;text-indent:-.25in;mso-list:l5 level1 lfo7">
<![if !supportLists]><span style="font-family:Symbol;color:red"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">
</span></span></span><![endif]><span style="color:red">But in the above scenario where multiple sources multiplex frames into the same master channel for uplink, a VC Frame service user could want to receive the FSRs corresponding to its uplink VCIDs. (Would
this also hold true for a CSTS Forward Channel Frame service? I’m guessing it would.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:red"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:55.2pt"><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">2021-10-19 CTB & JP: The intent of the question that I posed in the original email was to ascertain whether
it makes sense operationally for a mission ground entity (e.g., a MOC or payload control center) to receive “stand-alone” FSRs – that is, would there be use cases in which a facility would *<b>not</b>* be receiving the full frames that carry the OCF/FSRs.
Based on my conversation with Craig, I think that there potentially is such a use case: e.g., consider a scenario in which the spacecraft is configured to return FSRs corresponding to all of the forward link VCs in every frame of the return link MC. Depending
on the onboard application, there may not be any data generated by the application if the SA fails, and the ground application that receives the VCs carrying that application data won’t get any VC frames for that VC, and so no OCF/FSRs would be inserted in
that return link VC. However, because the FSRs are carried by every VC in that MC, the FSR information fror that forward link SA would be carried in the frame of any return VC of that MC, and so the ROCF service can be used to obtain the status of the SA.<br>
<br>
However, as described in 1A above, it is not possible to identify the forward link VC that is carrying the SA from the information available in the FSR. The only way to make such an identification for purposes of filtering the OCFs transferred by an ROCF service
instance is if the spacecraft uses a different return link VC or MC for each forward link VC, such that the OCF/FSRs of a given return VC or MC contain only the FSRs of its peer forward link VC. In such a case, the ROCF service instance can be configured to
transfer the OCF/FSRs that appear on that specific VC or MC. As described above, this is already within the capability of the ROCF service, and no technical changes need to be made to the ROCF service.
<br>
<br>
</span><span style="color:red"><o:p></o:p></span></p>
<p class="MsoListParagraph" style="margin-left:.75in"><span style="color:#212121"><o:p> </o:p></span></p>
<ol style="margin-top:0in" start="2" type="A">
<li class="MsoNormal" style="color:red;mso-list:l3 level1 lfo10"><span style="color:#212121">With respect to the FCLTU service, PIDs IAS-01 through IAS-03 imply that the FCLTU service should use information in the FSRs to regulate transmission on the forward
link in the same way that the FCLTU service currently regulates transmission on the basis of the the NoRFAvail and NoBitLock flags in the CLCW (whether the FCLTU service does or doesn’t such regulation, and whether such regulation is based on either or both
of these flags, is a configured parameter). These CLCW flags report the status of the whole physical link, so it is reasonable to deduce that if either flag indicates a “no flow” condition nothing is getting through the link. However, it is my understanding
(and please correct me if I am wrong) that the security associations are (or may be) established on a per VC basis, and indeed a physical channel may carry a mix of SDLP-protected and non-SDLP-protected VCs. In such situations, it seems possible that a security
associated for one or a subset of VCs may be in an errored state, but other VCs may be operating without problem. In such a case, it would seem unwise to have FCLTU shut down the whole forward link (Note that the FCLTU service “sees” only encoded CLTUs – it
has no knowledge of the VCs of the frames encoded in those CLTUs). </span><span style="color:#1F497D"><br>
<br>
</span>2021-10-14 GK: I share your concern here, John.<br>
<br>
<o:p></o:p></li></ol>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:red">2021-10-18 CTB: I agree. The FSR is forensic data to aid in troubleshooting link security failures; it does not prescribe any specific action in response.
<br>
<br>
</span><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%">2021-10-19 CTB & JP: Craig and I concurred that the FSRs should not be used by the production functions underlying the F-CLTU service to automatically
inhibit transmission on the forward link, especially since it would close off all VCs on the link, not just the one that has a problematic SA. A mission *<b>may</b>* choose to stop transmitting using a given VC by using the status information in the FSRs
that are present in the return link transfer frames or the OCFs obtained through an instance of the ROCF service. There is no need to make any changes to the F-CLTU service.
<b> </b></span><span style="color:red"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#548235;mso-style-textfill-fill-color:#548235;mso-style-textfill-fill-alpha:100.0%"> </span><span style="color:#1F497D"><o:p></o:p></span></p>
</div>
</body>
</html>