2.6.15.10.7.3 Congestion-Aware Route Lists

The DSR can use the congestion information in the TTGs to skip Route Groups in the Route List that do not meet threshold criteria for their congestion status. A typical use for skipping congested Route Groups is to prevent a DSR that can’t handle traffic itself due to congestion from sending that traffic to a mate DSR that is just as overloaded already.

When defining a Route List two new optional parameters are part of each Route Group:

• The TTG data associated with that Route Group.
• A threshold for the maximum acceptable loss before that Route Group is skipped.

Logically the new threshold functions just like the current “Minimum Route Group Availability Weight”, in that it causes the Route List to skip to the priority Route Group.

The figure below shows an example of the Route Group provisioning within a Route List, and the logic used to evaluate that data. There is an action associated with the Routing Option Set called the Routing Congestion Action. This is the action that is taken if all of the Route Groups in the Route List are skipped because they didn’t meet the congestion thresholds. Note that the existing action is taken if the Route List successfully selects any of the Route Groups, but then fails to route the request anyway. Like all ROS actions, the Routing Congestion action allows the user to specify whether the answer should be abandoned, or if an error answer is set, what the error should be. This new congestion-related error leg can be used to return an experimental error number indicating a congestion failure.

Figure 2-33 Congestion-Aware Route List Logic

The figure below gives an example of using these thresholds. In DSR 1 there are two Route Groups that can handle S6b initial requests, a primary one (RG1) and a secondary one (RG2). If neither of those Route Groups can handle the request, then the customer wants to try sending the requests to the mate DSR, DSR 2. Since RG1 and RG2 are local to the DSR, they have corresponding TTGs, DSR1_S6b and DSR1_2_S6b. However, to send S6b traffic to the mate DSR there isn’t a dedicated S6b Route Group, just RG3 which represents the connections to the mate. The TTG associated with RG3 in the Route List is then the TTG of the target resources on the mate, in this case TTG DSR2_S6b. This works because when the DSR is deciding whether or not to route traffic to the mate, it doesn’t care about the congestion status of the route group to get the DSR (that will be handled by ETGs for instance), it cares whether the S6b handling resources on the mate are congested or not.

Figure 2-34 Congestion-Aware Route List Example 1

The next figure shows the evaluation logic for this example. Since the TTG currently has a higher loss (90%) than the threshold for RG1 (Max Loss % = 80%), the Route List skips RG1 and goes directly to evaluating RG2. Since the loss and rate thresholds for RG2 are acceptable, the RL sends the request to RG2.

Figure 2-35 Congestion-Aware Route List Logic Example 1a

The next figure shows what happens when none of the Route Groups meets their minimum threshold. In this case all three Route Groups are skipped, and the action defined in the new “Routing Congestion Action” in the Routing Option Set is executed. Like the other actions defined in the ROS, this new action can either abandon the answer, or return a user-configured error number, error text and vendor ID. This action is only taken when the request skips all of the available Route Groups due to not meeting the Max % Loss threshold. If no Route Group is found due to other reasons, such as a Route Group was selected, but it couldn’t handle the request, then all of the existing error legs are used as appropriate.

Figure 2-36 Congestion-Aware Route List Logic Example 1b