Optimization for multi-path networks supporting segment routing

Abstract

Techniques for optimizing multipaths in a network supporting segment routing are described. For example, a computing device is configured to: for each link in a network layer of a multi-layer network, calculate usage (metrics) of all paths in a first plurality of multipaths for the link to calculate an aggregate usage of the first plurality of multipaths, the first plurality of multipaths being arranged in the network layer, the first plurality of multipaths having been calculated and placed in a model of the network layer in a first order; calculate a second plurality of multipaths, wherein the second plurality of multipaths have been calculated and placed in the model of the network layer in a second, different order; and in response to determining that the aggregate usage of the second plurality of multipaths is less than the aggregate usage of the first plurality of multipaths, arrange the second plurality of multipaths in the network layer.

Description

[0001] This application claims the benefit of U.S. Patent No. 17 / 446,375, filed on August 30, 2021, the entire contents of which are incorporated herein in their entirety. Technical Field

[0002] The present invention relates to computer networks, and more particularly, to segment routing for computing networks. Background Art

[0003] A computer network is a collection of interconnected computing devices that exchange data and share resources. In a packet-based network, such as the Internet, computing devices transmit data by dividing it into small chunks called packets, which are individually routed from a source device to a destination device across the network. The destination device extracts the data from the packets and assembles the data into its original form.

[0004] Certain devices within a network, such as routers, use routing protocols to exchange and accumulate topological information that describes the available routes through the network. This allows the router to build its own map of the network's routing topology. Upon receiving an incoming data packet, the router examines the information within the packet and forwards the packet based on the accumulated topological information.

[0005] Many routing protocols belong to a class of protocols known as interior gateway protocols (IGPs), which use a flooding-based distribution mechanism to publish topology information to routers within a network. These routing protocols typically rely on routing algorithms that require each router to have synchronized routing topology information for a given domain, known as an IGP area or domain. The contents of a link-state database (LSDB) or traffic engineering database (TED) maintained by a link-state routing protocol have the scope of an IGP domain. IGP routing protocols typically require all routers in an IGP routing domain to store all routing information distributed according to the IGP protocol in an internal LSDB or TED. In operation, each router typically maintains an internal link-state database and scans the entire database at defined intervals to generate and output link state messages to synchronize the database with neighboring routers within the routing domain. In this way, link state is propagated across the entire routing domain and is fully stored at every router within the domain.

[0006] Packet-based networks use label switching protocols for traffic engineering and other purposes. Multiprotocol Label Switching (MPLS) is a mechanism for orchestrating traffic patterns within Internet Protocol (IP) networks based on routing information maintained by routers in the network. By utilizing MPLS protocols such as Label Distribution Protocol (LDP), Resource Reservation Protocol (RSVP) with Traffic Engineering Extensions (RSVP-TE), or Segment Routing (SR) extensions, label switching routers can use labels prepended to traffic to forward traffic along a specific path (i.e., a Label Switched Path (LSP)) through the network to a destination device. An LSP defines different paths through the network to carry MPLS packets from a source device to a destination device. Using the MPLS protocol, each router along the LSP assigns a label associated with the destination and propagates the label to the nearest upstream router along the path. Routers along the path add (push), remove (pop), or swap labels and perform other MPLS operations to forward MPLS packets along the established path.

[0007] Routers can employ segment routing techniques to leverage the Source Packet Routing (SPRING) paradigm in the network. With segment routing, headend network nodes can direct packet flows along any path by augmenting the packet header with an ordered list of segment identifiers to enforce segment routing policies. Segment routing can reduce, and in some cases eliminate, the intermediate per-flow state inherent in conventional MPLS routing. Summary of the Invention

[0008] In general, techniques are described for optimizing multi-path networks that support segment routing. For example, a network may have an underlying transport layer (e.g., an optical network or other service layer) and a logical or overlay network layer (e.g., an Internet Protocol (IP) network or other client layer) that routes over the transport layer. A network with multiple layers is referred to as a multi-layer network. The logical network of the multi-layer network includes routers, such as Layer 3 (L3) routers and Layer 2 (L2) switches or L2 / L3 switches, that provide L2 / L3 traffic forwarding services, such as traffic engineering via segment routing. For example, the routers of the logical network may implement segment routing policies to direct packet flows along paths through one or more logical links in the logical network layer (e.g., IP links in the IP layer), which logical links correspond to paths in an underlying transport network that includes one or more physical links. In this way, the logical network is effectively an overlay network "built on top of" the underlying transport network.

[0009] The controller can control the routing and business engineering operations of the logical network and can also provide integrated control of the allocation or utilization of transport equipment within the transport network. In some examples, the controller can calculate and set up multiple paths (e.g., multiple paths implemented for segment routing tunnels) based on business needs to implement a segment routing policy. The network can typically calculate and set up multiple paths for multiple segment routing policies between the same source and destination. For a given segment routing policy, the controller can calculate the multiple paths in the network layer in an initial order. The business needs of the multiple paths can then be "placed" into the model of the network layer along the multiple paths. The calculation and placement of the business to the multiple paths may be referred to herein as the "placement" of the multiple paths in the network layer. The controller can then set up the multiple paths in the network.

[0010] According to the technology described in the present disclosure, a controller can provide optimization for a multipath network that supports segment routing. For example, the controller can provide an alternative way to route paths in a multipath (e.g., an SR tunnel) that can result in less usage of a metric (e.g., bandwidth) than the path set in the logical network. As an example, the controller calculates a first plurality of multipaths (corresponding to a corresponding segment routing policy) and places the first plurality of multipaths in a first order to a model of the network layer, and can set the first plurality of multipaths in the logical network. The controller calculates the overall usage of the metric (e.g., bandwidth) by the second plurality of multipaths. The controller (e.g., based on a heuristic algorithm and / or countermeasure) calculates a second plurality of multipaths (also corresponding to a corresponding segment routing policy) and places the second plurality of multipaths in a different second order, and calculates the overall usage of the metric by the second plurality of multipaths. If the overall usage of the second plurality of multipaths is less than the overall usage of the first plurality of multipaths, the controller can set the second plurality of multipaths in the logical network. Alternatively or additionally, if the total usage of the second plurality of multipaths is not less than the total usage of the first plurality of multipaths, the controller may leave the multipaths set in the logical network unchanged and / or perform a next iteration of the heuristic algorithm and / or countermeasure.

[0011] The technology may provide one or more technical advantages for practical applications. For example, by calculating multiple multipaths to be set in a network and placing the multiple multipaths in a different order, multiple multipaths may be provided that use fewer resources than the multiple multipaths set in the network layer, which may be caused by the order in which the paths in the multipaths are initially calculated and set in the network layer.

[0012] In an example, the present disclosure describes a method including: calculating, by a computing system having a model of a multi-layer network, for each link in a plurality of links, usage of a metric of the link by all paths in a first plurality of multipaths to calculate an aggregate usage of the first plurality of multipaths, the multi-layer network including a network layer having a plurality of links, the first plurality of multipaths being arranged in the network layer, wherein multipaths in the first plurality of multipaths have been calculated and placed in a first order to the model of the network layer, and wherein the multipaths in the first plurality of multipaths correspond to different respective segment routing policies; calculating, by the computing system, a second plurality of multipaths for the respective segment routing policies, wherein calculating the second plurality of multipaths includes: calculating multipaths in the second plurality of multipaths and placing the multipaths in the second plurality of multipaths in a second, different order to the model of the network layer; calculating, by the computing system, for each link in the plurality of links, usage of the metric of the link by all paths in the second plurality of multipaths to calculate an aggregate usage of the second plurality of multipaths; and in response to determining that the aggregate usage of the second plurality of multipaths is less than the aggregate usage of the first plurality of multipaths, setting, by the computing system, the second plurality of multipaths in the network layer.

[0013] In an example, the present disclosure describes a computing device including a multi-layer network having a network layer with multiple links, comprising: a memory; and a processing circuit system in communication with the memory, the processing circuit system and the memory being configured to: for each link in the multiple links, calculate usage of a metric of the link by all paths in a first plurality of multipaths to calculate an overall usage of the first plurality of multipaths, the first plurality of multipaths being set in the network layer, wherein multiple paths in the first plurality of multipaths have been calculated and placed in a model of the network layer in a first order, and wherein the multiple paths in the first plurality of multipaths correspond to different respective segment routing policies; calculate a second plurality of multipaths for the respective segment routing policies, wherein calculating the second plurality of multipaths includes: calculating multiple paths in the second plurality of multipaths and placing the multiple paths in the second plurality of multipaths in a different second order to the model of the network layer; and in response to determining that the overall usage of the second plurality of multipaths is less than the overall usage of the first plurality of multipaths, set the second plurality of multipaths in the network layer.

[0014] In an example, the present disclosure describes a non-transitory computer-readable storage medium encoded with instructions that, when executed, cause one or more programmable processors to perform the following operations: for each link in a plurality of links in a network layer of a multi-layer network, calculate usage of a metric of the link by all paths in a first plurality of multipaths to calculate an overall usage of the first plurality of multipaths, the first plurality of multipaths being set in the network layer, wherein multiple paths in the first plurality of multipaths have been calculated and placed in a first order to a model of the network layer, and wherein the multiple paths in the first plurality of multipaths correspond to different respective segment routing policies; calculate a second plurality of multipaths for the respective segment routing policies, wherein calculating the second plurality of multipaths includes: calculating multiple paths in the second plurality of multipaths and placing the multiple paths in the second plurality of multipaths in a different second order to the model of the network layer; and in response to determining that the overall usage of the second plurality of multipaths is less than the overall usage of the first plurality of multipaths, setting the second plurality of multipaths in the network layer.

[0015] The details of the technology are set forth in the accompanying drawings and the following description. Other features, objects, and advantages of the technology will become apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a block diagram illustrating an example system with a multi-layer network and a controller configured to provide optimization for a multi-path network supporting segment routing according to techniques described in this disclosure.

[0017] Figure 2 is a block diagram illustrating an example system with a multi-layer network and a controller configured to provide optimization for a multi-path network supporting segment routing according to techniques described in this disclosure.

[0018] Figure 3 is a block diagram illustrating an example controller in accordance with techniques of this disclosure.

[0019] Figure 4 is a block diagram illustrating an example controller in greater detail according to techniques of this disclosure.

[0020] Figure 5 is a block diagram illustrating in greater detail an example implementation of a path engine of a controller according to the techniques of this disclosure.

[0021] Figure 6 is a flow diagram illustrating example operation of a computing device in accordance with one or more techniques of this disclosure.

[0022] Figure 7 is a block diagram illustrating a data model for determining overall usage of multiple paths according to the techniques described in this disclosure.

[0023] Figure 8 is a block diagram illustrating a data model for optimizing a multi-path network supporting segment routing according to techniques described in this disclosure.

[0024] Like reference numerals refer to like elements throughout the drawings and text. DETAILED DESCRIPTION

[0025] Figure 1 is a block diagram illustrating an example system 100 having a multi-layer network 60 and a controller 52 configured to provide optimization for a multi-path network supporting segment routing according to techniques described in this disclosure. Figure 1 In the example of FIG, multi-layer network 60 includes a logical network layer 6 ("logical network 6") and a transport network layer 54 ("transport network 54"). Transport network 54 represents, for example, an optical transport network (OTN) or other transport network located below logical network 6. Transport network 54 transmits, multiplexes, and switches packet-based communications over high-speed optical fiber links. Transport network 54 may include a plurality of optical communication devices (e.g., packet optical transmission devices), such as optical nodes 7A-7E (collectively referred to as "optical nodes 7"), which are interconnected via optical links 8A-8E (collectively referred to as "optical links 8"), respectively, and control the transmission of optical signals carrying packet data along the optical links. In this manner, transport network 54 provides a physical layer that physically interconnects routers 4A-4F (collectively referred to as "routers 4") of logical network 6.

[0026] Although for simplicity Figure 1 Although not shown, the packet optical transport equipment may be, for example, a PCX, a wavelength division multiplexing (WDM) / dense WDM (DWDM) and time division multiplexing (TDM)-based equipment, an optical cross-connect (OXC), an optical add-drop multiplexer (OADM), a reconfigurable OADM (ROADM), a multiplexing device, or other types of equipment, or other equipment that transmits, switches, and / or multiplexes optical signals. As an example, router 4 may be a layer 3 (L3) router optically connected by an intermediate OXC of transport network 54 (e.g., an OXC to which router 4 has access to a link).

[0027] The transmission network 54 typically includes many other components, such as amplifiers, transponders, OTTs, repeaters, and other equipment for controlling the transmission of optical packet data along optical links (also not shown). Large optical transmission systems may have a large number of such devices that affect optical transmission. Although the transmission system 54 is described only with respect to optical links, the transmission system 54 may also include other types of physical links, such as Ethernet PHY, Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Lambda, or other Layer 2 data links that include packet transmission capabilities.

[0028] Logical network 6 includes routers 4 to control the switching and routing of packet flows. For example, logical network 6 may represent an Internet Protocol (IP) network. Examples of routers 4 include Layer 3 (L3) routers and Layer 2 (L2) switches, or L2 / L3 switches, that collectively provide logical network 6. That is, logical network 6 typically provides L2 / L3 traffic forwarding services, such as traffic engineering via Multi-Protocol Label Switching Traffic Engineering (MPLS-TE), including label-switched paths (LSPs), virtual local area networks (VLANs), and the like. Various examples of logical network 6 may encompass hundreds or even thousands of routers / switches.

[0029] The logical network 6 is actually an overlay network "built on top" of the underlying transport network 54. The router 4 is composed of virtual or logical links ( Figure 1 9 (e.g., physical link 8) of the transport network 54.

[0030] In this example, router 4 may employ segment routing (SR) technology. Segment routing (SR), which may also be referred to as source packet routing or source packet routing in networks (SPRING), is a control plane architecture that enables an ingress router to direct packets through a specific set of network nodes and links in a network without relying on intermediate network nodes in the network to determine the path it should take. The basis of SPRING forwarding is the concept of a segment identifier (SID). Segment routing and SIDs are described in more detail in “Segment Routing Architecture,” edited by Filsfils and Previdi, Internet Engineering Task Force (IETF) RFC 8402, July 2018; “Segment Routing Policy Architecture,” edited by Sivabalan, SPRING Working Group Version 09, November 1, 2020; and “SR Policy Implementation and Deployment Considerations,” edited by Talaulikar, SPRING Working Group Version 04, October 9, 2019; each of which is incorporated herein by reference in its entirety. “Segment Routing Policy Architecture” defines SR policy as “a framework that supports the instantiation of an ordered list of segments at a node” for implementing source routing policies with specific intent for steering traffic from that node.

[0031] Using segment routing, router 4 forwards network packets of a packet flow from a source to a destination along a segment routing path, where the segment routing path is encoded as a list of segment identifiers that augment the network packet header and is used by router 4 to identify the next segment to forward each network packet. For example, the ordered segment list can be instantiated by an SR policy with a specific intent for traffic steering.

[0032] The source of the network packets received and forwarded by the router 4 may include one or more devices (not shown) and / or any public or private network or the Internet. The destination of the network packets forwarded by the router 4 may include one or more destination devices and / or networks, which may include a LAN or a wide area network (WAN) including multiple devices. For example, the destination device may include a personal computer, a laptop, a workstation, a personal digital assistant (PDA), a wireless device, a network-ready appliance, a file server, a print server, or other device that receives the network packets from the source.

[0033] Segment routing has multiple types of segments. These segments include prefix segments, which represent the shortest path between any router in router 4 and a specified prefix (e.g., based on an IGP metric). Prefix segments include node segments, in which a specified prefix identifies a specific router 4 (e.g., the loopback address of a specific router 4), and anycast segments, which enforce an equal-cost multipath (ECMP)-aware shortest path forwarding toward the closest router 4 in the anycast group. An anycast group includes one or more routers 4, and a specified prefix can be advertised by any router 4 in the anycast group. A segment can be referenced by its segment identifier (SID).

[0034] Other segment types include adjacency segments (which are IGP adjacencies between routers 4), binding segments, and adjacency sets. A binding segment can represent a tunnel through router 4. A tunnel can include an SR policy. An adjacency set represents multiple adjacencies and uses the same SID for multiple adjacencies. This is an adjacency parallel version of an anycast SID, where the same SID refers to multiple nodes in the network. In general, SIDs that can be used to direct traffic to multiple paths simultaneously produce a more preferred SID reduction or minimization solution. Adjacency set SIDs and anycast SIDs are important examples of such SIDs.

[0035] In some examples, router 4 applies segment routing using a Multiprotocol Label Switching (MPLS) architecture. In such examples, each segment is encoded as an MPLS label, and the SR policy can be instantiated as a label stack attached to the network packet. The active segment is placed at the top of the label stack. After completing a segment, router 4 pops the corresponding label from the label stack.

[0036] In some examples, router 4 applies segment routing using the IPv6 architecture and the SR header (SRH). In such examples, instructions can be associated with a segment and encoded as an IPv6 address mapped to a SID. The SR policy is instantiated as an ordered list of SIDs in the routing header. The packet's destination address (DA) indicates the active segment. The SegmentsLeft (SL) pointer in the SRH indicates the next active segment. When router 4 completes a segment, the router decrements the SL pointer and copies the next segment to the destination address. Network packets are directed on the SR policy and augmented with the corresponding SRH for the SR policy.

[0037] In some examples, router 4 can operate as a label switching router (LSR) to distribute labels to neighboring LSRs within network 6. For example, there can be a variety of different label types, including "adjacency" labels and "node" labels. Such labels can be or otherwise correspond to segment identifiers that locally or globally identify segments in network 6. To forward a packet through network 6, router 4 can push, pop, or swap one or more labels in a segment identifier list that is applied to the packet as it is forwarded through the network. The label stack can encode the packet's topology and service source routing under the SR policy.

[0038] An adjacency label can have local semantics to a particular segment routing node, such as one of routers 4. Specifically, an adjacency label directs traffic to an adjacency (e.g., a communication link and / or interface) or a set of adjacencies. Thus, an adjacency label can be associated with a particular router 4. To use an adjacency label, a particular router 4 can initially assign an adjacency label to a particular adjacency and advertise the adjacency label to other routers in the segment routing domain using an IGP, such as Intermediate System-Intermediate System (IS-IS) or Open Shortest Path First (OSPF). A particular router 4 can be the only network node in the SR domain that uses a particular adjacency label. When router 4 forwards a packet using the adjacency label, router 4 can cause the packet to use the adjacency of the particular router 4 associated with the adjacency label. In this way, an adjacency label can be used to establish a one-hop tunnel for a segment.

[0039] In contrast, node labels can have global semantics within the SR domain. That is, each of routers 4 can be assigned a defined node label range (often referred to as a segment routing global block (SRGB)) that is unique to each router 4 within the SR domain. The operator of network 6 can ensure the unique assignment of different node label ranges from the global range to different routers 4. In addition to the node label range, each specific router 4 can also have a specific node identifier that uniquely identifies the specific router 4 in the SR domain. Each router 4 can, for example, use an IGP to advertise its corresponding node identifier and node label range to other routers 4 in the SR domain.

[0040] As described above, based on the routes determined using, for example, shortest path routing, each of routers 4 can configure its forwarding state to implement segment routing using MPLS or using the IPv6 architecture and SR header (SRH). For example, using MPLS, each of routers 4 can perform path selection using topology information learned via the IGP to calculate the shortest path within network 6 on a hop-by-hop basis based on the routing information maintained by router 4. Each of routers 4 can then select a next hop along the locally calculated shortest path and install forwarding information associated with the selected next hop in the forwarding plane of the network node, wherein the forwarding information identifies the network interface to use when forwarding the traffic and one or more labels to apply when forwarding the traffic out of the interface. Routers 4 forward the traffic hop-by-hop using the next hop with the assigned label.

[0041] System 100 can implement segment routing using distributed or centralized control. With distributed control, router 4 allocates and signals segments using a routing protocol such as IS-IS, OSPF, or Border Gateway Protocol (BGP). Router 4 independently decides to direct packets along the SR policy implemented using one or more paths. Router 4 independently calculates the SR policy. With distributed control, controller 52 may not be part of system 100. In the distributed control scenario, router 4 is a computing device that can calculate one or more SID lists that satisfy each of the multiple paths to implement the SR policy.

[0042] With centralized control, the controller 52 allocates and signals segments. The controller 52 determines the router 4 on which to direct packets mapped to the SR policy. The controller 52 applies path calculation to calculate candidate paths for satisfying the SR policy. In addition, the controller 52 programs the logical network 6 (particularly the routers 4) with forwarding information for implementing candidate paths using SID lists. The controller 52 can program the routers 4 using the Network Configuration Protocol (NETCONF), the Path Computation Element Communication Protocol (PCEP), BGP, or other protocols. The controller 52 can represent one or more SR controllers and can be a WAN controller that manages not only the SR domain, but also the path calculation, service engineering, settings, and other network control tasks of the operator of the logical network 6. The controller 52 can instantiate SIDs on various routers 4 and discover local (SRLB) label sets and global (SRGB) label sets. The controller 52 can use routing protocols to listen to other topology information.

[0043] In this example, the controller 52 is a computing device that can calculate one or more SID lists that satisfy each of a plurality of paths (referred to as a "multipath") to implement an SR policy. Each of the paths is from a source of the multipath to a destination of the multipath, and may be referred to herein as a segment routing tunnel. The controller 52 can calculate a multipath from one or more sources to one or more destinations in order to implement an SR policy. For example, the controller 52 can calculate a multipath that satisfies one or more SR policies that specify a business requirement (e.g., business requirement 32) and a set of sources (e.g., routers 4A or 4B) and a set of destinations (e.g., router 4F), respectively. In some examples, the controller 52 can calculate multiple multipaths, each of the multipaths corresponding to a different respective segment routing policy.

[0044] After calculating the one or more SID lists, the controller 52 can then program the logical network 6 to forward network traffic along a given multipath based at least on the one or more SID lists. When traffic forwarded by the router 4 using a SID list from the one or more SID lists is forwarded along one of the paths or is not forwarded along a path that is not one of the paths, the one or more SID lists satisfy each of the multiple paths to implement the SR policy. Furthermore, the one or more SID lists are satisfactory when they fully utilize multiple paths, i.e., the router 4 can forward traffic along any of the multiple paths using the one or more SID lists. For example, a first SID list can cause a network packet directed to the SR policy to traverse a first path from the multiple paths, while a second SID list can cause a network packet directed to the SR policy to traverse a second path from the multiple paths, or a single SID list can cause a network packet directed to the SR policy to traverse both the first and second paths from the multiple paths. The router can use weighted or unweighted equal cost multipath (ECMP) to forward traffic to the next segment and / or select one of the one or more SID lists.

[0045] In some example embodiments, the controller 52 provides integrated control of both the router 4 and the packet optical transport equipment underlying the transport network 54 with respect to the transmission of packet data over optical links and other equipment. For example, the controller 52 may not only control the routing and traffic engineering operations of the logical network 6, but may also provide integrated control of the allocation or utilization of optical spectrum and wavelengths utilized by each packet optical transport equipment within the transport network 54 that overlays an element of the logical network 6, or the controller 52 may use path or abstract link information from the transport layer to select candidate links for routing on the transport network 54.

[0046] Controller 52 may represent a high-level controller for configuring and managing logical network 6. Controller 52 may represent one or more general-purpose servers; appliances, controllers, or other specialized devices for computing paths; applications executed by computing devices; a distributed control plane of router 4 that computes paths for LSPs managed by the router; and the like. In some cases, aspects of controller 52 may be distributed among one or more real or virtual computing devices. With respect to logical network 6, any of the devices listed above may be within or outside the network. Example details of a software-defined network (SDN) controller for a software-defined network (which may perform the operations described herein to compute paths and route LSPs) are described in PCT International Patent Application No. PCT / US2013 / 044378, filed June 5, 2013, entitled “PHYSICAL PATH DETERMINATION FOR VIRTUAL NETWORK PACKET FLOWS,” which is incorporated herein in its entirety. Additional example details of an SDN controller for a software-defined network (which is used to obtain topology information for a network and set up the network) are described in U.S. patent application Ser. No. 14 / 042,614, entitled “SOFTWARE DEFINED NETWORK CONTROLLER,” filed on Sep. 30, 2013, and U.S. patent application Ser. No. 14 / 500,736, entitled “BATCHED PATH COMPUTATION IN RESOURCE-CONSTRAINED NETWORKS,” filed on Sep. 29, 2014, which are incorporated herein in their entireties.

[0047] Controller 52 can obtain traffic engineering information 21 for logical network 6 by executing one or more network routing protocols extended to carry traffic engineering information and intercepting routing protocol advertisements carrying this traffic engineering information. Traffic engineering information may include node and interface identifiers for routers 4; administrative weights and available bandwidth for each priority level of a link; LSP identifiers and status information for virtual links; and other information used to calculate paths for traffic engineering LSPs. Controller 52 may store the traffic engineering information in a traffic engineering database (TED).

[0048] In this example, the controller 52 presents a northbound interface 20 that can be called by other controllers in the controller hierarchy or by an orchestrator, administrator, application, or other entity to present the business requirements 32 of the logical network 6. The interface 20 can be used to integrate with an orchestration system such as OpenStack; the interface 20 can also be used or alternatively used by other applications or an operator's operations support system (OSS) / business support system (BSS). In some cases, the interface 20 can present a RESTful application programming interface (API). The interface 20 can also present a GUI / CLI by which a network operator can access network management tools, including, for example, a path computation module 58, to obtain information about the operation of and program the multi-layer network 60.

[0049] The controller 52 includes a path computation module 58 and, in some cases, a path setup module 26 for respectively computing and setting paths between path computation clients (e.g., routers) in the network. As further described below, the path computation module 58 can intelligently compute and establish requested paths across a path computation domain (e.g., the logical network 6). When computing paths, the path computation module 58 schedules the paths for setup by the path setup module 26.

[0050] For example, controller 52 determines the topology of network links 9 of logical network 6 through which router 4 can switch network traffic flows 30 in order to satisfy the SR policy corresponding to traffic flows 30. Controller 52 can determine the logical network topology of logical network 6 to ensure sufficient capacity for components of transport network 54 and to facilitate an optimized total resource cost for transporting traffic for logical network 6. Controller 52 obtains a set of candidate links available for use as network links in logical network 6. Additionally, in some cases, controller 52 obtains abstract link data 56 that describes the shared risk encountered by these candidate links along their physical (transmission) paths. In some cases, abstract link data 56 also defines available candidate links and may define additional abstract links that have already been configured and activated in logical network 6. In other words, in such cases, abstract link data 56 is the mechanism by which topology computation module 58 obtains the set of candidate links. In some cases, abstract link data 56 may also include information relevant to path optimization, such as the physical length or latency of the links.

[0051] In this way, the abstract link data 56 represents data that is "leaked" from the transport network 54 to the controller 52 in some way so that other constraints of the controller 52 can be applied to the destination of the path and the corresponding candidate link on which the traffic is routed. Such constraints can correspond to the type of abstract link data 56, which can include available candidate links, link lengths, link metrics (which can be based on link lengths), link costs (which can also be based on link lengths), and a list of shared risk link groups (SRLGs) for the links. Information describing the candidate links can include available links and associated link metrics, link costs, and / or SRLGs on the links. The combination of the topology information of the logical network 6 and the obtained candidate links defines a network topology model of the logical network 6. The model can include a metric graph that is rooted at the source network node and is shown next to the path tree representing the multiple paths.

[0052] Path computation module 58 determines the router 4 on which to direct packets mapped to the SR policy. Path computation module 58 applies path computation based on traffic engineering data 21 and / or abstract link data 56 to compute candidate paths, such as multiple paths, that satisfy the SR policy. The computed paths of the multiple paths can be placed into the model of the logical network layer 6, allowing links 9 to be mapped to paths in the multiple paths. Path computation module 58 then schedules the computed and placed paths for setup by path setup module 26, which in turn sets the computed paths in the network.

[0053] In some examples, controller 52 may calculate and set multiple multipaths in logical network 6 that correspond to different respective SR policies. The multiple multipaths may be calculated and placed in a model of logical network 6 in a specific order. Generally, controller 52 may calculate and place the multiple multipaths based on the order in which the SR policies are received. For example, controller 52 may receive a first SR policy and calculate a first multipath that satisfies the first SR policy. Controller 52 may place the traffic requirements specified by the SR policies in the model of logical network 6. Controller 52 may receive a second SR policy and calculate and place a second multipath in the model of logical network 6. However, in some examples, calculating the multipaths and placing the multipaths in the initial ("first") order may not result in the most efficient use of resources (e.g., bandwidth) for the multipaths set in logical network 6. For example, assume that controller 52 initially receives a first SR policy that specifies a traffic requirement (e.g., traffic requirement 32) corresponding to an end-to-end traffic flow that traverses logical network 6 from router 4A or 4B to router 4F for non-priority traffic (e.g., low-bandwidth traffic). Controller 52 calculates and sets a first plurality of multipaths using one or more of links 9 of logical network 6, corresponding to a first SR policy. In this example, controller 52 may arbitrarily map one or more links 9 to implement the first plurality of multipaths for non-priority traffic. In this example, the bandwidth usage of the links by the first plurality of multipaths may consume most, if not all, of the available bandwidth of these links. If controller 52 subsequently receives a second SR policy that specifies traffic requirements corresponding to another end-to-end traffic flow that traverses logical network 6 from router 4A or 4B to router 4F for high-priority traffic (e.g., high-bandwidth traffic), path computation module 58 may be unable to map certain links in the first plurality of multipaths to implement the second plurality of multipaths, even though these links may be more suitable for the second plurality of multipaths. Consequently, path computation module 58 may map different one or more links 9 to implement the second plurality of multipaths, which may be less desirable for high-priority traffic (e.g., high-bandwidth traffic). Because the calculation and placement of the first plurality of multipaths can occur before the calculation and placement of the second plurality of multipaths, the paths in the second plurality of multipaths can be placed on less optimal paths. In these examples, it may be desirable to calculate the paths in the multipaths and place the paths in the multipaths in a different order, which can result in a more optimal use of resources by the multipaths.

[0054] According to the techniques described in this disclosure, the controller 52 may include an optimization module 57 to provide optimization for multipaths that support segment routing. Assume, for example, that a logical network 6 is configured with a first plurality of multipaths. In this example, the optimization module 57 may calculate the overall usage of a metric (e.g., bandwidth) for the first plurality of multipaths, which is configured in the logical network layer 6. For example, the optimization module 57 may calculate, for each link in the links 9 in the logical network 6, the bandwidth usage of the link by all paths in the first plurality of multipaths, which is configured in the logical network layer 6. For example, the optimization module 57 may obtain traffic engineering information 21, which includes information such as an administrative weight and available bandwidth for each priority level of the link 9 and / or abstract link data 56 that describes the shared risk encountered by the link 9 of the path configured in the logical network 6 on its physical (transmission) path and / or information about the physical length or delay of the link. Based on this information, optimization module 57 can determine the bandwidth usage of link 9 by all paths in a first plurality of multipaths, which are provided in logical network layer 6. In some examples, optimization module 57 can calculate the total weighted bandwidth usage of the first plurality of multipaths by calculating a ratio of the total bandwidth usage of the link by the first plurality of multipaths to the total bandwidth capacity of the link used by the first plurality of multipaths.

[0055] As an example, link 9H is used to implement a multipath that includes a first path (“4A-4D-4F path”) of routers 4A, router 4D, and router 4F, and a second path (“4B-4D-4F path”) of routers 4B, router 4D, and router 4F. Link 9H can contribute a portion of the link's bandwidth (e.g., bandwidth capacity) for traffic placed on the 4A-4D-4F path, and can also contribute another portion of the link's bandwidth for traffic placed on the 4B-4D-4F path. In this example, optimization module 57 can determine the total bandwidth usage of link 9H by the first and second paths in the multipath, and can similarly determine the total bandwidth usage of the other links in all paths in the multipath to determine the total bandwidth usage of the multipath. Alternatively or additionally, optimization module 57 can calculate the delay of the first plurality of multipaths. The overall usage metric can include bandwidth, delay, or other metrics associated with the first plurality of multipaths.

[0056] The optimization module 57 can optimize the first plurality of multipaths arranged in the network layer by calculating the multipaths and placing the multipaths in a different order (referred to herein as the "second plurality of multipaths"). For example, the optimization module 57 can implement one or more heuristic algorithms and / or countermeasures to reorder the calculation and placement of one or more paths in the first plurality of multipaths to the model of the logical network layer 6. The heuristic algorithms and / or countermeasures can include a greedy algorithm, a randomization function, or any other algorithm and / or countermeasure to reorder the calculation and placement of the multipaths, such as sorting the multipaths based on the priorities assigned to the multipaths.

[0057] Because the order in which the paths are calculated and placed in the logical network layer 6 may cause the controller 52 to calculate the paths in the second plurality of multipaths with different links, this may result in different overall usage of the metric by the second plurality of multipaths. In this example, the optimization module 57 may calculate the bandwidth usage of the link for all paths in the second plurality of multipaths for each link in the links 9 to calculate the overall usage of the second plurality of multipaths. In some examples, the optimization module 57 may calculate a weighted bandwidth usage (e.g., a ratio of the total bandwidth usage of the second plurality of multipaths to the total bandwidth capacity of the links used by the second plurality of multipaths).

[0058] The optimization module 57 may then compare the total bandwidth usage of the second plurality of multipaths with the total bandwidth usage of the first plurality of multipaths. If the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths, the optimization module 57 may cause the controller 52 to place the second plurality of multipaths in the logical network 6. If the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths, the controller 57 may perform the next iteration of the heuristic algorithm and / or countermeasure and / or leave the multipaths placed in the logical network 6 unchanged. Figure 2 Additional examples of the optimization process are described in .

[0059] In some examples, optimization module 57 may assign corresponding priorities to one or more multipaths to optimize (or not optimize) the multipaths. For example, optimization module 57 may use a priority module (not shown) to assign priorities to one or more multipaths (which are set in logical network 6) to prevent any changes or modifications to these multipaths. Alternatively or additionally, optimization module 57 may assign priorities to one or more multipaths (which are set in logical network 6) to support changes or modifications to the calculation and placement of these multipaths.

[0060] In some examples, optimization module 57 may additionally or alternatively determine the quality of the multipaths. For example, multipaths calculated and placed into the model of logical network 6 earlier may be more robust to link failures (e.g., have many alternative paths), and multipaths calculated and placed into the model of logical network 6 later may leave a smaller number of paths. In these examples, optimization module 57 may identify multipaths with a greater number of paths, from which optimization module 57 may shift link bandwidth to multipaths with fewer paths, or provide constraints on the calculation and placement of multipaths that occurred earlier. For example, optimization module 57 may calculate and place all multipaths with an equal distribution of resources and / or number of paths to avoid instances where some multipaths have a greater number of paths and some multipaths have a smaller number of paths (e.g., only one).

[0061] Figure 2 is a block diagram illustrating an example system 200 having a multi-layer network 60 and a controller 52 configured to provide optimization for a multi-path network supporting segment routing according to techniques described in this disclosure. Figure 1 For example, system 200 implements SR policy 202 ("4A / 4B-4F with bandwidth constraint") by computing and setting a first multipath in logical network 6 from source routers 4A and 4B to destination router 4F.

[0062] The first multipath set in logical network 6 may include path 206 from source router 4A or 4B to destination router 4F. In this example, path 206 includes the paths of routers 4A, 4D, and 4F located on links 9C and 9H, respectively (“4A-4D-4F path”); the paths of routers 4B, 4D, and 4F located on links 9E and 9H, respectively (“4B-4D-4F path”); the paths of routers 4A, 4C, 4E, and 4F located on links 9B, 9F, and 9I, respectively (“4A-4C-4E-4F path”); the paths of routers 4B, 4D, and 4F located on links 9E and 9H, respectively (“4B-4D-4F path”); the paths of routers 4A, 4C, 4E, and 4F located on links 9B, 9F, and 9I, respectively (“4A-4C-4E-4F path”); The paths of routers 4A, 4D, 4E, and 4F on links 9C, 9G, and 9I ("4A-4D-4E-4F path") are included; the paths of routers 4B, 4C, 4E, and 4F on links 9D, 9F, and 9I are included ("4B-4C-4E-4F path") are included; and the paths of routers 4B, 4D, 4E, and 4F on links 9E, 9G, and 9I are included ("4B-4D-4E-4F path") are included. For ease of explanation, Figure 2Although illustrated as having a single multipath set in logical network 6, logical network 6 may also be provided with multiple multipaths corresponding to different respective segment routing strategies. The multiple multipaths set in logical network 6 may be referred to herein as "first multiple multipaths."

[0063] According to the techniques described in this disclosure, the controller 52 may include an optimization module 57 to provide optimization for a multipath supporting segment routing. In this example, the optimization module 57 may determine the total bandwidth usage of paths in a multipath (e.g., path 206 in a first multipath and other paths in other multipaths), which are set in the network layer 6. In this example, the optimization module 57 may obtain traffic engineering information 21 and / or abstract link data 56 for links 9B, 9C, 9D, 9E, 9F, 9G, 9H, and 9I (collectively referred to as "path links 9"), which describes the shared risk encountered by path links 9 on their physical (transmission) paths and / or information about the physical length or delay of path links 9. Based on this information, the optimization module 57 may calculate the bandwidth usage of the links for all paths 206 in the first multipath for each path link in path links 9 to calculate the total usage of the first multipath. As an example, the optimization module 57 may use the following function to calculate the total usage of the links:

[0064] LinkDir.use=∑(pm∈LinkDir.PathMem)pm.BWFrac*pm.PathLinks.PathsOption.LinkDir.cap

[0065] In the above example, "LinkDir.use" represents all usage of directed links within the network layer (e.g., logical network 6) to implement multipathing. "LinkDir.use" is calculated, for example, by summing all usage of bandwidth by links across all paths using the link in multipathing. For example, "pm" represents a path member (e.g., a specific path corresponding to an SR policy), and "LinkDir.PathMem" represents a specific link of the path. The bandwidth usage of a link is calculated by multiplying the portion of the bandwidth used by the link (e.g., "pm.BWFrac") by the bandwidth capacity of the link for all path options, which is represented by "pm.PathLinks.PathsOption.LinkDir.cap".

[0066] In order to determine the total bandwidth usage of the path links 9 by all paths 206 in the first multipath (which is provided in the logical network 6), the optimization module 57 calculates the bandwidth usage of each path link in the path links 9. Figure 2In the example shown in FIG, the bandwidth usage of path 206 in the first multipath for link 9B is calculated by multiplying the bandwidth portion of link 9B (e.g., 0.125) by the bandwidth capacity (e.g., 1 gigabit (Gb) of traffic), which is a total bandwidth usage of 125 megabytes (MB) for link 9B. Similarly, the bandwidth usage of path 206 in the first multipath for link 9D is calculated by multiplying the bandwidth portion of link 9D (e.g., 0.375) by the bandwidth capacity, which is a total bandwidth usage of 375 MB for link 9D. The total bandwidth usage of each path link in path 206 is calculated and aggregated to calculate the total bandwidth usage of the multipaths configured in logical network 6. As described above, optimization module 57 can similarly calculate the overall usage of other multipaths configured in logical network 6.

[0067] Optimization module 57 may optimize the multipaths (referred to herein as "second multipaths") configured in logical network 6 by calculating one or more paths from the first multipaths and placing the one or more paths from the first multipaths in a different order. For example, optimization module 57 may calculate the second multipaths for a corresponding segment routing policy. For example, optimization module 57 may calculate the paths from the second multipaths and place the paths from the second multipaths into a model of logical network 6 in a second order that is different from the first multipaths. In some examples, optimization module 57 may implement one or more heuristic algorithms and / or countermeasures to reorder the calculation and placement of one or more paths from the multipaths configured in the network.

[0068] As an example, the optimization module 117 can implement a greedy algorithm, wherein the optimization module 57 can calculate and place the paths in the multipath starting from the largest path (e.g., the path with the highest bandwidth usage) to the smallest path (e.g., the path with the lowest bandwidth usage). The optimization module 57 can then calculate the bandwidth usage of all paths in the second plurality of multipaths for each path link in the path links 9 to calculate the overall usage of the second plurality of multipaths.

[0069] Optimization module 57 may then determine whether the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths. If the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths, optimization module 57 may cause controller 52 to place the second plurality of multipaths in logical network 6. If the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths, optimization module 57 may perform the next iteration of the greedy algorithm, such as calculating and placing the paths in the multipaths starting from the second largest path (e.g., the path with the second highest bandwidth usage) to the smallest path (e.g., the path with the lowest bandwidth usage), and determine whether the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths. In some examples, if the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths and a given time limit has been exceeded, the multipaths placed in logical network 6 remain unchanged.

[0070] Alternatively or additionally, the optimization module 117 may calculate and place one or more paths in the second plurality of paths based on a random order. For example, the optimization module 57 may select a subset of paths in the multipaths provided in the logical network 6 and then randomize the order in which the subset of paths is calculated and placed. The optimization module 57 may then calculate the bandwidth usage of the link for all paths in the second plurality of paths for each path link 9 to calculate the overall usage of the second plurality of paths.

[0071] Optimization module 57 may then determine whether the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths. If the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths, optimization module 57 may cause controller 52 to place the second plurality of multipaths in logical network 6. If the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths, optimization module 57 may perform another iteration of the randomization function, such as selecting another subset of paths placed in logical network 6, then randomizing the order in which the path subsets are calculated and placed, and determining whether the total bandwidth usage of the second plurality of multipaths is less than the total bandwidth usage of the first plurality of multipaths. In some examples, if the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths and a given time limit has been exceeded, the multipaths placed in logical network 6 remain unchanged.

[0072] In some examples, the optimization module 57 may assign a corresponding priority to one or more paths in the multipath to optimize (or not optimize) the path. For example, the optimization module 57 may use a priority module (not shown) to assign a priority to one or more multipaths (which are set in the logical network 6) to prevent any changes or modifications to these multipaths. For example, the multipath including path 206 may be assigned a priority (e.g., as a high-priority multipath) to prevent any changes or modifications to the multipath. Alternatively or additionally, the optimization module 57 may assign a priority to one or more multipaths (which are set in the logical network 6) to support changes or modifications to the calculation and placement of these multipaths.

[0073] In some examples, if a greedy algorithm is used, the order in which paths are calculated and placed may also be defined by the assigned priorities. For example, the optimization module 57 may calculate and place paths in the multipath starting from the highest priority path to the lowest priority path.

[0074] Figure 3 is a block diagram illustrating an example controller according to the techniques of the present disclosure, which is configured to provide optimization of multi-paths supporting segment routing. In response to receiving a demand, the controller 100 calculates and outputs a logical network topology that meets the business requirements of the logical network 6. For example, the controller 100 may include a server or a network controller, and may represent Figure 1 1. In some cases, controller 100 may represent an example network management system that may not be capable of setting paths but is used by network operators for network planning and analysis purposes. In this case, controller 100 may not include path setting module 118 and may include an interface similar to interface 23 for outputting a representation of the selected links of the solution.

[0075] The controller 100 includes a control unit 102 coupled to a network interface 110 for exchanging packets with other network devices via one or more inbound links 122 and one or more outbound links 124. The main memory 108 of the control unit 102 represents one or more computer-readable storage media, which may include random access memory (RAM), such as various forms of dynamic RAM (DRAM), for example, DDR2 SDRAM; or static RAM (SRAM); flash memory; or any other form of fixed or removable storage medium that can be used to carry or store desired program code and program data in the form of instructions or data structures and that can be accessed by a computer. The main memory 108 provides a physical address space consisting of addressable memory locations accessible by the modules 112, 104.

[0076] The main memory 108 is coupled to the disk 127, which may include computer-readable storage media, including volatile and / or nonvolatile, removable and / or non-removable media implemented in any method or technology for storage of information (such as processor-readable instructions, data structures, program modules, or other data). Computer-readable storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), EEPROM, flash memory, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store data and instructions.

