Dynamic load balancing of network traffic on a multi-path label switched path using resource reservation protocol with traffic engineering

Patent metadata

Field	Value
Publication number	US-9923798-B1
Application number	US-201213536757-A
Country	US
Kind code	B1
Filing date	Jun 28, 2012
Priority date	Jun 28, 2012
Publication date	Mar 20, 2018
Grant date	Mar 20, 2018

Abstract

Techniques are describe for establishing an overall label switched path (LSP) for dynamic load balancing of network traffic being sent across a network using the a resource reservation protocol such as Resource Reservation Protocol with Traffic Engineering (RSVP-TE). The tunnel may be a single RSVP-TE Label Switched Path (LSP) that is configured to automatically and dynamically load balance network traffic across different sub-paths of the RSVP-TE LSP over the network. The ingress device of the overall multi-path LSP can analyze traffic statistics to determine when a network traffic demand differs from a currently reserved bandwidth of the overall multi-path LSP by at least a threshold amount, and can automatically add or remove a sub-path from the overall multi-path LSP to adjust capacity of the overall multi-path LSP to correspond to the currently reserved bandwidth.

First claim

The invention claimed is:

1. A method comprising:
by an ingress device, establishing an overall multi-path label switched path (LSP) from the ingress device to an egress device, wherein the overall multi-path LSP includes a plurality of different sub-paths to the egress device that satisfy a traffic-engineering constraint, wherein each of the sub-paths comprises a sub-LSP of the overall multi-path LSP, and wherein at least two of the sub-paths traverse different sets of nodes within a network between the ingress device and the egress device;
forwarding received network traffic to the egress device over the overall multi-path LSP by load balancing the network traffic across the sub-paths of the overall multi-path LSP;
by the ingress device, analyzing traffic statistics for network traffic received at the ingress device on a tunnel interface associated with the overall multi-path LSP;
determining, by the ingress device, based on the analysis of the traffic statistics, that a network traffic demand detected by the ingress device on the tunnel interface differs from a currently reserved bandwidth of the overall multi-path LSP by at least a threshold amount; and
in response to the determining, by the ingress device, automatically adding a sub-path to or removing a sub-path from the plurality of different sub-paths of the overall multi-path LSP to adjust capacity of the overall multi-path LSP to correspond to the network traffic demand.

2. The method of claim 1 , wherein the traffic-engineering constraint includes a bandwidth requirement for the overall multi-path LSP, wherein a sum of bandwidth reserved along each of the sub-paths satisfies the bandwidth requirement for the overall multi-path LSP.

3. The method of claim 1 , further comprising re-signaling one or more of the plurality of sub-paths of the overall multi-path LSP to adjust an amount of currently reserved bandwidth on the sub-paths based on the network traffic demand.

4. The method of claim 1 , wherein adding a sub-path comprises sending a resource reservation request along the sub-path to be added, wherein the resource reservation request includes the identifier associating the request with the same overall multi-path LSP, and wherein the resource reservation request includes an indicator specifying the overall multi-path LSP as a load-balancing LSP.

5. The method of claim 1 , wherein removing a sub-path comprises sending a resource reservation PathTear message to tear down the sub-path, wherein the PathTear message includes the identifier associating the request with the same overall multi-path LSP, and wherein the PathTear message includes a sub-path identifier that identifies the sub-path to be removed.

6. The method of claim 1 , wherein analyzing the traffic statistics comprises analyzing a rate of data traffic received for the tunnel interface associated with the overall multi-path LSP.

7. The method of claim 1 , wherein analyzing the traffic statistics comprises analyzing a maximum average traffic demand measured on the tunnel interface during a time interval.

8. The method of claim 1 , wherein analyzing the traffic statistics comprises analyzing the traffic statistics at configured time intervals.

9. The method of claim 1 , further comprising receiving configuration information specifying loading preferences that indicate a percent of available bandwidth capacity of each of the sub-paths of the overall multi-path LSP that should be utilized for the overall multi-path LSP before adding additional sub-paths.

