Service Level Agreement based data forwarding with link aggregation grouping

Techniques are described for providing service level agreement performance in a link aggregation group computer networking environment. A performance measurement data packet such as a bi-directional forwarding detection (BFD) packet is received. The performance measuring data packet can be considered a parent performance measurement data packet is split into multiple child performance measurement data packets which are each different constituent links of a link aggregation database. The performance of each constituent is tested to determine which constituents satisfy service level agreement parameters. Data packets can then be sent to constituents that meet the data packet's service level agreement performance parameters while still allowing link aggregation grouping.

TECHNICAL FIELD

The present disclosure relates generally to data forwarding to meet Service Level Agreement (SLA) performance requirements in a Link Aggregation Group data routing environment.

BACKGROUND

Ever increasing amounts of data are routed through computer networks. Performance requirements for such data routing can vary depending upon the application applying such data. For example, in an application such as video conferencing there may be a need to maintain low jitter or low latency, whereas other applications such as email may have less of a need to maintain such strict performance requirements. Service Level Agreement (SLA) can be employed to tailor performance requirements for specific applications. An SLA can apply certain data routing performance parameters such as jitter, latency and/or data loss to the transmission of data in a network.

Currently, data transfer that employs Service Level Agreement (SLA) utilizes individual physical interfaces for tunnel transport. As such, every tunnel is egressed or ingressed through one physical interface, with or without loopback Transport Location (TLOC) and with or without Equal Cost Multi-Path (ECMP) on the underlay of the network. Using one physical interface allows seamless Service Level Agreement (SLA) based forwarding, because Bi-Directional Forwarding (BFD) and data traffic will always use the same egress interface.

In a computer network, Link Aggregation Grouping (LAG) can be used to increase bandwidth and reduce data loss. Multiple constituent links can be aggregated into a group. Data packets can be routed through the constituent links using load balancing to select an efficient link path. If one constituent fails or loses data rate or bandwidth data packets can be routed to a different link in the LAG.

However, meeting Service Level Agreement requirements when using Ling Aggregation Grouping presents challenges. Because a link aggregation group can use multiple interfaces, a BFD used to test whether performance metrics meet SLA requirements could traverse a different interface than production data in the same LAG. Production data could be forced through the same LAG constituent as the BFD, however, that would eliminate any performance benefits provided by the use of LAG.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

This disclosure describes techniques for providing Service Level Agreement (SLA) compliant data routing in a Link Aggregation Group (LAG) networking architecture. A performance measuring data packet is received and is split into multiple child performance measuring data packets. In one embodiment, the received performance measuring data packet can be referred to as a “parent” performance measuring data packet. The child performance measurement packets are then routed to separate constituents of a Link Aggregation Group to test performance of each constituent. A determination can be made as to which constituents satisfy certain performance requirements of one or more Service License Agreements (SLAs). Then, a data packet requiring an SLA performance parameter is routed to one or more of the constituents that have been determined to meet the SLA requirement.

Additionally, the techniques described in this disclosure may be performed as a method and/or by a system having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the techniques described above.

Example Embodiments

Link Aggregation Grouping can be used in a computer network to improve data transmission efficiency and reliability. Link aggregation allows a network switch to treat multiple physical links between two end-points as a single logical link. All of the physical links in a given Link Aggregation Group (LAG) can operate in full-duplex mode at the same speed. LAGs can be used to directly connect two switches when the traffic between them requires high bandwidth and reliability, or to provide a higher-bandwidth connection to a public network. Management functions treat a LAG as if it were a single physical port. LAG can be applied to a Virtual Large Area Network (VLAN), Software Defined Wide Area Network (SDWAN) as well as other network architectures.

A Link Aggregation Group (LAG) bundles all of the controller's distribution system ports into a single 802.3ad port channel. This reduces the number of IP addresses required to configure the ports on the controller. When LAG is enabled, the system dynamically manages port redundancy and load balances access points transparently to the corresponding user.

