[Sls-slp] Follow on to the SPP telecon / was: Packet channel multiplexing no longer needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue Book
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Thu Feb 1 14:43:14 UTC 2018
Dear All,
in the attached file you find my considerations over Greg's input
and Ed's comments (marked red).
I converted Ed's e-mail below to a Word File to be able to use WinWord
comments etc.
If required I can provide the original WinWord file, while I attach here
the pdf for easier reading.
Comments are welcome.
Regards
Gian Paolo
From: "Greenberg, Edward (312B)" <edward.greenberg at jpl.nasa.gov>
To: "Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>,
"Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, John
Pietras <john.pietras at gst.com>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>
Date: 01/02/2018 07:17
Subject: Re: [Sls-slp] Packet channel multiplexing no longer
needed? : Results of Discussion with Takahiro Yamada on Revising SPP Blue
Book
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
My comments are in red in the text below.
From: SLS-SLP [mailto:sls-slp-bounces at mailman.ccsds.org] On Behalf Of
Kazz, Greg J (312B)
Sent: Wednesday, January 31, 2018 3:39 PM
To: Gian.Paolo.Calzolari at esa.int; John Pietras <john.pietras at gst.com>
Cc: sls-slp at mailman.ccsds.org
Subject: Re: [Sls-slp] Packet channel multiplexing no longer needed? :
Results of Discussion with Takahiro Yamada on Revising SPP Blue Book
All,
Here is a follow on to the telecon that occurred today between myself,
Gian-Paolo, Stefan Veit, and Ed Greenberg.
We are searching for the right approach to revise the SPP.
We are still in the brainstorming part of development. All inquiries and
ideas are most invited!
As we discussed in the Haag in Nov. 2017, the Space Packet provides a
duality of functionality: It is both an Application Layer (AP) Data
Structure and Format as well as a data link layer transport mechanism i.e.
it is transported within the frame data field of CCSDS transfer frames.
We all seem to agree that there should be no mention of multiple
subnetworks and routing in the future SPP. These things are handled much
better by DTN, IP, etc.
We go back to the basic structure of what we shall describe in the SPP
Blue Book: (This is where I would like to get consensus on first)
1. In the Application Layer, there are multiple users (data sources)
including the SPP Packet Assembly Function (out of strings it makes
packets) that request the transfer of Space Packets out of the Application
Layer by supplying the APID, APID_Qualifier (optional), QoS Rqmt
(optional) – as currently defined by the SPP. This is accomplished by
generating the packet.request primitive in SPP. So multiple users are
producing packets with different APIDs under management control and
outside the purview of CCSDS. APID is already in the packet thus it need
not be supplied externally.
2. In the Application Layer, those packets provided by those multiple
users and SPP Packet Assembly Function, shall be multiplexed to produce a
single packet stream in the appropriate order set by management whose
algorithm is not specified by CCSDS – as currently defined by SPP. (SPP
talks about a single Queue, but use of the term “stream” is better because
it is implementation agnostic). There is a packet stream to each VC SAP.
If there is only one packet stream then the transfer protocol must include
the VCID along with the QoS desired. I don’t understand APID_Qualifier.
3. NOW HERE COMES SOME CONTENTION – Do we want the SPP to have the
capability of forwarding data (not routing data) on-board (mostly
envisioned for on-board the spacecraft) within a single closed subnetwork
in an A-B-A configuration ? If the answer is yes (I think it is yes), then
APID_Qualifier needs to be well and unambiguously defined for SPP. I can
supply a use case from the ISS. For Telecommand, Space Station uses
Logical Data Path – Endpoint as the APID_Qualifier (this field occurs in
the packet 2nd Header, which is currently non-compliant with SPP because
there is currently no standard packet 2nd header defined) to forward
commands to user modules on-board the ISS. In this case, Logical Data Path
is short circuited to be a Logical Data Path Endpoint. OR Gian Paolo
contents that we should retire the concept of Logical Data Path
completely, and only leave a historical note in SPP about its previous
existence? I’m not quite sure what you mean by data forwarding. The
Logical Data Path concept that was defined in the otiginal Source Packet
sped was for a single link. That could be a local network addressing
scheme or a remote addressing scheme across a single link. This later
scheme is what is used almost totally by non-manned missions. The use of
a standard set of labels within the secondary header is a fine use of the
current packet format for multiple things but the current users use the
secondary header flag for non-standard secondary headers.
We may need to hold open the possibility of Logical Data Path Endpoint or
something similar until we get clarification from all agencies and the SIS
area about their desires for eventually modifying the SPP packet 2nd
header in order to accomplish data forwarding on-board a spacecraft. Does
this data forwarding function take place in the application layer ? We
may not need to modify the current format if we set a few constraints(i.e.
we could define a single APID in the packet header as a flag signaling the
inclusion of standard labels in the secondary header. These standard
labels could provide the true APID, APID_Qualifier( whatever this is), QoS
Rqmt, time of generation, time to live, priority for delivery, global
source and destination addresses, packet security parameters. Etc. This
methodology would have little effect on today’s usage of the Packet Format
and Link layer Packet service.
4. In the Data Link Layer, the transfer across the space link of
those Space Packets is requested. Here an additional multiplexing step may
take place, packets of multiple PVNs are multiplexed into the stream,
before packets are placed into the transfer frame data fields of frames.
Each single packet stream is then injected into the TF data field of a
specific VC frame by sending it to the instance of the Packet Processing
Function for that VC that transports packets as defined in the appropriate
SDLP Packet Processing Function. The most generic way of expressing this
primitive is to use Encapsulation.request (Data Unit, SDLP_Channel, PVN,
EPI). Of course, one could also accomplish this transfer by using
VCP.request (only for AOS or TM) or MAPP.request (TC) or (USLP) or Packet
Service in Prox-1.
Makes sense ?
Thanks!
Greg
Chairman SLP WG
From: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Date: Wednesday, January 31, 2018 at 6:30 AM
To: John Pietras <john.pietras at gst.com>
Cc: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, "sls-slp at mailman.ccsds.org" <
sls-slp at mailman.ccsds.org>
Subject: Packet channel multiplexing no longer needed? : [Sls-slp] Results
of Discussion with Takahiro Yamada on Revising SPP Blue Book
John,
I think that Packet channel multiplexing is still needed and
surely implemented by space agencies.
The point is that those implementation are not exposed and I find this
correct.
Let's say that we should keep the same approach we have had in the past;
i.e. SPP book shall mention that Packet channel multiplexing is to be
performed but leaving the implementation to users as loong as there no for
a commen service (either SLS or CSTS).
If you think this is the same that happened with the TC standard and FSP.
The TC Standard mentioned that TC Frames were multiplexed over VCs/MAPs
but gave no definition.
When SLE FSP was done it was realised that the TC Frame multiplexing
required to be defined and in fact you have relevant clauses and an Annex
in FSP.
The same for TM frame, they are multiplexed over a Master Channel and
their multiplexing is mentioned but not defined (specially because that
multiplexing is normally done on board a spacecrat :o).
Regards
Gian Paolo
From: John Pietras <john.pietras at gst.com>
To: "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>,
"Kazz, Greg J (312B)" <greg.j.kazz at jpl.nasa.gov>
Cc: "sls-slp at mailman.ccsds.org" <sls-slp at mailman.ccsds.org>,
SLS-SLP <sls-slp-bounces at mailman.ccsds.org>
Date: 30/01/2018 19:06
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada
on Revising SPP Blue Book
Sent by: "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>
All,
In an earlier email in this thread, Greg commented that he understood that
many missions multiplex different “packet channels” into the same VC, but
that he did not see this happening in an interoperable way. I think that
Greg has hit on the important factor here – what is exposed in an
interoperable, cross-supported way?
Back when we wrote the original AOS book, we had the notion that “cross
support” users would be able to access individual packet channels via
standard intefaces. This notion was formalized in the Cross Support
Reference Model, Part 1 – Space Link Extension Services Blue Book
(colloquially known as the “SLE Ref Model”), which envisioned two
“flavors” of Forward Space Packet (TC and AOS) and one Return Space Packet
service. Those services would have allowed multiple FSP instances to carry
packete channels all destined for the same VC.
As it turned out, only the TC flavor of the Forward Space Packet service
was ever realized. Different instances of the (TC) FSP service are indeed
capable of carrying different packet channels destined for the same VC.
The FSP service uses MAP, so the necessary packet channel multiplexing
into VCs is accomplished (indirectly) through MAP Multiplexing.
But had the AOS FSP been realized, it *would* have required the packet
channel muxing that currently resides in the SPP. But since it wasn’t
realized, the main use case (that I know of) disappears, and perhaps
packet channel multiplexing is indeed no longer needed at a cross-support
interoperability level, which I agree with Greg is the important factor in
considering whether to retain the specification in the SPP (or migrate it
back into one or more of the SDLP books).
Best regards,
John
From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int]
Sent: Tuesday, January 30, 2018 8:55 AM
To: Kazz, Greg J (312B)
Cc: John Pietras; sls-slp at mailman.ccsds.org; SLS-SLP
Subject: Re: [Sls-slp] Results of Discussion with Takahiro Yamada on
Revising SPP Blue Book
Greg,
what we have to be sure it captured in our CCSDS books is the
following situation (e.g. for a TM/AOS link)
There multiple sources generating packet contents and asking creation of
packets
Those packets are created with different APIDs depending on the source
Those different APIDs shall be multiplexed to produce a single packet
stream:
This single packet stream is then injected in in a VC
It is then correct that "The current AOS SDLP version i.e., CCSDS
732.0-B-3 Sept 2015 is agnostic about “packet channels” and “Individual
CCSDS packets from multiple sources” (implying multiple APIDs). It is
really only concerned about multiplexing of packets with different PVNs
onto VCs." In fact AOS would only see that single stream.
All the rest shall be done above the SDLP.
We shall check also what we lost with respect to CCSDS 103.0-B-2 (now
silver) where there was a nice picture for which I attach a detail.
Another document to be checked for losses is CCSDS 203.0-B-2 and even FSP
that mention APID multiplexing if I remember well.
Finally we shall verify all fits within the encapsulation service.
Ciao
Gian Paolo
This message and any attachments are intended for the use of the addressee
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the
sender.
Please consider the environment before printing this email.
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
This message and any attachments are intended for the use of the addressee
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the
sender.
Please consider the environment before printing this email.
_______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.
Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180201/9bc858d2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 21545 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180201/9bc858d2/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20180131.SPPwebexNotes.v0.2.pdf
Type: application/octet-stream
Size: 388635 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20180201/9bc858d2/attachment.obj>
More information about the SLS-SLP
mailing list