[CESG] IOAG: Service Catalogue #1 / "packet / file / frame plumbing"

Gian.Paolo.Calzolari at esa.int Gian.Paolo.Calzolari at esa.int
Tue Sep 27 16:53:52 UTC 2016


Peter, 
        a few replies below.
BTW, note that I missed a NOT and added a ? too  much; i.e. I meant: I am 
NOT sure I really understand what you mean for  "packet / file / frame 
plumbing".
Regards

Gippo




From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>
Cc:     "CCSDS Engineering Steering Group - CESG 
Exec(cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org>, "CESG" 
<cesg-bounces at mailman.ccsds.org>, "Nestor.Peccia at esa.int" 
<Nestor.Peccia at esa.int>
Date:   27/09/2016 18:15
Subject:        Re: [CESG] IOAG: Service Catalogue #1 /  "packet / file / 
frame plumbing"



Hi Gippo,
 
Please go look at the SCCS-ADD (or ARD) which have carefully prepared (and 
reviewed) diagrams that show just exactly what is involved in providing 
the F-Frame service and an ABA forward file service built on top of it. 
You are quite right that "Space/Encapsulation Packets, reliable/unreliable 
transfer, COP usage" are functions that will need to be built to operate 
the service and that it will be necessary to also define and build the 
Service Management (SM) capabilities that will allow these functions to be 
requested, managed, and configured by the service user.  But that is not 
all that will be required.
GPC: I never said this is the end of the story. My understand is that IOAG 
gives requirements (sometimes with some warning) and CCSDS then does the 
full work.
Alternativekly you could say
IOAG = what
CCSDS = how
 
The more significant "plumbing" that I was referencing includes: CFDP 
protocol processing, SPP packet creating, frame creation (AOS or TC), 
frame merging & multiplexing into separate VCs, and frame encoding.  All 
of those functions are defined in the ADD, some assigned to F-Frame (from 
frame creation down), as a re-usable set of structures, and some to 
specific services (such as CFDP and SPP).  And all of those functions also 
need SM capabilities defined.  Furthermore, those functions, as defined in 
the F-Frame service description, are re-usable and can support both ABA 
and SSI protocol stacks and end-to-end services.
GPC: It  seems we are basically matching about the idea of plumbing. 
Indeed IOAG states that some plumbing (e.g. COP usage, reliable transfer) 
can drive to complex systems.
With respcet to the "re-usable set of structures" I think you even go 
beyond CCSDS unless you mean that part of that (future) standard can be 
used for other standards. If you do not mean that and you intend reusable 
software then you are into the implemenation domain (out of CCSDS in 
principle)

To say that the "IOAG File services suppose a file is passed from A to B" 
is to ignore all of the actual plumbing that is required to make this 
happen.  From a simplistic, "top level", view this may be acceptable, but 
from a protocol view we really need to understand and define the whole set 
of protocols in the stack(s) and the gyrations that they go through.  We 
cannot ignore the plumbing.  So, in order to define a set of services that 
maximize functionality for the users and minimize the effort on the part 
of the ESLT (and the users) we took the approach defined in the SCCS-ADD. 
You were one of the reviewers and approvers of that document, I assumed 
you were familiar with it.
GPC:    To say that the "IOAG File services suppose a file is passed from 
A to B" is NOT to ignore all of the actual plumbing. It simply says that 
the splitting of tasks is different and the related standards are 
different. Again, CCSDS is the authority to determine the standardization 
details.

I hope you recall that the origins of this F-Frame approach was in the 
IOAG SISG, in a sub-committee that you, Wolfgang, and I participated in. 
The focus there was on space internetworking, but the forward frame 
service we cooked up was a general one and entirely suitable for the 
"plumbing" of even these sorts of ABA services.  And that is exactly what 
is described in the SCCS-ADD.
GPC: I do recall but you forgot I was there working on many details of 
F-Frame :o) . However, as mention, if Agency A wants to pass a file for 
uplink to Agency B, the work snd the standards are different from those 
implied when Agency A wants to pass frame for uplink to Agency B .
 
I think we should stick to the plan of developing the F-Frame first, and 
building these other services on top of that framework instead of 
developing another collection of "one-off" SLE-like services.
GPC:  What has this to do with IOAG Catalogs. Catalog 1 and Catalog 2 
define IOAG Services  with some envisaged components (e.g. Space Link 
Interface Standards & Ground Link Interface Standards & Service Management 
Standards & Data Format Standards). Out of the catalogs, IOAG define 
priorities and need dates to which CCSDS react accordingly of even in 
disagreement.
 
Regards, Peter
 
 
 
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Tuesday, September 27, 2016 at 8:53 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>, 
CESG <cesg-bounces at mailman.ccsds.org>, Nestor Peccia 
<Nestor.Peccia at esa.int>
Subject: Re: [CESG] IOAG: Service Catalogue #1 / "packet / file / frame 
plumbing"
 
