Client location sensing for proper URI preparation at server side

[openBackhaul]

Is it necessary to add an additional function to the ApplicationPattern for "sensing" the location of the client for being able to provide proper URI e.g. in the request of the Generic Representation?

x-Domain communication must be supported, too.

(Issue is put into 2.0.2_spec for keeping it in mind. Most likely it will be transferred into 2.1.0.)

[PrathibaJee]

Including the following thoughts here , so that we can also look into this option while discussing this issue. Thanks.
Lets consider the following scenario,

1. An application is running in lab in the IP address x.x.x.x
2. Within lab environment , this shall be addressed by using this address itself
3. To access this IP address from external bubbles(let’s say Zone-A) , if a corresponding NAT IP address(let’s say y.y.y.y) is available , then Zone-A will address this application by using the address y.y.y.y.
4. For a man-to-machine communication from Zone-A , manually this ip-address will be typed and used.
5. So , for a machine-to-machine communication from Zone-A also , client application shall map the corresponding ip-address using which it shall reach the destination.

For example ,
Case 1 : If StartApplicationInGenericRepresentationGUI(SAIGR GUI) is running outside the TAC environment , SAIGR GUI should have a mapping file with NAT IP details to do the translation.
Case 2 : If SAIGR GUI is also running in the same environment as TAC , But this GUI will be accessed from outside environment , then , the man/machine in the outside environment should do the address translation.

By leaving the address translation logic to the client side will have the following advantage ,

1. Reduce complexity in our architecture by having single tcp-clients and servers
2. Reduce efforts in maintaining NAT IPs of in different Zones

[PrathibaJee]

Call on 28th of April 2023 , (including the meeting details and further points to discuss)
All applications within the SDN MS environment shall use “http” protocol for internal communication.
External applications shall address the applications of SDN MS environment using a proxy application.
Such proxy application will be always part of the SDN MS environment.

Its better to outsource the address translation to the client side.
And an agreement should be made that the “port of a proxy application should be stable”.

Further discussion required for the following ,
Currently we have two tcp-servers to hold http and https information
During application registration , both of this http and https tcp-server information will be sent to the RegistryOffice
Applications that adapted the application pattern concept and installed in the SDN MS environment shall be eligible for receiving operation-keys.
This means all microservices are inside the same secured bubble and shall be communicated by using “http”

Potential Proposal :
If communication between microservices in the SDN MS environment is decided to use “http” , then the following changes are required,
config file shall hold a single tcp-server instance with “http” protocol information. ( detailed separate issue shall be created for Config file change , server , testsuite)
During Registration of application , only a single tcp information shall be sent to RegistryOffice (detailed separate issue shall be created for OAS , server , testsuite)
OAM services in that manipulated tcp-server instance needs to modify the {uuid} pattern to point to a single instance -000
Keeping the getTcpServerLocalProtocol/putTcpServerLocalProtocol as it is to keep the protocol open for https communication aswell. (There is no harm in reaching an application via https)

What about tcp-clients ?
As per the current modelling , all the applications except RO will hold only a single tcp-client instance.
All tcp-client’s protocol shall be either http/https to support connecting to any external applications( like SDN controller which is usually preferred to be reached via https.)

[openBackhaul]

Thoughts after reading through past considerations and proposals:

• The following directions should be no-go areas as they are introducing complexity that should be managed somewhere else (e.g. other OSI layer, by infrastructure, or anything else), but not as a part of the applications' logic:
  • the server side "sensing" the location of the client for being able to provide proper URI
  • managing multiple TCP/IP addresses as the applications could be addressed via different NATs
  • the application to find out its own location
  • ...
• The communication between microservices in the MW SDN MS environment should be exclusively http.
• Every Server/Client stack shall contain just a single TcpServer/Client (for holding the http address).
• All applications (including GenericRepresentationGUI, if required) that are located outside the MW SDN MS environment shall be connected via some Proxy that is also separating the internal and external management of TCP/IP addresses.

[PrathibaJee]

@openBackhaul , thanks for the details.

All applications (including GenericRepresentationGUI, if required) that are located outside the MW SDN MS environment shall be connected via some Proxy that is also separating the internal and external management of TCP/IP addresses.

Initially we wanted to have more than one tcp-client to cater external applications. Since proxy application will interface the external applications, having a single TcpServer/client will not have a negative impact in the architecture.

Also , some small doubts regarding the following points

1. For the point, "The communication between microservices in the MW SDN MS environment should be exclusively http".
   How shall we proceed for the following usecases ,

   • If the microservices are installed in differenct vms in inside the same GCP bubble
   • For the communication between the microservice and the database(Elastic search's REST client)
     (Reason for this doubt : recently Senthilvel/Andreas asked us to have HTTPS communication between VMs)

2. In the no-go area , for the point#3 "the application to find out its own location"
   (Asking this clarifications to analyse the impact)
   This means that,

• we will not have tcp/http/operation-clients for the same(own) application?
• forwarding-construct will have fc-port that points to an operation-server ?

Kindly please let us know your views.

[openBackhaul]

Created a pull-request that is implementing the following design aspects:

• The communication between microservices in the MW SDN MS environment should be exclusively http.
• Every Server/Client stack shall contain just a single TcpServer/Client (for holding the http address).
• All applications (including GenericRepresentationGUI, if required) that are located outside the MW SDN MS environment shall be connected via some Proxy that is also separating the internal and external management of TCP/IP addresses.