What Is Inter-AS Bandwidth Pooling?

Dual-Core Single-homed Networking

On the network shown in the following figure, DeviceA and DeviceB on the MAN respectively establish EBGP peer relationships with DeviceC and DeviceD on the backbone network through loopback interfaces. Multiple physical links exist between the EBGP peers, and routes of the MAN are advertised to the backbone network through EBGP. Assume that DeviceA and DeviceC are on the upper plane, and DeviceB and DeviceD are on the lower plane. Traffic is load balanced between ASs and distributed equally to DeviceA and DeviceB.

Dual-core single-homed networking

Dual-Core V-shaped Networking

On the network shown in the following figure, DeviceA and DeviceB on the MAN establish EBGP peer relationships with DeviceC and DeviceD on the backbone network through loopback interfaces. Multiple physical links exist between the EBGP peers, and routes of the MAN are advertised to the backbone network through EBGP. Assume that DeviceA-DeviceC and DeviceB-DeviceC are on the upper plane, and DeviceA-DeviceD and DeviceB-DeviceD are on the lower plane. DeviceC supports UCMP and implements load balancing based on the bandwidth ratio between DeviceA-DeviceC and DeviceB-DeviceC. The same applies to DeviceD. Traffic is load balanced between ASs and distributed equally to MAN devices.

Dual-core V-shaped networking

Dual-Core Single-homed Networking

If only some links between DeviceA and DeviceC fail or encounter traffic bursts, BGP routes remain unchanged because the EBGP peer relationships between the two devices are not disrupted. In this case, the backbone network cannot detect the faults and thus cannot automatically adjust the load balancing ratio. As a result, traffic congestion occurs between DeviceA and DeviceC, leading to packet loss or increased delay.

BGP EPE is configured on DeviceA and DeviceB for their EBGP peers so that the link status, bandwidth, and bandwidth usage can be obtained and BGP-LS link routes can be generated. Between DeviceA and DeviceB, a BGP-LS address family peer relationship is established to transmit link information, and a BGP RPD address family peer relationship is established to exchange export policy information. Export policies are applied to the IPv4 public network unicast routes to be advertised by DeviceA and DeviceB to their EBGP peers. In this manner, route priorities are controlled for route selection. For example, a route-policy is configured on DeviceA to change the MED value and extend the AS_Path attribute.

Assume that the upper plane's total bandwidth is X and bandwidth usage is a, and that the lower plane's total bandwidth is Y and bandwidth usage is b. In this case, the bandwidth ratio (λ) is X/Y.

Dual-core single-homed networking

The fundamentals involved in the dual-core single-homed networking are as follows:

1. DeviceA and DeviceB respectively obtain the incoming traffic information corresponding to the routes sent to DeviceC and DeviceD. DeviceA and DeviceB then determine whether to adjust traffic.
2. Use DeviceA as an example. If some links on the upper plane fail or encounter traffic bursts and the following conditions are met, traffic adjustment starts:
   • Some links on the upper plane fail but the EBGP peer relationships between DeviceA and DeviceB are not disrupted, or traffic bursts occur on the upper plane, leading to congestion (a ≥ 90%, which is the congestion threshold in this example).
   • The lower plane has room for traffic adjustment (b < a – 20%, which is the relative adjustment difference in this example) and is not congested (b < 90%).
3. Assume that the total volume of traffic to be adjusted on DeviceA is Z and that the traffic adjustment target is (aX – Z)/(bY + Z) = λ. In this case, Z can be calculated. DeviceA generates a traffic optimization policy based on the bandwidth, bandwidth usage, and traffic information corresponding to the RIB-out routes that it sends to DeviceC. DeviceA sorts the prefixes of the routes sent to DeviceC in descending order of the incoming traffic volume and removes the prefixes with the bandwidth ratio greater than the relative adjustment difference. It then selects the routes whose total traffic volume is less than or equal to Z as the routes to be adjusted, and adds them one by one to the traffic optimization policy set that is used for traffic adjustment from the upper plane to the lower plane.
4. DeviceA generates an RPD route based on the pre-configured route-policy and each prefix to be adjusted and reduces the priority of the route that it sends to DeviceC.
5. DeviceA periodically checks whether the conditions for triggering traffic adjustment are met. If they are, DeviceA repeats steps 3 and 4 for traffic adjustment. Otherwise, it does not trigger traffic adjustment.
6. DeviceA periodically checks whether the following conditions for triggering traffic restoration are met (if they are, DeviceA starts to restore traffic):
   • DeviceA has locally generated RPD routes.
   • The congestion on DeviceA is relieved (a < 90% – 20%), or DeviceB is congested (b > 90%, a < b – 20%).