LAG simplifies controller configuration because it is no longer necessary to configure ports for each interface. If any of the controller ports fail, traffic is automatically migrated to one of the other ports. As long as at least one controller port is functioning, the system continues to operate, access points remain connected to the network, and wireless clients continue to send and receive data. A wireless Virtual Large Are Network (VLAN) can only be part of one port channel. Link Aggregation Control Protocol (LACP) is supported on a stand-alone controller.

Link Aggregation Control Protocol (LACP) is a part of an IEEE specification (802.3ad) that makes it possible to bundle several physical ports together to form a single logical channel. LACP allows a switch to negotiate an automatic bundle by sending LACP packets to a peer. By using the LACP, the wireless controller learns the identity of peers that are capable of supporting LACP, and the capabilities of each port. The LACP then dynamically groups similar configured ports into a single logical link (channel or aggregate port). Similarly, configured ports are grouped based on hardware, administrative, and port parameter constraints. If any of the controller ports fail, traffic is automatically migrated to one of the other ports. As long as at least one controller port is functioning, the system continues to operate, access points remain connected to the network, and wireless clients continue to send and receive data.

To configure LAG using LACP, multiple port-channel interfaces must be created, and these interfaces should be added to the corresponding port bundle. LACP should also be configured on the uplink switch for the LACP bundle to come up.

Port Aggregation Protocol (PAgP) developed by CISCO®, is one example of a protocol that can be run on controllers. PAgP facilitates the automatic creation of EtherChannels by exchanging PAgP packets between Ethernet ports. PAgP packets are sent between Fast EtherChannel-capable ports in order to form a channel. When any of the active ports fail, a standby port becomes active.

By using PAgP, the controller learns the identity of partners that are capable of supporting PAgP and the capabilities of each port. PAgP then dynamically groups similarly configured ports (on a single device in a stack) into a single logical link (channel or aggregate port). Similarly, configured ports are grouped based on hardware, administrative, and port parameter constraints.

To configure LAG using PAgP, multiple port-channel interfaces must be created, and these interfaces should be added to the corresponding port bundle. PAgP should also be configured on the uplink switch for the PAgP bundle to come up. To configure LAG in “on” mode, multiple port-channel interfaces must be created, and these interfaces can be added to the corresponding port bundle. LACP should also be configured on the uplink switch for the LACP bundle to come up.

Different network applications can require different performance parameters. Service Level Agreements (SLAs) apply rules for minimum performance parameters that must be met for a given application. In some applications an SLA can set rules for a maximum amount of jitter, maximum amount of latency and/or maximum level of data loss. A network administrator can set these SLA rules depending upon the application being used. For example, in a video conference setting there may be a need to maintain a low level of jitter. In another application such as email there may not be such a need for low jitter.

An SLA can include not only a description of the services to be provided and their expected service levels, but also metrics by which the services are measured, the duties and responsibilities of each party, the remedies or penalties for breach, and a protocol for adding and removing metrics.

SLAs are a key part of IT Service Management (ITSM). SLAs are agreements that: define what users and customers can expect from the IT services; define targets for suppliers; provide suppliers, customers and stakeholders with regular information on how the services are delivering on these expectations. This information is used to drive improvements. Use of SLAs can support effective working relationships between IT and the business employing the IT, as both should be involved in the SLAs' creation, maintenance, and use. Service Level Management is the process responsible for SLAs in an organization.

An SLA is a formal, structured agreement between two parties to provide one or more services to a mutually agreed performance level. One of the parties is the customer of the services. The other party is the supplier that provides the services. A supplier can be part of the same organization as the customer (service provider) or in a different organization (external). The SLA can be a physical or electronic document. The document extends the definition of a service from one contained in a service catalogue and provides an agreed and guaranteed minimum level of service performance.

An SLA can describe: the services it covers; the scope of the services; the service characteristics, including the hours when it is available and the hours that are supported; the targets for these services (known as service levels); and the responsibilities of both parties, including responsibilities for review and maintenance of it contents. It can also include a pricing model, with any charges for using the service and penalties that are payable for failures to fulfill the service levels. The SLA should be written from the viewpoint of the customer, to facilitate understanding.