10. The method of claim 9 , further comprising, by the ingress router, in response to determining that the plurality of sub-paths of the overall multi-path LSP do not have sufficient available bandwidth to accommodate the network traffic demand without going beyond the loading preferences, adding one or more sub-paths to the plurality of sub-paths of the overall multi-path LSP.

11. The method of claim 9 , further comprising:
by the ingress router, in response to determining that to decrease currently reserved bandwidth on each of the plurality of sub-paths of the overall multi-path LSP to adjust to a network traffic demand below the currently reserved bandwidth will result in each of the plurality of sub-paths having too little bandwidth with respect to the loading preferences, deleting one or more sub-paths from the plurality of sub-paths of the overall multi-path LSP.

12. The method of claim 1 , wherein the traffic-engineering constraint comprises one or more of bandwidth, link color, and Shared Risk Link Group (SRLG), latency, number of hops, and geographic location.

13. The method of claim 1 , wherein establishing the overall multi-path LSP comprises giving preference to sub-paths having lower latency when selecting sub-paths of the overall multi-path LSP from among a plurality of possible sub-paths.

14. The method of claim 1 , wherein establishing the overall multi-path LSP comprises giving preference to sub-paths having a lower number of hops when selecting sub-paths of the overall multi-path LSP from among a plurality of possible sub-paths.

15. The method of claim 1 , further comprising receiving automatic bandwidth configuration parameters comprising one or more of a minimum bandwidth amount for the overall multi-path LSP, a maximum bandwidth amount for the overall multi-path LSP, an adjustment threshold, an adjustment interval, and a sampling interval.

16. The method of claim 1 , further comprising re-signaling one or more of the plurality of sub-paths of the overall multi-path LSP to adjust an amount of currently reserved bandwidth on the sub-paths based on the different traffic demand.

17. The method of claim 1 , further comprising:
configuring a forwarding plane of the ingress device to store allocated labels and corresponding next hops for the sub-paths of the overall multi-path LSP;
configuring the forwarding plane with load balancing requirements that specify how network traffic is to be load-balanced across the sub-paths of the overall multi-path LSP;
receiving network traffic at the ingress device of the overall multi-path LSP;

in the forwarding plane of the ingress device, load balancing the network traffic across the sub-paths by selecting from among the stored labels and corresponding next hops for forwarding the network traffic in accordance with load balancing requirements; and
forwarding the network traffic with the selected labels onto sub-paths of the overall multi-path LSP.

18. The method of claim 1 , wherein the network traffic comprises packets associated with a plurality of packet flows destined for the egress device of the overall multi-path LSP, wherein load balancing the network traffic across the sub-paths comprises applying flow-level load balancing to the received network traffic.

19. The method of claim 1 , wherein load balancing the network traffic comprises applying a hash function to a portion of a packet of the network traffic, and accessing a hash map based on the hash function to determine a Multiprotocol Label Switching (MPLS) label to apply to the packet and an output interface from which to output the packet.

20. The method of claim 1 , further comprising load balancing the network traffic across the sub-paths without re-ordering packets in packet flows of the network traffic.

21. The method of claim 1 , further comprising enforcing a maximum number of the sub-paths in the overall multi-path LSP.

22. The method of claim 1 , further comprising:
evaluating the

Assignees

• Bahadur Nitin
• Kompella Kireeti
• Juniper Networks Inc

Inventors

• Bahadur Nitin
• Kompella Kireeti

Classifications

• H04L45/00 Primary

  Routing or path finding of packets in data switching networks (routing or path finding in wireless networks H04W40/00) · CPC title

• H04L45/24 Primary

  Multipath · CPC title

• H04L45/125

  based on throughput or bandwidth · CPC title

• H04L45/50

  using label swapping, e.g. multi-protocol label switch [MPLS] · CPC title