[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2015112159A1 - Proposal generation for a network - Google Patents

Proposal generation for a network Download PDF

Info

Publication number
WO2015112159A1
WO2015112159A1 PCT/US2014/012915 US2014012915W WO2015112159A1 WO 2015112159 A1 WO2015112159 A1 WO 2015112159A1 US 2014012915 W US2014012915 W US 2014012915W WO 2015112159 A1 WO2015112159 A1 WO 2015112159A1
Authority
WO
WIPO (PCT)
Prior art keywords
proposals
proposal
value
network
controller
Prior art date
Application number
PCT/US2014/012915
Other languages
French (fr)
Inventor
Alvin Auyoung
Yoshio F. Turner
Sujata Banerjee
Lucian Popa
Jung Gun Lee
Puneet Sharma
Yadi Ma
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2014/012915 priority Critical patent/WO2015112159A1/en
Publication of WO2015112159A1 publication Critical patent/WO2015112159A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04Network management architectures or arrangements
    • H04L41/042Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0895Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities

Definitions

  • a Software Defined Network (SDN) controller is software that manages the control plane of a network. SDN controllers leverage protocols, such as OpenFlow®, to manage SDN-supported switches in order to control the flow of network packets, for example.
  • a controller may be considered the core of an SDN or similar controller-based system.
  • a controller may lie anywhere in the system with connectivity to the network devices and end-points such as servers and end-clients. Any communication between the end-points may go through a controller.
  • FIG. 1 illustrates an example of a system in accordance with an implementation according to the present disclosure.
  • FIG. 2 illustrate examples of systems in accordance with an implementation according to the present disclosure
  • FIG. 3 illustrate examples of systems in accordance with an implementation according to the present disclosure.
  • FIG. 4 illustrates an environment diagram as an example of proposal generation according to the present disclosure.
  • FIG. 5 illustrates a flow diagram for an example of a method for proposal generation according to the present disclosure.
  • a network can include a variety of network devices (e.g., routers, switches, etc.) with varying capabilities (e.g., receiving software instructions, communicating with a network controller and/or network controllers, and/or multiple controllers, etc.).
  • Software Defined Network (SDN) network devices can be network devices capable of receiving software instructions such as forwarding rules from a network controller (e.g., network manager, etc.).
  • An SDN controller e.g., network controller, controller, multiple-controllers, etc.
  • An SDN controller can include an application that manages flow control (e.g. data flow, etc.) to enable intelligent networking.
  • SDN controllers can be based on protocols, such as OpenFlow®, that allow servers to guide network devices on where to send packets (e.g., data packets, etc.).
  • the SDN controller can be located between network devices at a first end and applications at a second end. Any
  • communication between end-points and/or devices can be routed (e.g., sent, distributed, etc.) through the SDN controller.
  • each of the plurality of SDN controllers can compete for resources (e.g., network devices, bandwidth, etc.) That is, two or more SDN controllers and/or two or more
  • SDN single-to-Network Interface
  • applications/modules on a single SDN controller can compete for one or more finite resources (e.g., link bandwidth, switch table slots, the placement of a flow or virtual machine in a physical topology).
  • finite resources e.g., link bandwidth, switch table slots, the placement of a flow or virtual machine in a physical topology.
  • controllers may generate different types of proposal requests (e.g., resource requests, resource allocation, etc.) in order to receive resources and may further generate proposals and/or counter-proposals to arrive at an allocation that provides a particular function.
  • proposal requests e.g., resource requests, resource allocation, etc.
  • a number of proposal types can be generated and allow an SDN controller to report (e.g., send, export, etc.) information about local objectives and/or policies of the SDN controller and/or multiple SDN controllers (e.g., multi-SDN controller, multi- controller, meta-controller, modules, etc.).
  • Multiple controllers can operate in coordination, can be interconnected, and/or can manage different aspects of the network while competing for shared resources.
  • the reported information can maximize system-wide objectives while also meeting policy constraints of the system.
  • Multiple controllers can share network information and can operate in coordination to improve route optimization and/or other allocation decisions. Multiple controllers can share information in the same or different networks.
  • Sharing information can include sending and/or receiving proposals between the multiple controllers.
  • a first controller can generate a proposal that includes resource allocations as described herein.
  • the first controller can share the information by sending the generated proposal to a second controller.
  • the second controller can be a central controller designed to receive proposals from other controllers in addition to generating proposals.
  • Proposals and/or counter-proposals are used to help a controller satisfy its objectives (e.g., power consumption limits, resource consumptions, cost, etc.), and in aggregate, these proposals allow the system to reach global system-wide objectives.
  • Each module can choose from parameters R, S, C, R', S', and/or C to tradeoff between speed, accuracy, and space consumption in generating proposals and/or counter-proposals.
  • the parameters can be used to generalize the tradeoff random jumps in the search space with a progressive search (e.g., continuous search, etc.) to increase the likelihood of generating proposals with an increased value in an effort to find a "best" proposal from the plurality of proposals.
  • a first number of the controllers of the multiple controllers can be utilized for a first aspect (e.g., bandwidth, flow latency, flow level, feature, etc.) of the network and a second number of controllers of the multiple controllers can be utilized for a second aspect of the network.
  • a first network controller can be configured to allocate resources for a first aspect and/or portion of a network and a second network controller can be configured to allocate resources for a second aspect and or/portion of the network.
  • a network controller from the multiple controllers can be designated to receive proposals from a plurality of other controllers that correspond to portions of the network and select a proposal to allocate resources to each of the corresponding portions of the network.
  • a or "a number of” something can refer to one or more such things.
  • a number of network devices can refer to one or more network devices.
  • FIG. 1 illustrates an example of a system 100 in accordance with an implementation according to the present disclosure.
  • the system 100 comprises modules 1 10, 120 and 130, a central coordinator 140, and an SDN controller 150.
  • the system 100 comprises controllers/modules 1 10, 120 and 130, each performing a specific function and may be used alone or combined with other modules.
  • the modules 1 10, 120, and/or 130 can each perform a specific function for a particular aspect (e.g., bandwidth, flow latency, flow level, feature, etc.) of the network.
  • the modules can perform the function for the particular aspect of an entire network (e.g., physical network, virtual network, combination of physical and virtual network, etc.).
  • modules 1 10, 120, and/or 130 can perform the function for the particular aspect of a portion of the network (e.g., partial network, specific area of the network, etc.).
  • the modules 1 10, 120, and 130 can include a bandwidth allocator module, which is a module that allocates guaranteed bandwidth to a set of endpoints.
  • the modules 1 10, 120, and 130 can include a flow latency controller module, which is a module to support end-to-end latency bounds for flows or flow classes.
  • the modules 1 10, 120, and 130 can include a flow-level traffic engineering module, which is a module that re-routes flows to achieve an objective, such as load balancing.
  • the modules 1 10, 120, and 130 can include a VM-migrator, which is a module that migrates VMs between servers, e.g., for consolidation.
  • the modules 1 10, 120, and 130 can include a power control manager, which is a module that reduces energy costs by attempting to turn off under-utilized resources.
  • the modules 1 10, 120 and 130 may generate one or more proposals for reservations of resources.
  • a proposal may represent a change in the current reservation state with a specific start time and end time.
  • Such proposals propose to modify the system 100, which results in a topology change.
  • the topology change can involve turning servers, switches, or links on or off, adding a switch table entry, or moving virtual machines (e.g., a software implementation of a machine (i.e. a computer) that executes programs like a physical machine).
  • the resources can include a fraction of a link's bandwidth, a rate limiter or switch port, an entire line card, an internet group management protocol table entry, a virtual local area network tag, a queue and/or an OpenFlow table entry.
  • the modules 1 10, 120 and 130 can generate proposals in response to new inputs (e.g. a customer request for bandwidth), changes in network reservation state (e.g., no more reservations for line-card), and periodic timer (e.g., load balancing across link technologies).
  • new inputs e.g. a customer request for bandwidth
  • changes in network reservation state e.g., no more reservations for line-card
  • periodic timer e.g., load balancing across link technologies
  • Each individual module 1 10, 120 or 130 may have its own set of policies and objectives.
  • policies can express constraints on what may be allowed, and objectives can express the costs and benefits of specific proposals.
  • a topology proposed by one module might violate the policies of another module. For such an embodiment, it may be necessary to enforce each module's policies.
  • FIG. 2 illustrates examples of a system 200 in accordance with an implementation according to the present disclosure.
  • the system 200 can include a data store 202, a proposal processing system 204, a random proposal engine 254, a suggestion proposal engine 256, and/or a counter-proposal engine 258.
  • the proposal processing system 204 can be in communication with the data store 202 via a communication link, and can include the engines 254, 256, and 258.
  • the proposal processing system 204 can include additional engines other than illustrated to perform the various functions described herein.
  • the random proposal engine 254, suggestion proposal engine 256, and counter-proposal engine 258 can include a combination of hardware and programming that is configured to perform a number of functions described herein (e.g., generate proposals in a network, evaluate the plurality of proposals, alter a feature of a proposal, select a proposal, etc.).
  • the random proposal engine 254, suggestion proposal engine 256, and counter-proposal engine 258 can include a combination of hardware and programming that is configured to perform a number of functions described herein (e.g., generate proposals in a network, evaluate the plurality of proposals, alter a feature of a proposal, select a proposal, etc.).
  • programming can include program instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., computer readable medium, machine readable medium, etc.) as well as hard-wired program (e.g. logic).
  • program instructions e.g., software, firmware, etc.
  • a memory resource e.g., computer readable medium, machine readable medium, etc.
  • hard-wired program e.g. logic
  • Figure 3 illustrates a diagram of an example computing device 300 according to the present disclosure.
  • the computing device 300 can utilize software, hardware, firmware, and/or logic to perform a number of functions described herein.
  • the computing device 300 can be any combination of hardware and program instructions configured to share information.
  • the hardware for example, can include a processing resource 304 and/or a memory resource 306 (e.g., computer-readable medium (CRM), machine readable medium (MRM), database, etc.).
  • a processing resource 304 may be integrated in a single device or distributed across multiple devices.
  • the program instructions e.g., computer-readable instructions (CRI)
  • CRM computer-readable instructions
  • the memory resource 306 can be in communication with a processing resource 304.
  • a memory resource 306, as used herein, can include any number of memory components capable of storing instructions that can be executed by processing resource 304.
  • Such memory resource 306 can be non- transitory CRM or MRM.
  • Memory resource 306 may be integrated in a single device or distributed across multiple devices. Further, memory resource 306 may be fully or partially integrated in the same device as processing resource 304 or it may be separate but accessible to that device and processing resource 304.
  • the memory resource 306 can be in communication with the processing resource 304 via a communication link (e.g., a path) 308.
  • the communication link 308 can be local or remote to a machine (e.g., computing device) associated with the processing resource 304. Examples of a local communication link 308 can include an electronic bus internal to a machine (e.g., a computing device) where the memory resource 306 is one of volatile, non-volatile, fixed, and/or removable storage medium in communication with the processing resource 304 via the electronic bus.
  • a number of modules 310, 320, 330 can include CRI that when executed by the processing resource 304 can perform a number of functions.
  • the number of modules 310, 320, 330 can be sub-modules of other modules.
  • the random proposal module 310, the suggestion proposal module 320, and the counter proposal module 330 can all be sub-modules and/or contained within a different module.
  • the number of modules 310, 320, 330 can comprise individual modules at separate and distinct locations (e.g., CRM, etc.).
  • the random proposal module 310 can generate a first plurality of proposals, the first plurality of proposals being completely random proposals (e.g., random assignment of virtual machines to physical machines) and assign a first value to a proposal in the first plurality of proposals.
  • the suggestion proposal module 320 can generate a second plurality of proposals by applying minimal logic and assign a second value to a proposal in the second plurality of proposals. The first and/or second proposal of the first and/or second plurality of proposals can be ordered based on the first and/or second value assigned.
  • the random proposal engine 254 and/or suggestion proposal engine 256 and/or counter proposal engine 258 can submit a proposal from the first and/or second plurality of proposals based on one of the first and/or second values.
  • the counter proposal module 330 can identify the first and/or second proposal(s) from the first and/or second plurality of proposals and can generate a third plurality of proposals and assign a third value to a proposal in the third plurality of proposals that is based on the value assigned to the first and/or the second proposal(s). In some embodiments, the counter proposal module 330 can order the third proposal(s) from the third plurality of proposals based on the third value assigned. In some embodiments, the modules 310, 320, and/or 330 generate and submit a number of random, suggestion, and counter-proposals based on the parameters (e.g., R, S, C, R', S', and/or C).
  • the parameters e.g., R, S, C, R', S', and/or C.
  • Each of the number of modules 310, 320, 330 can include instructions that when executed by the processing resource 304 can function as a corresponding engine as described herein.
  • the random proposal module 310 can include instructions that when executed by the processing resource 304 can function as the random proposal engine 254.
  • the suggestion proposal module 320 can include instructions that when executed by the processing resource 304 can function as the suggestion proposal engine 256.
  • the counter proposal module 330 can include instructions that when executed by the processing resource 304 can function as the counter proposal engine 258.
  • Figure 4 illustrates an environment diagram as an example of proposal generation according to the present disclosure.
  • the environment shows proposal generation based on proposal type.
  • Types of proposal generation can include a random proposal generation 410 (e.g., randomly generated proposals, non-logic based, bootstrapping, etc.), suggestion proposal generation 420 (e.g., based on some known or approximated objective function, knowledge of system constraints, knowledge of "good” proposals, etc.), and/or a counter-proposal generation 430 (e.g., compromise, proposals that balance different constraints and/or ideal networking features, perturbation of existing proposals, etc.).
  • each type of proposal generation can include resource requests and/or resource allocations among other requests.
  • Random proposal generation (e.g., completely random proposals, etc.) can be generated to meet a set of defined parameters (e.g., speed of generating a proposal, accuracy/likelihood of a high-valued proposal, and/or space available to generate the proposals, etc.).
  • the random proposals generated may be useful for SDN controllers that cannot easily determine allocation value (e.g., allocations that promote system objectives, allocations that violate system and/or module constraints, etc.). Random proposal generation may occur in multiple iterations.
  • a random proposal may include a random assignment of virtual machines to physical machines. Automatically generating random proposals removes the need to write programming logic to generate proposals.
  • logic is an alternative or additional processing resource to execute the actions and/or functions as described herein, which includes hardware (e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc.), as opposed to computer executable instructions (e.g., software, firmware, etc.) stored in memory and executable by a processor.
  • ASICs application specific integrated circuits
  • computer executable instructions e.g., software, firmware, etc.
  • the random proposal generation in which random assignments are created may not be the most efficient or effective proposals for a system.
  • the different types of proposal generation can be collected from a number of network devices to allow for the trading-off of speed, accuracy, or space in the system.
  • Parameters (R, S, C, R', S', C) allow for the tradeoff of speed, accuracy, and space.
  • the parameters R, S, and C are the number of proposals to be generated.
  • Parameter R is the number of random proposals to be generated.
  • Parameter S is the number of suggestion proposals to be
  • Parameter C is the number of counter-proposals to be generated.
  • the parameter R' is the number of the random proposals generated (R) that can be submitted to the system.
  • the parameter S' is the number of suggestion proposal generated (S) that can be submitted to the system.
  • the parameter C is the number of the suggestion proposals generated (C) that can be submitted to the system.
  • speed e.g., how quickly an engine generates a set of proposals or converges with a controller and/or multi-controllers for resource allocation
  • accuracy e.g., how valuable the requested resource are for a module's objective relative to other requests, such as a random request
  • space e.g., storage space consumed by the implementation of the method.
  • the engine and/or modules within various network devices can have different system/module efficiencies (e.g., resource capabilities, etc.). Balancing of the demands and limitations (e.g., constraints, bandwidth, etc.) of the network devices can increase an efficiency (e.g., balance of energy and costs, etc.) of the system.
  • system/module efficiencies e.g., resource capabilities, etc.
  • Balancing of the demands and limitations (e.g., constraints, bandwidth, etc.) of the network devices can increase an efficiency (e.g., balance of energy and costs, etc.) of the system.
  • any proposal that violates a constraint e.g., module constraint, power limitation, excessive bandwidth, time, etc.
  • a constraint e.g., module constraint, power limitation, excessive bandwidth, time, etc.
  • a proposal from a plurality of received proposals that are in violation of a module constraint of a network device can be filtered and/or removed from the plurality of proposals that are being evaluated for selection.
  • a set of proposals (e.g., plurality of proposals, a proposal, etc.) are generated at 412 as an initial set of proposals in the space of possible proposals (e.g., proposal that includes allocations that can complete a function, allocations that fulfill system
  • an engine e.g., random proposal engine 254 as reference in Figure 2
  • a module can submit more than one proposal for consideration.
  • the set of proposals can be evaluated 414 by an evaluation technique (e.g., an evaluation function) and each proposal can be assigned a value.
  • An evaluation function can evaluate each set of proposals in the first plurality of proposals and assign a first value to each proposal from the first plurality of proposals.
  • the assigned value is determined for each proposal based on the evaluation.
  • the evaluation function can be expressed in uniform units (e.g., normalized from [0,1], increments, currency, etc.).
  • the assigned value can be based on a feature (e.g., aspects, etc.).
  • Features can include, but are not limited to, physical location of computing devices, virtual machine (VM) assignments, power limitations, and/or bandwidth limitations, among other features of the proposal.
  • aspects manage features (e.g., bandwidth, power consumption, etc.). In some embodiments, aspects manage features of an entire network. In some embodiments, aspects manage features of a portion of a network.
  • the set of proposals can be ordered at 416 to determine the highest-valued proposals (e.g., the most valuable). In some embodiments, the set of proposals can be ordered into a sequence of decreasing value.
  • a set of random, initial, and/or outdated proposals can be refined (e.g., altered, evaluated, etc.) to relatively higher-valued proposals based on an evaluation function (e.g., evaluate the proposals based on features, etc.).
  • a relatively higher value can be closer to a threshold value.
  • a threshold value is a value that is closer to a maximum value, a predetermined threshold value, and/or a value that is acceptable to the system.
  • the suggestion proposals are generated.
  • the proposals are evaluated at 422.
  • Proposals generated from the suggestions proposal generation 420 can be generated from an externally and/or internally known objective function.
  • the objective function can be explicitly or implicitly related to the evaluation function with the assigned value based on a feature.
  • the suggestion proposals are altered with a particular amount of perturbation (e.g., minimal amount of perturbation, perturbed, perturbed allocations, etc.)
  • perturbation can include altering at least one feature of the proposal.
  • Perturbing the suggestion proposals 423 can alter a number of features of a portion of the plurality of proposals to determine a second assigned value for each proposal within the portion of plurality of proposals.
  • Perturbation may include a change in a normal state or a regular movement of a proposal.
  • Perturbation can be a small change in a physical or processing system that changes an assigned value of the proposal.
  • Perturbing features e.g., allocations, etc. involves moving a relatively small fraction of its resources in the assignment.
  • the relatively small fraction can be a value that is utilized to perturb and/or alter resource assignments for the plurality of proposals.
  • perturbing allocations can include altering the location of a single virtual machine (VM) from a first physical computing device to a second physical computing device.
  • the evaluation function can evaluate the suggestion proposals from 421 and refined proposals 423. Each proposal within the plurality of proposals is assigned a value.
  • the set of proposals from 421 and 423 can be ordered by decreasing value. That is, the suggestion proposals 425 are ordered from a relatively greater value (e.g., greatest value) to suggestion proposals that have a relatively low value (e.g., minimum value).
  • the proposals are submitted.
  • the suggestion proposals that are submitted can include a portion of proposals that exceed a defined threshold value. In other embodiments, the proposals that are submitted can include a percentage of proposals that have a relatively higher value compared to other proposals.
  • submission of the suggestion proposal from the plurality of proposals can be based on the assigned values.
  • the counter-proposal generation 430 can determine a third (e.g., alternative and/or "compromise") proposal when the random proposal module and/or suggestion proposal module proposals cannot be accepted by the system (e.g., bandwidth constraints, monetary costs, etc.).
  • the counterproposal generation is based on knowledge of the current network allocation (e.g., current features of system, etc.) and/or the best previous proposal from the random proposal generation 410 and/or the suggestion proposal generation 420.
  • the counter-proposal generation 430 can include identifying the best previous proposal from the random proposal generation 410 and/or suggestion proposal generation 432. Ordinarily, the selected proposal is the output of the suggestion proposal generation 420, otherwise, it is the output of the random proposal generation 410.
  • the counter-proposal generation 430 can generate a number of proposals "in between" 434 the "best" random and/or suggestion proposal generation and a known "good" proposal.
  • the counter-proposal generates a third set of proposals 434 (e.g., alternative plurality of proposals, etc.).
  • the counter proposal generation 430 can order the set of proposals by ordering the proposals based on their value.
  • the counter-proposals can be submitted at 436 to an auditor.
  • the top set e.g., highest value assigned for the plurality of proposals, greatest compromise value, etc.
  • the counter-proposal generation 430 can trade-off speed and space by also returning accuracy, a higher set of proposals (e.g., increase the number of counter-proposals desired (e.g., C and C), which in turn takes longer to generate the number of proposals and increases space consumption, but returns better, more accurate proposals), etc.).
  • the counter-proposal generation 430 can assign a third value to each proposal from the plurality of proposals.
  • An example of a counter-proposal can include finding a sequence of "alterations" (e.g., moves, each move can result in a single-step perturbation) that transforms the random proposal or suggestion proposal via perturbations to a higher (e.g., best, ideal proposal, etc.) for the system to select.
  • alterations e.g., moves, each move can result in a single-step perturbation
  • a higher e.g., best, ideal proposal, etc.
  • a counter-proposal generation (e.g., a compromise proposal) can be based on knowledge of a current network allocation, selected proposal, and/or "winning" proposal. Automatically generating counter-proposals can allow for a contingency where a particular proposal (e.g., proposal with a relatively high value, proposal with a highest value compared to the other proposals within a plurality of proposals, etc.) cannot be accepted for a reason. In circumstances where a particular proposal can not be selected, a third (e.g., alternative) proposal can be generated that resembles the particular proposal and the currently enacted (or soon to be) allocation.
  • a particular proposal e.g., proposal with a relatively high value, proposal with a highest value compared to the other proposals within a plurality of proposals, etc.
  • a third (e.g., alternative) proposal can be generated that resembles the particular proposal and the currently enacted (or soon to be) allocation.
  • a module can be instructed for how many of each type of proposal to generate.
  • a module can take as input the parameters R, S, C, which reflect the number of random (“R"), suggestion ("S"), and counter-proposal ("C") proposals to generate.
  • R random
  • S suggestion
  • C counter-proposal
  • a module can also take as input the parameters R', S', C which represent the number of proposals submitted from the original proposals generated (i.e., R, S, C), where R ' ⁇ R, s r ⁇ s, and c ? ⁇ c.
  • the choice of these parameters can represent a trade-off between speed, space, and accuracy.
  • a relatively large R, S, or C, and R', S', or C may use more storage space and require more time to compute, but can lead to a higher likelihood of generating proposals with high evaluation scores.
  • Using a relatively high R',S',C parameters relative to R,S,C can also increase the likelihood of a module having any of its proposals accepted at the risk of a lower evaluation score.
  • the generation of counter-proposals to contain an additional parameter can be included, wherein the additional parameter can describe which direction to prioritize counter-proposals.
  • FIG. 5 illustrates a flow diagram 500 for an example of proposal generation (e.g., random, suggestion, and/or counter-proposal) according to the present disclosure.
  • a module within an SDN controller generates a number of proposals of each type of proposal (e.g., random, suggestion, and/or counter-proposal, etc.).
  • Each proposal generation type may have at least one parameter that can be used to trade off speed (e.g., how quickly one can generate a set of proposals or converge with the meta-controller for a resource allocation), accuracy (e.g., how valuable the requested resources are for a modules objective, such as relative to a random request), and space (e.g., storage space consumed by the implementation of the method).
  • a set of proposals is generated as a starting set of proposals in the space of possible proposals, in accordance with a number of features (e.g., allocations, etc.).
  • the generation of the random set of proposals 510 is based on parameters that tradeoff speed, space, and accuracy.
  • the module can generate a set of completely random allocations.
  • the set of proposals can be evaluated at 512 by an evaluation technique (e.g., evaluation function) and each proposal assigned a value (e.g., a dollar value, cardinal, etc.).
  • the network can comprise a first network controller and a second network controller.
  • the first network controller can generate a plurality of proposals that meet a set of parameters for a first aspect of the network. Parameters influence speed, accuracy, and space of each of the first and second plurality of proposals.
  • the set of proposals can be ordered 514 into a sequence of decreasing value.
  • evaluating the plurality of proposals and assigning a first value to each proposal from the plurality of proposals, wherein the value is based on a feature of a corresponding proposal can occur. Based on the defined parameters (e.g., R and R', etc.), the random proposals are submitted at box 540.
  • a set of suggestion proposals is generated.
  • the set of suggestion proposals are evaluated and assigned a value at box 522.
  • the set of suggestion proposals are refined via perturbations at box 524.
  • the set of random and/or outdated proposals e.g., no longer useful proposals, etc.
  • the module can have input parameters and its original set of ordered allocations from the random proposal generation, as described herein.
  • the modules can evaluate the set of proposals via an evaluation function 526 (e.g., evaluation technique), wherein the evaluation function is normalized (e.g., normalized from [0,1 ], etc.).
  • each proposal can have a virtual machine assigned to its own physical machine and may have a maximum ("good") evaluation of 1 and a minimum (“worst”) evaluation of 0.
  • the assigned value is determined for each proposal based on the evaluation at 526.
  • the plurality of modules can evaluate the set of proposals and the evaluation function can be expressed in uniform units (e.g., normalized from [0,1], increments, etc.).
  • a suggestion proposal can be based on knowledge of a relatively good, or set of "good” proposals.
  • a "good” proposal can be one that returns a relatively large number for the module's evaluation function.
  • alterations to the proposals can be used to generate other perturbations that are similar to a "good” proposal.
  • the suggestion proposal generation alters the feature of a second portion of the plurality of proposals to determine a second value for each proposal within the portion of the plurality of proposals.
  • the first and second plurality of proposals are refined in some embodiments when the proposal engine alters the portion the first and second plurality of proposals via perturbations. As described herein, the proposals may have minor perturbations applied so as to try and increase the value.
  • the first network controller receives a second plurality of proposals that are generated by a second network controller that meet a set of defined parameters for a second aspect of the network.
  • the set of proposals are evaluated and assigned a value at box 526.
  • the set of proposals are numerically ordered based on value at box 528.
  • the suggestion proposals are submitted at box 540.
  • a threshold e.g., defined threshold, predefined threshold, compatible with system requirements, etc.
  • a determination at box 540 is that the set of random and/or suggestion proposals is not within a defined threshold (e.g., violation of module/system constraints, excessive bandwidth, proposal cannot be accepted by the system (i.e., meta-controller) for some reason, etc.) the process moves to box 530 in which determining a proposal with a relatively high value (e.g., best, ideal proposal, "winning” proposal, current "winning” proposal, etc.), and identifying said proposal as a "best" previous random and/or suggestion proposal 530.
  • a defined threshold e.g., violation of module/system constraints, excessive bandwidth, proposal cannot be accepted by the system (i.e., meta-controller) for some reason, etc.
  • assigning the value to each proposal includes categorizing each proposal, wherein the categories include a first category that includes proposals with a value that is greater than a predetermined threshold and a second category that includes proposals with a value that is less than the predetermined assigned value.
  • Box 540 determines whether the counter-proposal (e.g., top counter proposal, counter proposal with a relatively high value, counter proposal with a greatest value, etc.) set is within a defined threshold (e.g., complies with constraints, acceptable to the system, complies with constraints, etc.). If the set is within the defined threshold 540, the set of counter-proposals moves to box 541 in which a counter-proposal from the set of counter-proposals is submitted 541 to the auditor for selection and/or implementation.
  • a defined threshold e.g., complies with constraints, acceptable to the system, complies with constraints, etc.
  • a module can generate a third plurality of proposals that is generated for the first network controller and that meet a set of defined parameters for the first portion of the network; and assign a third value to each proposal from the third plurality of proposals.
  • instructions generate an alternate plurality of proposals to create counterproposals, wherein creating counter-proposals includes generating the third plurality of proposals based on the defined parameters and the selected proposals.
  • the counter-proposal engine receives an altered set of defined parameters that are utilized to generate a third plurality of proposals based on the altered set of defined parameters (e.g., an alternative plurality of proposals, or a third plurality of proposals).
  • the first, second, and third plurality of proposals is normalized and ordered based on a threshold of the assigned value. If the set is within the defined threshold 540, the set of counter-proposals moves to box 541 in which a counter-proposal from the set of counter-proposals is submitted to an auditor for selection and/or implementation.
  • filtering the set of proposals into a sequence according to a threshold value and submitting a portion of proposals that include a value that is greater than the threshold value can occur.
  • a proposal from the plurality of proposals in violation of a module constraint is filtered and removed from the plurality of proposals.
  • a proposal that violates a module's constraints can be filtered out and/or removed from the system's consideration for selection.
  • a proposal from at least one of the first, second, and third plurality of proposals in violation of a module constraint is filtered and removed from the respective plurality of proposals.
  • filtering the set of proposals according to value and submitting a portion of proposals that include a value that is greater than the threshold value can occur.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A method for generating proposals in a network can include, generating a first plurality of proposals for a first aspect of the network for a first controller, wherein each proposal from the first plurality of proposals assigns resources based on defined parameters, evaluating each proposal in the first plurality of proposals based on features of the first plurality of proposals, assigning a value to each proposal in the first plurality of proposals based on the evaluation, ordering the first plurality of proposals into a sequence according to the assigned values, the first network controller receiving a second plurality of proposals from a second network controller based on the first plurality of proposals via perturbation, submitting a proposal from the second plurality of proposals, and instructing a module associated with a selected proposal from the portion of proposals to implement the selected proposal.

Description

PROPOSAL GENERATION FOR A NETWORK
Background
[0001] A Software Defined Network (SDN) controller is software that manages the control plane of a network. SDN controllers leverage protocols, such as OpenFlow®, to manage SDN-supported switches in order to control the flow of network packets, for example. A controller may be considered the core of an SDN or similar controller-based system. A controller may lie anywhere in the system with connectivity to the network devices and end-points such as servers and end-clients. Any communication between the end-points may go through a controller.
Brief Description of the Drawings
[0002] Fig. 1 illustrates an example of a system in accordance with an implementation according to the present disclosure.
[0003] Fig. 2 illustrate examples of systems in accordance with an implementation according to the present disclosure
[0004] Fig. 3 illustrate examples of systems in accordance with an implementation according to the present disclosure.
[0005] Fig. 4 illustrates an environment diagram as an example of proposal generation according to the present disclosure.
[0006] Fig. 5 illustrates a flow diagram for an example of a method for proposal generation according to the present disclosure. Detailed Description
[0007] A network can include a variety of network devices (e.g., routers, switches, etc.) with varying capabilities (e.g., receiving software instructions, communicating with a network controller and/or network controllers, and/or multiple controllers, etc.). Software Defined Network (SDN) network devices can be network devices capable of receiving software instructions such as forwarding rules from a network controller (e.g., network manager, etc.). An SDN controller (e.g., network controller, controller, multiple-controllers, etc.) can include an application that manages flow control (e.g. data flow, etc.) to enable intelligent networking. SDN controllers can be based on protocols, such as OpenFlow®, that allow servers to guide network devices on where to send packets (e.g., data packets, etc.). The SDN controller can be located between network devices at a first end and applications at a second end. Any
communication between end-points and/or devices can be routed (e.g., sent, distributed, etc.) through the SDN controller.
[0008] In a system that includes a plurality of SDN controllers (e.g., multiple controllers or "multi-controller", modules, etc.), each of the plurality of SDN controllers can compete for resources (e.g., network devices, bandwidth, etc.) That is, two or more SDN controllers and/or two or more
applications/modules on a single SDN controller can compete for one or more finite resources (e.g., link bandwidth, switch table slots, the placement of a flow or virtual machine in a physical topology). In this type of system, SDN
controllers may generate different types of proposal requests (e.g., resource requests, resource allocation, etc.) in order to receive resources and may further generate proposals and/or counter-proposals to arrive at an allocation that provides a particular function.
[0009] A number of proposal types (e.g., random, suggestion, and counter-proposal) can be generated and allow an SDN controller to report (e.g., send, export, etc.) information about local objectives and/or policies of the SDN controller and/or multiple SDN controllers (e.g., multi-SDN controller, multi- controller, meta-controller, modules, etc.). Multiple controllers can operate in coordination, can be interconnected, and/or can manage different aspects of the network while competing for shared resources. The reported information can maximize system-wide objectives while also meeting policy constraints of the system. Multiple controllers can share network information and can operate in coordination to improve route optimization and/or other allocation decisions. Multiple controllers can share information in the same or different networks. Sharing information can include sending and/or receiving proposals between the multiple controllers. For example, a first controller can generate a proposal that includes resource allocations as described herein. In this example, the first controller can share the information by sending the generated proposal to a second controller. In this example, the second controller can be a central controller designed to receive proposals from other controllers in addition to generating proposals.
[0010] Proposals and/or counter-proposals are used to help a controller satisfy its objectives (e.g., power consumption limits, resource consumptions, cost, etc.), and in aggregate, these proposals allow the system to reach global system-wide objectives. Each module can choose from parameters R, S, C, R', S', and/or C to tradeoff between speed, accuracy, and space consumption in generating proposals and/or counter-proposals. The parameters can be used to generalize the tradeoff random jumps in the search space with a progressive search (e.g., continuous search, etc.) to increase the likelihood of generating proposals with an increased value in an effort to find a "best" proposal from the plurality of proposals.
[0011] In some embodiments, a first number of the controllers of the multiple controllers can be utilized for a first aspect (e.g., bandwidth, flow latency, flow level, feature, etc.) of the network and a second number of controllers of the multiple controllers can be utilized for a second aspect of the network. For example, a first network controller can be configured to allocate resources for a first aspect and/or portion of a network and a second network controller can be configured to allocate resources for a second aspect and or/portion of the network. In one embodiment, a network controller from the multiple controllers can be designated to receive proposals from a plurality of other controllers that correspond to portions of the network and select a proposal to allocate resources to each of the corresponding portions of the network.
[0012] In the following detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be utilized and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.
[0013] As used herein, "a" or "a number of" something can refer to one or more such things. For example, "a number of network devices" can refer to one or more network devices.
[0014] Figure 1 illustrates an example of a system 100 in accordance with an implementation according to the present disclosure. The system 100 comprises modules 1 10, 120 and 130, a central coordinator 140, and an SDN controller 150. The system 100 comprises controllers/modules 1 10, 120 and 130, each performing a specific function and may be used alone or combined with other modules. The modules 1 10, 120, and/or 130 can each perform a specific function for a particular aspect (e.g., bandwidth, flow latency, flow level, feature, etc.) of the network. In some embodiments, the modules can perform the function for the particular aspect of an entire network (e.g., physical network, virtual network, combination of physical and virtual network, etc.). In other embodiments, modules 1 10, 120, and/or 130 can perform the function for the particular aspect of a portion of the network (e.g., partial network, specific area of the network, etc.). In some embodiments, the modules 1 10, 120, and 130, can include a bandwidth allocator module, which is a module that allocates guaranteed bandwidth to a set of endpoints. In some embodiments, the modules 1 10, 120, and 130, can include a flow latency controller module, which is a module to support end-to-end latency bounds for flows or flow classes. In some embodiments, the modules 1 10, 120, and 130, can include a flow-level traffic engineering module, which is a module that re-routes flows to achieve an objective, such as load balancing. In some embodiments, the modules 1 10, 120, and 130, can include a VM-migrator, which is a module that migrates VMs between servers, e.g., for consolidation. In some embodiments, the modules 1 10, 120, and 130, can include a power control manager, which is a module that reduces energy costs by attempting to turn off under-utilized resources.
[0015] The modules 1 10, 120 and 130 may generate one or more proposals for reservations of resources. In some embodiments, a proposal may represent a change in the current reservation state with a specific start time and end time. Such proposals propose to modify the system 100, which results in a topology change. The topology change can involve turning servers, switches, or links on or off, adding a switch table entry, or moving virtual machines (e.g., a software implementation of a machine (i.e. a computer) that executes programs like a physical machine). Further, the resources can include a fraction of a link's bandwidth, a rate limiter or switch port, an entire line card, an internet group management protocol table entry, a virtual local area network tag, a queue and/or an OpenFlow table entry.
[0016] The modules 1 10, 120 and 130 can generate proposals in response to new inputs (e.g. a customer request for bandwidth), changes in network reservation state (e.g., no more reservations for line-card), and periodic timer (e.g., load balancing across link technologies).
[0017] Each individual module 1 10, 120 or 130 may have its own set of policies and objectives. In some embodiments, policies can express constraints on what may be allowed, and objectives can express the costs and benefits of specific proposals. In some embodiments, a topology proposed by one module might violate the policies of another module. For such an embodiment, it may be necessary to enforce each module's policies.
[0018] Figure 2 illustrates examples of a system 200 in accordance with an implementation according to the present disclosure. The system 200 can include a data store 202, a proposal processing system 204, a random proposal engine 254, a suggestion proposal engine 256, and/or a counter-proposal engine 258. The proposal processing system 204 can be in communication with the data store 202 via a communication link, and can include the engines 254, 256, and 258. The proposal processing system 204 can include additional engines other than illustrated to perform the various functions described herein.
[0019] The random proposal engine 254, suggestion proposal engine 256, and counter-proposal engine 258 can include a combination of hardware and programming that is configured to perform a number of functions described herein (e.g., generate proposals in a network, evaluate the plurality of proposals, alter a feature of a proposal, select a proposal, etc.). The
programming can include program instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., computer readable medium, machine readable medium, etc.) as well as hard-wired program (e.g. logic).
[0020] Figure 3 illustrates a diagram of an example computing device 300 according to the present disclosure. The computing device 300 can utilize software, hardware, firmware, and/or logic to perform a number of functions described herein.
[0021] The computing device 300 can be any combination of hardware and program instructions configured to share information. The hardware, for example, can include a processing resource 304 and/or a memory resource 306 (e.g., computer-readable medium (CRM), machine readable medium (MRM), database, etc.). A processing resource 304 may be integrated in a single device or distributed across multiple devices. The program instructions (e.g., computer-readable instructions (CRI)) can include instructions stored on the memory resource 306 and executable by the processing resource 304 to implement a particular function (e.g., generate proposals in a multi-controller network).
[0022] The memory resource 306 can be in communication with a processing resource 304. A memory resource 306, as used herein, can include any number of memory components capable of storing instructions that can be executed by processing resource 304. Such memory resource 306 can be non- transitory CRM or MRM. Memory resource 306 may be integrated in a single device or distributed across multiple devices. Further, memory resource 306 may be fully or partially integrated in the same device as processing resource 304 or it may be separate but accessible to that device and processing resource 304.
[0023] The memory resource 306 can be in communication with the processing resource 304 via a communication link (e.g., a path) 308. The communication link 308 can be local or remote to a machine (e.g., computing device) associated with the processing resource 304. Examples of a local communication link 308 can include an electronic bus internal to a machine (e.g., a computing device) where the memory resource 306 is one of volatile, non-volatile, fixed, and/or removable storage medium in communication with the processing resource 304 via the electronic bus.
[0024] A number of modules 310, 320, 330 can include CRI that when executed by the processing resource 304 can perform a number of functions. The number of modules 310, 320, 330 can be sub-modules of other modules. For example, the random proposal module 310, the suggestion proposal module 320, and the counter proposal module 330 can all be sub-modules and/or contained within a different module. In another example, the number of modules 310, 320, 330 can comprise individual modules at separate and distinct locations (e.g., CRM, etc.).
[0025] In some embodiments, the random proposal module 310 can generate a first plurality of proposals, the first plurality of proposals being completely random proposals (e.g., random assignment of virtual machines to physical machines) and assign a first value to a proposal in the first plurality of proposals. In some embodiments, the suggestion proposal module 320 can generate a second plurality of proposals by applying minimal logic and assign a second value to a proposal in the second plurality of proposals. The first and/or second proposal of the first and/or second plurality of proposals can be ordered based on the first and/or second value assigned. The random proposal engine 254 and/or suggestion proposal engine 256 and/or counter proposal engine 258 can submit a proposal from the first and/or second plurality of proposals based on one of the first and/or second values.
[0026] In some embodiments, the counter proposal module 330 can identify the first and/or second proposal(s) from the first and/or second plurality of proposals and can generate a third plurality of proposals and assign a third value to a proposal in the third plurality of proposals that is based on the value assigned to the first and/or the second proposal(s). In some embodiments, the counter proposal module 330 can order the third proposal(s) from the third plurality of proposals based on the third value assigned. In some embodiments, the modules 310, 320, and/or 330 generate and submit a number of random, suggestion, and counter-proposals based on the parameters (e.g., R, S, C, R', S', and/or C). Each of the number of modules 310, 320, 330 can include instructions that when executed by the processing resource 304 can function as a corresponding engine as described herein. For example, the random proposal module 310 can include instructions that when executed by the processing resource 304 can function as the random proposal engine 254. In another example, the suggestion proposal module 320 can include instructions that when executed by the processing resource 304 can function as the suggestion proposal engine 256. In another example, the counter proposal module 330 can include instructions that when executed by the processing resource 304 can function as the counter proposal engine 258.
[0027] Figure 4 illustrates an environment diagram as an example of proposal generation according to the present disclosure. The environment shows proposal generation based on proposal type. Types of proposal generation can include a random proposal generation 410 (e.g., randomly generated proposals, non-logic based, bootstrapping, etc.), suggestion proposal generation 420 (e.g., based on some known or approximated objective function, knowledge of system constraints, knowledge of "good" proposals, etc.), and/or a counter-proposal generation 430 (e.g., compromise, proposals that balance different constraints and/or ideal networking features, perturbation of existing proposals, etc.). As described herein, each type of proposal generation can include resource requests and/or resource allocations among other requests.
[0028] Random proposal generation (e.g., completely random proposals, etc.) can be generated to meet a set of defined parameters (e.g., speed of generating a proposal, accuracy/likelihood of a high-valued proposal, and/or space available to generate the proposals, etc.). The random proposals generated may be useful for SDN controllers that cannot easily determine allocation value (e.g., allocations that promote system objectives, allocations that violate system and/or module constraints, etc.). Random proposal generation may occur in multiple iterations. For example, a random proposal may include a random assignment of virtual machines to physical machines. Automatically generating random proposals removes the need to write programming logic to generate proposals. As used herein, "logic" is an alternative or additional processing resource to execute the actions and/or functions as described herein, which includes hardware (e.g., various forms of transistor logic, application specific integrated circuits (ASICs), etc.), as opposed to computer executable instructions (e.g., software, firmware, etc.) stored in memory and executable by a processor. However, the random proposal generation in which random assignments are created, may not be the most efficient or effective proposals for a system.
[0029] In some embodiments, the different types of proposal generation (random, suggestion, counter-proposal, etc.) can be collected from a number of network devices to allow for the trading-off of speed, accuracy, or space in the system. Parameters (R, S, C, R', S', C) allow for the tradeoff of speed, accuracy, and space. The parameters R, S, and C are the number of proposals to be generated. Parameter R is the number of random proposals to be generated. Parameter S is the number of suggestion proposals to be
generated. Parameter C is the number of counter-proposals to be generated. The parameter R' is the number of the random proposals generated (R) that can be submitted to the system. The parameter S' is the number of suggestion proposal generated (S) that can be submitted to the system. The parameter C is the number of the suggestion proposals generated (C) that can be submitted to the system. Based on the parameters, there can be a tradeoff of speed (e.g., how quickly an engine generates a set of proposals or converges with a controller and/or multi-controllers for resource allocation), accuracy (e.g., how valuable the requested resource are for a module's objective relative to other requests, such as a random request), and/or space (e.g., storage space consumed by the implementation of the method). The engine and/or modules within various network devices can have different system/module efficiencies (e.g., resource capabilities, etc.). Balancing of the demands and limitations (e.g., constraints, bandwidth, etc.) of the network devices can increase an efficiency (e.g., balance of energy and costs, etc.) of the system.
[0030] Within all three types of proposal generation (random proposal, suggestion proposal, and counter-proposal) any proposal that violates a constraint (e.g., module constraint, power limitation, excessive bandwidth, time, etc.) of the network devices and/or modules within the network devices can be filtered out and/or removed from consideration for selection. For example, a proposal from a plurality of received proposals that are in violation of a module constraint of a network device can be filtered and/or removed from the plurality of proposals that are being evaluated for selection.
[0031] At the random proposal generation 410, a set of proposals (e.g., plurality of proposals, a proposal, etc.) are generated at 412 as an initial set of proposals in the space of possible proposals (e.g., proposal that includes allocations that can complete a function, allocations that fulfill system
constraints, etc.), in accordance with particular allocations. In some
embodiments, an engine (e.g., random proposal engine 254 as reference in Figure 2) generates a plurality of proposals based on a set of defined
parameters (R, S, C, R', S', and/or C). In some embodiments, a module can submit more than one proposal for consideration.
[0032] The set of proposals can be evaluated 414 by an evaluation technique (e.g., an evaluation function) and each proposal can be assigned a value. An evaluation function can evaluate each set of proposals in the first plurality of proposals and assign a first value to each proposal from the first plurality of proposals. The assigned value is determined for each proposal based on the evaluation. The evaluation function can be expressed in uniform units (e.g., normalized from [0,1], increments, currency, etc.). The assigned value can be based on a feature (e.g., aspects, etc.). Features can include, but are not limited to, physical location of computing devices, virtual machine (VM) assignments, power limitations, and/or bandwidth limitations, among other features of the proposal. Aspects manage features (e.g., bandwidth, power consumption, etc.). In some embodiments, aspects manage features of an entire network. In some embodiments, aspects manage features of a portion of a network. The set of proposals can be ordered at 416 to determine the highest-valued proposals (e.g., the most valuable). In some embodiments, the set of proposals can be ordered into a sequence of decreasing value.
[0033] At the suggestion proposal generation 420, a set of random, initial, and/or outdated proposals can be refined (e.g., altered, evaluated, etc.) to relatively higher-valued proposals based on an evaluation function (e.g., evaluate the proposals based on features, etc.). A relatively higher value can be closer to a threshold value. A threshold value is a value that is closer to a maximum value, a predetermined threshold value, and/or a value that is acceptable to the system. At 421 , the suggestion proposals are generated. The proposals are evaluated at 422. Proposals generated from the suggestions proposal generation 420 can be generated from an externally and/or internally known objective function. The objective function can be explicitly or implicitly related to the evaluation function with the assigned value based on a feature.
[0034] At 423, the suggestion proposals are altered with a particular amount of perturbation (e.g., minimal amount of perturbation, perturbed, perturbed allocations, etc.) As described herein, perturbation can include altering at least one feature of the proposal. Perturbing the suggestion proposals 423 can alter a number of features of a portion of the plurality of proposals to determine a second assigned value for each proposal within the portion of plurality of proposals. Perturbation may include a change in a normal state or a regular movement of a proposal. Perturbation can be a small change in a physical or processing system that changes an assigned value of the proposal. Perturbing features (e.g., allocations, etc.) involves moving a relatively small fraction of its resources in the assignment. That is, the relatively small fraction can be a value that is utilized to perturb and/or alter resource assignments for the plurality of proposals. For example, perturbing allocations can include altering the location of a single virtual machine (VM) from a first physical computing device to a second physical computing device. [0035] At 424, the evaluation function can evaluate the suggestion proposals from 421 and refined proposals 423. Each proposal within the plurality of proposals is assigned a value. At 425 the set of proposals from 421 and 423 can be ordered by decreasing value. That is, the suggestion proposals 425 are ordered from a relatively greater value (e.g., greatest value) to suggestion proposals that have a relatively low value (e.g., minimum value). At 426, the proposals are submitted. In some embodiments, the suggestion proposals that are submitted can include a portion of proposals that exceed a defined threshold value. In other embodiments, the proposals that are submitted can include a percentage of proposals that have a relatively higher value compared to other proposals. Submission of the suggestion proposal from the plurality of proposals can be based on the assigned values.
[0036] The counter-proposal generation 430 can determine a third (e.g., alternative and/or "compromise") proposal when the random proposal module and/or suggestion proposal module proposals cannot be accepted by the system (e.g., bandwidth constraints, monetary costs, etc.). The counterproposal generation is based on knowledge of the current network allocation (e.g., current features of system, etc.) and/or the best previous proposal from the random proposal generation 410 and/or the suggestion proposal generation 420. The counter-proposal generation 430 can include identifying the best previous proposal from the random proposal generation 410 and/or suggestion proposal generation 432. Ordinarily, the selected proposal is the output of the suggestion proposal generation 420, otherwise, it is the output of the random proposal generation 410. The counter-proposal generation 430 can generate a number of proposals "in between" 434 the "best" random and/or suggestion proposal generation and a known "good" proposal.
[0037] The counter-proposal generates a third set of proposals 434 (e.g., alternative plurality of proposals, etc.). The counter proposal generation 430 can order the set of proposals by ordering the proposals based on their value. The counter-proposals can be submitted at 436 to an auditor. In some embodiments, the top set (e.g., highest value assigned for the plurality of proposals, greatest compromise value, etc.) is submitted to an auditor. The counter-proposal generation 430 can trade-off speed and space by also returning accuracy, a higher set of proposals (e.g., increase the number of counter-proposals desired (e.g., C and C), which in turn takes longer to generate the number of proposals and increases space consumption, but returns better, more accurate proposals), etc.). The counter-proposal generation 430 can assign a third value to each proposal from the plurality of proposals.
[0038] An example of a counter-proposal can include finding a sequence of "alterations" (e.g., moves, each move can result in a single-step perturbation) that transforms the random proposal or suggestion proposal via perturbations to a higher (e.g., best, ideal proposal, etc.) for the system to select.
[0039] A counter-proposal generation (e.g., a compromise proposal) can be based on knowledge of a current network allocation, selected proposal, and/or "winning" proposal. Automatically generating counter-proposals can allow for a contingency where a particular proposal (e.g., proposal with a relatively high value, proposal with a highest value compared to the other proposals within a plurality of proposals, etc.) cannot be accepted for a reason. In circumstances where a particular proposal can not be selected, a third (e.g., alternative) proposal can be generated that resembles the particular proposal and the currently enacted (or soon to be) allocation.
[0040] For each of the three proposal generation types (random proposal, suggestion proposal, and counter-proposal), a module can be instructed for how many of each type of proposal to generate. A module can take as input the parameters R, S, C, which reflect the number of random ("R"), suggestion ("S"), and counter-proposal ("C") proposals to generate. A module can also take as input the parameters R', S', C which represent the number of proposals submitted from the original proposals generated (i.e., R, S, C), where R' < R, sr < s, and c? < c. The choice of these parameters (all non-negative integers) can represent a trade-off between speed, space, and accuracy. For example, a relatively large R, S, or C, and R', S', or C may use more storage space and require more time to compute, but can lead to a higher likelihood of generating proposals with high evaluation scores. Using a relatively high R',S',C parameters relative to R,S,C can also increase the likelihood of a module having any of its proposals accepted at the risk of a lower evaluation score.
[0041] For example, if C'=1 and C=5, the parameter setting can allow for all 5 different counter-proposals (e.g., compromise) to be generated by the module. If C < 5, then fewer proposals will be submitted to the system, and if C'=1 , the module can simply submit the "highest score" counter-proposal (e.g., highest value assigned for the plurality of proposals, highest compromise value, etc.). In addition, the generation of counter-proposals to contain an additional parameter can be included, wherein the additional parameter can describe which direction to prioritize counter-proposals.
[0042] Figure 5 illustrates a flow diagram 500 for an example of proposal generation (e.g., random, suggestion, and/or counter-proposal) according to the present disclosure. In some embodiments, a module within an SDN controller generates a number of proposals of each type of proposal (e.g., random, suggestion, and/or counter-proposal, etc.). Each proposal generation type may have at least one parameter that can be used to trade off speed (e.g., how quickly one can generate a set of proposals or converge with the meta-controller for a resource allocation), accuracy (e.g., how valuable the requested resources are for a modules objective, such as relative to a random request), and space (e.g., storage space consumed by the implementation of the method).
[0043] At box 510 a set of proposals is generated as a starting set of proposals in the space of possible proposals, in accordance with a number of features (e.g., allocations, etc.). The generation of the random set of proposals 510 is based on parameters that tradeoff speed, space, and accuracy. In some embodiments, the module can generate a set of completely random allocations. The set of proposals can be evaluated at 512 by an evaluation technique (e.g., evaluation function) and each proposal assigned a value (e.g., a dollar value, cardinal, etc.). In some embodiments, the network can comprise a first network controller and a second network controller. In some embodiments, the first network controller can generate a plurality of proposals that meet a set of parameters for a first aspect of the network. Parameters influence speed, accuracy, and space of each of the first and second plurality of proposals. The set of proposals can be ordered 514 into a sequence of decreasing value. In some embodiments, evaluating the plurality of proposals and assigning a first value to each proposal from the plurality of proposals, wherein the value is based on a feature of a corresponding proposal, can occur. Based on the defined parameters (e.g., R and R', etc.), the random proposals are submitted at box 540.
[0044] At box 520, a set of suggestion proposals is generated. The set of suggestion proposals are evaluated and assigned a value at box 522. The set of suggestion proposals are refined via perturbations at box 524. The set of random and/or outdated proposals (e.g., no longer useful proposals, etc.) can be refined (e.g., a feature of the proposal is altered, etc.) to generate a higher- valued proposal based on the module's evaluation function. The module can have input parameters and its original set of ordered allocations from the random proposal generation, as described herein. The modules can evaluate the set of proposals via an evaluation function 526 (e.g., evaluation technique), wherein the evaluation function is normalized (e.g., normalized from [0,1 ], etc.). For example, each proposal can have a virtual machine assigned to its own physical machine and may have a maximum ("good") evaluation of 1 and a minimum ("worst") evaluation of 0. The assigned value is determined for each proposal based on the evaluation at 526. The plurality of modules can evaluate the set of proposals and the evaluation function can be expressed in uniform units (e.g., normalized from [0,1], increments, etc.). A suggestion proposal can be based on knowledge of a relatively good, or set of "good" proposals. A "good" proposal can be one that returns a relatively large number for the module's evaluation function. In some embodiments, alterations to the proposals can be used to generate other perturbations that are similar to a "good" proposal.
[0045] In some embodiments, the suggestion proposal generation alters the feature of a second portion of the plurality of proposals to determine a second value for each proposal within the portion of the plurality of proposals. The first and second plurality of proposals are refined in some embodiments when the proposal engine alters the portion the first and second plurality of proposals via perturbations. As described herein, the proposals may have minor perturbations applied so as to try and increase the value. In some
embodiments, the first network controller receives a second plurality of proposals that are generated by a second network controller that meet a set of defined parameters for a second aspect of the network. The set of proposals are evaluated and assigned a value at box 526. The set of proposals are numerically ordered based on value at box 528. Based on the defined parameters (e.g., S and S', etc.) the suggestion proposals are submitted at box 540.
[0046] At box 540 a determination is made if the set of random and/or suggestion proposals are within a threshold (e.g., defined threshold, predefined threshold, compatible with system requirements, etc.). If it is determined that the set of random and/or suggestion proposals are within a threshold (e.g., defined threshold, predefined threshold, compatible with system requirements, etc.) the random and/or suggestion proposal is submitted to auditor 541 (e.g., meta-controller) for selection and/or implementation. In some embodiments, the system selects a proposal from the first and second plurality of proposals based on one of the first and second values. At box 541 the selected proposal is submitted to the system (e.g., meta-controller, etc.) for actualization by at least one module. If a determination at box 540 is that the set of random and/or suggestion proposals is not within a defined threshold (e.g., violation of module/system constraints, excessive bandwidth, proposal cannot be accepted by the system (i.e., meta-controller) for some reason, etc.) the process moves to box 530 in which determining a proposal with a relatively high value (e.g., best, ideal proposal, "winning" proposal, current "winning" proposal, etc.), and identifying said proposal as a "best" previous random and/or suggestion proposal 530. Once the "best" previous proposal is identified, the process can move to box 532 and can generate counter-proposals (e.g., proposals that are "in between" the said "best" proposal and a random and/or suggestion evaluated proposal 514 and/or 528). The set of counter-proposals can be evaluated 534 and ordered according to decreasing value based on the evaluation function for each counter-proposal. In some embodiments, assigning the value to each proposal includes categorizing each proposal, wherein the categories include a first category that includes proposals with a value that is greater than a predetermined threshold and a second category that includes proposals with a value that is less than the predetermined assigned value.
[0047] Box 540 determines whether the counter-proposal (e.g., top counter proposal, counter proposal with a relatively high value, counter proposal with a greatest value, etc.) set is within a defined threshold (e.g., complies with constraints, acceptable to the system, complies with constraints, etc.). If the set is within the defined threshold 540, the set of counter-proposals moves to box 541 in which a counter-proposal from the set of counter-proposals is submitted 541 to the auditor for selection and/or implementation.
[0048] In some embodiments, a module can generate a third plurality of proposals that is generated for the first network controller and that meet a set of defined parameters for the first portion of the network; and assign a third value to each proposal from the third plurality of proposals. In some embodiments, instructions generate an alternate plurality of proposals to create counterproposals, wherein creating counter-proposals includes generating the third plurality of proposals based on the defined parameters and the selected proposals. In some embodiments, the counter-proposal engine receives an altered set of defined parameters that are utilized to generate a third plurality of proposals based on the altered set of defined parameters (e.g., an alternative plurality of proposals, or a third plurality of proposals). In some embodiments, the first, second, and third plurality of proposals is normalized and ordered based on a threshold of the assigned value. If the set is within the defined threshold 540, the set of counter-proposals moves to box 541 in which a counter-proposal from the set of counter-proposals is submitted to an auditor for selection and/or implementation. In some embodiments, filtering the set of proposals into a sequence according to a threshold value and submitting a portion of proposals that include a value that is greater than the threshold value can occur. In some embodiments, a proposal from the plurality of proposals in violation of a module constraint is filtered and removed from the plurality of proposals. During one or more of the types of proposal generation, as described herein, a proposal that violates a module's constraints (e.g., limitations, hard constraints, etc.) can be filtered out and/or removed from the system's consideration for selection. In some embodiments, a proposal from at least one of the first, second, and third plurality of proposals in violation of a module constraint is filtered and removed from the respective plurality of proposals. In some embodiments, filtering the set of proposals according to value and submitting a portion of proposals that include a value that is greater than the threshold value can occur.
[0049] The specification examples provide a description of the
applications and use of the system and method of the present disclosure. Since many examples can be made without departing from the spirit and scope of the system and method of the present disclosure, this specification sets forth some of the many possible example configurations and implementations.

Claims

What is claimed:
1 . A system for generating proposals in a network comprising:
a first network controller comprising a proposal engine to:
generate a plurality of proposals that meet a set of defined parameters for a first aspect of the network;
receive a second plurality of proposals generated by a second network controller that meet a set of defined parameters for a second aspect of the network;
evaluate the first and second plurality of proposals and assign a first value to each proposal from the first and second plurality of proposals, wherein the value is based on a feature of a corresponding proposal;
alter the feature of a portion of the first and second plurality of proposals to determine a second value for each proposal within the portion of the first and second plurality of proposals; and
submit a proposal from the portion of the first and second plurality of proposals based on one of the first and second values.
2. The system of claim 1 , further including a counter-proposal engine to:
generate a third plurality of proposals generated by the first network controller, that meet the set of defined parameters for the first aspect of the network; and
assign a third value to each proposal from the third plurality of proposals.
3. The system of claim 2, wherein the proposal engine receives an altered set of defined parameters that are utilized to generate the third plurality of proposals based on the altered set of defined parameters.
4. The system of claim 1 , wherein the proposal engine alters the portion of the first and second plurality of proposals via perturbations.
5. The system of claim 1 , wherein the first, second, and third plurality of proposals is normalized and ordered based on a threshold of the assigned value.
6. The system of claim 1 , wherein a proposal from the at least one of the first, second, and third plurality of proposals in violation of a module constraint is filtered and removed from the respective plurality of proposals.
7. A non-transitory computer-readable medium comprising instructions that when executed by a processor to cause a computing device to:
generate a first plurality of proposals, the first plurality of proposals complying with defined parameters;
assign a first value to each proposal in the first plurality of proposals;
generate a second plurality of proposals by altering the first plurality of proposals via perturbation;
assign a second value to each proposal in the second plurality of proposals; and
submit a proposal from the first and second plurality of proposals based on one of the first and second values.
8. The non-transitory computer-readable medium of claim 7, wherein the instructions cause the computing device to:
identify the proposals from the first and second plurality of proposals;
generate a third plurality of proposals based on the second plurality of proposals; and
order each proposal from the third plurality of proposals based on an assigned value.
9. The non-transitory computer-readable medium of claim 7, wherein the instructions generate a third plurality of proposals to create a compromise, wherein creating a compromise includes generating the third plurality of proposals based on the defined parameters and the selected proposal.
10. The non-transitory computer-readable medium of claim 7, wherein perturbation includes altering at least one feature of the proposal.
1 1 . A method for generating proposals in multi-controller networking, the method comprising:
generating a first plurality of proposals for a first controller, wherein each proposal from the first plurality of proposals assigns resources based on defined parameters;
evaluating each proposal in the first plurality of proposals based on features of the first plurality of proposals;
assigning a value to each proposal in the first plurality of proposals based on the evaluation;
ordering the first plurality of proposals into a sequence according to the assigned values;
receiving a second plurality of proposals from a second controller based on the first plurality of proposals via perturbation;
submitting at the first controller, a proposal from the second plurality of proposals; and
instructing a module associated with the selected proposal to implement a selected proposal.
12. The method of claim 1 1 , wherein the defined parameters include speed, accuracy, and space of each of the first and second plurality of proposals.
13. The method of claim 12, wherein speed includes proposal generation time, accuracy includes valuableness of a request, and space includes storage consumed.
14. The method of claim 1 1 , wherein assigning the value to each proposal includes categorizing each proposal, wherein the categories include a first category that includes proposals with a value that is greater than a
predetermined threshold and a second category that includes proposals with a value that is less than the predetermined threshold.
15. The method of claim 1 1 , including filtering the set of proposals into a sequence according to a threshold value and submitting a portion of proposals that include an assigned value that is greater than the threshold value.
PCT/US2014/012915 2014-01-24 2014-01-24 Proposal generation for a network WO2015112159A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2014/012915 WO2015112159A1 (en) 2014-01-24 2014-01-24 Proposal generation for a network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2014/012915 WO2015112159A1 (en) 2014-01-24 2014-01-24 Proposal generation for a network

Publications (1)

Publication Number Publication Date
WO2015112159A1 true WO2015112159A1 (en) 2015-07-30

Family

ID=53681791

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2014/012915 WO2015112159A1 (en) 2014-01-24 2014-01-24 Proposal generation for a network

Country Status (1)

Country Link
WO (1) WO2015112159A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160150460A1 (en) * 2014-11-26 2016-05-26 Futurewei Technologies Inc. Network abstractor for advanced interactive sdn optimization

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003040947A1 (en) * 2001-11-02 2003-05-15 Netvmg, Inc. Data network controller
US20110317559A1 (en) * 2010-06-25 2011-12-29 Kern Andras Notifying a Controller of a Change to a Packet Forwarding Configuration of a Network Element Over a Communication Channel
WO2013104375A1 (en) * 2012-01-09 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Network device control in a software defined network
US20130237264A1 (en) * 2012-03-12 2013-09-12 Nokia Corporation Method, apparatus, and computer program product for resource allocation conflict handling in rf frequency bands
WO2013173482A1 (en) * 2012-05-18 2013-11-21 Brocade Communications Systems, Inc. Network feedback in software-defined networks

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003040947A1 (en) * 2001-11-02 2003-05-15 Netvmg, Inc. Data network controller
US20110317559A1 (en) * 2010-06-25 2011-12-29 Kern Andras Notifying a Controller of a Change to a Packet Forwarding Configuration of a Network Element Over a Communication Channel
WO2013104375A1 (en) * 2012-01-09 2013-07-18 Telefonaktiebolaget L M Ericsson (Publ) Network device control in a software defined network
US20130237264A1 (en) * 2012-03-12 2013-09-12 Nokia Corporation Method, apparatus, and computer program product for resource allocation conflict handling in rf frequency bands
WO2013173482A1 (en) * 2012-05-18 2013-11-21 Brocade Communications Systems, Inc. Network feedback in software-defined networks

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160150460A1 (en) * 2014-11-26 2016-05-26 Futurewei Technologies Inc. Network abstractor for advanced interactive sdn optimization
US10757630B2 (en) * 2014-11-26 2020-08-25 Huawei Technologies Co., Ltd. Network abstractor for advanced interactive SDN optimization

Similar Documents

Publication Publication Date Title
Yao et al. Haste: Hadoop yarn scheduling based on task-dependency and resource-demand
Webb et al. Blender: Upgrading tenant-based data center networking
Hummaida et al. Adaptation in cloud resource configuration: a survey
US10425293B2 (en) Network resource allocation proposals
Yu et al. Dynamic scaling of virtual clusters with bandwidth guarantee in cloud datacenters
US20140153388A1 (en) Rate limit managers to assign network traffic flows
EP2724301A1 (en) Method and system for reactive scheduling
US10027596B1 (en) Hierarchical mapping of applications, services and resources for enhanced orchestration in converged infrastructure
US20170034063A1 (en) Prioritization of network traffic in a distributed processing system
WO2020134133A1 (en) Resource allocation method, substation, and computer-readable storage medium
US20140223053A1 (en) Access controller, router, access controlling method, and computer program
US20190028407A1 (en) Quality of service compliance of workloads
CN113867930A (en) Method for adjusting machine learning model and system for adjusting machine learning model
Elsharkawey et al. Mlrts: multi-level real-time scheduling algorithm for load balancing in fog computing environment
Mollamotalebi et al. Multi-objective dynamic management of virtual machines in cloud environments
WO2015112159A1 (en) Proposal generation for a network
Jung et al. Ostro: Scalable placement optimization of complex application topologies in large-scale data centers
US10009285B2 (en) Resource allocator
Naik et al. Scheduling tasks on most suitable fault tolerant resource for execution in computational grid
Yang et al. Joint optimization of mapreduce scheduling and network policy in hierarchical clouds
US20160073543A1 (en) Zoneable power regulation
Mahdizadeh et al. Task scheduling and load balancing in SDN-based cloud computing: A review of relevant research
KR102563329B1 (en) Method for Inter-Resource Dependency Scheduling for Containers and Network System for performing the same
US20240378079A1 (en) Predictive resource allocation and scheduling for a distributed workload
Xiong et al. Towards a scalable and adaptable resource allocation framework in cloud environments

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14880341

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14880341

Country of ref document: EP

Kind code of ref document: A1