[Css-csts] [Smwg] Proposed topic for joint meeting: USLP + CSS Area

[John Pietras]

Erik,
To address two of your questions:

1.       The most-recently-posted version of the FR Reference Model Tech Note (0.14, dated July 2018, at URL
https://cwe.ccsds.org/css/docs/CSS%20Area/CWE%20Private/Functional%20Resources%20and%20Service%20Components/FunctionalResourcesRefModel_TechNote-TN-0.14-180730.docx)
has placeholder sections for USLP in the forward direction (section 3.4.3) and return direction (section 3.4.5).  However, these are truly merely placeholders at this point, and another possibility might be to combine the forward asynchronous form of USLP functionality into the existing Forward Telecommand SLP Transmission FRs (section 3.4.1 of the FR Reference Model), the forward synchronous form of USDP functionality into the existing Forward AOS SLP Transmission FRs* (section 3.4.2 of the FR Ref Model), and the return USLP functionality into the existing Return TM/AOS SLP Reception FRs (section 3.4.4 of the FR Ref Model). Indeed, the Return TM/AOS SLP Reception FRs already form a precedent for such combining of functionality in that they represent both the TM and AOS variants of the return space data link protocols.
[*Keep in mind that the Forward AOS Space Data Link Protocol functionality is already standardized. It is the Forward AOS Sync and Channel Coding functions that are still being defined.]

2.       The Forward Frame CSTS is already set up to accommodate USLP. We deliberately made FF-CSTS as "agnostic" as possible with respect to the underlying space data link protocols, sync and channel coding schemes, and physical channel (i.e., media - RF or optical), and in particular I endeavored to make sure that there was nothing about USLP that would make it incompatible with the Forward Frame service.

As of now, nothing has been done to assign the managed parameters, pending the decision as to whether to address the USLP functionality through dedicated FRs or through combining them with existing FRs. Going forward, I can start to investigate this and make a recommendation (although I will not have a it completed by the Fall Workshop).

Let me propose to put together a briefing for the Fall Workshop that introduces the Forward Frame service: what it does (with an emphasis on the user perception of the service and only minimal discussion of the internal composition such as how it's built on SFW procedures) and how it interacts with the forward space data link protocol functions and forward sync and channel coding functions. I would be willing to call into a WebEx of the joint meeting with the USLP folks at whatever time you can set it up.

Hopefully, the briefing would also have use beyond that one session, as an introduction for reviewers of the Forward Frame Red Book. The CSTSWG had originally hoped that the Red-1 review would have been completed by the Fall Workshop (optimism springs eternal!) but given that the review period will almost certainly begin no sooner than the Fall Workshop the briefing could be a top-level 'roadmap" as to why a reviewer should care about the service.

And even if a joint session with the USLP folks doesn't pan out, it might still be useful for the CSS Area itself.

If it's agreed that such a presentation would be useful, let me know and I'll get started on it ASAP.

One final observation regard USLP - although the Forward Frame CSTS has been made essentially underlying-protocol-agnostic, I don't think that the same can be said for the SLE Forward Space Packet service, the definition of which is highly intertwined with the Telecommand SDLP. Is it better to (a) "stretch" the FSP service to encompass USLP (and if so, would it only address the asynchronous form, which corresponds to TC, or both asynchronous and synchronous forms?), (b) restructure SLE FSP to make it as agnostic as possible to the particular SDLP so as to support both TC and  USLP,  or (c) spin up a new CSTS FSP that covers TC and forward USLP and leave SLE FSP for legacy  TC-only missions?

Best regards,
John

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Tuesday, September 25, 2018 8:41 PM
To: css-csts at mailman.ccsds.org; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: [Smwg] Proposed topic for joint meeting: USLP + CSS Area

CSTS and CSSM Colleagues,

The USLP (Universal Space Link Protocol) recommendation is currently undergoing CESG polling in consideration for being approved as Blue Book.  I think this merits some discussion at our joint session for the upcoming fall meetings.  In particular, I think it would be good to check re:


1)      USLP vs Functional resource model - do we have new resources to add and/or existing ones to update?

2)     How do FF-CSTS and USLP fit together? (in particular in reference to the diagram below from the USLP draft recommendation)

3)     Inclusion of managed parameters in service management configuration profile and/or service agreement


---USLP sending protocol entity organization (per USLP draft recommendation)---

[cid:image001.png at 01D45575.9B34CB50]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180926/c3205cad/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 63616 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20180926/c3205cad/attachment.png>