This section defines a preference ordering for relay addresses during the relay discovery process. Gateways are encouraged to implement a Happy Eyeballs [RFC 8305
] algorithm to try candidate relays concurrently (see Section 3.2
), but even gateways that do not implement a Happy Eyeballs algorithm SHOULD
use this ordering, except as noted.
When establishing an AMT tunnel to forward multicast data, it's very important for the discovery process to prioritize network topology considerations ahead of address selection considerations in order to gain the packet replication benefits from using multicast instead of unicast tunneling in the multicast-capable portions of the network path.
The intent of the advice and requirements in this section is to describe how a gateway should make use of the concurrency provided by a Happy Eyeballs algorithm to reduce the join latency while still prioritizing network efficiency considerations over address selection considerations.
of RFC 8305
requires a Happy Eyeballs algorithm to sort the addresses with the Destination Address Selection defined in Section 6
of RFC 6724
, but for the above reasons, that requirement is superseded in the AMT discovery use case by the following considerations:
Prefer Local Relays
Figure 5 and Section 126.96.36.199 provide a motivating example to prefer DNS-SD [RFC 6763] for discovery strictly ahead of using the AMTRELAY RR controlled by the sender for AMT discovery.
For this reason, it's RECOMMENDED that AMT gateways by default perform service discovery using DNS Service Discovery (DNS-SD) [RFC 6763] for _amt._udp.<domain> (with <domain> chosen as described in Section 11 of RFC 6763) and use the AMT relays discovered that way in preference to AMT relays discoverable via the mechanism defined in this document (DRIAD).
Prefer Relays Managed by the Containing Network
When no local relay is discoverable with DNS-SD, it still may be the case that a relay local to the receiver is operated by the network providing transit services to the receiver.
In this case, when the network cannot make the relay discoverable via DNS-SD, the network SHOULD use the well-known anycast addresses from Section 7 of RFC 7450 to route discovery traffic to the relay most appropriate to the receiver's gateway.
Accordingly, the gateway SHOULD by default discover a relay with the well-known AMT anycast addresses as the next-best option after DNS-SD when searching for a local relay.
Let Sender Manage Relay Provisioning
A related motivating example is provided by considering a sender whose traffic can be forwarded by relays in a sender-controlled network like Figure 6 in Section 188.8.131.52 and by relays in a provider-controlled network like Figure 7 in Section 184.108.40.206, with different cost and scalability profiles for the different options.
In this example about the sending-side network, the precedence field described in Section 4.2.1 is a critical method of control so that senders can provide the appropriate guidance to gateways during the discovery process in order to manage load and failover scenarios in a manner that operates well with the sender's provisioning strategy for horizontal scaling of AMT relays.
Therefore, after DNS-SD, the precedence from the RR MUST be used for sorting preference ahead of the Destination Address Selection ordering from Section 6 of RFC 6724 so that only relay IPs with the same precedence are directly compared according to the Destination Address Selection ordering.
Accordingly, AMT gateways SHOULD
by default prefer relays in this order:
Anycast addresses from Section 7 of RFC 7450
This default behavior MAY
be overridden by administrative configuration where other behavior is more appropriate for the gateway within its network.
Among relay addresses that have an equivalent preference as described above, a Happy Eyeballs algorithm for AMT SHOULD
use the Destination Address Selection defined in Section 6
of RFC 6724
Among relay addresses that still have an equivalent preference after the above orderings, a gateway SHOULD
make a non-deterministic choice (such as a pseudorandom selection) for relay preference ordering in order to support load balancing by DNS configurations that provide many relay options.
The gateway MAY
introduce a bias in the non-deterministic choice according to information that indicates expected benefits from selecting some relays in preference to others. Details about the structure and collection of this information are out of scope for this document but could, for example, be obtained by out-of-band methods or from a historical record about network topology, timing information, or the response to a probing mechanism. A gateway in possession of such information MAY
use it to prefer topologically closer relays.
Within the above constraints, gateways MAY
make use of other considerations from Section 4
of RFC 8305
, such as the address family interleaving strategies, to produce a final ordering of candidate relay addresses.
Note also that certain relay addresses might be excluded from consideration by the hold-down timers described in Section 220.127.116.11
]. These relays constitute "unusable destinations" under Rule 1 of the Destination Address Selection and are also not part of the superseding considerations described above.
The discovery and connection process for the relay addresses in the above described ordering MAY
operate in parallel, subject to delays prescribed by the Happy Eyeballs requirements described in Section 5
of RFC 8305
for successively launched concurrent connection attempts.
In some deployments, it may be useful for a gateway to connect to multiple upstream relays and subscribe to the same traffic in order to support an active/active failover model. A gateway SHOULD NOT
be configured to do so without guaranteeing that adequate bandwidth is available.
A gateway configured to do this SHOULD
still use the same preference-ordering logic from Section 3.1.2
for each connection. (Note that this ordering allows for overriding by explicit administrative configuration where required.)