How UUri maps to Zenoh key

[evshary]

As we discussed in the weekly meeting, let me put the conclusion here to see whether we're on the same page.
Then I can update the Zenoh spec in up-spec later.

1. We don't need to distinguish the local and remote UUri in the Zenoh key. The Zenoh key transformed from UUri is visible globally. No matter local entity or remote entity subscribes to the same Zenoh key.
2. If the UUri doesn't include UAuthority, we need to prepend it while transforming UUri into Zenoh key.
   Users should add UAuthority or we can create UAuthority internally in the UPClientZenoh constructor.
   

If we agree on the conclusion, then Zenoh doesn't need to do any access control to the local UUri on Zenoh router and I'll close the issue.
eclipse-zenoh/zenoh#773

Let me know your thoughts. @Mallets @sophokles73 @stevenhartley @PLeVasseur

[Mallets]

A clarification on:

1. We don't need to distinguish the local and remote UUri in the Zenoh key.

From point of view the Zenoh network always operate on remote (i.e. global) UUri. If the uProtocol developer uses a local UUri, then it's the duty of the UPClientZenoh to properly add the UAuthority in such a way at Zenoh level only remote UUri are present. I hope my understanding is correct.

[evshary]

From point of view the Zenoh network always operate on remote (i.e. global) UUri. If the uProtocol developer uses a local UUri, then it's the duty of the UPClientZenoh to properly add the UAuthority in such a way at Zenoh level only remote UUri are present. I hope my understanding is correct.

Correct. This is also my understanding.

[PLeVasseur]

I think this will work with the concept of the uStreamer so long as:

• The uStreamer can be configured to ignore Publish messages from certain authorities, even though uSubscription is saying there's a valid subscription
  • To allow for the use case of where we wish to allow Zenoh to handle the routing from A->B, instead of the uStreamer
• The uStreamer is configured carefully so that we never add a forwarding rule from A->B so that Request, Response, and Notification message forwarding is handled entirely by the Zenoh Router

Here's a (somewhat messy) diagram how I think the routing would look from a Zenoh and uStreamer perspective. Looking to hear your feedback, folks!