These different terms can be confusing, especially to those who aren't well versed in IT Service Management. It is valuable to have a formal agreement on the levels of service a supplier provides a customer and documented in an ALS. This ensures that the customer is aware of what can be expected and ensures that the supplier is aware of what must be provided. Many organizations just use the term SLA to refer to all of the three types of service level agreement.

It is good practice for an organization to have one SLA per supplier, which includes all of the services the supplier provided. This simplifies the creation of the agreement, as the general requirements will be the same and the services will often have the same service levels. The SLA can be subsequently updated to add new services or remove retired ones. There is no limit to how many services can be in one agreement. It is also good practice to ensure SLAs exist for every supplier, including internal ones. This helps to ensure that the expectations of the customer are explicitly stated, and the suppliers understand them and that the customer understands what service it can expect to receive.

A multi-level SLA is a structure used to avoid duplication and reduce the frequency of updates to the SLAs, whilst allowing the flexibility to customize them for specific customers and services. Using a multi-level SLA structure is typically for documenting service levels when the suppliers are within the same organization. It can also be particularly useful when an external supplier provides multiple services, which mostly share common requirements, but where certain services have different service levels or requirement, such as 24-7 support requirements. A typical multi-level SLA structure can have three levels. First, the SLA can include a corporate level, covering requirements common to every customer within a business. An example is an SLA for every user of an email system, so passwords can be changed every 30 days. Second, the SLA can include a customer level, which can cover requirements specific to a particular customer or set of customers within a business, including all of the services delivered to it. An example is a standard level of service availability for all services provided to one customer. Third, the SLA can include a service level, which can cover requirements for specific services. This is lowest level and can be used if a specific service has requirements and service levels that are different from the standard for the business or a customer.

The customer is the person or organization that uses the services. The customer can be internal or external to the organization. Businesses can provide services to customers. These can be services based on IT, such as cloud-based applications or non-IT services, such as a holiday booking call center. The customer for the services can be an individual or another company. Even when it is impractical for external customers to sign an agreement formally, SLAs should still be created, as they provide a clear and precise description of what the customer can expect and drive improvements in service quality.

SLAs can be useful whenever there is a need for a formal agreement between two parties, detailing the expected levels of service, accompanied by the associated responsibilities. IT service management has traditionally only included IT services, including the service desk in SLAs. Service levels and the associated agreements can, however, include types of services such as labor-based services including IT support, commodity services including supplying consumables and technical, non-IT service. SLAs can also be used for process-related activities where there is a need to define, monitor and measure compliance. This can include attendance at formal meetings, targets for responding to complaints and achieving deadlines for submitting bills.

Service Level Management (SLM) is the process that negotiates SLAs between the customer and the supplier and aims to ensure that they are fulfilled. SLM can ensure that all other processes used in IT service management support achieving the agreed upon service levels. This can include verifying that all SLAs can support the agreed service-level targets. Service level management monitors and reports on the service levels documented in the agreed SLAs conducts regular service reviews with customers and suppliers, identifies required improvements, and then reports on and monitors improvement actions.

The achievement of every service-level target document can be monitored and reported. How this is accomplished depends upon the precise nature of the service level. The method and frequency of monitoring should be defined and documented in the SLA. For complex targets and where penalties for failure exist, it is good practice to test all calculations before going live. SLA reports can be automatically produced from the data captured during monitoring, as this will give an accurate view of the true SLA achievement. SLA reports should be produced often enough to highlight trends in SLA achievement before failures occur and to generate confidence in the process. During the early stages of a service, weekly reporting can be used to verify whether all processes, systems, etc. are working as expected. Reporting to customers can be reduced to a monthly interval and even quarterly as confidence is gained in both the services and the supplier.

Therefore, in the case where an SLA involves specific network data transfer performance parameters, such as but not limited to jitter, loss or latency, it is necessary to have a means for periodically testing such performance parameters. In order to test such performance parameters, a performance measurement packet can be sent through the network such as by implementing Bidirectional Forwarding Detection (BFD). BFD is a detection protocol designed to provide fast forwarding path failure detection times for all media types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection, BFD provides a consistent failure detection method for network administrators. Because the network administrator can use BFD to detect forwarding path failures at a uniform rate, rather than the variable rates of different routing protocol “hello” mechanism, network profiling and planning is facilitated, and reconvergence time can be consistent and predictable.

