CA2354353C - Network resource allocation methods and systems - Google Patents
Network resource allocation methods and systems Download PDFInfo
- Publication number
- CA2354353C CA2354353C CA002354353A CA2354353A CA2354353C CA 2354353 C CA2354353 C CA 2354353C CA 002354353 A CA002354353 A CA 002354353A CA 2354353 A CA2354353 A CA 2354353A CA 2354353 C CA2354353 C CA 2354353C
- Authority
- CA
- Canada
- Prior art keywords
- connection
- weighted
- link
- links
- metric
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0896—Bandwidth or capacity management, i.e. automatically increasing or decreasing capacities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
- H04L41/5003—Managing SLA; Interaction between SLA and QoS
- H04L41/5019—Ensuring fulfilment of SLA
- H04L41/5022—Ensuring fulfilment of SLA by giving priorities, e.g. assigning classes of service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
- H04L45/123—Evaluation of link metrics
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/302—Route determination based on requested QoS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/829—Topology based
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
- H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
Abstract
Methods and components are provided which ensure both the improved use of network resources and adequate performance of best effort (BE) traffic by intelligently distributing the BE traffic demands at connection level with corresponding scaling weights, and without reserving bandwidth. A weighted sum of the best effort (BE) class connections (or LSPs in MPLS context) in a link is used as a path selection criterion, where each BE connection is weighted by its service volume. Path selection for a requested BE
service volume is performed by creating a virtual topology in which all links in a network have weighted BE metrics updated to include the effects of the requested BE service volume, and identifying a best path through the virtual topology taking into account the weighted BE metrics.
service volume is performed by creating a virtual topology in which all links in a network have weighted BE metrics updated to include the effects of the requested BE service volume, and identifying a best path through the virtual topology taking into account the weighted BE metrics.
Description
.' 78945-14 Network Resource Allocation Methods and Systems Field of the Invention The invention relates to network resource allocation methods and systems, and more particularly to methods and systems of allocating resources to low priority traffic, such as best effort traffic.
Background of the Invention In current IP (Internet Protocol) networks, packet forwarding is based on connectionless and destination-based SPF
(Shortest Path First) routing mechanisms and also in the best effort manner. As a result of this, some links can be heavily utilized and congested while others remain idle, resulting in non-optimal use of network wide resources and poor packet performance. As a remedy to this problem, the explicit routing capability of MPLS (Multi Protocol Label Switching) is being employed to redirect traffic toward under-utilized parts of the network (1,2]. Such a practice is generally termed ~~traffic engineering."
Different levels of QoS (Quality of Service) can also be supported by MPLS explicit LSP (Label Switched Path) setup coupled with constraint based routing protocols (e.g., OSPF-TE
(Open Shortest Path First - Traffic Engineering) or ISIS-TE
(Intermediate System to Intermediate System Routing exchange Protocol - Traffic Engineering). In such mechanisms, the bandwidth for a certain service class is explicitly reserved along the path, and the link usage information is updated for CAC (Connection Admission Control) purpose. However, in general, BE (Best Effort) class traffic is not associated with any bandwidth reservation, i.e., CIR (Committed Information Rate) - 0, hence no performance guarantee.
Background of the Invention In current IP (Internet Protocol) networks, packet forwarding is based on connectionless and destination-based SPF
(Shortest Path First) routing mechanisms and also in the best effort manner. As a result of this, some links can be heavily utilized and congested while others remain idle, resulting in non-optimal use of network wide resources and poor packet performance. As a remedy to this problem, the explicit routing capability of MPLS (Multi Protocol Label Switching) is being employed to redirect traffic toward under-utilized parts of the network (1,2]. Such a practice is generally termed ~~traffic engineering."
Different levels of QoS (Quality of Service) can also be supported by MPLS explicit LSP (Label Switched Path) setup coupled with constraint based routing protocols (e.g., OSPF-TE
(Open Shortest Path First - Traffic Engineering) or ISIS-TE
(Intermediate System to Intermediate System Routing exchange Protocol - Traffic Engineering). In such mechanisms, the bandwidth for a certain service class is explicitly reserved along the path, and the link usage information is updated for CAC (Connection Admission Control) purpose. However, in general, BE (Best Effort) class traffic is not associated with any bandwidth reservation, i.e., CIR (Committed Information Rate) - 0, hence no performance guarantee.
- 2 -ECMP (Equal Cost Multi-Path) routing [1] allows flow (e. g., packets with same source and destination IP addresses) or packet level load balancing, but this does not employ the concept of explicit routing.
Typically, explicit routing is a three step process.
First, a topology database is maintained which identifies network topology, typically by identifying nodes and links between nodes. IGP (Internal Gateway Protocol) for example, provides such network topologies. A scalar metric or metrics is associated with each link, for example in accordance with OSPF-TE. Then, signalling is employed in the network to reserve resources between a source and a destination, for example employing the RSVP-TE (Resource ReSerVation Protocol -Traffic Engineering) protocol. After resources have been successfully reserved, label distribution is performed to set up the actual label switched paths between the source and destination.
Summary of the Invention This invention provides a novel mechanism to ensure both the improved use of network resources and adequate performance of best effort (BE) traffic by intelligently distributing the BE traffic demands at connection level with corresponding scaling weights, and without reserving bandwidth.
A weighted sum of the best effort (BE) class connections (or LSPs in MPLS context) in a link is used as a path selection criterion, where each BE connection is weighted by its service volume ( for example lOMbps may be assigned an integer value of 10, while lOGbps is to 10,000).
Preferably, the traffic engineering extension of IGP
(Internal Gateway Protocol) such as OSPF-TE is adapted to advertise the weighted sum of BE connections as one of the link
Typically, explicit routing is a three step process.
First, a topology database is maintained which identifies network topology, typically by identifying nodes and links between nodes. IGP (Internal Gateway Protocol) for example, provides such network topologies. A scalar metric or metrics is associated with each link, for example in accordance with OSPF-TE. Then, signalling is employed in the network to reserve resources between a source and a destination, for example employing the RSVP-TE (Resource ReSerVation Protocol -Traffic Engineering) protocol. After resources have been successfully reserved, label distribution is performed to set up the actual label switched paths between the source and destination.
Summary of the Invention This invention provides a novel mechanism to ensure both the improved use of network resources and adequate performance of best effort (BE) traffic by intelligently distributing the BE traffic demands at connection level with corresponding scaling weights, and without reserving bandwidth.
A weighted sum of the best effort (BE) class connections (or LSPs in MPLS context) in a link is used as a path selection criterion, where each BE connection is weighted by its service volume ( for example lOMbps may be assigned an integer value of 10, while lOGbps is to 10,000).
Preferably, the traffic engineering extension of IGP
(Internal Gateway Protocol) such as OSPF-TE is adapted to advertise the weighted sum of BE connections as one of the link
- 3 -constraints, and a CBR (Constraint Based Routing) algorithm will select a path with the lowest utilization level.
A motivation of embodiments of the invention is to ensure that even the BE class connections can get adequate level of performance by (1) incorporating usage information of BE traffic as part of the traffic engineering extension IGP
such as OSPF-TE, and by (2) using such information in calculating paths for BE connections with different service volume. An improved use of network resources is also achieved.
According to one broad aspect, the invention provides a network path selection method involving maintaining a network topology model comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links; to determine a path from a source to a destination having a requested BE service volume: creating a virtual topology in which all links have weighted BE metrics updated to include the effects of the requested BE service volume, and identifying a best path through the virtual topology taking into account the weighted BE metrics.
In one embodiment the weighted BE connection metric takes into account only BE connection service volume. In other embodiments, the weighted BE connection metric for a given link takes into account BE connection service volume on the given link, and a remaining capacity on the given link taking into account other traffic classes with bandwidth commitment.
Preferably, a fraction of each link's capacity to be made available for BE traffic is set aside.
A motivation of embodiments of the invention is to ensure that even the BE class connections can get adequate level of performance by (1) incorporating usage information of BE traffic as part of the traffic engineering extension IGP
such as OSPF-TE, and by (2) using such information in calculating paths for BE connections with different service volume. An improved use of network resources is also achieved.
According to one broad aspect, the invention provides a network path selection method involving maintaining a network topology model comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links; to determine a path from a source to a destination having a requested BE service volume: creating a virtual topology in which all links have weighted BE metrics updated to include the effects of the requested BE service volume, and identifying a best path through the virtual topology taking into account the weighted BE metrics.
In one embodiment the weighted BE connection metric takes into account only BE connection service volume. In other embodiments, the weighted BE connection metric for a given link takes into account BE connection service volume on the given link, and a remaining capacity on the given link taking into account other traffic classes with bandwidth commitment.
Preferably, a fraction of each link's capacity to be made available for BE traffic is set aside.
- 4 -Preferably, the weighted BE connection metrics are computed in a manner which encourages making use of at least a portion of unused bandwidth which is reserved for other traffic classes.
The path selection process may also take into account one or more of administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
Preferably, the weighted BE connection metric within a network is advertised as part of a modified OSPF-TE (Open Shortest Path First - Traffic Engineering) link state advertisement.
Another broad aspect of the invention provides a network component adapted to perform path selection. The component has a network topology repository identifying a network topology comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links. There is also a network path selecting component adapted to determine a path from a source to a destination having a requested BE
service volume by: a) creating a virtual topology in which all links in the network topology have weighted BE metrics updated to include the effects of the requested BE service volume; and b) identifying a best path through the virtual topology taking into account the weighted BE metrics.
Another broad aspect of the invention provides a network component comprising means for computing a weighted BE
connection metric for a link and means for advertising the weighted BE connection metric within a network.
The path selection process may also take into account one or more of administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
Preferably, the weighted BE connection metric within a network is advertised as part of a modified OSPF-TE (Open Shortest Path First - Traffic Engineering) link state advertisement.
Another broad aspect of the invention provides a network component adapted to perform path selection. The component has a network topology repository identifying a network topology comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links. There is also a network path selecting component adapted to determine a path from a source to a destination having a requested BE
service volume by: a) creating a virtual topology in which all links in the network topology have weighted BE metrics updated to include the effects of the requested BE service volume; and b) identifying a best path through the virtual topology taking into account the weighted BE metrics.
Another broad aspect of the invention provides a network component comprising means for computing a weighted BE
connection metric for a link and means for advertising the weighted BE connection metric within a network.
- 5 -Brief Description of the Drawings Preferred embodiments of the invention will now be described with reference to the attached drawings in which:
Figures 1, 2 and 3 are network topologies in accordance with a network path selection method provided by an embodiment of the invention;
Figure 4 is a block diagram of a network path selection component provided by an embodiment of the invention;
and Figure 5 is a flowchart of a network path selection method provided by an embodiment of the invention.
Detailed Description of the Preferred Embodiments An embodiment of the invention provides a novel mechanism to ensure both the efficient use of network resources and adequate performance of best effort (BE) traffic by intelligently distributing the BE traffic demands at connection level through the use of scaling weights which are preferably based on/factor in a computed weighted sum of BE connections.
Each BE connection has an associated service volume which may or may not be achieved since BE service volumes are not guaranteed. The BE connection's service volume can be determined for example by the user port speed or requested via the SLA (service Level Agreement) as part of the service creation process. Alternatively, the PIR (Peak Information Rate) of a BE connection can also be used as the service volume. Each link over which a BE connection is routed has an associated metric maintained consisting a weighted sum of BE
connections over the link, with each BE connection being weighted by an amount proportional to the connection's service volume. More specifically, in a first preferred embodiment of
Figures 1, 2 and 3 are network topologies in accordance with a network path selection method provided by an embodiment of the invention;
Figure 4 is a block diagram of a network path selection component provided by an embodiment of the invention;
and Figure 5 is a flowchart of a network path selection method provided by an embodiment of the invention.
Detailed Description of the Preferred Embodiments An embodiment of the invention provides a novel mechanism to ensure both the efficient use of network resources and adequate performance of best effort (BE) traffic by intelligently distributing the BE traffic demands at connection level through the use of scaling weights which are preferably based on/factor in a computed weighted sum of BE connections.
Each BE connection has an associated service volume which may or may not be achieved since BE service volumes are not guaranteed. The BE connection's service volume can be determined for example by the user port speed or requested via the SLA (service Level Agreement) as part of the service creation process. Alternatively, the PIR (Peak Information Rate) of a BE connection can also be used as the service volume. Each link over which a BE connection is routed has an associated metric maintained consisting a weighted sum of BE
connections over the link, with each BE connection being weighted by an amount proportional to the connection's service volume. More specifically, in a first preferred embodiment of
- 6 -the invention, for the kth link the following metric Mk is maintained:
Mk - Ewr where Ewi = the sum of the BE connection service volume, where wi is the service volume for the ith BE connection. In this embodiment, the link metric is simply the sum of the BE
connection service volume. A link with more BE connection service volume will have a higher metric.
Figure 1 depicts an example of a network topology for the purpose of describing BE path selection based on the weighted sum of BE connections. In this example, there are six nodes labelled A,B,C,D,E,F with various interconnecting links.
Each link interconnects two nodes, and will be referred to by the pair of nodes it interconnects. Thus in Figure 1, the links include AB, AE, BC, BE, CD, CE, CF, FD. In this example Figure, only BE connections are supported. Each link has an associated current number of BE connections indicated in parenthesis shown for illustrative purposes only, and has a BE
connection weight equal to the sum of the service volumes for these BE connections (i.e. Ewi ). For example, link AB has 10 BE connections having a total service volume of 100.
When a new request for a BE connection is made having a requested service volume, a virtual topology is created in which each link's BE connection weight is increased by the requested service volume. For a requested bandwidth of 50, the virtual topology is as shown in Figure 2. The best path through the temporary topology is identified using a shortest path first computation such as a Dijkstra algorithm where the above metric is used as the link cost.
_ 7 _ In addition to the weighted BE connection metric, a MCR (Multi Constraint Routing) algorithm may be used which is further adapted to consider other link constraints (such as administrative costs, edge, and/or node disjointness, shared risk link group disjointness for protection/restoration, etc) for the path selection. The non-BE bandwidth requirements also need to be considered when multiple traffic classes are to be supported via a single LSP.
In the illustrated example, the best path 25 is identified to be links AB, BC, CF, and FD. The BE connection weights associated with the links of the best path 25 in the original topology (Figure 1) are increased by the requested BE
service volume resulting in the topology of Figure 3 after allocation.
In another preferred embodiment of the invention, in addition to considering BE traffic load balancing, the metrics also take into account the amount of bandwidth being used for other traffic classes. For the kth link the following metric Mk is maintained:
Mk =Ew; lX
where X is a quantity which is larger when the particular link has more capacity available for BE traffic, and is smaller when the particular link has less capacity available for BE traffic.
For example, in a preferred embodiment, the metrics are determined according to:
Mk = Ew; l(8 ((1- a )C - E(Reserved bandwidth of non - BE) + aC) ( 1 ) where:
C = total capacity of link;
_ g _ 8 = a scaling constant (0<=8<=1) determining the fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic.
a = fraction of total capacity C to be set aside for aggregate use by BE connections - such a practice of reserving a portion of link capacity prevents starvation of BE traffic due to higher priority class traffic;
E(Reserved bandwidth of non-BE) _ the sum of all non-BE bandwidth reserved on the particular link;
Ewi = the sum of the BE connection service volumes, where wi is the service volume for the ith BE connection.
In this embodiment, the link metric is the sum of the BE connection service volumes divided by a quantity representative of available bandwidth on the link. A link with more BE connection service volume will have a higher metric.
At the same time, a link with less available bandwidth will also have a higher metric. When 8 = 0, the BE path computation only considers the available bandwidth to be link bandwidth set aside for BE and its utilization level. This is the case for the example of Figures 1-3 described above. On the other hand, when 8 =1, the path computation aggressively accounts for the total available bandwidth for the BE at the time of computation, including unutilized portions of bandwidth allocated to other service classes. Network operators can set the non-BE scaling factor, 8, appropriately, for example depending on the observed characteristics of non-BE service request arrival and departure rates.
It is noted that the sum of the reservable bandwidths for non-BE traffic may be in general greater than (1-a)C to prevent link under-utilization to a degree. This is also _ g _ termed "partial sharing". In one extreme case, the sum of the maximum reservable bandwidths is constrained not to exceed (1-a)C. In this case, it is possible for the link to be under-utilized when any class of traffic is not using the link to its full maximum reserved bandwidth. The other extreme case is "complete sharing" in which each maximum reservable bandwidth is set to equal (1-a)C meaning that any one class can fully book the link capacity. Note that in both "partial" and "complete" sharing, an additional condition is required, namely that the sum of the actual reserved bandwidths for non-BE
traffic be less than or equal to (1-a)C.
A detailed example of this type of metric computation will be described in the context of the traffic classes of service defined by in [3,4,5], in which the link metric introduced in equation 1 is employed. The traffic classes include EF (expedited forwarding), AF-1 (assured forwarding-1), AF-2 and BE (best effort). Now as an example of link metric computation for a particular link using equation 1 above, we assume that for that link, a total capacity of C=lOGbps, and a _ 0.1. We assume ~ = 0.5 meaning half of the unused capacity of higher traffic classes is made available to BE traffic. For this example, the maximum reservable and reserved bandwidths for the traffic classes on a given link are as follows:
EF traffic can reserve up to a=3Gbps, 2Gbps currently reserved;
AF1 can reserve up to b=SGbps; lGbps reserved;
AF2 can reserve up to c= 9Gbps; 2 Gbps reserved;
BE reserved bandwidth of aC = lGbps; 4 Gbps total aggregate service volume carried.
In this example, the maximum reservable bandwidths for non-BE traffic is 3+5+9 which is greater than (1-a)C = 9, so partial sharing is occurring.
In addition to the above constraints, the total aggregate sum of reserved bandwidth of all non-BE class traffic (e. g., EF + AF1 + AF2) cannot be more than (1 - a)C = 9Gbps thereby providing the reserved bandwidth aC for BE traffic.
Note however that BE service volume can be greater, as all BE
requests are serviced on a best effort basis. The link metric is then computed according to equation 1 as follows:
Mk = Ew; l(8 ((1- a )C - E(Reserved bandwidth of non - BE) + aC) = 4 /(0.5((1- 0.1)10 - 5) + . lxl 0) = 4 / 3 =1.33 In a preferred embodiment of the invention, the traffic engineering extension of IGP (Internal Gateway Protocol) such as OSPF-TE is adapted to use the weighted sum of BE connections as one of the link constraints, and the MCR
(Multi-Constraint Routing) algorithm will select a path with the lowest utilization level. In a preferred embodiment of the invention, the weighted sum of BE connections is included as part of the OSPF-TE link state advertisement. More generally, in a preferred embodiment, the network nodes advertise the weighted sum of BE connections in any suitable manner.
Preferably, all nodes in the network flood such link metrics to all others. Such advertisement may occur periodically, or as events occur such as link failures. The advertisement may be done on the basis of physical (e. g, lambda) or logical links.
Path selection can be performed using these methods by any component supplied with the necessary topology information. Referring to Figure 4, shown is a network path selecting component (NPSC) generally indicated by 10, which may be part of a network node, a network management platform for example, and may be implemented using any suitable combination of hardware and/or software. The NPSC 10 has a topology database 12 of a network under consideration which forms the basis of the path selection. More generally, the topology may be maintained in any suitable topology repository. The topology database 12 includes an identification of all nodes and the interconnections between the nodes, and one or more metrics/costs/parameters associated with each link. Topology input 18 is generally representative of any and all input which might change the topology. For example, it might consist of the above referenced OSPF-TE link state advertisements which will allow the topology to update the metrics/costs/parameters associated with each link. The NPSC 10 has a routing algorithm which is preferably a multi-constraint routing algorithm 14.
The NPSC 10 receives as input 16 an identification of a source and destination within the network topology database 12. The multi-constraint routing algorithm 14 identifies the best path through the network topology database 12 from the source to the destination.
The functionality of the NPSC 10 is also summarized in flowchart form in Figure 5. Step 5-1 involves maintaining the network topology database including weighted BE connection metric for each link. Step 5-2 is the receipt of a request for a new BE connection from a source to a destination, the request having a service volume . Next, a virtual topology is created in which all links have weighted BE metrics updated to include the effects of the requested service volume (step 5-3). Next, the best path through the virtual topology is identified (step 5-4). Next, the original topology is modified to include the new connection requested bandwidth (step 5-5). This next step need not explicitly be performed in the event the topology is updated in step 5-1 to include the changes at a later time.
The changes may not occur until the nodes in the network generate link state advertisements which include the effects of the added BE connection.
The functionality of the NPSC may also be delivered in the form of a computer readable medium having computer readable program code means embodied therein.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the l0 appended claims, the invention may be practised otherwise than as specifically described herein.
References [1] D. Awduche, et al "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999.
[2] D. Awduche, et al "A Framework for Internet Traffic Engineering," Work in progress, draft-ietf-tewg-framework-03.txt, March 2001.
[3] F. L. Faucheur, et al, "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," Work in progress, draft-lefaucheur-diff-te-reqts-OO.txt, July 2000.
[4] v. Jacobson, et al, "An Expedited Forwarding PHB," RFC
2598, June 1999.
[5] J. Heinanen, et al, "Assured Forwarding PHB Group," RFC
2597, June 1999.
Mk - Ewr where Ewi = the sum of the BE connection service volume, where wi is the service volume for the ith BE connection. In this embodiment, the link metric is simply the sum of the BE
connection service volume. A link with more BE connection service volume will have a higher metric.
Figure 1 depicts an example of a network topology for the purpose of describing BE path selection based on the weighted sum of BE connections. In this example, there are six nodes labelled A,B,C,D,E,F with various interconnecting links.
Each link interconnects two nodes, and will be referred to by the pair of nodes it interconnects. Thus in Figure 1, the links include AB, AE, BC, BE, CD, CE, CF, FD. In this example Figure, only BE connections are supported. Each link has an associated current number of BE connections indicated in parenthesis shown for illustrative purposes only, and has a BE
connection weight equal to the sum of the service volumes for these BE connections (i.e. Ewi ). For example, link AB has 10 BE connections having a total service volume of 100.
When a new request for a BE connection is made having a requested service volume, a virtual topology is created in which each link's BE connection weight is increased by the requested service volume. For a requested bandwidth of 50, the virtual topology is as shown in Figure 2. The best path through the temporary topology is identified using a shortest path first computation such as a Dijkstra algorithm where the above metric is used as the link cost.
_ 7 _ In addition to the weighted BE connection metric, a MCR (Multi Constraint Routing) algorithm may be used which is further adapted to consider other link constraints (such as administrative costs, edge, and/or node disjointness, shared risk link group disjointness for protection/restoration, etc) for the path selection. The non-BE bandwidth requirements also need to be considered when multiple traffic classes are to be supported via a single LSP.
In the illustrated example, the best path 25 is identified to be links AB, BC, CF, and FD. The BE connection weights associated with the links of the best path 25 in the original topology (Figure 1) are increased by the requested BE
service volume resulting in the topology of Figure 3 after allocation.
In another preferred embodiment of the invention, in addition to considering BE traffic load balancing, the metrics also take into account the amount of bandwidth being used for other traffic classes. For the kth link the following metric Mk is maintained:
Mk =Ew; lX
where X is a quantity which is larger when the particular link has more capacity available for BE traffic, and is smaller when the particular link has less capacity available for BE traffic.
For example, in a preferred embodiment, the metrics are determined according to:
Mk = Ew; l(8 ((1- a )C - E(Reserved bandwidth of non - BE) + aC) ( 1 ) where:
C = total capacity of link;
_ g _ 8 = a scaling constant (0<=8<=1) determining the fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic.
a = fraction of total capacity C to be set aside for aggregate use by BE connections - such a practice of reserving a portion of link capacity prevents starvation of BE traffic due to higher priority class traffic;
E(Reserved bandwidth of non-BE) _ the sum of all non-BE bandwidth reserved on the particular link;
Ewi = the sum of the BE connection service volumes, where wi is the service volume for the ith BE connection.
In this embodiment, the link metric is the sum of the BE connection service volumes divided by a quantity representative of available bandwidth on the link. A link with more BE connection service volume will have a higher metric.
At the same time, a link with less available bandwidth will also have a higher metric. When 8 = 0, the BE path computation only considers the available bandwidth to be link bandwidth set aside for BE and its utilization level. This is the case for the example of Figures 1-3 described above. On the other hand, when 8 =1, the path computation aggressively accounts for the total available bandwidth for the BE at the time of computation, including unutilized portions of bandwidth allocated to other service classes. Network operators can set the non-BE scaling factor, 8, appropriately, for example depending on the observed characteristics of non-BE service request arrival and departure rates.
It is noted that the sum of the reservable bandwidths for non-BE traffic may be in general greater than (1-a)C to prevent link under-utilization to a degree. This is also _ g _ termed "partial sharing". In one extreme case, the sum of the maximum reservable bandwidths is constrained not to exceed (1-a)C. In this case, it is possible for the link to be under-utilized when any class of traffic is not using the link to its full maximum reserved bandwidth. The other extreme case is "complete sharing" in which each maximum reservable bandwidth is set to equal (1-a)C meaning that any one class can fully book the link capacity. Note that in both "partial" and "complete" sharing, an additional condition is required, namely that the sum of the actual reserved bandwidths for non-BE
traffic be less than or equal to (1-a)C.
A detailed example of this type of metric computation will be described in the context of the traffic classes of service defined by in [3,4,5], in which the link metric introduced in equation 1 is employed. The traffic classes include EF (expedited forwarding), AF-1 (assured forwarding-1), AF-2 and BE (best effort). Now as an example of link metric computation for a particular link using equation 1 above, we assume that for that link, a total capacity of C=lOGbps, and a _ 0.1. We assume ~ = 0.5 meaning half of the unused capacity of higher traffic classes is made available to BE traffic. For this example, the maximum reservable and reserved bandwidths for the traffic classes on a given link are as follows:
EF traffic can reserve up to a=3Gbps, 2Gbps currently reserved;
AF1 can reserve up to b=SGbps; lGbps reserved;
AF2 can reserve up to c= 9Gbps; 2 Gbps reserved;
BE reserved bandwidth of aC = lGbps; 4 Gbps total aggregate service volume carried.
In this example, the maximum reservable bandwidths for non-BE traffic is 3+5+9 which is greater than (1-a)C = 9, so partial sharing is occurring.
In addition to the above constraints, the total aggregate sum of reserved bandwidth of all non-BE class traffic (e. g., EF + AF1 + AF2) cannot be more than (1 - a)C = 9Gbps thereby providing the reserved bandwidth aC for BE traffic.
Note however that BE service volume can be greater, as all BE
requests are serviced on a best effort basis. The link metric is then computed according to equation 1 as follows:
Mk = Ew; l(8 ((1- a )C - E(Reserved bandwidth of non - BE) + aC) = 4 /(0.5((1- 0.1)10 - 5) + . lxl 0) = 4 / 3 =1.33 In a preferred embodiment of the invention, the traffic engineering extension of IGP (Internal Gateway Protocol) such as OSPF-TE is adapted to use the weighted sum of BE connections as one of the link constraints, and the MCR
(Multi-Constraint Routing) algorithm will select a path with the lowest utilization level. In a preferred embodiment of the invention, the weighted sum of BE connections is included as part of the OSPF-TE link state advertisement. More generally, in a preferred embodiment, the network nodes advertise the weighted sum of BE connections in any suitable manner.
Preferably, all nodes in the network flood such link metrics to all others. Such advertisement may occur periodically, or as events occur such as link failures. The advertisement may be done on the basis of physical (e. g, lambda) or logical links.
Path selection can be performed using these methods by any component supplied with the necessary topology information. Referring to Figure 4, shown is a network path selecting component (NPSC) generally indicated by 10, which may be part of a network node, a network management platform for example, and may be implemented using any suitable combination of hardware and/or software. The NPSC 10 has a topology database 12 of a network under consideration which forms the basis of the path selection. More generally, the topology may be maintained in any suitable topology repository. The topology database 12 includes an identification of all nodes and the interconnections between the nodes, and one or more metrics/costs/parameters associated with each link. Topology input 18 is generally representative of any and all input which might change the topology. For example, it might consist of the above referenced OSPF-TE link state advertisements which will allow the topology to update the metrics/costs/parameters associated with each link. The NPSC 10 has a routing algorithm which is preferably a multi-constraint routing algorithm 14.
The NPSC 10 receives as input 16 an identification of a source and destination within the network topology database 12. The multi-constraint routing algorithm 14 identifies the best path through the network topology database 12 from the source to the destination.
The functionality of the NPSC 10 is also summarized in flowchart form in Figure 5. Step 5-1 involves maintaining the network topology database including weighted BE connection metric for each link. Step 5-2 is the receipt of a request for a new BE connection from a source to a destination, the request having a service volume . Next, a virtual topology is created in which all links have weighted BE metrics updated to include the effects of the requested service volume (step 5-3). Next, the best path through the virtual topology is identified (step 5-4). Next, the original topology is modified to include the new connection requested bandwidth (step 5-5). This next step need not explicitly be performed in the event the topology is updated in step 5-1 to include the changes at a later time.
The changes may not occur until the nodes in the network generate link state advertisements which include the effects of the added BE connection.
The functionality of the NPSC may also be delivered in the form of a computer readable medium having computer readable program code means embodied therein.
Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the l0 appended claims, the invention may be practised otherwise than as specifically described herein.
References [1] D. Awduche, et al "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999.
[2] D. Awduche, et al "A Framework for Internet Traffic Engineering," Work in progress, draft-ietf-tewg-framework-03.txt, March 2001.
[3] F. L. Faucheur, et al, "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," Work in progress, draft-lefaucheur-diff-te-reqts-OO.txt, July 2000.
[4] v. Jacobson, et al, "An Expedited Forwarding PHB," RFC
2598, June 1999.
[5] J. Heinanen, et al, "Assured Forwarding PHB Group," RFC
2597, June 1999.
Claims (15)
1. A network path selection method comprising:
maintaining a network topology repository comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links;
to determine a path from a source to a destination having a requested BE service volume:
a) creating a virtual topology in which all links have weighted BE metrics updated to include the effects of the requested BE service volume;
b) identifying a best path through the virtual topology taking into account the weighted BE metrics;
wherein the weighted BE connection metric for a given link takes into account BE connection service volumes on the given link, and a remaining capacity on the given link taking into account other traffic classes.
maintaining a network topology repository comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links;
to determine a path from a source to a destination having a requested BE service volume:
a) creating a virtual topology in which all links have weighted BE metrics updated to include the effects of the requested BE service volume;
b) identifying a best path through the virtual topology taking into account the weighted BE metrics;
wherein the weighted BE connection metric for a given link takes into account BE connection service volumes on the given link, and a remaining capacity on the given link taking into account other traffic classes.
2. A method according to claim 1 further comprising:
setting aside a fraction of each link's capacity to be made available for BE traffic.
setting aside a fraction of each link's capacity to be made available for BE traffic.
3. A method according to claim 1 further comprising:
computing the weighted BE connection metrics in a manner which encourages making use of at least a portion of unused bandwidth which is reserved for other traffic classes.
computing the weighted BE connection metrics in a manner which encourages making use of at least a portion of unused bandwidth which is reserved for other traffic classes.
4. A method according to claim 1 wherein the weighted BE connection metric for each of the plurality of links is determined according to M k = .SIGMA.w i where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume for the ith previously requested BE connection.
5. A method according to claim 1 wherein the weighted BE connection metric for each of the plurality of links is determined according to:
M k = .SIGMA.w i / X
where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume bandwidth for an ith previously requested BE connection, and where X is a quantity which introduces effects of other traffic classes, with X
being larger when a particular link has more capacity available for BE traffic, and X being smaller when a particular link has less capacity available for BE traffic.
M k = .SIGMA.w i / X
where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume bandwidth for an ith previously requested BE connection, and where X is a quantity which introduces effects of other traffic classes, with X
being larger when a particular link has more capacity available for BE traffic, and X being smaller when a particular link has less capacity available for BE traffic.
6. A method according to claim 1 wherein the weighted BE connection metric for each of the plurality of links is determined according to:
M k = .SIGMA.w i /(.delta.((1-.alpha.)C - .SIGMA.(Reserved bandwidth of non -BE) + .alpha.C) where:
M k is the metric for a kth of the plurality of links;
.SIGMA.w i = a sum of the previously requested BE connection service volumes, where w i is a service volume for the ith BE
connection;
C = total capacity of a link;
.delta. = a scaling constant (0<=.delta.<=1) determining a fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic;
.alpha. = fraction of total capacity C to be set aside for reservation by BE connections; and .SIGMA.(Reserved bandwidth of non-BE) = the sum of all non-BE bandwidth reserved on the link.
M k = .SIGMA.w i /(.delta.((1-.alpha.)C - .SIGMA.(Reserved bandwidth of non -BE) + .alpha.C) where:
M k is the metric for a kth of the plurality of links;
.SIGMA.w i = a sum of the previously requested BE connection service volumes, where w i is a service volume for the ith BE
connection;
C = total capacity of a link;
.delta. = a scaling constant (0<=.delta.<=1) determining a fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic;
.alpha. = fraction of total capacity C to be set aside for reservation by BE connections; and .SIGMA.(Reserved bandwidth of non-BE) = the sum of all non-BE bandwidth reserved on the link.
7. A method according to claim 1 wherein the step of identifying a best path through the virtual topology taking into account the weighted BE metrics is performed using a multi-constraint routing algorithm which also takes into account at least one of:
administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
8. A network component for performing a path selection, the component comprising:
a network topology repository identifying a network topology comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links;
a network path selecting component for determining a path from a source to a destination having a requested BE
service volume by:
a) creating a virtual topology in which all links in the network topology have weighted BE metrics updated to include the effects of the requested BE service volume;
b) identifying a best path through the virtual topology taking into account the weighted BE metrics.
wherein the weighted BE connection metric takes into account only BE connection service volumes.
a network topology repository identifying a network topology comprising a plurality of nodes and a plurality of links interconnecting the nodes, the network topology further comprising a weighted BE (best effort) connection metric for each of the plurality of links;
a network path selecting component for determining a path from a source to a destination having a requested BE
service volume by:
a) creating a virtual topology in which all links in the network topology have weighted BE metrics updated to include the effects of the requested BE service volume;
b) identifying a best path through the virtual topology taking into account the weighted BE metrics.
wherein the weighted BE connection metric takes into account only BE connection service volumes.
9. A network component according to claim 8 wherein the weighted BE connection metric for a given link takes into account BE connection service volumes on the given link, and a remaining capacity on the given link taking into account other traffic classes.
10. A network component according to claim 8 wherein a fraction of each link's capacity is set aside to be made available for BE traffic.
11. A network component according to claim 8 wherein:
the network path selecting component for computing the weighted BE connection metrics in a manner which encourages making use of at least a portion of unused bandwidth which is reserved for other traffic classes.
the network path selecting component for computing the weighted BE connection metrics in a manner which encourages making use of at least a portion of unused bandwidth which is reserved for other traffic classes.
12. A network component according to claim 8 wherein the weighted BE connection metric for each of the plurality of links is determined according to M k = .SIGMA.w i where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume for the ith previously requested BE connection.
13. A network component according to claim 8 wherein the weighted BE connection metric for each of the plurality of links is determined according to:
M k = .SIGMA.w i / X
where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume bandwidth for the ith previously requested BE connection, and where X is a quantity which introduces effects of other traffic classes, with X
being larger when the particular link has more capacity available for BE traffic, and X being smaller when the particular link has less capacity available for BE traffic.
M k = .SIGMA.w i / X
where M k is the metric for a kth of the plurality of links, where .SIGMA.w i = a sum of previously requested BE connection service volumes, where w i is a service volume bandwidth for the ith previously requested BE connection, and where X is a quantity which introduces effects of other traffic classes, with X
being larger when the particular link has more capacity available for BE traffic, and X being smaller when the particular link has less capacity available for BE traffic.
14. A network component according to claim 8 wherein the weighted BE connection metric for each of the plurality of links is determined according to:
M k = .SIGMA.w i /(.delta.((1 - .alpha.)C - .SIGMA.(Reserved bandwidth of non -BE) + .alpha.C) where:
M k is the metric for a kth of the plurality of links;
.SIGMA.w i = a sum of the previously requested BE connection service volumes, where w i is a service volume for the ith BE
connection;
C = total capacity of the link;
.delta. = a scaling constant (0<=.delta.<=1) determining the fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic;
.alpha. = fraction of total capacity C to be set aside for reservation by BE connections; and .SIGMA.(Reserved bandwidth of non-BE) = the sum of all non-BE bandwidth reserved on the link.
M k = .SIGMA.w i /(.delta.((1 - .alpha.)C - .SIGMA.(Reserved bandwidth of non -BE) + .alpha.C) where:
M k is the metric for a kth of the plurality of links;
.SIGMA.w i = a sum of the previously requested BE connection service volumes, where w i is a service volume for the ith BE
connection;
C = total capacity of the link;
.delta. = a scaling constant (0<=.delta.<=1) determining the fraction of remaining unreserved bandwidth of higher priority traffic classes which is to be made available for BE traffic;
.alpha. = fraction of total capacity C to be set aside for reservation by BE connections; and .SIGMA.(Reserved bandwidth of non-BE) = the sum of all non-BE bandwidth reserved on the link.
15. A network component according to claim 8 wherein identifying a best path through the virtual topology taking into account the weighted BE metrics is performed using a multi-constraint routing algorithm which also takes into account at least one of:
administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
administrative costs, edge disjointness, node disjointness, and shared risk link group disjointness for protection/restoration paths.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002354353A CA2354353C (en) | 2001-07-31 | 2001-07-31 | Network resource allocation methods and systems |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA002354353A CA2354353C (en) | 2001-07-31 | 2001-07-31 | Network resource allocation methods and systems |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2354353A1 CA2354353A1 (en) | 2003-01-31 |
| CA2354353C true CA2354353C (en) | 2006-01-03 |
Family
ID=4169624
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002354353A Expired - Fee Related CA2354353C (en) | 2001-07-31 | 2001-07-31 | Network resource allocation methods and systems |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2354353C (en) |
-
2001
- 2001-07-31 CA CA002354353A patent/CA2354353C/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2354353A1 (en) | 2003-01-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6785737B2 (en) | Network resource allocation methods and systems | |
| US9071541B2 (en) | Path weighted equal-cost multipath | |
| Wang et al. | A new bandwidth guaranteed routing algorithm for MPLS traffic engineering | |
| US8279754B1 (en) | RSVP-passive interfaces for traffic engineering peering links in MPLS networks | |
| KR100411251B1 (en) | A constrained multipath routing method | |
| US7889652B1 (en) | Traffic engineering using extended bandwidth accounting information | |
| Lee et al. | A constrained multipath traffic engineering scheme for MPLS networks | |
| US8787400B1 (en) | Weighted equal-cost multipath | |
| Kodialam et al. | Dynamic routing of restorable bandwidth-guaranteed tunnels using aggregated network resource usage information | |
| US7187652B2 (en) | Multi-constraint routing system and method | |
| US7643425B2 (en) | LSP path selection | |
| Khan et al. | A fuzzy constraint-based routing algorithm for traffic engineering | |
| Rabbat et al. | Traffic engineering algorithms using MPLS for service differentiation | |
| CA2354353C (en) | Network resource allocation methods and systems | |
| Degrande et al. | Inter-area traffic engineering in a differentiated services network | |
| Zubairi | An automated traffic engineering algorithm for MPLS-Diffserv domain | |
| Liu et al. | A static routing algorithm used in the Internet traffic engineering | |
| Vutukury et al. | A scalable architecture for providing deterministic guarantees | |
| Gopalan et al. | Network-wide load balancing routing with performance guarantees | |
| Kim et al. | Constraint-based LSP setup by message reversing of CR-LDP | |
| Siripongwutikorn et al. | Traffic engineering in the internet: A survey of load balanced routing | |
| Zhang et al. | Designing a new routing simulator for DiffServ MPLS networks | |
| Chatzaki et al. | Resource allocation in multiservice MPLS | |
| Spitler et al. | Integrating effective-bandwidth-based QoS routing and best effort routing | |
| Park et al. | Stable load control with load prediction in multipath packet forwarding |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed |