[CESG] CESG-P-2017-08-007 Conditions
Thomas Gannett
thomas.gannett at tgannett.net
Sun Oct 29 22:51:08 UTC 2017
Dear CESG Members:
Conditions for approval of CESG-P-2017-08-007 Approval to publish CCSDS
524.2-B-1, Mission OperationsMessage Abstraction Layer Binding to TCP/IP
Transport and Split Binary Encoding (Blue Book, Issue 1) have been resolved
to the satisfaction of the AD who voted to approve with conditions. The
Secretariat will now proceed with CMC polling.
Thomas Gannett
<mailto:thomas.gannett at tgannett.net> thomas.gannett at tgannett.net
+1 443 472 0805
From: <mailto:Mario.Merri at esa.int> Mario.Merri at esa.int [
<mailto:Mario.Merri at esa.int> mailto:Mario.Merri at esa.int]
Sent: Friday, October 13, 2017 2:01 PM
To: Thomas Gannett
Cc: Danford S. Smith; Sam Cooper
Subject: Fwd: MAL to TCP-IP binding
Hi Tom,
Could you please proceed with the required steps for publication?
Please let me know if we need to add the extra bullet agreed with Scott or
if you could do it.
Many thanks,
__Mario
Begin forwarded message:
From: "Burleigh, Scott C (312B)" <scott.c.burleigh at jpl.nasa.gov>
Date: 13 October 2017 at 17:06:19 CEST
To: "Mario.Merri at esa.int" <Mario.Merri at esa.int>
Cc: "Cesar.Coelho at esa.int" <Cesar.Coelho at esa.int>, "dan.smith at nasa.gov"
<dan.smith at nasa.gov>, "Jose.Luis.Feiteirinha at esa.int"
<Jose.Luis.Feiteirinha at esa.int>, "Mehran.Sarkarati at esa.int"
<Mehran.Sarkarati at esa.int>, "Champsavoir Nicolas "
<Nicolas.Champsavoir at cnes.fr>, "Sam Cooper" <sam at brightascension.com>
Subject: RE: MAL to TCP-IP binding
Thanks, Mario, I think the additional bullet is a helpful change; at least
the reader will be directed to the appropriate supplemental specification.
My condition is satisfied. It is possible that others may raise similar
objections during Agency review, but lets not delay that review any
further.
Scott
From: Mario.Merri at esa.int [mailto:Mario.Merri at esa.int]
Sent: Friday, October 13, 2017 3:44 AM
To: Burleigh, Scott C (312B) <scott.c.burleigh at jpl.nasa.gov>
Cc: Cesar.Coelho at esa.int; dan.smith at nasa.gov; Jose.Luis.Feiteirinha at esa.int;
Mehran.Sarkarati at esa.int; Champsavoir Nicolas <Nicolas.Champsavoir at cnes.fr>;
Sam Cooper <sam at brightascension.com>
Subject: RE: MAL to TCP-IP binding
Hi Scott,
thanks for resolving your condition. Nevertheless, since we take seriously
your comment, I have discussed the matter further with Cesar and we came up
with a small change that could better address your condition. Basically, it
consists of modifying the Scope section by adding the bullet in red (see
below).
Would that work for you?
Thanks,
__Mario
1.2 SCOPE
The scope of this Recommended Standard is the specification of the binding
in terms of technology mapping to the Transmission Control Protocol (TCP)
over Internet Protocol (IP) of:
a) MAL message;
b) MAL Transport Interface.
The MAL Blue Book (reference [1]) specifies the MAL protocol in an abstract
way, i.e., without defining the concrete protocol data units. The MAL
binding to TCP/IP Transport protocol and the Split Binary Encoding specify a
complete and unambiguous mapping of:
a) the MAL message to a binary Protocol Data Unit to be transmitted
over TCP/IP;
b) the MAL transport interface to the TCP/IP interface;
c) the MAL data types to a binary encoding format (split binary
encoding).
This Recommended Standard does not specify:
a) individual implementations or products;
b) the implementation of entities or interfaces within real systems.
c) recommendations nor best practices for deploying systems with
proxies and/or firewalls.
d) a direct mapping to the sockets API as the TCP Protocol
Specification (reference [4]) is unambiguously used for the mapping.
In a concrete deployment, on the wire interoperability between application
layer MO Service consumer and provider will be achieved by encoding the
abstract MAL messages in the concrete split binary encoding and transmitting
them by means of TCP/IP PDUs, as defined in this Recommended Standard.
From: "Burleigh, Scott C (312B)" <
<mailto:scott.c.burleigh at jpl.nasa.gov> scott.c.burleigh at jpl.nasa.gov>
To: " <mailto:Cesar.Coelho at esa.int> Cesar.Coelho at esa.int" <
<mailto:Cesar.Coelho at esa.int> Cesar.Coelho at esa.int>
Cc: Sam Cooper < <mailto:sam at brightascension.com>
sam at brightascension.com>, " <mailto:dan.smith at nasa.gov> dan.smith at nasa.gov"
< <mailto:dan.smith at nasa.gov> dan.smith at nasa.gov>, "
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int" <
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int>, "
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int" <
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int>,
"Champsavoir Nicolas" < <mailto:Nicolas.Champsavoir at cnes.fr>
Nicolas.Champsavoir at cnes.fr>, " <mailto:Mehran.Sarkarati at esa.int>
Mehran.Sarkarati at esa.int" < <mailto:Mehran.Sarkarati at esa.int>
Mehran.Sarkarati at esa.int>
Date: 11/10/2017 17:44
Subject: RE: MAL to TCP-IP binding
_____
Hi, César. I think my comment is actually pretty self-explanatory: I
believe the specification would be easier to implement if you mapped the MAL
functions to the socket API, with which developers are very familiar, rather
than to the formal TCP specification. You are free to take this suggestion
or not, as you see fit; you have considered my suggestion, so please
consider my condition satisfied. I certainly dont have spare time for
writing any new text for you to review.
Scott
From: <mailto:Cesar.Coelho at esa.int> Cesar.Coelho at esa.int [
<mailto:Cesar.Coelho at esa.int> mailto:Cesar.Coelho at esa.int]
Sent: Wednesday, October 11, 2017 8:03 AM
To: Burleigh, Scott C (312B) < <mailto:scott.c.burleigh at jpl.nasa.gov>
scott.c.burleigh at jpl.nasa.gov>
Cc: Sam Cooper < <mailto:sam at brightascension.com> sam at brightascension.com>;
<mailto:dan.smith at nasa.gov> dan.smith at nasa.gov;
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int;
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int;
Champsavoir Nicolas < <mailto:Nicolas.Champsavoir at cnes.fr>
Nicolas.Champsavoir at cnes.fr>; <mailto:Mehran.Sarkarati at esa.int>
Mehran.Sarkarati at esa.int
Subject: Fw: MAL to TCP-IP binding
Dear Scott,
I was asked to agree with you on the new changes and write them in the book.
However, I must confess that I am a bit confused with the whole exchange of
emails, so please bear with me.
In the original comment, one reads:
"It was not clear to me which MAL operations map to initiation and
acceptance of TCP connections using "socket" terminology. I think most TCP
developers
are more familiar with the socket API than with the TCP protocol
specification, so I think adding some notes on this mapping might improve
implementation success."
I understand that developers are more familiar with the socket API (SOCKET,
BIND, LISTEN, ACCEPT, CONNECT, SEND, RECEIVE, CLOSE) specification than with
the TCP (OPEN, SEND, RECEIVE, CLOSE) specification as you state. However
throughout the document, the TCP specification was used (RFC 793).
The establishment of the connections is present in page 49 and 51 for
TRANSMIT REQUEST and RECEIVE INDICATION respectively. It uses the TCP OPEN
primitive, as this is the specification the book is mapping to.
What exactly would you like to see in the book?
It would be great if you could propose your changes to be included and we
would review them.
Thank you very much for your time.
Best regards,
César Coelho
From: "Burleigh, Scott C (312B)" <
<mailto:scott.c.burleigh at jpl.nasa.gov> scott.c.burleigh at jpl.nasa.gov>
To: " <mailto:Mehran.Sarkarati at esa.int> Mehran.Sarkarati at esa.int" <
<mailto:Mehran.Sarkarati at esa.int> Mehran.Sarkarati at esa.int>
Cc: Sam Cooper < <mailto:sam at brightascension.com>
sam at brightascension.com>, " <mailto:dan.smith at nasa.gov> dan.smith at nasa.gov"
< <mailto:dan.smith at nasa.gov> dan.smith at nasa.gov>, "
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int" <
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int>, "
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int" <
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int>,
"Champsavoir Nicolas" < <mailto:Nicolas.Champsavoir at cnes.fr>
Nicolas.Champsavoir at cnes.fr>
Date: 05/10/2017 17:53
Subject: RE: MAL to TCP-IP binding
_____
Mehran, I think your assumption (at the bottom of this email) is correct,
and I think there just ought to be a sentence or two to this effect
somewhere at the start of the specification.
Scott
From: <mailto:Mehran.Sarkarati at esa.int> Mehran.Sarkarati at esa.int [
<mailto:Mehran.Sarkarati at esa.int> mailto:Mehran.Sarkarati at esa.int]
Sent: Thursday, October 5, 2017 4:12 AM
To: Burleigh, Scott C (312B) < <mailto:scott.c.burleigh at jpl.nasa.gov>
scott.c.burleigh at jpl.nasa.gov>
Cc: Sam Cooper < <mailto:sam at brightascension.com> sam at brightascension.com>;
<mailto:dan.smith at nasa.gov> dan.smith at nasa.gov;
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int;
<mailto:Jose.Luis.Feiteirinha at esa.int> Jose.Luis.Feiteirinha at esa.int;
Champsavoir Nicolas < <mailto:Nicolas.Champsavoir at cnes.fr>
Nicolas.Champsavoir at cnes.fr>
Subject: Fw: MAL to TCP-IP binding
Dear Scott,
We have been discussing on our side the condition, which you had raised
during the review of the MAL to TCP/IP binding book:
It was not clear to me which MAL operations map to initiation and acceptance
of TCP connections using "socket" terminology. I think most TCP developers
are more familiar with the socket API than with the TCP protocol
specification, so I think adding some notes on this mapping might improve
implementation success."
To be honest, I am not sure if we have fully and correctly understood your
condition and I have to say I am no expert in this domain.
The best answer I have gathered so far is from our experts is the one below.
Please have a look and let me know if this is answering your condition
sufficiently? If so, we can certainly add a corresponding explanation in the
book to explain what is at the level of the binding and what a typical
implementation would do.
Kind Regards
Mehran
----- Forwarded by Mehran Sarkarati/esoc/ESA on 05/10/2017 13:02 -----
From: José Luís Feiteirinha < <mailto:jose.luis.feiteirinha at esa.int>
jose.luis.feiteirinha at esa.int>
To: <mailto:Mehran.Sarkarati at esa.int> Mehran.Sarkarati at esa.int
Cc: " <mailto:Cesar.Coelho at esa.int> Cesar.Coelho at esa.int" <
<mailto:Cesar.Coelho at esa.int> Cesar.Coelho at esa.int>, Thomas Pignede <
<mailto:thomas.pignede at hotmail.de> thomas.pignede at hotmail.de>, Dario Lucia <
<mailto:Dario.Lucia at telespazio-vega.de> Dario.Lucia at telespazio-vega.de>,
<mailto:Mario.Merri at esa.int> Mario.Merri at esa.int, Sam Cooper <
<mailto:sam at brightascension.com> sam at brightascension.com>
Date: 05/10/2017 08:55
Subject: Re: Fwd: TCP-IP binding
_____
HI Mehran,
>From what I recall from Thomas, this can be a common misconception. I'll go
through it briefly and explain my current understanding.
Typical sockets work the following way:
1) There is socket server running on a specific TCP port, let's call it the
TCP-Server.
2) When 'someone' connects to a TCP-server, a random port (between 32768 and
65535) is attributed to the client. Let's call it the TCP-client.
3) Afterwards all messages from the TCP-server to the TCP-client set the
"TCP Destination Port" to be the randomly attributed TCP-client's port and
vice-versa.
Now, for the TCP IP binding we mapped the "URI From" and "URI To" partially
to the corresponding TCP/IP port. But we do not expect that the consumer's
URI will be randomly defined by the socket layer.
For this reason the sockets are not instantiated as for typical TCP sockets,
rather than that, we specifically tell, we'd like a TCP-IP client to be
established from that specific port (the one we've agreed in the URI).
I think that above covers it, assuming my understanding is correct.
That was also what I briefly intended to cover when I wrote: "The concept of
the MAL TCP/IP binding is independent from the typical TCP/IP server/client
socket configuration (i.e. doesn't care who is the socket server or client
in case the link was established using traditional sockets) . However it can
work on top of any existing TCP/IP sockets so-long the mapping of URI to TCP
(port) and IP(address) are respected."
Cheers,
José
On 03/10/2017 8:49 PM, Mehran.Sarkarati at esa.int wrote:
Hi ,
I have very little understanding of the TCP/IP protocol and the socket API.
Reading he RID raised by Scott, I understand he is asking "Who and how is
the
TCP/IP connection established". As we do not have a "connect" operation like
in SLE, I understand his question to be how is the tcp/ip hand-shake done
and
the connection initiated as there is no corresponding MAL operation for
this.
Am I right in assuming that someone "as part of the implementation" must
initiate the TCP/IP connection and open a connection before MAL interactions
can happen?
If yes, is the book clear on how this is supposed to happen?
@Dario, Thomas: I would appreciate an answer from your side as well.
Cheers
Mehran
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.
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/20171029/c62808a4/attachment.html>
More information about the CESG
mailing list