BFD provides fast BFD peer failure detection times independently of all media types, encapsulations, topologies, and routing protocols. By sending rapid failure detection notices to the routing protocols in the local router to initiate the routing table recalculation process, BFD contributes to greatly reduced overall network convergence time. When Open Shortest Path First (OSPF) protocol discovers a neighbor, it sends a request to the local BFD process to initiate a BFD neighbor session with the OSPF neighbor router. The BFD neighbor session with the OSPF neighbor router is established.

When a failure occurs in a network, the BFD neighbor session with the OSPF neighbor router is torn down. The BFD notifies the local OSPF process that the BFD neighbor is no longer reachable. The local OSPF process tears down the OSPF neighbor relationship. If an alternative path is available, the routers will immediately start converging on it. Once a BFD session has been established and timer negations are complete, BFD peers send BFD control packets that act in the same manner as in Interior Gateway Protocol (IGP) hello protocol to detect liveliness, except at a more accelerated rate.

Therefore, in order to determine whether such SLA metrics are being met, a data measurement packet can be sent through the network. As discussed above, one such data measurement packet can be referred to as a Bidirectional Forwarding Detection (BFD) packet. For the BFD to effectively ensure that an SLA requirement is being met, the BFD packet must travel along the same network path as the data packet that requires the SLA. This presents a challenge when using Link Aggregation Grouping (LAG) in a situation where a data packet requires SLA metrics.

As discussed above, LAG includes multiple data links or interfaces that function as a single logical link or interface. If a BFD data packet is used to test for the SLA requirements of a data packet, in a LAG there is no way to ensure that the BFD packet and the data packet were routed through the same link. Therefore, the SLA for the data packet will be violated. On the other hand, if the BFD packet and the data packet are forced into the same link or constituent of the LAG, the benefits of the link aggregation are lost. The routing stops behaving as a LAG, because the data packet is not free to switch from one link to another to ensure maximum performance and reliability.

The described embodiments provide a solution to this challenge to allow link aggregation to be employed without violating the SLA terms. As described in detail herein below, a BFD packet can be split into multiple child BFD packets which can then be routed through each link of the LAG. In that way, a determination can be made as to which links or constituents of the LAG satisfy the SLA metrics requirements. The data packet can then be routed through any of those links, thereby providing the benefits of LAG without violating the SLA metrics requirements.

In one embodiment, the parent and child performance measurement packets are Bidirectional Forwarding Detection (BFD) data packets. In one embodiment, each of the child performance measurement packets (e.g. BFDs) can include a unique link aggregation group constituent identifier, which in one embodiment can comprise a type-length-value extension. Each of the child performance measurement packets is routed through its respective constituent link to a switch connected with the link and then is again received to provide data regarding performance parameter metrics for each constituent of the Link Aggregation Group (LAG). In this way a determination can be made as to which constituents satisfy the SLA requirements for a data packet to be routed. This can, therefore, provide a hybrid process where Link Aggregation Grouping can be employed using constituents that are capable of meeting SLA requirements, thereby ensuring that SLA is not violated in the LAG.

Additionally, the techniques described herein may be performed by a system and/or device having non-transitory computer-readable media storing computer-executable instructions that, when executed by one or more processors, performs the method described above. Link Aggregation Grouping (LAG) provides increased reliability and availability. If one of the physical links in the LAG goes down, traffic is automatically and transparently reassigned to one of the other physical links. LAG also provides better use of physical resources. Traffic can be load-balanced across the physical links. In addition, LAG can provide increased bandwidth. The aggregated physical links deliver higher bandwidth than each individual link alone.

