[CESG] CESG-P-2024-04-001 Approval to publish CCSDS 732.1-B-3, Unified Space Data Link Protocol (Blue Book, Issue 3)

[CCSDS Secretariat]

Dear CESG Members,

Conditions for approval of CCSDS 732.1-B-3, Unified Space Data Link Protocol (Blue Book, Issue 3) have been disposed to the satisfaction of the AD(s) who voted to approve with conditions. The Secretariat will now proceed with CMC polling to authorize publication.
-------------- next part --------------
From:	Tomaso.deCola at dlr.de
Sent:	Thursday, May 16, 2024 3:36 AM
To:	greg.j.kazz at jpl.nasa.gov; thomas.gannett at tgannett.net; matt.cosby at goonhilly.org
Subject:	AW: [EXTERNAL] Condition on USLP poll

Categories:	Poll Condition Closure

Hi Greg, all

Thank you for explaining why interoperability testing was considered redundant here. I’ve checked again 
the two specifications (in force and the new one) with respect to these aspects and I concur with you 
that by testing the MAP packet service you are implicitly testing also the “new” VCP by simply putting 
the MAP ID  equal to 0, so that the GMAP ID is just the GVCID as requested the VCP. Maybe a minor 
difference can be that in the VCP primitives we have the Service Type while in MAP we have QoS. But 
the semantic is exactly the same and I think the reason for keeping different names is just to keep the 
same nomenclature used in TC/TM.

As such from my side, the point can be considered closed.

Regards,

Tomaso

Von: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov>  
Gesendet: Mittwoch, 15. Mai 2024 21:55 
An: Thomas Gannett <thomas.gannett at tgannett.net>; de Cola, Tomaso <Tomaso.deCola at dlr.de>; 
Matthew Cosby <matt.cosby at goonhilly.org> 
Betreff: Re: [EXTERNAL] Condition on USLP poll

Hi All,

The reason the SLP WG concluded that since USLP already contained MAPs (MAP Packet Service), 
which is an additional subdivision of a  VCID (VCP Service), by testing MAP Packet Service in 
interoperability testing, the implementations  also proved packet service. The reason is testing also 
included the minimal MAP case i.e, a MAP equal to zero, which really defaulted to VCP service.
The SLP WG was concerned that without explicitly putting VCP service (and VCA service) into the 
specification, a user might think that VCP wasn’t doable, even though one could make it happen by 
minimalization. The other concern was to make USLP look as close to the existing TC, TM, AOS, 
services as possible.

Craig Biggerstaff in the SDLP WG also had this observation about USLP recent addition of VCA and 
VCA services:
The primary use case I can imagine for VCP and VCA would be to support 
relay (pass-through) links.  Here, using VCP and/or VCA would require
the definition of some value to populate the MAP ID field present in the 
Transfer Frame Primary Header, therefore a practical implementation 
would be almost indistinguishable from existing MAP services.

So in conclusion, SLP WG is saying we have tested the VCP case, by testing the MAP Packet cases along 
with the default MAP case, which reverts to VCP service.

Regards,
Greg

From: Thomas Gannett <thomas.gannett at tgannett.net> 
Date: Wednesday, May 15, 2024 at 9:20?AM 
To: Kazz, Greg (US 312B) <greg.j.kazz at jpl.nasa.gov> 
Subject: [EXTERNAL] Condition on USLP poll
(so far: poll closes Friday)
 
SIS-AD  Tomaso de Cola                APPROVE WITH CONDITIONS (state conditions that must be satisfied)   
 
In my understanding, the main change to the specification is the introduction of the VC packet service, 
for which a dedicated section detailing the procedures and also a related functional architecture is 
provided. Likewise, also the NPICS is updated by adding two items to the specific VC packet service. As 
such, I'd have expected to see interoperability testing to verify the consistency of the specification and 
as such an updated version of the yellow prepared once ago for the first release of the USLP BB. Can you 
please clarify why it is not the case here?
 
 
Logothete, L.L.C.
thomas.gannett at tgannett.net
+1 443 472 0805