7. After the preceding process is complete, the priorities of some routes received by DeviceC and DeviceD change, and the route received by DeviceD is preferentially selected on the backbone network. Traffic forwarding paths are then adjusted.
   

   To prevent DeviceA and DeviceB from adjusting traffic at the same time, only one of them (the one with a smaller router ID) is allowed to adjust traffic at any given moment.

Dual-Core V-shaped Networking

If only some links between DeviceA and DeviceC fail or encounter traffic bursts, BGP routes remain unchanged because the EBGP peer relationships between the two devices are not disrupted. In this case, the backbone network cannot detect the faults and thus cannot automatically adjust the load balancing ratio. As a result, traffic congestion occurs between DeviceA and DeviceC, leading to packet loss or increased delay.

BGP EPE is configured on DeviceA and DeviceB for their EBGP peers so that the link status, bandwidth, and bandwidth usage can be obtained and BGP-LS link routes can be generated. In addition, BGP RPD and BGP-LS address family peer relationships are established between DeviceA and DeviceB, and a route-policy is configured on DeviceA.

Assume that the total bandwidth and bandwidth usage are X1 and a1 between DeviceA and DeviceC, X2 and a2 between DeviceA and DeviceD, Y1 and b1 between DeviceB and DeviceC, and Y2 and b2 between DeviceB and DeviceD, respectively. The bandwidth ratio (λ) is (X1 + Y1)/(X2 + Y2).

Dual-core V-shaped networking

The fundamentals involved in the dual-core V-shaped networking are as follows:

1. DeviceA and DeviceB obtain the incoming traffic information corresponding to the routes sent to DeviceC and DeviceD and then determine whether to adjust traffic.
2. Use DeviceA as an example. If some links between DeviceA and DeviceC fail or encounter traffic bursts and the following conditions are met, traffic adjustment starts:
   • Some links between DeviceA and DeviceC fail and the EBGP peer relationships between them are not disrupted or traffic bursts occur, leading to a congestion (a1 ≥ 90%). Because DeviceC supports UCMP, traffic is preferentially adjusted on the upper plane. As a result, both a1 and b1 are not less than 90%.
   • The lower plane has room for traffic adjustment (a2 < a1 – 20%, b2 < b1 – 20%) and is not congested (a2 < 90%, b2 < 90%).
   • DeviceA does not have RPD routes that are originated from DeviceB and affect the priority of the routes advertised by DeviceA to its EBGP peers.
   • The router ID of DeviceA is smaller than that of DeviceB.
3. Assume that the total volume of local traffic to be adjusted on DeviceA is Z1 and that the total volume of traffic to be adjusted on DeviceB is Z2. Also assume that Z1/Z2 = X1/Y1 and that the traffic adjustment target is (a1X1 + b1Y1 – Z1 – Z2)/(a2X2 + b2Y2 + Z1 + Z2) = λ. In this case, Z1 and Z2 can be calculated. DeviceA sorts the prefixes of the routes sent to DeviceC in descending order of the incoming traffic volume. It then removes the prefixes with the bandwidth ratio greater than the relative adjustment difference and selects the routes whose total traffic volume is less than or equal to Z1 as the routes to be adjusted. Finally, DeviceA adds the routes one by one to the traffic optimization policy set that is used for traffic adjustment from the upper plane to the lower plane.
4. Based on the preset policy and each prefix to be adjusted, DeviceA generates an RPD route to reduce the priority of the route to be sent to DeviceC. In addition, DeviceA sends the RPD route to DeviceB, which then reduces the priority of the route to be sent to DeviceC.
5. DeviceA periodically checks whether the conditions for triggering traffic adjustment are met. If they are, DeviceA repeats steps 3 and 4 for traffic adjustment. Otherwise, it does not trigger traffic adjustment.
6. DeviceA periodically checks whether the following conditions for triggering traffic restoration are met (if they are, DeviceA starts to restore traffic):
   • DeviceA has locally generated RPD routes.
   • The congestion on the upper plane is relieved (a1 < 90% – 20% and b1 < 90% – 20%) or the lower plane meets the optimization conditions (a2 > 90%, b2 > 90%, a1 < a2 – 20%, b1 < b2 – 20%).
7. After the preceding process is complete, the priorities of some routes received by DeviceC and DeviceD change, and the route received by DeviceD is preferentially selected on the backbone network. Traffic forwarding paths are then adjusted.
   

   To prevent DeviceA and DeviceB from adjusting traffic at the same time, only one of them (the one with a smaller router ID) is allowed to adjust traffic at any given moment.

   If the connection between DeviceA and an EBGP peer is interrupted during traffic adjustment, DeviceA exits the traffic adjustment process and withdraws the generated RPD routes. If the congestion persists, DeviceB adjusts traffic.