[0077] The control unit 102 in this example includes a multi-core computing platform 111 to execute modules 104 and 112. The multi-core computing platform includes multiple processing cores, each of which includes an independent execution unit to execute instructions that conform to the instruction set architecture for the core. The cores of the multi-core computing platform 111 can each be implemented as a separate integrated circuit (IC) or can be combined in one or more multi-core processors (or "multi-core" processors) that are each implemented using a single IC (i.e., a chip multiprocessor).

[0078] The multi-core computing platform 111 executes software instructions, such as those defining software or computer programs stored to the main memory 108. Alternatively or additionally, the control unit 102 may include dedicated hardware for performing the techniques described herein, such as one or more integrated circuits, one or more application specific integrated circuits (ASICs), one or more application specific processors (ASSPs), one or more field programmable gate arrays (FPGAs), or any combination of one or more of the foregoing dedicated hardware examples.

[0079] The control unit 102 provides an operating environment for the network service application 104 and the topology element 112. In some examples, these modules can be implemented as one or more processes that execute on one or more virtual machines of one or more servers. That is, although the modules 104 and 112 are generally illustrated and described as executing on a single controller 100, aspects of the modules 104 and 112 can be executed on other computing devices or on different virtual machines of one or more computing devices.

[0080] The network service applications 104 represent one or more processes that provide services to clients of a service provider network including the logical network 6 and the controller 100 to manage connectivity in a path computation domain. The network service applications 104 can provide, for example, movie, television, or other media content distribution, voice over IP (VoIP), video on demand (VOD), bulk transfer, walled / open garden, IP mobility subsystem (IMS), and other mobility services, as well as Internet services to clients of the service provider network controlled at least in part by the controller 100. The network service applications 104 can publish a request for transport services of the logical network 6 to the topology element 112. One or more of the network service applications 104 can include or otherwise utilize a client interface 106 through which one or more client applications request transport services. For example, the client interface 106 can represent a command line interface (CLI) or a graphical user interface (GUI). The client interface 106 can also or alternatively provide an application programming interface (API), such as a web service, to the client applications.

