[CESG] CESG-P-2021-02-004 Approval to release CCSDS 732.0-P-3.1, AOS Space Data Link Protocol (Proposed Pink Sheets, Issue 3.1) for CCSDS Agency review
CCSDS Secretariat
thomas.gannett at tgannett.net
Sat Feb 20 16:19:46 UTC 2021
Dear CESG Members,
Conditions for approval of CCSDS 732.0-P-3.1, AOS Space Data Link
Protocol (Proposed Pink Sheets, Issue 3.1) 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 release
for Agency review.
-------------- next part --------------
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent: Thursday, February 18, 2021 5:36 PM
To: Gian.Paolo.Calzolari at esa.int
Cc: Gilles.Moury at cnes.fr; Kazz, Greg J (US 312B); Matt Cosby; Tom Gannett
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Follow Up Flag: Follow up
Flag Status: Flagged
Categories: Poll Condition Closure
Gippo,
From my point of view it appears that there are still remaining inconsistencies among these different
statements. I do not know when they appeared, but you may be correct that they were introduced in
the 2003 rewrites. You are also correct that some of these are outside the normal scope of a Pink Sheet
review and therefore discussing them is ground ruled off the table. Im fine with that.
I cannot prove this, but I suspect the reason why this has not been an issue before now is that those
missions that do use AOS, and there are quite a few, do not use these fancy features where there are all
of these you can do this, but not that restrictions. Instead they use straightforward approaches like
packets => MPDU => AOS frames, and possibly some frame merging into different VCs from different
sources.
Ill remove the PID, and leave you guys to sort out the thornier issues on your own
if you care to.
Regards, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Thursday, February 18, 2021 at 9:42 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Matt Cosby
<matt.cosby at goonhilly.org>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Peter,
the restriction "2.2.4 a)" (in red in your mail) is not new (and then formally speaking not under review)
as it present in the actual form since CCSDS 732.0-B-1 September 2003.
If somebody can say that this restriction was invented by Takahiro out of the blue, I have the impression
this is not true and that restriction "2.2.4 a)" in 732.0-B has been generated as a natural consequence of a
few clauses from CCSDS 701.0-B-3 June 2001 as e.g.
5.4.3.e In view of complex interactions with internal VCA error control, the Virtual Channel Data
Unit service and Insert service shall not be simultaneously active on a particular Physical Channel.
...
5.4.9.1.2.4.a When the optional Insert service is activated, a fixed-length Insert Zone exists
in every VC_PDU (VCDU/CVCDU) that is transmitted in a particular PCA_PDU (including Fill
VC_PDUs). The Insert service and Virtual Channel Data Unit service may not be activated
simultaneously.
Apart from formal aspects, that can easily be overcome if the improvement is important, I think I have
duly reported to you what is the understanding within SLS (unless Greg, Matt or Gilles want to disprove
this) mentioning a few clauses that - of course - only offer a partial view of the complete situation that IMO
can be confirmed reading the complete picture for those functions at sending at receiving end..
Based on this, if you are not convinced yet, I repeat my proposal that Greg, taking note of this issue,
generates a RID such that proper discussion is held in the WG when the Agency Review RIDs will be
disposition.
Would you agree?
Regards
Gippo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>,
"Matt Cosby" <matt.cosby at goonhilly.org>, "Tom Gannett" <thomas.gannett at tgannett.net>
Date: 18-02-21 01:56
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Hi Gippo,
Thanks for the clarification on just exactly what you meant by VCF and Packet services.
That said, given the statement originally at issue:
2.2.4 a)
On one Physical Channel, the Insert service shall not exist simultaneously with the Virtual
Channel Frame or Master Channel Frame service.
I still believe that this statement is inconsistent with those two clauses that you quoted,
particularly 4.2.4.3 and 4.2.7.2, which, taken together, says something quite different.
Or maybe I am misunderstanding how this really works.
Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, February 17, 2021 at 2:42 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Matt Cosby
<matt.cosby at goonhilly.org>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Peter,
the term Packet Service is not casual in my discussion.
This is fully explained in the AOS Blue Book.
Just look at Figure 4-7 and at the attached snapshot and consider the example where
* Virtual Channel 1 is used by a Virtual Channel Frame Service User.
* Virtual Channel 2 is used by a Packet Service user.
*
The Packet Service makes use of the following functions:
* Packet Processing
* Virtual Channel Generation
* Virtual Channel Multiplexing
* Master Channel Multiplexing
* All Frames Generation
The VC Frame Service makes use of the following functions
* Virtual Channel Multiplexing
* Master Channel Multiplexing
* All Frames Generation
Frames for VC 1 are generate "externally" while frames for VC 2 are generated/assembled within the
Virtual Channel Generation function.
The Virtual Channel Generation function defined in section 4.2.4 can include the insert zone field but
does not fill the insert zone as per following clause
4.2.4.3 The Insert Zone and the Frame Error Control Field of Transfer Frames, if present for a
particular Physical Channel, shall be kept empty by the Virtual Channel Generation Function.
It is the ALL FRAMES GENERATION FUNCTION defined in section 4.2.7 that fill up the Insert Zone as
per following clause
4.2.7.2 If the optional Insert Service is activated, a fixed-
length Insert Zone shall exist in every Transfer Frame that is transmitted in a particular P
hysical Channel. The IN_SDUs shall be timed to arrive at a constant interval that corresp
onds to the release time of the Transfer Frames onto the Physical Channel. The All Frames
Generation Function shall place
the IN_SDUs, received from the Insert Service user, into the Insert Zone of the Transfer Fr
ames, preserving octet alignment.
AOS has been designed to not replace the contents of the insert zone when frames are provided e.g. by
the VC Frame Service User (this behaviour is the opposite of TM SDLP).
Therefore, if the (pre cooked) frames of VC 1 contain a "filled up" insert zone, the frames of VC 2 will
always contain an "empty" insert zone.
This is mirrored in the restriction stated since several years (since ever?)
Right of wrong this is the situation.
It could have been done differently of course, but I cannot judge it at this point in time.
This means that in the current standard the "frame generation service to create frames and carry those
packets" in AOS only generates an empty Insert Zone.
I hope this clarifies the issue.
Regards
Gippo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>,
"Matt Cosby" <matt.cosby at goonhilly.org>, "Tom Gannett" <thomas.gannett at tgannett.net>
Date: 17-02-21 22:25
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Hi Gippo,
It might help to look at this from the perspective of the Functional Resource Model (FRM) that
the CSS Area has developed. They have the unenviable problem of making sense of, and
describing, how all of these different features of links, coding, synchronization, modulations, fit
together in the context of an ESLT. And they were motivated to do this in order to provide the
necessary configuration, control, and monitoring services. One of the things that becomes clear
from their analysis is that you cannot just say Packet Service without also saying Frame
Generation Function. There is no magic bullet that gets you from a Packet Service interface,
that accepts SPP (or EP) packets and have frames containing those packets magically
appear. There must be an intervening Frame Generation and Packet Stuffing Function that
creates the frames and loads them with packets, or parts of packets, and handles spanning of
packets across frames.
I draw your attention to two relevant, but not entirely on-point, diagrams from the draft FRM
document, CCSDS 901.3-W-0.7 that is currently being reviewed within the CSS SM WG. It
shows, quite clearly, the interfaces, functionality, and connections among the different FRM that
are needed to flow data along various paths. These are the functional flow diagrams that
implement the kind of data merge flows that appear in typical protocol specs.
I guess the short way to state this is that in your example 2) I think that there must be a frame
generation service to create frames and carry those packets. And that frame generation service,
if the Insert Zone managed parameter is set, ought to be generating Insert Zones and populating
them with relevant data.
Right?
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, February 17, 2021 at 12:13 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Matt Cosby
<matt.cosby at goonhilly.org>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Peter,
I have some issues with the statement " It seems equally clear that if one uses it then all other
users of that same service must use it too."
Let's consider this example:
* We have a single Master Channel
* Virtual Channel 1 is used by a Virtual Channel Frame Service User. In principle this user could
pre-cook the frames with an Insert Zone.
* Virtual Channel 2 is used by a Packet Service user.
The second user has no way to fill up the insert zone.
If you enable the managed parameter for the insert zone, the ALL FRAMES GENERATION FUNCTION
will fill up it for all the frames (i.e both VCs).
If you DO NOT enable the managed parameter for the insert zone, the ALL FRAMES GENERATION
FUNCTION will NOT fill up it for any frames (i.e VC #2 will never have an insert zone and the ALL
FRAMES RECEPTION FUNCTION will go banana).
At this point in time my frank suggestion is that Greg, taking note of this issue, generates a RID such that
proper discussion is held in the WG when the AGency Review RIDs will be dispositioned.
Would you agree?
Regards
Gippo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>,
"Matt Cosby" <matt.cosby at goonhilly.org>, "Tom Gannett" <thomas.gannett at tgannett.net>
Date: 17-02-21 20:56
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Hi Gippo,
As long as you are clear in the text that there are cases where one or more users of the MCF or
VCF services can use the Insert Zone then I am satisfied. It seems equally clear that if one uses
it then all other users of that same service must use it too. My objection was to the text that
apparently read that it was NEVER possible.
Just saying:
2.2.4 a)
On one Physical Channel, the Insert service shall not exist simultaneously with the Virtual
Channel Frame or Master Channel Frame service.
Gives the impression that it is never possible, and clearly that is not the case.
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, February 17, 2021 at 10:48 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Gilles Moury <Gilles.Moury at cnes.fr>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Matt Cosby
<matt.cosby at goonhilly.org>, Tom Gannett <thomas.gannett at tgannett.net>
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Peter,
before replying I went to check the AOS book. Here below a reduced summary of my findings:
3.9.1 states Only one user can use this service on a Physical Channel and the user is identified with the
Physical Channel Name of the Physical Channel. Service data units from different users are not
multiplexed together within one Physical Channel.
4.1.2.3.2 Note 3 states A Transfer Frame on the Idle Virtual Channel may not contain any valid user
data within its Transfer Frame Data Field, but it must contain the Insert Zone if the Insert Service is
supported.
moreover
4.1.3.2 The presence or absence of the optional Transfer Frame Insert Zone shall be established
by management.
4.1.3.3 If the Physical Channel supports the Insert Service for transfer of periodic data, then the
Insert Zone shall exist in every Transfer Frame transmitted within the same Physical Channel, including
OID Transfer Frames.
Clearly the basic rule is the old one
2.2.4 a)
On one Physical Channel, the Insert service shall not exist simultaneously with the Virtual
Channel Frame or Master Channel Frame service.
Now let's make a few examples.
1) the sending user has only one MC and on the MC there is only a Master Channel Frame service user.
Then it is in principle possible that the pre-cooked frames contain also an insert zone In this case the
ALL FRAMES GENERATION FUNCTION does not fill up the Insert Zone while the ALL FRAMES
RECEPTION FUNCTION can extract it at the receiving end. A little tricky but it can work.
2) if the sending user has two MCs it is possible that the first MC there is a Master Channel Frame service
user (with pre-cooked frames containing an insert zone) while on the second MC the Packet Service is
provided. In this case the ALL FRAMES GENERATION FUNCTION does not fill up the Insert Zone.
Consequently at the receiving end there will frames from the first MC with insert zone and frames from the
second MC without an insert zone. Therefore the ALL FRAMES RECEPTION FUNCTION will not be able
to extract correctly the data from the frames as that function operates on the physical channel.
3) the same as #1 above with only a Virtual Channel Frame service user.
4) the same as #2 above with a Virtual Channel Frame service user.
My conclusion is that your proposed NOTE would be true only in case on top of the physical
channel there is only one Master Channel Frame service user. Or - as extreme alternative - on top of the
physical channel there are only Master Channel Frame service users and they all behave the same with
respect to their pre-cooked frames.
Some reasoning for Virtual Channel Frame service user.
Having said this, I would not include that NOTE.
Clearly the WG may note down your remark and iscuss it further to check if my initial and fast analysis is
correct or not.
I hope we can converge
Regards
Gippo
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc: "Tom Gannett" <thomas.gannett at tgannett.net>, "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>,
"Gilles.Moury at cnes.fr" <Gilles.Moury at cnes.fr>, "Matt Cosby" <matt.cosby at goonhilly.org>
Date: 17-02-21 18:50
Subject: Re: [EXTERNAL] SEA Conditions on 732.0-B AOS
Hi Gippo,
These changes partially clarify what I saw as confusing language. The one further change I
would suggest, probably best inserted into sec 3.2.6, is this:
NOTE: The AOS Transfer frames carried by the VCF or MCF services may all contain a
user supplied, and filled, Insert Zone field, but the underlying Physical Channel Service
cannot also provide an Insert Zone in these cases.
Does this work for you? I believe that is an accurate statement.
Thanks, Peter
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, February 17, 2021 at 2:05 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Tom Gannett <thomas.gannett at tgannett.net>, Greg Kazz <greg.j.kazz at jpl.nasa.gov>,
Gilles Moury <Gilles.Moury at cnes.fr>, Matt Cosby <matt.cosby at goonhilly.org>
Subject: [EXTERNAL] SEA Conditions on 732.0-B AOS
Dear Peter,
after SLS coordination with the SLP WG chairs you find here below the reply to your conditions.
----------------------------------------------------------------------------------------
SEA AD Peter Shames APPROVE WITH CONDITIONS (state conditions that must be
satisfied)
There is some confusing, and apparently innaccurate, wording vis-a-vis Insert zones in Sec 3.2.6
and sec 4.2.7.2. See attached file with mark-ups.
------------------------------------------------------------------------------------------
For VCF/MCF PID it shall be remarked that the restriction is not new and present since many
years in section 2.2.4 RESTRICTIONS ON SERVICES that states "There are some restrictions
on the services provided on a Physical Channel, as follows:
a)On one Physical Channel, the Insert service shall not exist simultaneously with the Virt
ual Channel Frame or Master Channel Frame service. ..."
However the proposed clarifications are proposed:
a. Section 3.2.6
FROM: The following restriction applies to AOS Transfer Frames: if at least a Virtual
Channel Frame or a Master Channel Frame service exists, all AOS Transfer Frames on
the Physical Channel shall not include the Transfer Frame Insert Zone.
TO: The following restriction applies to AOS Transfer Frames: if at least a Virtual
Channel Frame service (see 3.7) or a Master Channel Frame service (see 3.8) exists,
all AOS Transfer Frames on the Physical Channel shall not include the Transfer Frame
Insert Zone.
b. Section 3.2.6 NOTE 2
FROM: Unlike TM transfer frames, AOS transfer frames transferred by the Virtual Channel
Frame and Master Channel Frame services are not partially formatted AOS transfer frames.
TO: Unlike TM transfer frames, AOS transfer frames transferred by the Virtual Channel Frame
and Master Channel Frame services are complete AOS transfer frames preventing periodic
transmission of the Insert Zone SDUs at a constant frame rate.
c. Section 4.2.7.2 NOTE
FROM: This is possible because the Insert service cannot exist on a Physical Channel when
either Virtual Channel Frame or Master Channel Frame services exist.
TO: This is possible because the Insert service cannot exist on a Physical Channel when either
Virtual Channel Frame or Master Channel Frame services exist. See section 3.2.6
------------------------------------------------------------------------------------------
I hope this explanation will be sufficient to remove your condition and proceed to Agency Review.
Best regards
Gian Paolo
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).
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).
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 "FRM Overview fig 2-7 2021-02-17
at 1.12.02 PM.pdf" deleted by Gian Paolo Calzolari/esoc/ESA] [attachment "FRM
fig 2-8 2021-02-17 at 1.12.39 PM.pdf" deleted by Gian Paolo
Calzolari/esoc/ESA]
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).
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).
More information about the CESG
mailing list