FIG.1schematically illustrates a computer network architecture100. In one embodiment, the computer networking architecture100can be a Software Defined Wide Area Network (SDWAN). The network environment100can include a software defined network102that can be configured, modified or changed as needed to meet changing network demands. In one embodiment, the network102can be managed by a controller104. The controller104can centralize management to the SDWAN edge and the SDWAN gateway. A service orchestrator106can be provided to manage SDWAN service lifecycle such as fulfillment, performance monitoring, analytics, security and policy management. A subscriber web portal108can be provided to manage the service orchestrator106and controller104. The web portal108can be used in conjunction with the service orchestrator106to monitor the SDWAN as a service.

In one embodiment, data can be routed through the network102between computer devices110,112through a logical data tunnel114using network switches116,118. In one embodiment, the network switches116,118can be routers. In other embodiments the switches116,118can be some other type of network switching devices, such as bridges, load balancers, etc. One or more of the network switches116includes circuitry120and computer logic122configured to provide Link Aggregation Grouping (LAG) while also ensuring Service Level Agreement is not violated. The switch116can send performance measurement data packets124as well as SLA production data packets through the network102such as through the logical data tunnel114. In one embodiment, the performance measurement data packet124can be a bidirectional forwarding detection (BFD) packet and can measure and determine performance parameters of constituent links, such as through the data tunnel114, to ensure that when the production data packet126is routed through the tunnel SLA requirements are not violated, as will be described in greater detail herein below.

FIG.2illustrate an enlarged schematic of the circuitry120of a network switch116ofFIG.1, which is configured to test performance parameters of multiple constituent links of a Link Aggregation Group (LAG) to ensure that SLA requirements of a data packet are not violated when routing the data packet through the LAG. A data measurement packet202is received such through an ingress port or constituent204. In one embodiment, the data measurement packet202can be a bidirectional forwarding detection (BFD) data packet. For purposes of clarity the data measurement packet202will be referred to as a BFD packet, although it should be understood that the BFD packet202encompasses a packet intended to measure network performance more generally. The BFD packet202can be referred to as a “parent” BFD packet. The parent BFD packet202is sent to bifurcator circuitry206, which splits the parent data packet202into multiple “child” BFD data packets. For example, in one embodiment as shown inFIG.2, the parent BFD202is split into a first child BFD packet208and a second child BFD210.

Each of the child BFD packets208,210is routed to a separate constituent of a Link Aggregation Group (LAG)212. For example, as shown inFIG.2, child BFD208is routed to a first constituent214, whereas the second child BFD is routed to second constituent216, where the first and second constituents214,216are constituent links of the Link Aggregation Group (LAG)212. The first child BFD208can be forwarded to a first network switch218, which can be a switch of a logical data tunnel such as the logical data tunnel114described above with reference toFIG.1. Similarly, the second child BFD210is routed to a second network switch220, which also may be part of the logical data tunnel114.

FIG.3illustrates a schematic view of logic and circuitry for processing BFDs and determining LAG routing of data packets without violating SLA requirements. In one embodiment, the SLA/Link Aggregation Logic122can include a BFD Analyzer Module302, an SLA Analyzer Module304, an SLA Tabulation Database306and an SLA Data Packet Routing Module308.

As discussed above with reference toFIG.2, the first and second child BFDs208,210are sent to first and second constituents214,216respectively. The first and second child BFD packets214,216can return to the to the circuitry120(FIG.2) and can be analyzed by SLA/Link Aggregation Logic120to determine which constituents214,216have performance parameters that satisfy various SLAs. Each child BFD208,210corresponds to a different constituent214,216. In addition, in one embodiment, each child BFD208,210can be modified with an extension Type-Length-Value (TLV) containing a custom type LAG constituent identifier. Therefore, in the shown example, the first child BFD packet208will contain C1 constituent214in its TLV, whereas the second child BFD packet210will contain C2 constituent in its TLV. When the child BFDs208,210return packets are received, the BFD manager302decodes the custom TLV and gets the LAG constituent ID. The BFD Analyzer Module302uses the information received from the BFD to determine various performance parameters of each constituent214,216of a Link Aggregation Group212. In one embodiment, these performance parameters can include one or more of jitter, latency and/or loss. In one embodiment, the BFD manager302can include logic or circuitry to split a parent BFD into multiple child BFDs as described above. For Example, the BFD manager302can receive a BFD202which can be referred to as a parent BFD202and can then split the parent BFD202into multiple child BFDs (e.g.208,210) as described above.