(I added some details around uStreamer in here to make sure I've understood how this would work -- this is specifically intended to be checked by @stevenhartley)

flowchart LR

subgraph ide0[Example Topology]

subgraph ide1[UAuthority A: Zenoh]

usub1[\uSubscription\]

str1[[uStreamer]]

subgraph ide2[Sub \n UUri: abc => A/abc]

end

subgraph ide3[Pub \n UUri: abc => A/abc]

end

a1[(Zenoh Router)]

end


subgraph ide4[UAuthority B: Zenoh]

strconf2{{Streamer Config}}

usub2[\uSubscription\]

str2[[uStreamer]]

subgraph ide5[Sub \n UUri: abc => A/abc]

end

a2[(Zenoh Router)]

end

subgraph ide6[UAuthority C: MQTT]

strconf3{{Streamer Config}}

usub3[\uSubscription\]

str3[[uStreamer]]

subgraph ide7[Sub \n UUri: abc => A/abc]

end

end




end

ide3-- Zenoh KeyExpr: up/A/abc -->ide2
ide3-- Zenoh KeyExpr: up/A/abc -->a1
a1-- Zenoh KeyExpr: up/A/abc -->a2
a2-- Zenoh KeyExpr: up/A/abc -->ide5
ide3-- Zenoh KeyExpr: up/A/abc -->str1
str1-- Zenoh KeyExpr: up/A/abc -->str3
usub2-- we ignore incoming \n publishes from A because \n we know that Zenoh will handle that routing -->str2
usub3-- because we have not \n been configured otherwise \n we do route zenoh publishes \n to local subscribers -->str3
usub3-- can obtain the authority A -->ide7
str3-- MQTT5 key equivalent of \n A/abc-->ide7
usub2-- can obtain the authority A -->ide5
ide3-- create topic A/abc -->usub1
strconf2-- we have a UTransport for Zenoh \n but it's set to ignore incoming \n publishes from A \n\n this will avoid unintentionally \n routing any Zenoh messages \n\n we also make sure to set no routes for \n request, response, notification \n between A<->B -->str2
strconf3-- we have a Zenoh UTransport and \n add any routes \n for request, response, notification \n between A<->C \n as only A is zenoh -->str3

[stevenhartley]

I think this will work with the concept of the uStreamer so long as:

• The uStreamer can be configured to ignore Publish messages from certain authorities, even though uSubscription is saying there's a valid subscription

  • To allow for the use case of where we wish to allow Zenoh to handle the routing from A->B, instead of the uStreamer

• The uStreamer is configured carefully so that we never add a forwarding rule from A->B so that Request, Response, and Notification message forwarding is handled entirely by the Zenoh Router

Here's a (somewhat messy) diagram how I think the routing would look from a Zenoh and uStreamer perspective. Looking to hear your feedback, folks!

(I added some details around uStreamer in here to make sure I've understood how this would work -- this is specifically intended to be checked by @stevenhartley)

flowchart LR

subgraph ide0[Example Topology]

subgraph ide1[UAuthority A: Zenoh]

usub1[\uSubscription\]

str1[[uStreamer]]

subgraph ide2[Sub \n UUri: abc => A/abc]

end

subgraph ide3[Pub \n UUri: abc => A/abc]

end

a1[(Zenoh Router)]

end


subgraph ide4[UAuthority B: Zenoh]

strconf2{{Streamer Config}}

usub2[\uSubscription\]

str2[[uStreamer]]

subgraph ide5[Sub \n UUri: abc => A/abc]

end

a2[(Zenoh Router)]

end

subgraph ide6[UAuthority C: MQTT]

strconf3{{Streamer Config}}

usub3[\uSubscription\]

str3[[uStreamer]]

subgraph ide7[Sub \n UUri: abc => A/abc]

end

end




end

ide3-- Zenoh KeyExpr: up/A/abc -->ide2
ide3-- Zenoh KeyExpr: up/A/abc -->a1
a1-- Zenoh KeyExpr: up/A/abc -->a2
a2-- Zenoh KeyExpr: up/A/abc -->ide5
ide3-- Zenoh KeyExpr: up/A/abc -->str1
str1-- Zenoh KeyExpr: up/A/abc -->str3
usub2-- we ignore incoming \n publishes from A because \n we know that Zenoh will handle that routing -->str2
usub3-- because we have not \n been configured otherwise \n we do route zenoh publishes \n to local subscribers -->str3
usub3-- can obtain the authority A -->ide7
str3-- MQTT5 key equivalent of \n A/abc-->ide7
usub2-- can obtain the authority A -->ide5
ide3-- create topic A/abc -->usub1
strconf2-- we have a UTransport for Zenoh \n but it's set to ignore incoming \n publishes from A \n\n this will avoid unintentionally \n routing any Zenoh messages \n\n we also make sure to set no routes for \n request, response, notification \n between A<->B -->str2
strconf3-- we have a Zenoh UTransport and \n add any routes \n for request, response, notification \n between A<->C \n as only A is zenoh -->str3

Couple of comments:

1. registerListener() by the streamer for publish events will only be based on information that is stored in the uSubscription service, mainly what remote subscribers want to receive this published event.
2. Other transport topics will not necessaraly be a mapping directly or even indirectly with A/abc cuz in the case of MQTT, there is only device level topics (in topic and out topic) when MQTT is used as a cloud gateway. If the MQTT is used for local uTransport between uEs, then the topic would be like you mentioned.

BTW, I approve.

[evshary]

@PLeVasseur I'm curious about what the role uSubscription plays in Zenoh scenario.
uStreamer always knows the transport type each uAuthority uses (Zenoh, MQTT...)
Then it can just ignore the message from a certain uAuthority if uStreamer finds that the uAuthority uses the same transport type. uStreamer doesn't need uSubscription in this case.
I know little about the uSubscription, and am trying to understand how Zenoh coordinates with it.

---

It seems like we all agree to the conclusion, so I'll create a PR to update zenoh.adoc later.
After the spec is updated, I'll also update the up-client-zenoh-rust.

[Mallets]

I think this will work with the concept of the uStreamer so long as:

• The uStreamer can be configured to ignore Publish messages from certain authorities, even though uSubscription is saying there's a valid subscription

  • To allow for the use case of where we wish to allow Zenoh to handle the routing from A->B, instead of the uStreamer

• The uStreamer is configured carefully so that we never add a forwarding rule from A->B so that Request, Response, and Notification message forwarding is handled entirely by the Zenoh Router

It looks good to me.

To allow the uStreamer to ignore the publications, I believe it's enough to not let the uStremer calling registerListener() on Zenoh. In that way, Zenoh will take care to not deliver those publications to the uStreamer.
I.e., as @stevenhartley wrote, the uStreamer will call registerListener() only for remote subscriptions.

[stevenhartley]

Merged and closing this issue, thank you @evshary and team!!!