Abstract:
One embodiment of the present invention provides a network device that facilitates configuration orchestration. During operation, the system interprets a configuration command and stores a data structure representing a set of business logic. The business logic can be triggered by the configuration command, a local condition, or both. Furthermore, the system configures the switch according to an outcome of the business logic.

Description:
RELATED APPLICATIONS 
       [0001]    This application claims the benefit of U.S. Provisional Application No. 61/364,941, Attorney Docket Number BRCD-3050.0.1.US.PSP, entitled “CONFIGURATION ORCHESTRATION INFRASTRUCTURE,” by inventors Shiv Haris and Suresh Vobbilisetty, filed 16 Jul. 2010, the disclosure of which is incorporated by reference herein. 
         [0002]    The present disclosure is related to U.S. patent application Ser. No. 13/042,259, (attorney docket number BRCD-3012.1.US.NP), entitled “PORT PROFILE MANAGEMENT FOR VIRTUAL CLUSTER SWITCHING,” by inventors Dilip Chatwani, Suresh Vobbilisetty, and Phanidhar Koganti, filed 7 Mar. 2010, the disclosure of which is incorporated by reference herein. 
     
    
     BACKGROUND 
       [0003]    1. Field 
         [0004]    The present disclosure relates to network design. More specifically, the present disclosure relates to a method and system for managing configuration of devices in a network. 
         [0005]    2. Related Art 
         [0006]    The relentless growth of the Internet has brought with it an insatiable demand for bandwidth. As a result, equipment vendors race to build larger, faster, and more versatile switches to move traffic. However, the size of a switch cannot grow infinitely. It is limited by physical space, power consumption, and design complexity, to name a few factors. More importantly, because an overly large system often does not provide economy of scale due to its complexity, simply increasing the size and throughput of a switch may prove economically unviable due to the increased per-port cost. 
         [0007]    One way to increase the throughput of a switch system is to use switch stacking. In switch stacking, multiple smaller-scale, identical switches are interconnected in a special pattern to form a larger logical switch. However, switch stacking requires careful configuration of the ports and inter-switch links. The amount of required manual configuration becomes prohibitively complex and tedious when the stack reaches a certain size, which precludes switch stacking from being a practical option in building a large-scale switching system. Furthermore, a system based on stacked switches often has topology limitations which restrict the scalability of the system due to fabric bandwidth considerations. 
         [0008]    In addition, modern-day datacenters often include heterogeneous servers, switches, and storage devices manufactured by different vendors. Configuration changes on one of these devices usually result in configuration changes at other devices. It is conceivable that a change at a device may create a cascade of changes across a number of datacenter devices. Furthermore, the evolution of virtual computing has placed additional requirements on the network. For example, as the locations of virtual servers become more mobile and dynamic, it is often desirable that the network configuration can respond to these changes in a timely fashion. However, at present, there are no readily applicable solutions that can achieve this goal without using proprietary communication protocols. 
       SUMMARY 
       [0009]    One embodiment of the present invention provides a network device that facilitates configuration orchestration. During operation, the system interprets a configuration command and initiates a set of business logic. The business logic can be triggered by the configuration command, a local condition, or both. Furthermore, the system configures the switch according to an outcome of the business logic. 
         [0010]    In a variation on this embodiment, the configuration command is encapsulated in a Web service message. 
         [0011]    In a variation on this embodiment, while interpreting the configuration command, the system interprets a Web Service Description Language message. 
         [0012]    In a variation on this embodiment, the business logic specifies one or more of: a local configuration operation, a condition for performing a local configuration, a query to a virtual machine managing system, and a command to a data center. 
         [0013]    In a further variation, the business logic is written in script language based on PHP, Python, Perl, or Java. 
         [0014]    In a variation on this embodiment, the system triggers the business logic in response to detecting a local connectivity change. 
         [0015]    In a variation on this embodiment, the system interprets a user command to modify the business logic. 
         [0016]    In a variation on this embodiment, business logic comprises a function for auditing configuration information associated with the switch or a remote device. 
     
    
     
       BRIEF DESCRIPTION OF THE FIGURES 
         [0017]      FIG. 1  illustrates an exemplary fabric system that facilitates configuration orchestration, in accordance with an embodiment of the present invention. 
           [0018]      FIG. 2  illustrates a logical VCS access layer (VAL) which includes an automatic port profile manager, in accordance with one embodiment of the present invention. 
           [0019]      FIG. 3  illustrates an example of the operation of automatic migration of port profiles (AMPP), in accordance with one embodiment of the present invention 
           [0020]      FIG. 4A  illustrates exemplary port profile contents, in accordance with one embodiment of the present invention. 
           [0021]      FIG. 4B  illustrates three exemplary port profiles, in accordance with on embodiment of the present invention. 
           [0022]      FIG. 5  presents a flowchart illustrating the process of creating and applying a port profile, in accordance with one embodiment of the present invention. 
           [0023]      FIG. 6  illustrates an exemplary architecture of a switch that facilitates configuration orchestration, in accordance with one embodiment of the present invention. 
           [0024]      FIG. 7  illustrates an exemplary configuration of a data center that facilitates configuration orchestration, in accordance with one embodiment of the present invention. 
           [0025]      FIG. 8  illustrates an exemplary implementation of a switch that facilitates configuration orchestration based on a Web Service Definition Language (WSDL) interface, in accordance with one embodiment of the present invention. 
           [0026]      FIG. 9  presents a flowchart illustrating the process of implementing a port profile based on business logic, in accordance with one embodiment of the present invention. 
           [0027]      FIG. 10  presents a flowchart illustrating the process of moving a virtual machine with configuration orchestration, in accordance with one embodiment of the present invention. 
           [0028]      FIG. 11  illustrates an exemplary VCS member switch that facilitates configuration orchestration, in accordance with one embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION 
       [0029]    The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the embodiments shown, but is to be accorded the widest scope consistent with the claims. 
       Overview 
       [0030]    In embodiments of the present invention, the problem of coordinating configuration of a number of network devices in a datacenter is solved by facilitating an open management interface and a set of business logic on a respective device. The open management interface allows a device to query configuration states on other devices, as well as initiate local or remote configuration changes. In addition, the business logic stored on a respective device allows configuration changes to take place in an intelligent and coordinated fashion, thereby allowing coherent interoperation among various network devices. In general, the business logic stored in multiple devices collectively forms the overall intelligence of the datacenter or a subset thereof (or any general network). 
         [0031]    In addition, the business logic within a network device may also be used to audit the configuration of the network device. Auditing does not change the configuration, but involves querying and verifying the configuration. Auditing may also involve querying another device and/or database. 
         [0032]    The audit business logic can also reside on an entity that is separate from the network devices. This separate entity can trigger audits on the network devices and gather resulting audit information. This audit information collected from multiple can then be analyzed to audit and verify the configuration of the datacenter or a subset thereof. 
         [0033]    In some embodiments, the open management interface is a Web service interface. This open interface, which is provided on a number of participating devices, forms a logical “bus,” meaning that any device can communicate with any other device on a common communication channel, via Web service. This logical bus also allows seamless communication with virtual machine management systems (such as the vCenter by VMware) as well as other devices. Within each device, the business logic can implement complex configuration intelligence and trigger additional configuration changes (in both the local device and a remote device) in response to a received command. In the following description, such inter-related configuration maneuvers across multiple devices are referred to as “configuration orchestration.” 
         [0034]    In this disclosure, a number of examples are provided in the context of a fabric switching system, which is a logical switch formed by a number of individual, physical switches (referred to as “fabric switch,” “virtual cluster switch,” or VCS). However, the general concept of configuration orchestration disclosed herein is not limited to a particular type of switching system. The same idea can be implemented in a stand-alone switch, an end host, a virtual machine, a datacenter management system, or a virtual machine management system. In fact, the general configuration-orchestration mechanism can be implemented on any datacenter device (or any networked device in general). 
         [0035]    In this disclosure, the term “orchestrator” refers to a device that triggers a command on another device based on a set of business logic local to itself. An “orchestrated” device refers to a device that intelligently changes its local configuration state based on its local business logic in response to a command received from another device. Note that “orchestrator” and “the orchestrated” are both relative terms. A device can be both an orchestrator and orchestrated. 
         [0036]    Since the orchestrator and the orchestration functions can be in any device, a command triggered at one device can result in further initiation of new set of commands at other devices. Each network device based on its business logic will query configuration information from its surrounding network devices, modify its own configuration and trigger commands further to other network devices. This process will stop at some point and the resulting configuration will be the new configuration of the datacenter or a subset thereof. 
         [0037]    It is possible that due to some unforeseeable situation the configuration may not exactly be what is desired—a provisioning of audit capability could also be built using this orchestration infrastructure. This audit mechanism is in addition to the mechanism for configuration management described above. 
         [0038]    The terms “virtual cluster switch,” “virtual cluster switching,” and “VCS” refer to a group of interconnected physical switches operating as a single logical switch. The control plane for these physical switches provides the ability to automatically configure a given physical switch, so that when it joins the VCS, little or no manual configuration is required. 
         [0039]    The terms “frame” or “packet” refer to a group of bits that can be transported together across a network. “Frame” should not be interpreted as limiting embodiments of the present invention to layer-2 networks. “Packet” should not be interpreted as limiting embodiments of the present invention to layer-3 networks. “Frame” or “packet” can be replaced by other terminologies referring to a group of bits, such as “cell” or “datagram.” 
       Fabric Switch Architecture 
       [0040]      FIG. 1  illustrates an exemplary fabric switch system which facilitates configuration orchestration, in accordance with an embodiment of the present invention. In this example, a fabric switch system  100  includes physical switches  101 ,  102 ,  103 ,  104 ,  105 ,  106 , and  107 . A given physical switch runs an Ethernet-based transport protocol on its ports (e.g., TRILL on its inter-switch ports, and Ethernet transport on its external ports), while its control plane can run on a different protocol stack, such an FC switch fabric protocol stack. The transport protocol facilitates transport of Ethernet frames within and across VCS  100  in a routed fashion. The control-plane protocol stack facilitates the automatic configuration of individual physical switches, in a way similar to how a conventional FC switch fabric is formed and automatically configured. In one embodiment, fabric switch system  100  can appear externally as an ultra-high-capacity Ethernet switch. More details on FC network architecture, protocols, naming/address conventions, and various standards are available in the documentation available from the NCITS/ANSI T11 committee (www.t11.org) and publicly available literature, such as “Designing Storage Area Networks,” by Tom Clark, 2nd Ed., Addison Wesley, 2003, the disclosures of which are incorporated by reference in their entirety herein. 
         [0041]    A physical switch may dedicate a number of ports for external use (i.e., to be coupled to end hosts or other switches external to the fabric switch system) and other ports for inter-switch connection. Viewed externally, fabric switch system  100  appears to be one switch to a device from the outside, and any port from any of the physical switches is considered one port on the fabric switch. For example, port groups  110  and  112  are both external ports and can be treated equally as if they were ports on a common physical switch, although switches  105  and  107  may reside in two different locations. 
         [0042]    The physical switches can reside at a common location, such as a data center or central office, or be distributed in different locations. Hence, it is possible to construct a large-scale centralized switching system using many smaller, inexpensive switches housed in one or more chassis at the same location. It is also possible to have the physical switches placed at different locations, thus creating a logical switch that can be accessed from multiple locations. The topology used to interconnect the physical switches can also be versatile. Fabric switch system  100  is based on a mesh topology. In further embodiments, a fabric switch can be based on a ring, fat tree, or other types of topologies. 
         [0043]    In one embodiment, the protocol architecture of a fabric switch is based on elements from the standard IEEE 802.1Q Ethernet bridge, which is emulated over a transport based on the Fibre Channel Framing and Signaling-2 (FC-FS-2) standard. The resulting switch is capable of transparently switching frames from an ingress Ethernet port from one of the edge switches to an egress Ethernet port on a different edge switch through the fabric switch. 
         [0044]    In one embodiment, each member switch provides a Web service-based interface that facilitates communication of network management information with any other devices in the datacenter or coupled to the fabric switch. Via this interface, a device can query the configuration state of another device, initiate a local configuration change, or initiate a remote configuration change. 
         [0045]    Because of its automatic configuration capability, a fabric switch can be dynamically expanded as the network demand increases. In addition, one can build a large-scale switch using many smaller physical switches without the burden of manual configuration. For example, it is possible to build a high-throughput fully non-blocking switch using a number of smaller switches. This ability to use small switches to build a large non-blocking switch significantly reduces the cost associated switch complexity. 
       Automatic Port Profile Management 
       [0046]    Today&#39;s server virtualization infrastructure (e.g. a Hypervisor, also called virtual machine monitor) associates a server side (e.g. Hypervisor or adapter) Virtual Ethernet Bridge (VEB) port profile to each Ethernet MAC address used by a virtual machine (VM) to access the network through a VEB port. Examples of the VEB&#39;s port profile attributes includes: the types of frames allowed on the port (e.g. all frames, only frames tagged with certain VLAN values, or untagged frames), the VLAN identifiers that are allowed to be used, and rate limiting attributes (e.g. port or access-control based rate limits). In today&#39;s server virtualization infrastructure, if the VM migrates from one physical server to another, the VEB&#39;s port profile migrates with it. In other words, today&#39;s server virtualization infrastructure provides automated port profile migration of the server&#39;s VEB port(s) that are associated with a VM. 
         [0047]    However, in existing technologies, there remains a gap between the access and Quality of Service (QoS) controls supported in external layer 2 switches and server virtualization infrastructure. That is, external layer 2 switches have more advanced controls compared to server VEB implementations. Although server virtualization infrastructure is continually adding these controls, this gap is expected to remain. Some environments prefer the more advanced controls provided by external network switches. An example of such an environment is a multi-tier data center that has several types of applications, each with differing advanced network controls, running over the same layer-2 network. In this type of environment the network administrator often prefers the use of advanced access controls available in external switches. 
         [0048]    Today&#39;s layer-2 networks do not provide a mechanism for automatically migrating switch access and traffic controls associated with an end-point device (e.g., a VM), when that device migrates from one switch to another. The migration may be physical, such as an Operating System image (application, middleware, Operating System and associated state) that is running on one physical system and is migrated to another system. The migration may be also be virtual, such as an Operating System image (OS image) that is running over a Hypervisor on one system and is migrated to run over a Hypervisor on another system. 
         [0049]    Embodiments of the present invention provides a mechanism for automatically migrating port profiles resident in a switch and associated with an OS image to a port on a second switch, when that OS image migrates from one physical end-host system to another end-host system, which is attached to the second switch. 
         [0050]      FIG. 2  illustrates a logical VCS access layer (VAL) which includes an automatic port profile manager, in accordance with one embodiment of the present invention. In this example, a fabric switch (VCS)  200  is coupled with a number of physical server systems, such as system  202 . Each physical server system runs a number of VMs. For example, system  202  includes four VMs, one of which is VM  204 . A VM may be dedicated to a certain application (e.g., instant messaging services, directory services, data base applications, etc.) and may have its own requirement on the network. A VM running mission-critical applications may require a separate VLAN within VCS  200  and may have more strict QoS requirement (such as guaranteed port bandwidth, low latency, and guaranteed packet delivery). A VM running non-critical applications may have much lower requirements. 
         [0051]    The switches within VCS  200  which are coupled externally to the physical end-host systems form a logical VCS access layer (VAL)  210 . The automatic migration of port profiles (AMPP) is implemented in VAL  210 . During operation, various port profiles, which are often tailored to different requirements of the VMs, are created and distributed to all the member switches in VCS  200 . As described in detail below, when the packets generated by a VM are detected by an ingress member switch of VCS  200 , the VM&#39;s source MAC address is recognized and used to identify the corresponding port profile, which is then applied to the appropriate ingress switch port. When a VM moves from one physical server to another, the MAC-address detection mechanism can quickly identify the new physical switch port to which the VM is coupled to, and apply the same port profile to the new port. 
         [0052]      FIG. 3  illustrates an example of the operation of advanced management of port profile (AMPP), in accordance with one embodiment of the present invention. In this example, a fabric switch (VCS)  300  includes two switches  320  and  322 , which are coupled to two physical servers,  316  and  318 , respectively. Physical server  316  hosts four VMs,  302 ,  304 ,  306 , and  308 . Each VM has a virtual port (VP, or virtual network interface card, VNIC). For example, VM  302  has a VP  310 . A respective VP is assigned a virtual MAC address. The four VPs are logically coupled to a virtual switch  312  which is provided by a hypervisor  314 . Virtual switch  312  is responsible for dispatching outgoing and incoming traffic through a physical NIC  317 . Note that an Ethernet frame generated by a respective VM has the virtual MAC of the corresponding VP as its source address. Logically, virtual switch  312  functions as an aggregation point that provides a link to the ingress member switch in VCS  300 . Physical server  318  has a similar architecture. During operation, a VM can migrate from one physical server to another (e.g., “VMotion” function provided by VMware). This migration can be event-driven or pre-scheduled. Such migration is often used to cope with changing dynamics in a number of parameters, such as server load, power consumption, resource utilization, etc. 
         [0053]    During operation, one or more port profiles can be created to specify a number of requirements/restrictions/limitations that should be enforced at a VCS switch port corresponding to one or more VMs. For example, a port profile for VM  302  (which can be identified by the virtual MAC address of VP  310 ) can be created and distributed to every member switch of VCS  300 . When VM  302  sends its first Ethernet frame to the network, switch  320  would learn this source MAC address. Upon learning VP  310 &#39;s MAC address, switch  320  then searches its port profile database and identifies the matching port profile. Subsequently, the identified port profile is applied to the port on switch  320  which is coupled to system  316 . In addition, the same port profile is applied to the port where the matching MAC address is the destination MAC address of a frame. This way, the same network parameters are enforced at both ingress and egress ports of the VCS. Note that the port profile might include “soft” parameters. In other words, the requirements and limitations in the port profile may be specific to certain MAC addresses, and may not be “hard” limitations on the physical parameters of the switch port, since traffic from/to multiple VMs is handled by the same physical switch port. 
         [0054]    In one embodiment, VCS  300  provides a mechanism that distributes all the port profiles and the port-profile-to-MAC mapping information to all the member switches. The port profiles can be created using a command line interface (CLI) or other network management software. In addition, upon migration of a VM (such as a VMware VMotion), the target switch port in the VCS can automatically activate the correct port profile configuration. 
         [0055]      FIG. 4A  illustrates exemplary port profile contents, in accordance with one embodiment of the present invention. As shown in  FIG. 4A , a port profile can contain the entire configuration needed for a VM to gain access to a LAN or WAN, which can include: Fibre Channel over Ethernet (FCoE) configuration, VLAN configuration, QoS related configuration, and security related configuration (such as access control lists, ACLs). The list above is by no means complete or exhaustive. Furthermore, it is not necessary that a port profile contains every type of configuration information. 
         [0056]    In one embodiment, a port profile can be capable of operating as a self contained configuration container. In other words, if a port profile is applied to a new switch without any additional configuration, the port profile should be sufficient to set the switch&#39;s global and local (interface level) configuration and allow the switch to start carrying traffic. 
         [0057]    A VLAN configuration profile within a port profile can define:
       a VLAN membership which includes tagged VLANs and an untagged VLAN; and   ingress/egress VLAN filtering rules based on the VLAN membership.       
 
         [0060]    A QoS configuration profile within a port profile can define:
       mapping from an incoming frame&#39;s 802.1p priority to internal queue priority; (if the port is in QoS untrusted mode, all incoming frame&#39;s priorities would be mapped to the default best-effort priority)   mapping from an incoming frame&#39;s priority to outgoing priority;   scheduling profile, such as weighted Round-Robin or strict-priority based queuing;   mapping of an incoming frame&#39;s priority to strict-priority based or weighted Round-Robin traffic classes;   flow control mechanisms on a strict-priority based or weight Round-Robin traffic class; and   limitations on multicast data rate.       
 
         [0067]    An FCoE configuration profile within a port profile defines the attributes needed for the port to support FCoE, which can include:
       FCoE VLAN;   FCMAP;   FCoE Priority; and   virtual Fabric ID.       
 
         [0072]    A security configuration profile within a port profile defines the security rules needed for the server port. However, the security rules can be different at different ports, so some of the locally configured ACLs can be allowed to override conflicting rules from a port profile. A typical security profile can contain the following attributes:
       Enable 802.1x with EAP TLV extensions for VM mobility; and   MAC based standard and extended ACLs.       
 
         [0075]    In one embodiment, each port profile can have one or more MAC addresses associated with it.  FIG. 4B  illustrates three exemplary port profiles, in accordance with on embodiment of the present invention. In this example, port profile PP-1 is associated with 5 MAC addresses. These MAC address can be virtual MAC addresses assigned to different VMs. The port-profile-to-MAC mapping information is distributed throughout the VCS. A port profile can be activated on a server port in three ways: (1) when a hypervisor binds a MAC address to a port profile ID; (2) through regular MAC learning; and (3) through a manual configuration process via a management interface. 
         [0076]      FIG. 5  presents a flowchart illustrating the process of creating and applying a port profile, in accordance with one embodiment of the present invention. During operation, the system receives a user created port profile with the corresponding VM&#39;s MAC address (operation  502 ). This MAC address is then associated with the port profile and can be later used to identify the profile. The system then determines whether the new profile creates dependencies on other existing profiles or conflicts (operation  504 ). If so, the system allows the user to resolve the conflicting configuration and/or dependencies (operation  506 ). 
         [0077]    Subsequently, the system distributes the port profile and the corresponding VM MAC address to every member switch throughout the VCS fabric (operation  508 ). When a VM is initiated or migrated, the system then detects a matching virtual MAC address from the received ingress packets (operation  510 ). Based on the learned MAC address, the system then activates the corresponding port profile on the switch port (operation  512 ). 
       Configuration Orchestration 
       [0078]    In embodiments of the present invention, a network device (such as a VCS member switch, or a stand-alone switch) implements a Web service interface. This Web service interface provides a communication channel to other network devices to exchange configuration and management information. The network device also implements a set of business logic, which, when triggered by either a command received via the Web service interface or a local trigger, determines the necessary configuration-related operations to be performed. The distributed business logic in each device collectively provides the intelligence in the network configuration. Such collaborations among multiple switches, hosts, and VMs ensure coherent updates to the network&#39;s configuration state. This configuration-orchestration mechanism is particularly useful in a datacenter environment, where virtual machines are often relocated. 
         [0079]    Configuration orchestrations in a datacenter are usually due to changes in the environment within the datacenter. These changes act as triggers for initiating the business logic. Some common examples of triggers of orchestrations are: administrator initiated configuration changes, a virtual machine&#39;s movement in the datacenter, a switch or server coming online/offline, installation of new switches or servers, and loss of availability of devices due to malfunction. Typically, changes of virtual machines, e.g., location and QoS parameter changes, can lead to configuration changes at the physical switches (such as the advanced port profile management described above). 
         [0080]    The business logic can also be used to audit the configuration of the local device or a remote device. Note that auditing typically does not change the configuration of a device. A typical audit involves querying and verifying a device&#39;s configuration information. In one embodiment, the business logical associated with audit operations can be stored in a separate entity from the regular network devices. This entity can trigger configuration auditing on one or more devices. The collected audit information can then analyzed and used to verify the configuration state of the datacenter. 
         [0081]    In general, configuration orchestration provides a dynamic network management infrastructure that facilitates distributed and automatic configuration updates throughout a datacenter. Because each device maintains its own set of business logic, a configuration change in one device may trigger a series of cascaded changes in a number of devices throughout the network. As a result, the necessary changes are automatically propagated and implemented (if allowed) by all devices that are affected. In a conventional network, this is typically a tedious and error-prone manual process. However, with configuration orchestration, such configuration becomes much less laborious and much faster. One example of such cascaded automatic configuration is the re-location of a VM, as described in conjunction with  FIG. 10 . 
         [0082]    With virtualization the older paradigm of static connection of a server to a switch port is no longer valid. Virtualization of servers in today&#39;s datacenter creates a new network access layer closer to the server. This new access layer imposes new requirements due to mobility of VMs within the datacenter. Furthermore, this new network access layer remains invisible to the access layer provided at the physical layer and is also invisible to the network administrator. For example, a physical switch needs to be able setup its access layer policies similar to that of the VM&#39;s profile. There can be multiple such profiles, one per VM, which the switch needs to be aware of at each of its interfaces. Additionally, due to the VM mobility, the profile information that is applied at the physical switch access layer needs to move with the new VM&#39;s location. 
         [0083]    One embodiment of the present invention uses the Web Service Description Language (WSDL) and Simple Object Access Protocol (SOAP) as a mechanism to discover this new access layer, its profiles and policies as provisioned by the server administrator and further using it for synchronizing VM motion. More details about WSDL and SOAP can be found at: http://www.w3.org/2002/ws/desc/ which is incorporated in its entirety herein. In a network where each device provides this WSDL/SOAP interface for communicating management information with each other, this common communication channel functions as a logical “bus,” meaning that any device can communicate with any device via this channel. In one embodiment, this WSDL interface is referred to as a “WSDL bus.” 
         [0084]    Because WSDL is a protocol based on open standards, the WSDL bus is vendor-neutral. This feature allows devices from different vendors to exchange configuration information and, in certain cases, configure one another. Furthermore, since many virtual machine products today use WSDL as the communication protocol between a VM and a VM managing center, the WSDL bus facilitates a seamless mechanism for exchanging configuration information between the VMs and the switch(es). 
         [0085]      FIG. 6  illustrates an exemplary architecture of a switch that facilitates configuration orchestration, in accordance with one embodiment of the present invention. In this example, a switch  600  includes a switch configuration and control module  606 , a WSDL interface  604 , and a business logic module  602 . WSDL interface  604 , together with similar WSDL interfaces on other devices, form a WSDL bus  608 . In one embodiment, WSDL interface  604  provides a communication channel between switch  600  and the datacenter. 
         [0086]    Switch configuration and control module  606  is responsible for effectuating configuration changes to switch  600 . Both switch configuration and control module  606  and WSDL interface  604  are coupled to business logic module  602 , which maintains a set of business logic that describes the inter-dependencies of configuration state changes. For example, if another device in the network wishes to change the configuration of switch  600 , this other device can send a configuration command as a Web service request via WSDL interface  604 . The command is then parsed and checked against the business logic stored in module  602  to determine whether the command can be executed locally or whether additional conditions have to be met (for example, this command might trigger configuration changes in other switches). When the command is cleared for execution, switch configuration and control module  606  effectuates the changes.
       The example above is only one instance of configuration orchestration (where switch  600  is orchestrated). In general, configuration orchestration can include the following elements:
           executing the business logic,   
           controlling configuration of the local switch from the business logic,   querying configuration information of other devices in the datacenter or network in general,   providing local switch&#39;s configuration information to trusted devices in the datacenter or network,   allowing triggers to initiate certain business logic,   sending triggers to other devices in the datacenter (including the local switch itself),   authenticating another device before accepting orchestration requests, and   allowing a user to compose business logic.       
 
         [0096]    In general, a variety of communication protocols besides WSDL can be used to facilitate the aforementioned logical orchestration. WSDL is one of the preferred protocol because it is already used by a number of vendors of virtualization products and can provide security features. For example, WSDL provides authentication features which can be used to authenticate a remote device. In addition, the messages transmitted over the WSDL bus can be encrypted by, for example, a security socket layer (SSL). 
         [0097]      FIG. 7  illustrates an exemplary configuration of a data center that facilitates configuration orchestration, in accordance with one embodiment of the present invention. In this example, a WSDL bus  712  couples a virtual machine management system  708 , a datacenter management system  710 , and a switch  702 . In other words, each of these devices includes a WSDL interface and a set of internal business logic. Switch  702  is coupled to a physical host  703 , which includes virtual machines  704 ,  706 ,  708 , and  710 . Note that for clarity purposes,  FIG. 7  only shows the logical control plane and does not show the topology of the data plane. In the data plane, switch  702 , VM management system  708 , and datacenter management system  710  can be connected via a physical network. 
         [0098]    During operation, the movement of VMs is controlled by VM management system  708 . For example, when a server administrator intends to move VM  706  to a different location, he can log into VM management system  708  and issues a motion request. The business logic in VM management system  708  goes through a sequence of checks to determine whether VM  706  is allowed to be moved. One of these checks might be a query to switch  702  about whether the port profile corresponding to VM  706  is allowed to move to another switch. In response, switch  702  answers to VM management system  708  about the allowability of the port profile motion. Subsequently, both VM  706  and its corresponding port profile are moved. 
         [0099]      FIG. 8  illustrates an exemplary implementation of a switch that facilitates configuration orchestration based on a Web Service Definition Language (WSDL) interface, in accordance with one embodiment of the present invention. In this example, a switch  800  includes a number of ports  803 , a discovery module  812 , a switch configuration and control module  814 , and a business logic module  802 . Also included are a web server  804 , a PHP script module  806 , and PHP WSDL parser and SOAP message generator  808 , a PHP application interface (API)  810 , and a PHP module  811   
         [0100]    Discovery module  812  monitors the connectivity state of ports  803  and interfaces with switch configuration and control module  806 . When certain conditions are met, the information provided by discovery module  812  might trigger some configuration operation based on the business logic. In other words, a change in the local connectivity state (such as a new VM being coupled to one of ports  803 ) may trigger the execution of the business logic. 
         [0101]    Web server  804  and PHP extension  806  jointly provide the WSDL interface. PHP parser and SOAP message generator  808  is responsible for parsing the PHP script received via the WSDL interface and generating SOAP messages to be delivered to the WSDL interface on a remote device. PHP API  810  provides the API to business local module  802  as well as to the VM management system in the network. PHP module  811  in turn provides an interface with switch configuration and control module  814 , which allows the PHP script-based commands to be effectuated on the local hardware. 
         [0102]    In one embodiment, the business logic stored in module  802  is written in the PHP script language. Other scripting languages, such as Python, Perl, or Java, can also be used. In addition, switch  800  provides a user interface that allows a user to author or modify the business logic using PHP scripts. 
         [0103]      FIG. 9  presents a flowchart illustrating the process of implementing a port profile based on business logic, in accordance with one embodiment of the present invention. During operation, the system discovers a new virtual machine has been coupled to the switch (operation  902 ). Subsequently, the discovered new VM connectivity triggers the local business logic, which can be implemented as a PHP script (operation  904 ). As part of the result of this execution, the system then queries the VM management system to obtain a set of configuration parameters for the newly coupled VM (operation  906 ). Note that such parameters may include VLAN configuration information, QoS parameters, and other information associated with a port profile. Next, the system implements the corresponding port profile on the port coupling to the VM (operation  908 ). 
         [0104]      FIG. 10  presents a flowchart illustrating the process of moving a virtual machine with configuration orchestration, in accordance with one embodiment of the present invention. During operation, a VM motion is initiated by a server administrator (operation  1002 ). Subsequently, the business logic at the VM management system performs checks to determine whether the motion is permitted (operation  1004 ). Assuming that the motion is permitted, the VM management system then queries the corresponding switch, via the WSDL bus, whether the port-profile motion is also possible between two physical switches (operation  1006 ). If the port-profile motion is possible, the VM motion proceeds to take place (operation  1008 ). 
       Exemplary VCS Member Switch Facilitating Configuration Orchestration 
       [0105]      FIG. 11  illustrates an exemplary VCS member switch that facilitates configuration orchestration, in accordance with one embodiment of the present invention. In this example, the VCS member switch is a TRILL RBridge  1100  running special VCS software. RBridge  1100  includes a number of Ethernet communication ports  1101 , which can transmit and receive Ethernet frames and/or TRILL encapsulated frames. Also included in RBridge  1100  is a packet processor  1102 , a virtual FC switch management module  1104 , a logical FC switch  1105 , a WSDL interface  1106  and a set of business logic  1107 . 
         [0106]    During operation, packet processor  1102  extracts the source and destination MAC addresses of incoming frames, and attaches proper Ethernet or TRILL headers to outgoing frames. Virtual FC switch management module  1004  maintains the state of logical FC switch  1005 , which is used to join other VCS switches using the FC switch fabric protocols. In addition, when packet processor  1102  identifies WSDL messages, such messages are forwarded to WSDL interface  1106 . The configuration orchestration commands are then processed based on business logic  1107  to ensure that the desired configuration changes are properly made. 
         [0107]    Note that although the configuration orchestration are described using VCS switches as examples, embodiments of the present invention, including the WSDL interface and business logic, can be implemented in any entity in a network. Such entities include datacenter management systems, VM management systems, individual hosts, storage devices, etc. 
         [0108]    The methods and processes described herein can be embodied as code and/or data, which can be stored in a computer-readable non-transitory storage medium. When a computer system reads and executes the code and/or data stored on the computer-readable non-transitory storage medium, the computer system performs the methods and processes embodied as data structures and code and stored within the medium. 
         [0109]    The methods and processes described herein can be executed by and/or included in hardware modules or apparatus. These modules or apparatus may include, but are not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a dedicated or shared processor that executes a particular software module or a piece of code at a particular time, and/or other programmable-logic devices now known or later developed. When the hardware modules or apparatus are activated, they perform the methods and processes included within them. 
         [0110]    The foregoing descriptions of embodiments of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit this disclosure. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. The scope of the present invention is defined by the appended claims.