[0081] The network service application 104 may issue a demand to the topology element 112 requesting a corresponding path in the path computation domain from a source to a destination controlled by the controller 100. For example, the demand may include a required bandwidth or other constraint and two endpoints representing a source and a destination communicating through the path computation domain managed by the controller 100. The control unit 102 stores the demand as a list of demands in a demand 128 data structure ("demands 128"). In some cases, a service provider or other administrator of the logical network 6 may configure one or more of the demands 128 via a management interface. In some cases, the topology element 112 may additionally or alternatively derive the predicted demands 128 based on demand patterns previously experienced by the logical network 6.

[0082] Topology element 112 accepts requests for routing services between endpoints in response to requests for path computation domains. Requests can be made for different times and dates, as well as for different bandwidth requirements. Topology element 112 can reconcile requests from network service applications 104 based on request parameters and network resource availability to multiplex the requested paths for the corresponding services onto the path computation domains of logical network 6.

[0083] To intelligently calculate the topology of the logical network 6, the topology element 112 may in some cases include a topology module 116 to receive traffic engineering information (such as Figure 1The topology module 116 may also include traffic engineering information 21 describing the available resources of the logical network 6, which includes the routers 4 and their interfaces and the interconnecting network links 9. The topology module 116 may execute one or more southbound protocols (such as Open Shortest Path First with Traffic Engineering Extensions (OSPF-TE), Intermediate System to Intermediate System with Traffic Engineering Extensions (ISIS-TE), and BGP Link State (BGP-LS)) to learn the traffic engineering information of the logical network 6.

[0084] Traffic engineering database (TED) 126 stores traffic engineering information received by topology module 116 for logical network 6, which constitutes the path computation domain of controller 100. TED 126 may include one or more link state databases (LSDBs), where link and node data is received in routing protocol advertisements, received from a topology server, and / or discovered by a link layer entity (such as an overlay controller), which then provides this link and node data to topology module 116. In some cases, a service provider or other management entity may configure traffic engineering or other topology information within TED 126 via a management interface.

[0085] The path computation module 114 of the topology element 112 may compute a path that satisfies the network layer (eg, Figure 1 In some cases, the path computation module 114 may represent Figure 1 1 . The path computation module 114 obtains abstract link data 56 that describes candidate links of the logical network 6 and the shared risks encountered by these candidate links along their physical (transmission) paths, as well as information related to path optimization, such as the physical length or latency of the links. The abstract link data 56 can be stored in the TED 126. In some examples, the path computation module 114 obtains optical network data 750 of the optical transport network 54. The optical network data 750 includes data that describes the optical equipment of the optical transport network 54 and can be used by the controller 100 to determine the value of optical path impairments. The controller 100 can determine candidate links for routing in the logical network 6 with feasible optical paths based on the optical network data 750. The path computation module 114 can calculate paths mapped to the candidate links and place the paths into the network layer model.

[0086] The path computation module 114 has selected and routed candidate links for the logical network 6, and the path setup module 118 attempts to set the routing path of the candidate links on the logical network 6. The path setup module 118 of the controller 100 may program the path into the logical network 6 so that the state of the logical network 6 matches the state of the logical network 6 as determined by the path computation module 114. The path setup module 118 may indicate Figure 1 , an example of a path setup module 26. Setting up a path may require path validation before committing the path to provide packet transmission. The path setup module 118 executes one or more southbound protocols for path setup to inject state into elements of the logical network 6 (such as any one or more of the routers 4). Southbound protocols refer to protocols by which components of the controller 100 can communicate with network 6 elements (such as routers 4) to obtain or inject topology information, forwarding, and other network information that determines the operation of the logical network 6. For example, southbound protocols may include Path Computation Element (PCE) Communication Protocol (PCEP), Open Shortest Path First with Traffic Engineering Extensions (OSPF-TE), Intermediate System to Intermediate System with Traffic Engineering Extensions (ISIS-TE), BGP Link State (BGP-LS), NETCONF / Yang, Routing System Interface (I2RS) protocol, CLI of network elements, Simple Network Management Protocol (SNMP), and OpenFlow (or other SDN configuration protocols).

[0087] According to the techniques described in this disclosure, path computation module 114 may include optimization module 117 to provide optimization of multiple paths (e.g., a first plurality of paths) supporting segment routing in view of requirement 128 by computing one or more paths in the multiple paths (e.g., a second plurality of paths) and placing the one or more paths in a different order, and placing the second plurality of paths if the second plurality of paths has an overall usage of a metric that is less than the overall usage of the metric by the first plurality of paths. Optimization module 117 may indicate Figure 1 An example of an optimization module 57.

[0088] The optimization module 117 can use data (e.g., traffic engineering information 21 and / or abstract link data 56) to determine the overall usage of a metric (e.g., bandwidth) for multiple paths arranged in the logical network 6, the data describing the links used to implement the paths in the multipath. The optimization module 117 can calculate the usage of the metric for all paths in the multipath for each link in the links used to implement the paths in the multipath to calculate the overall usage of the metric for the multiple paths. As described above, the optimization module 117 can implement one or more heuristic algorithms and / or countermeasures ("countermeasures 134") to define the order in which one or more paths in the multipath are calculated and placed. The countermeasures 134 can include algorithms and / or countermeasures (such as greedy algorithms, randomization functions, or any other algorithms and / or countermeasures) to order the calculation and placement of paths, such as based on the priorities assigned to the paths. The optimization module 117 can then calculate the overall usage of the metric for the second plurality of paths and arrange the second plurality of paths if the overall usage of the metric for the second plurality of paths is less than the overall usage of the metric for the first plurality of paths. If the total bandwidth usage of the second plurality of multipaths is not less than the total bandwidth usage of the first plurality of multipaths, then the optimization module 117 may leave the multipaths arranged in the logical network 6 unchanged and / or perform the next iteration of the heuristic algorithm and / or countermeasure.

[0089] In some examples, the optimization module 117 includes a prioritizer module 132 to assign priorities to one or more paths in the multipath to control which paths set in the network layer will be optimized (or not optimized). For example, the optimization module 117 can use the prioritizer module 132 (not shown) to assign priorities to one or more paths in the multipath (which are set in the logical network 6) to prevent any changes or modifications to these paths. Alternatively or additionally, the prioritizer module 132 can assign priorities to one or more paths in the multipath (which are set in the logical network 6) to support changes or modifications to the calculation and placement of these paths.

[0090] In some examples, optimization module 117 can additionally or alternatively determine the quality of the multipaths. For example, multipaths calculated and placed into the model of logical network 6 earlier may be more robust to link failures (e.g., have many alternative paths), and multipaths calculated and placed into the model of logical network 6 later may leave a smaller number of paths. In these examples, optimization module 117 can identify multipaths with a greater number of paths, from which optimization module 117 can shift link bandwidth to multipaths with fewer paths, or provide constraints on the calculation and placement of multipaths that occurred earlier. For example, optimization module 117 can calculate and place all multipaths with an equal distribution of resources and / or number of paths to avoid instances where some multipaths have a greater number of paths while some multipaths have a smaller number of paths (e.g., only one).

[0091] Figure 4 is a block diagram illustrating an example of a controller according to the technology of the present disclosure in more detail. The controller 100 may represent Figure 3 Example implementations of the controller 100. For example, the controller 100 may be or implement a WAN controller, a software defined network (SDN) controller, and / or a path computation element.

[0092] In general, the path computation module 414 and path setup module 418 of the controller 100 can use protocols to instantiate paths between path computation clients (e.g., routers) in the network. The southbound API 432 allows the controller 100 to communicate with SR-enabled network nodes and other network nodes (e.g., routers and switches in the network) using protocols such as ISIS, OSPFv2, BGP-LS, and PCEP. By providing a view of the global network state and bandwidth requirements in the network, the controller 100 can calculate the best path and configure the network to forward using SID lists in the SR paradigm.

[0093] In some examples, an application service issues a path request to the controller 100 requesting a path in a path computation domain controlled by the controller 100. For example, the path request includes a required bandwidth or other constraints and two endpoints representing an access node and an edge node communicating through the path computation domain managed by the controller 100. The path request can further specify a time / date when the path must be operational and CoS parameters (e.g., required bandwidth for each class of certain paths).

[0094] The controller 100 accepts path requests from application services to establish paths between endpoints within the path computation domain. Path requests can be made for different times and dates, as well as for different bandwidth requirements. The controller 100 coordinates the path requests from application services based on the requested path parameters and expected network resource availability, multiplexing the requested paths onto the path computation domain.

[0095] To intelligently compute and establish paths through the path computation domain, the controller 100 includes a topology module 416 to maintain topology information (e.g., within a traffic engineering database 442) that describes the available resources of the path computation domain, including access, aggregation, and edge nodes, their interfaces, and interconnecting communication links.

[0096] The path calculation module 414 of the controller 100 calculates the requested path through the path calculation domain. Generally, a path is unidirectional. After calculating the path, the path calculation module 414 schedules the path for setup by the path setup module 418. The calculated path includes path information that the path setup module 418 can use to establish the path in the network. Setting up the path may require path validation before committing the path to provide packet transmission.

[0097] Additional example details of a distributed WAN controller can be found in U.S. Patent 9,450,817, entitled "Software Defined Network Controller," which is incorporated herein by reference in its entirety. This is merely an example, and the controller 100 may calculate and set paths in other ways.

[0098] In this example, the controller 100 includes northbound and southbound interfaces in the form of a southbound application programming interface (API) 430 and a southbound API 432. The southbound API 430 includes methods and / or accessible data structures through which application services, as mentioned above, can configure and request path computation within the path computation domain and query established paths. The southbound API 432 includes methods and / or accessible data structures through which the controller 100 receives topology information for the path computation domain and establishes paths by accessing and programming the data planes of aggregation nodes and / or access nodes within the path computation domain.

[0099] Path computation module 414 includes data structures to store path information for calculating and establishing requested paths. These data structures include constraints 434, path requirements 436, operational configuration 438, and path exports 440. Application services can call northbound API 430 to install / query data from these data structures. Constraints 434 represent data structures that describe external constraints after path computation. Constraints 434 allow application services to modify link attributes, such as metrics, before path computation module 414 calculates a set of paths.

[0100] Application services can modify the attributes of a link to influence the resulting traffic engineering calculations. In such cases, the link attributes can override the attributes received from the topology indication module 450 and remain valid for the duration of the node / companion port in the topology. The link edit message for constraint 434 can include a link descriptor specifying a node identifier and port index, and link attributes specifying, for example, bandwidth, expected transmission time, shared link groups, and fate sharing groups. The link edit message can be sent by the controller 100.

[0101] Operational configuration 438 represents a data structure that provides configuration information to controller 100 for configuring the path computation algorithm with respect to, for example, class of service (CoS) descriptors and detour behavior. Operational configuration 438 may receive operational configuration information based on the CCP. For example, the operational configuration message specifies CoS values, queue depths, queue depth priorities, scheduling rules, overprovisioning factors, detour types, path failure modes, and detour path failure modes. A single CoS profile may be used for the entire path computation domain. Example CoS values ​​are described in U.S. application Ser. No. 13 / 842,453, filed Mar. 15, 2013, entitled “Aggregation Network with Centralized Control,” the entire contents of which are incorporated herein by reference. The class of service assigned to a class of service may be node-independent as an attribute of the path computation domain.

[0102] The path egress 440 represents an interface that stores path descriptors for all paths currently committed or established in the path computation domain. In response to a query received via the northbound API 430, the path egress 440 returns one or more path descriptors. The received query may request a path between any two edges and an access node terminating the path(s). In some examples, the path descriptors may be used by an application service to establish forwarding configurations at the edges and access nodes terminating the path(s). The path descriptors may include explicit routing objects (EROs). Path descriptors or "path information" may be sent in response to a query from an interested party. The path egress message conveys path information, including path type (primary or detour); bandwidth for each CoS value. In response to receiving a path descriptor, the receiving device may use RSVP-TE to signal the MPLS LSP from the ingress to the egress of the path.

[0103] Path requirements 436 represent an interface that receives path requests for paths to be calculated by path computation module 436 and provides these path requests (including path requirements) to path engine 444 for computation. Path requirements 436 may be received by a controller or may be processed by the controller. In such cases, a path requirement message may include a path descriptor having an ingress node identifier and an egress node identifier of a node terminating a specified path; and request parameters including a CoS value and bandwidth. A path requirement message may be added to or removed from an existing path requirement for a specified path.

[0104] The topology module 416 includes a topology indication module 450 to handle topology discovery and maintain control channels between the controller 100 and nodes of the path computation domain when needed. The topology indication module 450 may include an interface for describing the received topology to the path computation module 414.

[0105] The topology indication module 450 can use a topology discovery protocol to describe the path computation domain topology to the path computation module 414. In one example, using a cloud control protocol mechanism for topology discovery, the topology indication module 450 can receive a list of node neighbors, where each neighbor includes a node identifier, a local port index, a remote port index, and a list of link attributes, for example, the link attributes specifying a port index, a bandwidth, an expected transmission time, a shared link group, and a fate sharing group, respectively.

[0106] The topology indication module 450 can communicate with a topology server (such as a routing protocol route reflector) to receive network layer topology information for the network. The topology indication module 450 can include a routing protocol process that executes a routing protocol to receive routing protocol advertisements, such as Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS) Link State Advertisements (LSAs) or Border Gateway Protocol (BGP) UPDATE messages. In some cases, the topology indication module 450 can be a passive listener that neither forwards routing protocol advertisements nor creates routing protocol advertisements. In some cases, the topology indication module 450 can alternatively or additionally execute a topology discovery mechanism, such as an interface for an Application Layer Traffic Optimization (ALTO) service. Thus, rather than executing a routing protocol to directly receive routing protocol advertisements, the topology indication module 450 can receive a summary of topology information collected by a topology server (e.g., an ALTO server).

[0107] In some examples, the topology indication module 450 receives topology information including traffic engineering (TE) information. The topology indication module 450 may, for example, implement Intermediate System to Intermediate System (IS-IS-TE) with TE extensions or Open Shortest Path First (OSPF-TE) with TE extensions to receive TE information for advertised links. This TE information includes one or more of the following: link status, management attributes, and metrics, such as bandwidth available for various LSP priority levels for the link, the link connecting routers in the path computation domain. In some cases, the indication module 450 implements BGP-TE to receive advertised TE information for inter-autonomous system links and other extra-network links.

[0108] A traffic engineering database (TED) 442 stores topology information received by the topology indication module 450 for a network constituting a path computation domain to a computer-readable storage medium (not shown) for the controller 100. The TED 442 may include one or more link state databases (LSDBs) in which link and node data is received in routing protocol advertisements, received from a topology server, and / or discovered by a link layer entity (such as an overlay controller) and then provided to the topology indication module 450. In some cases, an operator may configure traffic engineering or other topology information within the TED 442 via a client interface. In some cases, the TED 442 may also store abstract link data (e.g., Figure 1 Abstract link data 56) that describes candidate links of the path computation domain and the shared risks encountered by these candidate links on their physical (transmission) paths, as well as information related to path optimization, such as the physical length or delay of the links.

[0109] The path engine 444 accepts a current topology snapshot of the path computation domain in the form of TEDs 442 and uses the TEDs 442 to compute traffic engineering paths between nodes as dictated by configured node-specific policies (constraints 434) such as SR policies and / or by dynamic networking with external modules via an API.

[0110] In general, to compute a requested path, path engine 444 determines whether a path exists in the network layer based on TED 442 and all specified constraints that satisfies the TE specifications for the requested path for the duration of the requested time. Path engine 444 may use the Dijkstra-constrained SPF (CSPF) path computation algorithm to identify a satisfactory path through the path computation domain. If no TE constraints exist, path engine 444 may revert to SPF. If a satisfactory computed path exists for the requested path, path engine 444 provides the computed path's path descriptor to path manager 448 for path setup module 418 to establish the path. The path computed by path engine 444 may be referred to as a "computed" path until path setup module 418 programs the scheduled path into the network, at which point the scheduled path becomes an "active" or "committed" path. A scheduled or active path is a temporary, dedicated bandwidth channel for a scheduled time during which the path is, or will become, operational for the transport flow.

[0111] The path manager 448 establishes the calculated scheduling path using a path setup module 518, which in this case includes a forwarding information base (FIB) configuration module 552 (illustrated as "FIB CONFIG. 552"), a policer configuration module 554 (illustrated as "POLICER CONFIG. 554"), and a CoS scheduler configuration module 556 (illustrated as "COS SCHEDULER CONFIG. 556"). Figure 1 The paths established within the logical network 6) may be referred to as “placed” paths.