The BFD manager302can send the data regarding constituent performance parameters and can process this information to determine which constituents, if any, meet various SLA performance requirements. As discussed above, in one embodiment these SLA performance requirements can include one or more of jitter, latency and/or loss. Once the SLA Analyzer has made this calculation regarding which constituents meet which SLA performance requirements, the results can be stored in the SLA Tabulation Database306.

A data packet222can be received through an ingress port224as shown inFIG.2. This data packet can have one or more SLA requirements. As shown inFIG.3, the data packet is received and processed by the SLA Packet Routing Module308, which analyzes information such as extensions or metadata of the data packet to determine which SLA performance parameters are required by the data packet222. The SLA Data Packet Routing Module308can access the SLA Tabulation Database306to determine which constituents (e.g.214,216meet these SLA requirements. The SLA Data Packet Routing Module308can then route the data packet222to one of the constituents that has been found to meet the SLA requirements. If multiple constituents have been found to meet the SLA requirements, then the data can be routed to one of those constituents using load balancing algorithms in a Link Aggregation Group protocol. In this way the benefits of Link Aggregation Grouping are maintained as much as possible without violating SLA requirements. It should be noted the above description has been described has having two constituents214,216in the Link Aggregation Group (LAG). This has, however, been for purposes of illustration. The above process and system can be applied to a LAG having more than two constituents and can also be applied to a network architecture having more than one LAG.

FIG.4illustrates various tables indicating how a data packet can be routed to satisfy SLA requirements in a Link Aggregation Group. Tables and data structure illustrated with reference toFIG.4can correspond with the data that may be stored in SLA Tabulation Database306ofFIG.3.FIG.4shows a first Link Aggregation Group LAG-1402, and a second Link Aggregation Group LAG-2404. LAG-1402defines a data tunnel T1 having four constituents C1, C2, C3 and C4. LAG-2404defines a data tunnel T2 having two constituents C5 and C6. Table406indicates various SLAs, and which LAG tunnels satisfy those SLAs. In Table406, SLA0 indicates no SLA requirement. SLA1, SLA2, SLA3 indicate three different performance requirements, which in one embodiment can include one or more of jitter, latency and/or loss. In table406, if a data tunnel has multiple constituents and each meet different SLAs, then the tunnel is considered to satisfy each of these SLAs. In other words, if even one of the constituents of a data tunnel satisfies an SLA, then that tunnel is considered to satisfy that SLA.

Table408indicates which constituents of LAG-1402(e.g. tunnel T1) satisfy each of the SLAs. SLA 0 indicates no SLA requirement at all, so all constituents meet that SLA requirement. In Table408, it can be seen that constituents C1 and C4 meet the SLA requirement for SLA-1. None of the constituents of LAG 1402meet the requirements of SLA2, and only constituent C2 meets the requirements of SLA 3.

Table410indicates which constituents of LAG-2404satisfy which SLA requirements. In Table410it can be seen that both constituents C5 and C6 satisfy SLA-0, since that represents no SLA requirements. Neither of the constituents satisfy SLA1. Only constituent C6 satisfies SLA2, and only constituent C5 satisfies SLA3.

With continued reference toFIG.4, Application-1412represents a computer application being used to deliver a data packet wherein Application-1412requires SLA-1 performance parameters. Referring to table406it can be seen that at the tunnel level only LAG-1404(Tunnel T1) satisfies SLA-1. Then, using Table408it can be seen that constituents C1 and C4 meet SLA1. Therefore, the data packet implementing Application-1 can be routed to either of constituents C1 or C4 using LAG load balancing to determine which constituent (C1 or C4) to route the data packet to. In this way Link Aggregation Grouping can be employed to maximize bandwidth while also ensuring that SLA1 is not violated.

As another example, Application-2414requires SLA3. Referring to table406it can be seen that both T1 and T2 satisfy SLA3. Employing load balancing, such as implemented by load balancer416a data packet employing Application-2 can be routed to LAG 2 (tunnel T2). This is by way of illustration, however, as the data packet employing Application-2 could also have been sent to LAG1 (tunnel T1) as indicated by dashed line418. Since the data packet requiring SLA3 is being routed to LAG2 (tunnel T2) table410can be referenced to determine which constituents of LAG2 satisfy SLA3. From the Table410it can be seen that C5 satisfies SLA3. Therefore, the data packet requiring SLA3 is routed to constituent C5, thereby ensuring that the SLA is not violated. The above description ofFIG.4discusses various hypothetical scenarios in order to illustrate logic and method for routing data packets in a LAG environment without violating SLA requirements. However, this has been by way of example, as many different scenarios may be possible.

FIGS.5A-5Billustrate a flow diagram of example methods500that illustrates aspects of the functions performed at least partly by the devices in the distributed application architecture as described inFIGS.1-4. The logical operations described herein with respect toFIGS.5A-5Bmay be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system.

FIGS.5A-5Bshow a flowchart illustrating a method500according to an embodiment. With reference toFIG.5Aa performance measurement data packet is received502. The performance measurement data packet can be received by a network switch or node of a computer network can be received from a switch, router or other computer device such as a server connected with the computer network. In one embodiment, the performance measurement data packet can be a Bidirectional Forwarding Detection (BFD) data packet. In one embodiment, the performance measurement data packet can be a parent packet and can be a parent BFD packet.

The performance measurement data packet (e.g. parent BFD packet) is split into multiple child performance measurement packets504. In one embodiment, the parent performance measurement packet can be split into two child performance measurement packets, while in another embodiment, the parent performance measurement packet can be split into more than two child performance measurement packets. The splitting of the performance measurement data packet into multiple child performance measurement data packets can be performed by software (such by a Central Processing Unit (CPU)) or hardware (such as an Application Specific Integrated Circuit (ASIC)) of the network switch that received the performance measurement data packet.

Each of the child performance measurement data packets is routed to a separate constituent link of a Link Aggregation Group (LAG)506. In one embodiment, each child performance measurement packet can be modified with an extension TLV containing a custom type LAG constituent identifier.

Using the child performance measurement packets, performance parameters of each of the separate constituent of the LAG are determined508. A determination is made as to whether each of the separate constituents of the LAG satisfies performance parameter requirements of one or more Service Level Agreements (SLAs)510. In one embodiment, example service level agreement performance parameter requirements can include one or more of jitter, latency and/or loss. In response to determining whether each of the separate constituents of the LAG satisfies the service level agreement performance requirements of the SLA, a data packet having the specific SLA requirement can be routed to a LAG constituent that has been determined to meet that specific SLA requirement512. In the case where multiple constituents of the LAG have been found to satisfy the specific SLA, then load balancing can be performed to choose which constituent to route the data packet to. In one embodiment, the each of the child performance measurement packets and the data packet are routed through a common data tunnel.

FIG.6is a computing system diagram illustrating a configuration for a data center600that can be utilized to implement aspects of the technologies disclosed herein. The example data center600shown inFIG.6includes several server computers602A-602F (which might be referred to herein singularly as “a server computer602” or in the plural as “the server computers602”) for providing computing resources. In some examples, the resources and/or server computers602may include, or correspond to, the any type of networked device described herein. Although described as servers, the server computers602may comprise any type of networked device, such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc.

The server computers602can be standard tower, rack-mount, or blade server computers configured appropriately for providing computing resources. In some examples, the server computers602may provide computing resources604including data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers602can also be configured to execute a resource manager606capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager606can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer602. Server computers602in the data center600can also be configured to provide network services and other types of services.

In the example data center600shown inFIG.6, an appropriate LAN608is also utilized to interconnect the server computers602A-602F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between data centers700, between each of the server computers602A-602F in each data center600, and, potentially, between computing resources in each of the server computers602. It should be appreciated that the configuration of the data center600described with reference toFIG.6is merely illustrative and that other implementations can be utilized.

In some examples, the server computers602may each execute one or more application containers and/or virtual machines to perform techniques described herein.

In some instances, the data center600may provide computing resources, like application containers, VM instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by a cloud computing network may be utilized to implement the various services and techniques described above. The computing resources604provided by the cloud computing network can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

The computing resources604provided by a cloud computing network may be enabled in one embodiment by one or more data centers600(which might be referred to herein singularly as “a data center600” or in the plural as “the data centers600”). The data centers600are facilities utilized to house and operate computer systems and associated components. The data centers600typically include redundant and backup power, communications, cooling, and security systems. The data centers600can also be located in geographically disparate locations. One illustrative embodiment for a data center600that can be utilized to implement the technologies disclosed herein will be described below with regard toFIG.7.

FIG.7shows an example computer architecture for a server computer700capable of executing program components for implementing the functionality described above. The computer architecture shown inFIG.7illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, routing switch, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The server computer700may, in some examples, correspond to a physical server110ofFIG.1, or can correspond to networking switch116ofFIG.1, and may comprise other networked devices such as servers, switches, routers, hubs, bridges, gateways, modems, repeaters, access points, etc. In one embodiment the computer700can be used to perform the method500described above with reference toFIGS.5A-5B.

The computer700includes a baseboard702, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”)704operate in conjunction with a chipset706. The CPUs704can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the computer700.

