AW: [amqp] Global addressing model - brain dump

[Clemens Vasters <clemensv@microsoft.com>]

 

 

On Fri, Oct 5, 2018 at 9:33 AM Ted Ross <tross@redhat.com> wrote:

 

On Fri, Sep 14, 2018 at 6:04 AM Clemens Vasters <clemensv@microsoft.com> wrote:

For the Management spec I also need the Addressing spec to make progress, so Iâm now taking a fresh look at this.

 

From the F2Fs I recall that our biggest holdup was that weâve got tension between several distinct goals for addressing expressions:

a.      An address _expression_ should enable a âclientâ to find a âserverâ on an IP network to establish an AMQP TLS-first (5671) or TLS-upgrade (5672) connection, establish link(s) and transfer messages. The address _expression_ therefore needs to hold DNS/IP/TCP addressing information, a protocol selector, and a link target.

b.      An address _expression_ should enable a âsenderâ to have messages routed to a âreceiverâ inside a (yet poorly defined) AMQP network and fully abstracting the underlying IP layer, whereby the âreceiverâ address is a logical construct that doesnât contain network-related information. With such an address, it should be possible to find the receiving container (and node) by ways of:

a.      resolving the logical address to container name/location OR

b.      evaluating routing rules based on filter expressions that indirectly yield a container location

c.       An address _expression_ should enable a âsenderâ to route messages to a âreceiverâ inside a singular AMQP container, where address expressions correspond directly to node names inside of said container.

 

We also have amqp/amqps URIs being used in the wild based on the current draft and I donât want to break those.

 

Hereâs a proposal for an extended URI format that aims to hit all the goals at once:

 

{ amqp | amqps } : [ //user:key@ip-endpoint/ ] [ (container-name)/ ] [ [$] node-path ]

 

Iâll start the explanation with examples, because theyâll probably tell a whole lot of the story already:

        amqps://broker.example.com/queue1 â DNS qualified address of a TCP/IP endpoint of an AMQP container with path for the âqueue1â AMQP node

        amqp:(london-branch-34)/atm â Logical AMQP network address of âlondon-branch-34â with path for the âatmâ AMQP node

        amqps://megabank.example.com/(london-branch-34)/atm â DNS qualified address of a âgatewayâ into an AMQP network, with logical AMQP network address as suffix

        amqp:()/control â Anonymous AMQP network address to be resolved into a container location by evaluating message metadata, with path for the âcontrolâ node on the resulting container

        somewhere â Local container address of the âsomethingâ AMQP node

        $somewhere â AMQP reserved local container address

 

To start, Iâm splitting up the AMQP notion of container into two distinct concepts: âgatewayâ and âcontainerâ.

        A gateway is a TCP/IP listener that speaks the AMQP wire protocol. Clients establish connections and sessions with gateways. Gateways are onramps into AMQP networks.

        A container is a host for AMQP nodes. Multiple containers may be interrelated (and opportunistically interconnected) to form a logical network, with lookup mechanisms that allow resolving logical names to specific containers.

        Each container MUST have a gateway. Each configured relationship between containers holds information about which gateway ought to be used to reach the respective container. The configured destination gateway for any container MAY, however, be an intermediary, meaning it might take one or more further network resolution/routing steps to reach the destination container.

        Not all gateways have to be containers. A gateway can just do connection/session handling and never host nodes and/or take ownership of links; it might be a pure relay bridging sessions to another gateway.

 

If an endpoint is connected to a gateway that is not a container, what will the container-id field in the OPEN frame hold?

 

A TCP router or an Envoy TCP proxy are examples of such a gateway - although without any AMQP-specific smarts. They tunnel an entire connection thru to an AMQP peer. I'm not sure how such a gateway could do more complex AMQP-specific routing (like redirecting sessions or links to multiple back-ends) without fabricating a container-id to the the inbound connection -  in which case it would seem that it does have to be a container (or many containers)

 

 

[Clemens Vasters] I donât think you can connect (in the AMQP sense) to a gateway that has no explicit or implicit association with a container. When you connect to a gateway via TCP, you end up at a container and the container tells you its name as it responds to open. The container-id in open is documented as the frame source, not target.

 

The container information in the URI is routing information for when the container the client learns about in open is not the expected container. In that case, the container qualified URI goes into the link target address or into âtoâ (anon terminus) for further resolution by âinternal meansâ, which might result in the link/route be patched through further.