[0112] The FIB configuration module 452 programs the data plane of the aggregation node or access node that forwards information to the path computation domain. The FIB of the aggregation node or access node includes an MPLS switching table, a detour path for each primary LSP, a CoS scheduler for each interface, and a policy controller at the LSP ingress. The FIB configuration module 452 can implement, for example, a software-defined network (SDN) protocol (such as, OpenFlow protocol or I2RS protocol) to provide and guide nodes to install forwarding information to their corresponding data planes. Therefore, "FIB" can refer to, for example, a forwarding table in the form of one or more OpenFlow flow tables, each of which includes one or more flow table entries that specify the handling of matching packets. The FIB configuration module 452 can also or alternatively implement other interface types, such as a Simple Network Management Protocol (SNMP) interface, a Path Computation Element Protocol (PCEP) interface, a Device Management Interface (DMI), a CLI, an interface to a routing system (I2RS), or any other node configuration interface. The FIB configuration module 452 establishes a communication session with an aggregation node or access node to install forwarding information to receive path establishment event information, such as confirmation that the received forwarding information has been successfully installed or that the received forwarding information could not be installed (indicating a FIB configuration failure).

[0113] FIB configuration module 452 can add, change (i.e., implicitly add), or delete forwarding table entries based on information received from path computation module 414. A FIB configuration message from path computation module 414 to FIB configuration module 452 can specify an event type (addition or deletion); a node identifier; a path identifier; one or more forwarding table entries, each of which includes an ingress port index, an ingress label, an egress port index, and an egress label; and a detour path specifying a path identifier and CoS mode.

[0114] The policer configuration module 454 can be called by the path calculation module 414 to request that a policer be installed on a specific aggregation node or access node for a specific LSP ingress. As mentioned above, the FIB of the aggregation node or access node includes a policer at the LSP ingress. The policer configuration module 454 can receive a policer configuration request. The policer configuration request message can specify the event type (add, change, or delete); the node identifier; the LSP identifier; and, for each service class, a policer information list including CoS values, maximum bandwidth, burst, and drop / comment. The FIB configuration module 452 configures the policer based on the policer configuration request.

[0115] The CoS scheduler configuration module 456 can be invoked by the path computation module 414 to request configuration of the CoS scheduler on an aggregation node or access node. The CoS scheduler configuration module 456 can receive CoS scheduler configuration information. For example, the scheduling configuration request message can specify an event type (change); a node identifier; a port identity value (port index); and configuration information specifying bandwidth, queue depth, and scheduling rules.

[0116] The path engine 444 can calculate a list of segment identifiers (SIDs) that satisfy each path in the multipath solution of the segment routing (SR) policy. The path setup module 418 can output the SID list to the network nodes that support SR to set up the network to forward traffic along the multiple paths.

[0117] The controller 100 includes a hardware environment that includes processing circuitry 451 for executing machine-readable software instructions to implement modules, interfaces, managers, and other components illustrated and described with respect to the controller 100. These components may be implemented solely using software or hardware or as a combination of software, hardware, or firmware. For example, the controller 100 may include one or more processors that include processing circuitry 451 that executes program code in the form of software instructions. In that case, the various software components / modules may include executable instructions stored on a computer-readable storage medium, such as a computer memory or hard disk (not shown).

[0118] According to the techniques described in this disclosure, the path computation module 414 includes an optimization module 445 to provide optimization of multiple paths that support segment routing. The optimization module 445 may represent Figure 1 Optimization module 57 and Figure 3 Example implementation of the optimization module 117. The optimization module 117 may implement a data model for determining the overall usage of multiple paths, such as Figure 7 The data model of "PathsLinks" is shown in .

[0119] In this example, path engine 444 may use optimization module 445 to optimize multipaths supporting segment routing. Optimization module 445 may implement a data model for optimizing multipaths supporting segment routing, such as Figure 8. For example, the optimization module 445 may use data (e.g., traffic engineering information and / or abstract link data stored in the TED 442) to determine the overall usage of a metric (e.g., bandwidth) by multiple paths arranged in the logical network 6, the data describing the links used to implement the paths in the multipath. The optimization module 445 may calculate, for each link in the links used to implement the paths in the multipath, the usage of the metric by all paths in the multipath to calculate the overall usage of the metric by the multiple paths. As described above, the optimization module 445 may implement one or more heuristic algorithms and / or strategies ("strategies 447") to define the order in which one or more paths in the multipath are calculated and placed. The strategies 447 may include algorithms and / or strategies (such as a greedy algorithm, a randomization function, or any other algorithms and / or strategies) to order the calculation and placement of paths, such as based on priorities assigned to the paths.

[0120] Path engine 444 may calculate the paths in the second plurality of multipaths in a certain order based on the implementation of countermeasure 447 and place the paths in the second plurality of multipaths into the model of the logical network. Optimization module 445 may then calculate the total usage of the second plurality of multipaths and place the second plurality of multipaths if the total usage of the metric by the second plurality of multipaths is less than the total usage of the metric by the first plurality of multipaths. If the total usage of the metric by the second plurality of multipaths is not less than the total usage of the metric by the first plurality of multipaths, optimization module 445 may leave the multipaths placed in the logical network unchanged and / or execute the next iteration of the heuristic algorithm and / or countermeasures.

[0121] In some examples, the optimization module 445 may include a timing module (not shown) to control the duration of the optimization process. For example, if the time limit set by the timing module has not been exceeded, the optimization module 445 may execute the next iteration of the countermeasures 447, such as reordering the calculation and placement of the paths in the multipath for the next iteration. If the time limit set by the timing module has been exceeded and no optimization scenario has been found, the multipath set in the network layer remains unchanged.

[0122] In some examples, the optimization module 445 includes a prioritizer module 446 to assign priorities to one or more multipaths to control which multipaths set in the network layer will be optimized (or not optimized). For example, the optimization module 445 can use the prioritizer module 446 to assign priorities to one or more multipaths (which are set in the logical network 6) to prevent any changes or modifications to these multipaths. Alternatively or additionally, the prioritizer module 446 can assign priorities to one or more multipaths (which are set in the logical network 6) to support changes or modifications to the calculation and placement of these multipaths.

[0123] In some examples, optimization module 445 can additionally or alternatively determine the quality of the multipaths. For example, multipaths calculated and placed into the model of logical network 6 earlier may be more robust to link failures (e.g., have many alternative paths), and multipaths calculated and placed into the model of logical network 6 later may have a smaller number of paths. In these examples, optimization module 445 can identify multipaths with a larger number of paths from the data structure of path calculation module 414 (which stores path information for the calculated paths), and optimize module 445 can shift link bandwidth from these multipaths to multipaths with fewer paths, or provide constraints on the calculation and placement of multipaths that occurred earlier. For example, optimization module 445 can calculate and place all multipaths with an equal distribution of resources and / or number of paths to avoid instances where some multipaths have a larger number of paths and some multipaths have a smaller number of paths.

[0124] Figure 5 is a block diagram illustrating an example implementation of the path engine 444 in greater detail. The path engine 444 can execute various routing protocols 570 at different layers of the network stack. The path engine 444 is responsible for maintaining routing information 560 to reflect the current topology of the network. The routing information 560 can include the TED 442 and the LSDB 580. Specifically, the routing protocol periodically updates the routing information 560 to accurately reflect the topology of the network and other entities based on routing protocol messages received by the controller 100. The protocol can be a software process executed on one or more processors. For example, the path engine 444 includes a network protocol operating at the network layer of the network stack, which is typically implemented as executable software instructions. The operations can be overlapped with, or alternatively, performed by the topology module 416.

[0125] Protocol 570 may include Border Gateway Protocol (BGP) 571 to exchange routing and reachability information between routing domains in the network and BGP-LS 572 to exchange traffic engineering and segment routing policy information between routing domains in the network. Protocol 570 may also include IGP 573 to exchange link state information and facilitate forwarding of packets or other data units between routers within each routing domain. In some examples, IGP 573 may include the IS-IS routing protocol that implements an IGP for exchanging routing and reachability information within a routing domain. IGP 573 may include IS-IS extensions to support traffic engineering. In some examples, protocol 570 may include both OSPF and IS-IS components. Protocol 570 may also include configuration protocols. For example, protocol 570 may include PCEP 574 or NETCONF.

[0126] The path engine 444 includes an SR component that implements the techniques described herein to generate SID lists for multiple paths. The SID list 586 includes one or more SID lists generated in this manner, which can be set by the controller 100 to the network for segment routing tunnels. The ingress router can use the SID to guide packets through a controlled set of instructions (called segmentation) by appending a SID label stack to the packet in a segment routing header or MPLS label stack. The protocol 570 can include other routing protocols (not shown), such as the Label Distribution Protocol (LDP), the Resource Reservation Protocol with Traffic Extensions (RSVP-TE), the Routing Information Protocol (RIP), or other network protocols.

[0127] In this example, the path engine 444 includes a command line interface (CLI) 578 that provides administrators with access to monitor, configure, or otherwise manage the controller 100. Administrators can configure aspects of the controller 100, including aspects related to routing and calculating and setting up SID lists for multipathing, via the CLI 578. The CLI 578 can support specifying sources, destinations, user constraints, preferences, SR policies, and other configurable information.

[0128] Figure 6 is a flowchart illustrating an example operation of a computing device according to the techniques of this disclosure. Figure 1 The controller 52 and Figure 2 and Figure 3 Although the operation of the computing device is described with respect to the controller 52, the operation of the computing device may be applied to Figure 1 Optimization module 57, Figure 3 The optimization module 117 and / or Figure 4 The operation of the optimization module 445.

[0129] exist Figure 6 In the example, Figure 1 The controller 52 can calculate the usage of the link's metric for all paths in a first plurality of multipaths for each link in a plurality of links in the network layer to calculate the overall usage of the first plurality of multipaths, which are set in the network layer (602). For example, the controller 52 can obtain business engineering information 21, which business engineering information 21 includes information such as management weights and available bandwidth for each priority level of the link and / or abstract link data 56, which abstract link data 56 describes the shared risk encountered by the link 9 of the multipath set in the logical network 6 on its physical (transmission) path and / or information about the physical length or delay of the link. Based on this information, the optimization module 57 can calculate the first plurality of multipaths and place the first plurality of multipaths into a model of the network layer in a first order, where the first plurality of multipaths correspond to different corresponding segment routing strategies. The controller 52 can use the business engineering information 21 and / or the abstract link data 56 to, for example, by using Figure 2 The function described in calculates the total bandwidth usage of the first plurality of multipaths. In some examples, the controller 52 may alternatively or additionally calculate the delays of the first plurality of multipaths.

[0130] The controller 52 may calculate a different ("second") plurality of multipaths for the corresponding segment routing policy (604). For example, the controller 52 may calculate a second plurality of multipaths and place the second plurality of multipaths into the network layer model in a different second order. In some examples, the controller 52 may implement one or more heuristic algorithms and / or countermeasures to reorder the calculation and placement of one or more paths of the multipath. The heuristic algorithms and / or countermeasures may include a greedy algorithm, a randomization function, or any other algorithm and / or countermeasure to reorder the placement of paths in the network layer. In some examples, the controller 52 may assign corresponding priorities to one or more multipaths to optimize (or not optimize) the multipaths. For example, the controller 52 may assign priorities to one or more multipaths (which are set in the logical network 6) to prevent any changes or modifications to the multipaths. Alternatively or additionally, the optimization module 57 may assign priorities to one or more multipaths (which are set in the logical network 6) to support changes or modifications to the calculation and placement of the multipaths.

[0131] The controller 52 may calculate the usage of the link metric for all paths in the second plurality of multipaths for each link in the plurality of links to calculate the total usage of the second plurality of multipaths (606). The controller 52 may determine whether the total usage of the second plurality of multipaths is less than the total usage of the first plurality of multipaths (608). If the controller 52 determines that the total usage of the second plurality of multipaths is less than the total usage of the first plurality of multipaths ("yes" of step 608), then the controller 52 may set the second plurality of multipaths as the best plurality of multipaths (610). In some examples, the controller 52 may include a timer configured with a time limit within which the controller 52 will perform the optimization process as described above. For example, if the timer has expired ("yes" of step 612), then the controller 52 may cause the controller 52 to set the second plurality of multipaths in the network layer (614). If the timer has not expired ("No" at step 612), then in some examples, the controller 52 may perform the next iteration of the algorithm and / or countermeasures (e.g., calculating the paths in the multipath and placing the paths in the multipath in a different order) (604) and evaluate the calculated multiple multipaths to determine whether the calculated multiple multipaths have improved. In other words, the controller 52 may continue to generate candidate changes to the multipaths and track the best option until the timer expires.

[0132] If controller 52 determines that the total usage of the second plurality of multipaths is not less than the total usage of the first plurality of multipaths ("No" at step 608), optimization module 57 may determine whether a timer has expired (616). For example, if the timer has not expired ("No" at step 616), optimization module 57 may perform the next iteration of the algorithm and / or countermeasures (e.g., calculating the paths in the multipaths and placing the paths in the multipaths in a different order) (604). In some examples, if the timer has expired ("Yes" at step 616) and no optimization scenario is found, controller 52 does not change the first plurality of multipaths set in the network layer (618).

[0133] In some examples, the controller 52 may additionally or alternatively determine the overall use of metrics to determine the quality of the multipaths. For example, the multipaths calculated earlier and placed into the model of the logical network 6 may be more robust to link failures (e.g., have many alternative paths), and the multipaths calculated later and placed into the model of the logical network 6 may leave a smaller number of paths. In these examples, the controller 52 may determine the quality of the first plurality of multipaths (e.g., determine whether the first multipaths have an unequal distribution of paths). The controller 52 may determine that the first plurality of multipaths has an unequal number of paths. In response to determining that the first plurality of multipaths has an unequal number of paths, the controller 52 may calculate a different (third) plurality of multipaths for the corresponding segment routing policy, wherein calculating the third plurality of multipaths includes calculating the multipaths in the third plurality of multipaths and placing the multipaths in the third plurality of multipaths into the model of the network layer in a third order different from the multipaths in the first plurality of multipaths. The controller 52 may set the third plurality of multipaths in the network layer in response to determining that the third plurality of multipaths has an equal number of paths.

[0134] The techniques described herein can be implemented using hardware, software, firmware, or any combination thereof. The various features described as modules, units, or components can be implemented together in an integrated logic device, or separately as discrete but interoperable logic devices or other hardware devices. In some cases, various features of the electronic circuit system can be implemented as one or more integrated circuit devices, such as an integrated circuit chip or chipset.

[0135] If implemented in hardware, the present disclosure may be directed to an apparatus such as a processor or an integrated circuit device (such as an integrated circuit chip or chipset). Alternatively or additionally, if implemented using software or firmware, the techniques may be implemented at least in part by a computer-readable data storage medium comprising instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, a computer-readable data storage medium may store such instructions for execution by a processor.

[0136] A computer-readable medium or computer-readable storage device may form part of a computer program product, which may include packaging materials. A computer-readable medium may include computer data storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, etc. In some examples, an article of manufacture may include one or more computer-readable storage media.

[0137] In some examples, computer-readable storage media may include non-transitory media. The term "non-transitory" may indicate that the storage medium is not implemented as a carrier wave or propagating signal. In some examples, non-transitory storage media may store data that may change over time (e.g., in RAM or cache).

[0138] The code or instructions may be software and / or firmware executed by a processing circuit system including one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuit systems. Thus, the term "processor," as used herein, may refer to any of the foregoing structures or any other structure suitable for implementing the techniques described herein. Furthermore, in some aspects, the functionality described in this disclosure may be provided within software modules or hardware modules.

Claims

1. A method comprising: calculating, by a computing system having a model of a multi-layer network, for each link in a plurality of links, usage of the link as measured by the metric for all paths in a first plurality of multipaths to calculate an overall usage of the first plurality of multipaths, the multi-layer network including a network layer having the plurality of links, the first plurality of multipaths being arranged in the network layer, wherein multipaths of the first plurality of multipaths have been calculated and placed into a model of the network layer in a first order, and wherein the multipaths in the first plurality of multipaths correspond to different respective segment routing strategies; calculating, by the computing system, a second plurality of multipaths for the corresponding segment routing policy, wherein calculating the second plurality of multipaths comprises: calculating the multipaths in the second plurality of multipaths and placing the multipaths in the second plurality of multipaths into the model of the network layer in a second order different from the multipaths in the first plurality of multipaths based on corresponding priorities assigned to the segment routing policy, wherein the corresponding priorities assigned to the segment routing policy comprise at least one of: a priority for supporting modification of corresponding multipaths in the first plurality of multipaths or a priority for preventing modification of corresponding multipaths in the first plurality of multipaths; calculating, by the computing system, for each link in the plurality of links, usage of the link as measured by the metric for all paths in the second plurality of multipaths to calculate an overall usage of the second plurality of multipaths; and In response to determining that the total usage of the second plurality of multipaths is less than the total usage of the first plurality of multipaths, the second plurality of multipaths is set in the network layer by the computing system.

2. The method according to claim 1, wherein Calculating the overall usage of the first plurality of multipaths includes calculating a total weighted bandwidth usage and a total weighted bandwidth capacity of the first plurality of multipaths.

3. The method according to claim 1, wherein Calculating the usage of the link as measured by the metric for all paths in the first plurality of multipaths comprises: A portion of the bandwidth of the link used by a particular path in the first plurality of multipaths and a bandwidth capacity available for the link for the first plurality of multipaths are determined.

4. The method according to claim 1, in, The multi-layer network includes a transport layer, and Wherein, calculating the usage of the link as measured by the metric for all paths in the first plurality of multipaths includes: obtaining the usage of one or more links as measured by the metric for the paths in the transport layer that are mapped to the first plurality of multipaths.

5. The method according to any one of claims 1 to 4, wherein calculating the multipaths in the second plurality of paths and placing the multipaths in the second plurality of paths to the model of the network layer in the different second order to generate the second plurality of multipaths is based on a greedy algorithm.

6. The method according to any one of claims 1 to 4, wherein: Computing the multipaths in the second plurality of paths and placing the multipaths in the second plurality of paths to the model of the network layer in the different second order to generate the second plurality of multipaths is based on a random order.

7. The method according to claim 1, further comprising: In response to determining that the total usage of the second plurality of multipaths is not less than the total usage of the first plurality of multipaths, the first plurality of multipaths set in the network layer is left unchanged.

8. A computing device for a multi-layer network, the multi-layer network including a network layer having multiple links, the computing device comprising: Memory; as well as processing circuitry in communication with the memory, the processing circuitry and the memory being configured to: calculating, for each link in the plurality of links, usage of the link as measured by a metric for all paths in a first plurality of multipaths to calculate an overall usage of the first plurality of multipaths, the first plurality of multipaths being arranged in the network layer, wherein the multipaths in the first plurality of multipaths have been calculated and placed in a first order in a model of the network layer, and wherein the multipaths in the first plurality of multipaths correspond to different respective segment routing strategies; calculating a second plurality of multipaths for the corresponding segment routing policy, wherein calculating the second plurality of multipaths comprises: calculating the multipaths in the second plurality of multipaths and placing the multipaths in the second plurality of multipaths into the model of the network layer in a second order different from the multipaths in the first plurality of multipaths based on respective priorities assigned to the segment routing policy, wherein the respective priorities assigned to the segment routing policy comprise at least one of: a priority for supporting modification of a corresponding multipath in the first plurality of multipaths or a priority for preventing modification of the corresponding multipath in the first plurality of multipaths; and In response to determining that the total usage of the second plurality of multipaths is less than the total usage of the first plurality of multipaths, the second plurality of multipaths is set in the network layer.

9. The computing device of claim 8, wherein: To calculate the total usage of the first plurality of multipaths, the processing circuitry is further configured to: A total weighted bandwidth usage and a total weighted bandwidth capacity of the first plurality of multipaths are calculated.

10. The computing device of claim 8, wherein: To calculate the total usage of the first plurality of multipaths, the processing circuitry is further configured to: A portion of the bandwidth of the link used by a particular path in the first plurality of multipaths and a bandwidth capacity available for the link for the first plurality of multipaths are determined.

11. The computing device according to claim 8, in, The multi-layer network includes a transport layer, and In which, in order to calculate the usage of the metric of the link measured by the metric for all paths in the first plurality of multipaths, the processing circuit system is also configured to: obtain the usage of one or more links measured by the metric for the paths in the transport layer mapped to the first plurality of multipaths.

12. The computing device according to any one of claims 8 to 11, wherein: Computing the multipaths of the second plurality of paths and placing the multipaths of the second plurality of paths to the model of a network layer in the different second order to generate the second plurality of multipaths is based on a greedy algorithm.

13. The computing device according to any one of claims 8 to 11, wherein: Calculating the multipaths in the second plurality of paths and placing the multipaths in the second plurality of paths to the model of a network layer in the different second order to generate the second plurality of multipaths is based on a random order.

14. The computing device of claim 8, wherein: The processing circuitry is further configured to: In response to determining that the total usage of the second plurality of multipaths is not less than the total usage of the first plurality of multipaths, the first plurality of multipaths set in the network layer is left unchanged.

15. The computing device of claim 8, wherein: The processing circuitry is further configured to: determining that the first plurality of multipaths has an unequal number of paths; In response to determining that the first plurality of multipaths has an unequal number of paths, calculating a third plurality of multipaths for the corresponding segment routing policy, wherein calculating the third plurality of multipaths comprises: calculating the multipaths in the third plurality of multipaths and placing the multipaths in the third plurality of multipaths into the model of the network layer in a third order different from the multipaths in the first plurality of multipaths; and In response to determining that the third plurality of multipaths has an equal number of paths, the third plurality of multipaths is set in the network layer.

16. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to perform the method of any one of claims 1-7.

Images