[Moims-sc] Options for MO MAL Binding to HTTP Transport

[Mehran.Sarkarati at esa.int]

Dear SM&C WG,

As mentioned during the technical meetings in Pasadena and in the last 
web-ex, we have started the work on ESA side to define a binding between 
MAL and HTTP transport.

The main motivation for this binding is to use mainstream Internet 
infrastructure on the ground.
HTTP protocol is based on a request/response model.
For all MAL interaction patterns except for INVOKE, PUBSUB and PROGRESS, 
there is a simple mapping to the HTTP Request/Response model.

It gets more complicated for the above mentioned three interaction 
patterns, when the provider needs to asynchronously initiate a connection 
to the consumer for delivering a response (request in the other 
direction). This is specially problematic when the consumer/provider are 
behind firewalls and also when consumers are dynamically added and removed 
(hence the firewalls cannot be configured statically).
The options we have been discussing are: 

a) implement a mapping to pure HTTP request/response model for all MAL 
interaction patterns. For INVOKE, PUSUB and PROGRESS use active/long 
poling if the consumer is not addressable or behind a firewall (the OASIS 
WS Make Connection specification can be the model, which uses additional 
headers to correlate the messages).
b) implement a mapping to HTTP request/response for all MAL interaction 
patterns except for INVOKE, PUBSUB and PROGRESS. For these use 
web-sockets. Web-Sockets are a different protocol than HTTP. It is a 
message oriented bi-directional protocol on top of tcp/ip. It uses HTTP 
for initiating the connection and then establishes a bi-directional 
connection, using the tcp/ip channel below, which was opened by the HTTP.

Long polling is clearly less elegant than web-sockets. At the other side 
for many of our space domain scenarios the consumer and provider are known 
to each other and the firewalls must be configured anyway.
If I take the example of ESA data distribution systems (DDS/EDDS) on the 
DMZ, even for making a simple http request/response to the DDS, the 
consumer IP address must to be added to a white list.

The scenarios translate therefore to:

1. HTTP Request/Response based mapping to all MAL interaction patterns: 
This is either when 
        a) there are no firewalls involved (not very realistic) : No 
polling involved, simple http request/response
        b) consumer and provider are known up front and firewalls are 
configured accordingly to allow the traffic pass through in both 
directions (in my opinion more likely/realistic case): no polling 
involved, simple http request/response
        c) consumers are added and removed dynamically at run-time and 
firewalls do not allow out-bound connection initiation from provider side: 
Only for this particular case pooling techniques shall be adopted on top 
of simple HTTP request/response pattern 

2. HTTP Request/Response based mapping to all MAL interaction patterns 
except for INVOKE/PROGRESS and PUBSUB for which web-sockets shall be used: 
this would use web-sockets for any scenario (even for scenario a and b, 
where it would not be necessary and one could do simple http 
request/response with no polling)

3. A mixture of 1 and 2. Baseline is (1) but for PUBSUB and PROGRESS the 
consumer can decide if it wants to use web-sockets or long polling. This 
would be indicated with a header field in the initiating HTTP request 
(which is needed for both cases). I am not sure if this 3 option is 
possible without over complicating the binding.

I would like to ask you to

a) check the setup of the DMZ and firewalls in your organisation and tell 
us if in your today's setup the firwall/IDS would let web-socket traffic 
through or would detect and prevent it for port that is specified as http 
port (e.g. port 80)
b) Which of the three options you think we should take for MAL to http 
binding.

I would appreciate your feedback by mid September.

Kind Regards
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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-sc/attachments/20150813/7f11f1d1/attachment.html>