The chipset706provides an interface between the CPUs704and the remainder of the components and devices on the baseboard702. The chipset706can provide an interface to a RAM708, used as the main memory in the computer700. The chipset700can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)710or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer702and to transfer information between the various components and devices. The ROM710or NVRAM can also store other software components necessary for the operation of the computer700in accordance with the configurations described herein.

The computer700can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network724or network608ofFIG.6. The chipset706can include functionality for providing network connectivity through a NIC712, such as a gigabit Ethernet adapter. The NIC712is capable of connecting the computer700to other computing devices over the network724(and/or608) or network102ofFIG.1. It should be appreciated that multiple NICs712can be present in the computer700, connecting the computer to other types of networks and remote computer systems.

The computer700can be connected to a storage device718that provides non-volatile storage for the computer. The storage device718can store an operating system720, programs722, and data, which have been described in greater detail herein. The storage device718can be connected to the computer602through a storage controller714connected to the chipset706. The storage device718can consist of one or more physical storage units. The storage controller714can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

In addition to the mass storage device718described above, the computer700can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the computer700. In some examples, the operations performed by devices in the network architecture100, and or any components included therein, may be supported by one or more devices similar to computer700.

As mentioned briefly above, the storage device718can store an operating system720utilized to control the operation of the computer700. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Washington. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device718can store other system or application programs and data utilized by the computer700.

In one embodiment, the storage device718or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer700, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer700by specifying how the CPUs704transition between states, as described above. According to one embodiment, the computer700has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer700, perform the various processes described above with regard toFIGS.1-5B. The computer700can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

The computer700can also include one or more input/output controllers716for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, an input/output controller716can provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, or other type of output device. It will be appreciated that the computer700might not include all of the components shown inFIG.7, can include other components that are not explicitly shown inFIG.7, or might utilize an architecture completely different than that shown inFIG.7.

As described herein, the computer700may comprise one or more of a router, load balancer and/or server. The computer700may include one or more hardware processors704(processors) configured to execute one or more stored instructions. The processor(s)704may comprise one or more cores. Further, the computer700may include one or more network interfaces configured to provide communications between the computer700and other devices, such as the communications described herein as being performed by the router, load balancer and/or server. The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth. For example, the network interfaces may include devices compatible with Ethernet, Wi-Fi™, and so forth.

The programs722may comprise any type of programs or processes to perform the techniques described in this disclosure for providing a Service Level Agreement data routing in a Link Aggregation Group. That is, the computer700may comprise any one of the routers, load balancers, and/or servers. The programs722may comprise any type of program that cause the computer700to perform techniques for communicating with other devices using any type of protocol or standard usable for determining connectivity.