Configuring Realm Routing

This section describes the default Realm Routing behavior.

Routing Hierarchy

Default Routing and Realm Routing Table entries are considered in priority between relays in the target realm and relays in the local realm. For a default routed Request with no Destination-Host AVP, the following categories of destinations are considered in the following order:

1. nodes in the target realm that advertise support for the Request's Application ID
   
   
2. relays in the target realm
   
   
3. relays in realms that the realm routing table shows as routes to a target realm, least cost first
   
   
4. relays in the local realm

For a default routed Request with a Destination-Host AVP with value X, the following categories of destinations are considered in the following order:

1. X, in the target realm, if it advertised, supports for the Request's Application ID
   
   
2. relays in the target realm
   
   
3. relays in realms that the realm routing table shows as routes to a target realm, least cost first
   
   
4. relays in the local realm

These considerations mean that relays in the target realm are always considered as a higher priority than entries in the Realm Routing Table.

Interpreting Realm Routing Tables

The Realm Routing Table provides a concise way to indicate which relays should be considered as a viable next hop to a different realm. If an Adjacent Realm X is listed in a record to reach a Remote Realm Y, then any relay in X is considered as a viable next hop for a Request with Destination-Realm AVP Y. The following two record types are supported:

• VALUE records that indicate Adjacent Realms for specific Remote Realms
  
  
• DEFAULT records that are used when there is no matching VALUE record.

DEFAULT records are not considered as lower priority VALUE records. If a matching VALUE record exists for a Request, DEFAULT records are not considered even as alternate routes.

Among VALUE records with Remote Realm Y, records with lower cost are preferred over records with higher cost. Records with equal cost use load-balancing. Cost is treated similarly for DEFAULT records.

Ingress Filtering checks whether Requests are received from unexpected Adjacent Realms. An Adjacent Realm is "unexpected" if it is not in the list of Adjacent Realms when the Request's Origin-Realm AVP O is looked up in the Realm Routing Table as a Remote Realm. The Ingress Filtering check uses the same lookup logic as routing checks, so if a VALUE record exists with Remote Realm O, DEFAULT records are not considered.

To allow a message to pass Ingress Filtering, but not consider the record for Request routing, use the special cost INCOMING ONLY. This cost can be used for VALUE and DEFAULT records.

Provisioning Realm Routing Tables

If a VALUE record with Y is created as a Remote Realm, add all viable adjacent realms as VALUE records. 

To remove a remote realm R from consideration by some default routes, use VALUE records to route to Remote Realm R.

To remove a remote realm R from consideration by all default routes, create a VALUE record with Remote Realm R and a non-existent adjacent realm such as nodefault.example.com. The effect is to no longer consider the default routes for messages with Destination-Realm AVP R.

Realm Routing Examples

The following are examples for Realm Routing.

The dea.local.com node communicates directly with dea.a.com and dea.b.com (see the following figure); these connections are only used to transmit traffic to their respective realms. A connection can be made to ipx1.x.com to access a2.com and b2.com. The ipx2.y.com is used for all other traffic and as a backup route to b.com and b2.com. The ipx3.z.com is a backup route to other remote realms.

Adjacent Nodes Remote Realm Connectivity Example

The routing to a.com through dea.a.com is implicit (dea.a.com is a relay in the target realm) and is of higher priority than all records in the realm routing table. Similarly for b.com, dea.b.com is a relay in the target realm.

The corresponding routing table might look as follows:

To further allow ipx2.y.com to send Requests with Origin-Realm AVP a.com to dea.local.com, without considering it as a route, add the following:

To remove remote realm q.com from the DEFAULT routes (in this case, making it unrouteable), add a route through a non-existent adjacent realm (Adjacent Realm can be set to any realm that is not the realm of an ADN, nodefault.example.com is arbitrary):

Summarizing the preceding information in one table is as follows:

Using the preceding Realm Routing Table, consider the candidates for messages with various Destination-Host AVPs. For completeness, we indicate relays in the target realm although they are not entered explicitly in the Realm Routing Table.

A Request with Destination-Realm AVP a.com uses dea.a.com as the preferred next AVP. If dea.a.com is unavailable, there is no backup route. Requests with Origin-Realm AVP a.com pass Ingress Filtering if they are received from dea.a.com and from ipx2.y.com.

A Request with Destination-Realm AVP b.com uses dea.b.com as the preferred next hop. If dea.b.com is unavailable, ipx2.y.com is used as a backup route. Requests with Origin-Realm b.com pass Ingress Filtering if they are received from dea.b.com or from ipx2.y.com.

A Request with Destination-Realm AVP x.com uses ipx1.x.com as the preferred next hop. Because there is no VALUE record with x.com as a Remote Realm, the DEFAULT records are used as backup routes, so ipx2.y.com and ipx3.z.com are backup routes (in that order, because of cost). Requests with Origin-Realm AVP x.com pass Ingress Filtering if they are received from ipx1.x.com, ipx2.y.com or ipx2.z.com.

A Request with Destination-Realm AVP a2.com uses ipx1.x.com as the only next hop, if ipx1.x.com is unavailable there is no backup route. Requests with Origin-Realm AVP a2.com pass Ingress Filtering if they are received from ipx1.x.com.

A Request with Destination-Realm AVP b2.com uses ipx1.x.com as preferred next hop, with ipx2.y.com as the backup route. Requests with Origin-Realm AVP b2.com pass Ingress Filtering if they are received from ipx1.x.com or ipx2.y.com.

A Request with Destination-Realm AVP q.com does not use default routing and hence has no routing candidates. Requests with Origin-Realm AVP q.com do not pass Ingress Filtering.

A Request any other Destination-Realm AVP r.com uses the DEFAULT routes, hence, has ipx2.y.com as the preferred route and ipx3.z.com as the backup route. Requests with Origin-Realm AVP r.com pass Ingress Filtering if they are received from ipx2.y.com or ipx3.z.com.

Summarizing the preceding information in a table, the following are the results for routing and for Ingress Filtering: