Clearly define how uMessages will be routed between uEntities in-vehicle and off-vehicle

[Benedikt-Illich]

This ticket is in reference to the discussion from the uProtocol meeting on march 6th.

There may be an open problem in the way that messages should get routed between entities in the cloud and entities inside a vehicle.

Assume a client uEntity in the cloud with UURI cloud/1/1/0/
and a service uEntity on an ECU in a vehicle with UURI ecu/3/1/1 on a vehicle identifiable as VIN123456

Then there exists currently no way for the cloud based client to send a request to the service with UEID 3 on vehicle VIN123456.

Possible solutions:
Two possible solutions are

Hierarchical authorities:
The UUID of the service instead becomes akin to ecu.VIN123456/3/1/1. The service then becomes uniquely identifiable and the client can send requests to it.
The downside of this approach is that it requires that the cloud based client be aware on which in-vehicle device (i.e. which ECU) the service runs on. This may range from impractical for the client developer all the way to impossible if the vehicle architecture must be kept secret.

A new routing entity:
This requires a completely new component (similar to the uStreamer) which acts as a api-gateway into the vehicle. This component itself has a UUID like VIN123456/2/1/1/ and its job would be to look up the in-vehicle authority for any uEntity that gets requested from off-vehicle. The client would then direct its request at UURI VIN123456/3/1/1 which gets caught by the gateway. The authority of the service with UEID 3 gets determined and the gateway passes the message on to the inside of the vehicle towards UURI ecu/3/1/1 (with all of the source UURIs trivially known). The response message would get forwarded in the opposite way and have its source authority altered back from ecu/3/1/1 to VIN123456/3/1/1.
The downside of this approach is that either a whole new component is needed, or that the streamer needs to be expanded to handle this, increasing the complexity of any uProtocol network.

[Benedikt-Illich]

Very possible that I forgot a third or more approach to fix this that we talked about...

Personally I think that the second approach is more future proof and Ive started to experiment with a setup that could handle this. I also think it can tie into the development of the uDiscovery component since both gateway and discovery would critically need to handle some form of lookup in a consistent way.
Building on top of a api-gateway might very naturally lead to the discovery so it could be a good starting point for a component that will need to be developed anyways...

[stevenhartley]

@ValMobBIllich, in earlier versions of the protocol we separated uDevice from uDomain in UAuthority portion of the URIhowever in order to simplify the specifications, we merged them into one field for >1.5 of the spec, Earlier uProtocol schema was:
up://<UDEVICE>.<UDOMAIN>/<USERVICE_ID>/<USERVICE_VERSION_MAJOR>/<RESOURCE_ID>

So we could explicitly address something in the vehicle with ecu.VIN as the authority with both device and domain however the ask (that we never finished specifying), was is to omit the device name from the authority when communicating inter-domain (ex. vehicle <->cloud).

In order to achieve this request:

• Ingress traffic to a domain (i.e. vehicle), we require looking up the device that hosts the service and replacing the domain name with the device name.
• Egress from the domain, the device name needs to be replaced with the domain name.

The above proposal adds complexity to the domain level streamers and requires the streamer to lookup (and possibly cache) every ingress and egress message which is probably less frequency than intra-domain traffic.