Peter, 
        I am sure I really understand what you mean for  "packet / file / 
frame plumbing"? 
It looks to me that the description in Catalog 1 for the four files 
services (two directions x two flavours) do underline that the service 
provide will have to do quite some work (plumbing?) about 
Space/Encapsulation Packets, reliable/unreliable transfer, COP usage, 
You also say the  CSTS F-Frame is supposed to provide most of this 
plumbing but yor comment is ot about IOAG Catalog bu rather about the 
service an agency should select. 
In fact the IOAG File services suppose a file is passed from A to B, while 
F-Frame supposes frames are passed fromA to B. 

Regards 

Gian Paolo 



From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Nestor.Peccia at esa.int" <Nestor.Peccia at esa.int>, "CCSDS 
Engineering Steering Group - CESG Exec(cesg at mailman.ccsds.org)" 
<cesg at mailman.ccsds.org> 
Date:        26/09/2016 21:33 
Subject:        Re: [CESG] IOAG: Service Catalogue #1 
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org> 




Nestor, 
  
I know that this is a late input, but after reading the IOAG Svc Cat #1 I 
have a very real concern that I think needs to be surfaced.  Four new 
services have been introduced, the "Forward/Return CFDP-File Service Type" 
and the "Forward/Return PACKETS-File Service Type".  In reading through 
the descriptions I find that they mention certain SM characteristics, but 
fail to acknowledge the required presence of a whole lot of "packet / file 
/ frame plumbing" that is missing in most of our current systems.  Of 
particular concern, from a standards and logistics point of view, is that 
these new standards require a lot of the "plumbing" that CSTS F-Frame is 
supposed to provide, but make no mention of that standard.  In fact, the 
precursor standards, "Forward Synchronous Encoded Frame Service Type" has 
been dropped, and what is left is just some sort of weak "forward 
reference" to a CSTS F-Frame service. 
  
I think this is a huge mistake and that we should push back on it. 
  
Here is the logic behind this: 
  
1)       FF-CSTS includes the key services and functions that are required 
for anything like forward file, or forward packet, or forward DTN to work. 

2)       These functions include, quoting from the report "Users shall be 
aware that IOAG Service Catalog 2 foresees a future CSTS Forward Frame 
Service that is assumed will provide a forward service for [AOS] and 
[TC-DLP] frames implementing multiplexing, frame fill and coding in the 
provider and implementing the full stack down to the physical layer." 
3)       In order to implement a forward file or packet service all of 
these functions, plus frame creation, must be present in the service 
provider. 
4)       It makes little technical sense to create forward file and 
forward packet services, as new separate services that embed all of these 
function, instead of creating the FF-CSTS service and then building CFDP 
and Packet service "plug-ins" on top of that which use this underlying 
service. 
  
In fact, this approach is exactly how the forward file service is now 
described in the SCCS-ADD.  I draw your attention to CCSDS 901.1-M-1, sec 
5.2.2.2 and sec 6.2.2.2.  In fact, fig 6-4 shows the relationships among 
SM, CSTS F-Frame, the associated functions that are required, including 
ranging, and also SLE R-AF, and fig 6-8 (ABA ESLT Forward-File Protocol 
Building Blocks) shows how F-Frame and Fwd frame are designed to be 
integrated.  Any sort of forward packet service ought to just be a variant 
of this. 
  
My recommendation is that CCSDS push back on this IOAG Cat 1 request for 
two new stand alone services and instead argue that CSTS F-Frame should be 
done first, and these other new service built upon that base. 
  
Regards, Peter 
  
  
  
From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Nestor Peccia 
<Nestor.Peccia at esa.int>
Date: Thursday, September 15, 2016 at 3:43 AM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: [CESG] IOAG: Service Catalogue #1 
  
REMINDER 

Please let me have your comments (in particular from the CSS Area) by 22nd 
Sept 2016 cob. 

ciao 
nestor 

============================ 
Dear all, 

Please  find attached the Service Catalogue #1 that has been approved by 
the IOAG. 

You should be aware that the final approval regarding the editorial 
updates from NASA is still pending. There is an on-going discussion 
concerning service management ?function? vs. service management ?service?. 


However, this version is good enough to be processed by the CESG. 


[attachment "IOAG Service Catalog One.v2.0-Approved-20160823.pdf" deleted 
by Nestor Peccia/esoc/ESA] 
[attachment "IOAG Service Catalog One.v2.0-Approved-20160823withBars.pdf" 
deleted by Nestor Peccia/esoc/ESA] 

CESG will address this update during our next webex. 

Main changes are : 
1.        forward / return CFDP file over terrestrial generic file 
2.        forward / return packet file service  over terrestrial generic 
file 
3.        Service Management functions 


ciao 
nestor 
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._______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
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.

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/cesg/attachments/20160927/adc94216/attachment.html>


More information about the CESG mailing list