HK1183178A - Method and system for providing network capability over converged interconnect fabric - Google Patents

Description

Providing network capabilities over converged interconnect architectures

Background

Various implementations of interconnect technology (e.g., optical/electrical interconnect technology) provide interfaces that enable data communication between computers and peripheral devices. Interconnection technology may also enable communication of data between computing devices (i.e., nodes) via cables/connectors. For example, optical data communications are generally any form of telecommunications that utilizes light as a transmission medium. In general, light requires less energy than copper cables and generates less heat than electrical telecommunications.

Thunderbolt^TM(also known as Light Peak)^TM) AndSM10000^TMrepresents a type of connection-oriented and/or bus protocol independent converged interconnect fabric (converged interconnect fabric) technology that may use electrical or optical cables.Thunderbolt^TMIs an interoperability standard that can give bandwidth exceeding Universal Serial Bus (USB) and serial ATA and replace a large number of connector types (e.g., USB, FireWire, DVI, HDMI, DisplayPort) with a single connector.Thunderbolt^TMChip interconnects two or more computing devices/peripherals and sends and receives for PCI Express^TM(PCIe) and DisplayPort^TMInformation of the protocol.Thunderbolt^TMThe chip switches between the two protocols to support communication over a single cable or fiber optic cable. Because such asThunderbolt^TMSome of the interconnection technologies of (a) have not been accepted by a significant number of USB-dependent computer/peripheral manufacturers or application software developers that rely on existing networking standards, and thus the average consumer may have to wait several years before utilizing such technologies.

Disclosure of Invention

This summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.

Briefly, various aspects of the subject matter described herein relate to enabling a local area network over a converged interconnect fabric by emulating a data network interface interoperable with the converged interconnect fabric. In one aspect, the fused interconnect architecture includes a plurality of optical interconnects and/or a plurality of electrical interconnects using nanostructured reflectors. The data network interface may include a software implementation that controls a networking standard that conforms to a networking hardware component (such as a switch) of the converged interconnect fabric. The network hardware components may also include an interconnection controller and bus protocol devices. In one aspect, a data network interface may provide address resolution data associated with a destination for application data within a converged interconnect fabric. The data network interface routes the application data to the destination based on the address resolution data using the interconnection controller.

In another aspect, a software implementation of a networking standard may include a kernel mode component and a user mode component that cooperate to provide an intermediate driver implementing a data communication protocol to a local miniport driver associated with a networking hardware component. In another aspect, the intermediate driver also provides a miniport to an overlapping protocol driver in the protocol stack. For example, the overlay Protocol driver may attempt to request host configuration data using a Dynamic Host Configuration Protocol (DHCP) message. The intermediate driver redirects the message to a root node within the converged interconnect fabric, which replies with a network address associated with the data network interface.

In one aspect, a kernel mode component can intercept a request for address resolution data associated with a destination, which a user mode component redirects to a root node via an interconnection controller. In one aspect, a coordinator (or coordinator) running on the root node responds with a mapping between a physical address and a network address associated with a data network interface of the destination. The kernel mode component may store communication paths and destination physical addresses represented as destinations to one or more topology identifiers. The kernel mode component may instruct the interconnect controller to transfer the application data to a destination via a communication path (e.g., an optical or electrical communication path) along the converged interconnect fabric.

Other advantages will be apparent from the following detailed description when taken in conjunction with the accompanying drawings.

Drawings

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements, and in which:

fig. 1 is a block diagram illustrating an example architecture of a communication network according to an example embodiment.

FIG. 2 is a block diagram illustrating an example system for simulating a data network interface such that interoperability with interconnected controllers is achieved, according to one example embodiment.

Fig. 3 is a block diagram illustrating an example protocol stack interoperable with a communication network according to an example embodiment.

Fig. 4 is a block diagram illustrating an exemplary configuration of a network on a converged interconnect architecture between data network interfaces according to an example embodiment.

Fig. 5 is a flowchart illustrating example steps for providing a local area network on a converged interconnect fabric according to an example embodiment.

FIG. 6 is a flowchart illustrating example steps for simulating a data network interface according to a networking standard, according to an example embodiment.

FIG. 7 is a block diagram representing non-limiting exemplary networked environments in which various embodiments described herein can be implemented.

FIG. 8 is a block diagram representing a non-limiting example computing system or operating environment in which one or more aspects of various embodiments described herein can be implemented.

Detailed Description

Various aspects of the technology described herein relate generally to providing a communication network according to a networking standard. In an example embodiment, the communication network may be a local area (Ethernet) network on a converged interconnect fabric. The local networking standard for the local area network may be the same networking standard associated with the converged interconnect architecture, or may be a completely different networking standard. Each node of the communication network may include one or more emulated data network interfaces interoperable with an interconnection controller for communicating application data, conforming to a local networking standard, through a converged interconnection fabric. An example emulated data network interface may provide ethernet network capabilities over non-ethernet networking components (e.g., optical interconnects).

In one example embodiment, each emulated data network interface may include one or more networking hardware components, such as a switch for coupling with one or more electrical or optical interconnects and/or an optical or electrical interconnect controller for a converged interconnect fabric and an abstraction of a data communication protocol that conforms to a native networking standard. It should be understood that the term "data network interface" may be used interchangeably with other terms having similar or equivalent meanings such as a network interface controller, a network adapter, and the like. In this specification, any one of these terms may be used.

It should be understood that any of the examples herein are non-limiting. Thus, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing, networking, and electrical/optical communications in general.

Fig. 1 is a block diagram illustrating an example architecture of a communication network according to an example embodiment. The example architecture includes various components, including a connection manager 102, a coordinator 104, and what is shown in FIG. 1 as a "node 106₁… …, node 106_N"of a plurality of nodes 106. Each node of the plurality of nodes 106 may be a computing device.

The plurality of nodes 106 may form at least a portion of a network 108, and the network 108 may be a communication network such as a local area network on a converged interconnect architecture. A converged interconnect architecture can integrate all communications (e.g., inter-process/cluster (cluster) communications, network traffic, storage input/output, etc.) into a common interconnect of a single architecture through which a consolidated set of computing, storage, and networking capabilities can be provided. According to an example embodiment, a converged interconnect architecture may be deployed in a datacenter environment to enhance communication to a set of blade servers. The network 108 may be via connection-oriented interconnect technologies (e.g., a network interface technology)Thunderbolt^TM(also known as Light Peak)^TM) Etc.), data is communicated between the plurality of nodes 106 and/or with an external computing device (such as a node of another network).

Such interconnection technology may be protocol independent and thus may be used with any type of serial or parallel bus protocol (e.g., Universal Serial Bus (USB), PCI Express^TM(PCIe)、DisplayPort^TM) Etc.) are compatible. This interconnection technique may utilize hardware/software implementations of these protocols for data input/output operations. Alternatively, such interconnection techniques may involve a dedicated bus protocol for point-to-point data communication. In an example embodiment, the network 108 may include an electrical or between two or more of the plurality of nodes 106Optical communications networks, which generally refer to any form of telecommunications network using copper or light, respectively, as the transmission medium.

Each of the plurality of nodes 106 may be logically connected to a coordinator 104, the coordinator 104 enabling an internetworking technology-based data network (e.g., TCP/IP over Ethernet) as described herein. The coordinator 104 may include software code that executes as a software module on another node within the network 108, which may be referred to as a root node. The connection manager 102 may also communicate with the coordinator 104 via a logical connection. The connection manager 102 may also be a software module running on the root node, or it may run on a computing device located outside the network and configured to manage the plurality of nodes 106.

As described herein, the connection manager 102 controls various interconnect technology mechanisms (e.g., firmware, drivers, hardware controllers, switches, etc.) to obtain a bus topology within the network 108 and establish (logical) communication paths. In conjunction with these mechanisms, according to an example embodiment, connection manager 102 enumerates each data network interface and establishes a topology map that assigns each data network interface within each of nodes 106 a topology identifier (e.g., TopologyID), which may be a unique identifier within network 108. Thus, an example node 106 including multiple data network interfaces₁There may be multiple topology identifiers. Each identifier may be valid for a limited period of time, such as the period between topology enumerations. Connection manager 102 may be notified of topology changes caused by particular events (e.g., plug/unplug events, power on/off nodes, etc.) and connection manager 102 modifies topology identifier assignments within network 108 in response.

During initial enumeration, connection manager 102 configures (logical) communication paths between multiple nodes 106. After initial enumeration, connection manager 102 may reconfigure communication paths between multiple nodes 106 based on the particular network traffic pattern. The connection manager 102 may assign an identifier to each communication path accessible from a particular node. Thus, a particular node corresponds to a set of local communication path identifiers, where each path identifier represents a plurality of data network interfaces, including source and destination data network interfaces, between source and destination data network interfaces. For embodiments comprising multiple communication networks that may be arbitrarily interconnected, multiple connection managers 102 in adjacent networks utilize primitives (privatives) to configure inter-network communication paths.

In an example embodiment, network 108 may be a local area network over a plurality of electrical or optical interconnects between respective pairs of the plurality of nodes 106. Each interconnect may include an optical or electrical cable connecting two data network interfaces (adapters) at each port (e.g., miniport). The cable may be manufactured using one or more electrical conductors or optical fibers. The data network interface port may be configured to form a coupling with a cable connector such that the optical cable is communicatively connected to a converged interconnect fabric technology hardware component such as a switch (e.g., a non-blocking switch).

An example data network interface may include a software implementation of a data communication protocol (e.g., a data link layer protocol such as a media access control sublayer protocol) according to a particular networking standard (e.g., ethernet). According to this implementation, for higher level protocols, the data communication protocol emulates functionality that conforms to a particular networking standard and enables interoperability with converged interconnect architecture technologies. Example data network interfaces may also include hardware implementations (e.g., Network Interface Cards (NICs)) that incorporate interconnect architecture technology and/or bus protocols.

In an example embodiment, the data network interface uses physical addresses (e.g., data link layer addresses in a protocol stack, topology identifiers in an optical or electrical communications network, etc.) and path identifiers to route data along a corresponding communications path that may include one or more interconnects. For example, a respective communication path (e.g., a data link layer communication path) may include two or more interconnects that define a chain of one data network interface communicating with a destination data network interface via one or more intermediate data network interfaces (e.g., hops). When routing data along such a communication path, each interconnect transfers the data to an intermediate data network interface that relays the data to the next intermediate data network interface or ultimately to the destination data network interface.

In addition to such a communication path configuration, connection manager 102 may also assign Internet Protocol (IP) addresses to multiple nodes 106. For example, connection manager 102 may implement a Dynamic Host Configuration Protocol (DHCP) server. Because the data network interfaces initially lack a globally unique identifier, the connection manager 102 determines an IP address based on the globally unique identifier (e.g., hostname) of each of the nodes 106 and the locally unique identifier of each data network interface.

FIG. 2 is a block diagram illustrating an example system for simulating a data network interface enabling interoperability with an interconnection controller according to one example embodiment. The example system includes various components, such as a root node 202 and a host node 204, connected to each other by a local communication path 206 associated with the interconnect technology. Root node 202 and host node 204 may form part of a communication network, such as a local area network on a converged interconnect fabric, with other nodes.

In an example embodiment, the root node 202 includes various exemplary components, such as the connection manager 102, the coordinator 104, and the network configuration information 208. The root node 202 may also include one or more interconnect-technology-compatible networking components (such as a switch 210) through which data is communicated to the host node 204 along the local communication path 206. In compliance with the interconnect technology, the connection manager 102 may provide a local communication path 206 between the switch 210 and a complementary switch, such as switch 212, on the host node 204. In an example embodiment, local communication path 206 may be represented by one or more topology identifiers corresponding to one or more interconnections coupling switch 210 and switch 212.

Initially, the connection manager 102 may pre-configure the root node 202 with one or more addresses that enable a computing device, such as the host node 204, to locate the root node 202 and communicate with the root node 202. The connection manager 102 and/or coordinator 104 may provide one or more addresses to the host node 204 and other host nodes within the communication network. The one or more addresses may correspond to layers of a protocol stack (e.g., Open Systems Interconnection (OSI) reference networking model), such as a data link layer and a network layer. For example, root node 202 may be preconfigured with a physical address and a network address associated with a data link layer protocol and a network layer protocol, respectively.

As described herein, the connection manager 102 and coordinator 104 may generate the network configuration information 208 as a description of the underlying network topology. In an example embodiment, the network configuration information 208 may include a mapping between a locally unique identifier and one or more addresses of each switch in the communication network. For example, the connection manager 102 and coordinator 104 may assign a network topology identifier (e.g., TopologyID) and a physical or hardware address (e.g., MAC address) to the switch 212, respectively, in conjunction with the assignment of network addresses (e.g., IP addresses), which are stored in the network configuration information 208 and communicated in whole or in part to the host node 204 and other host nodes.

When another host node wishes to transmit data to host node 204, some of these addresses may be used to identify and locate host node 204 within the communication network. In an example embodiment, the network configuration information 208 may map the physical address of the host node 204 and/or the physical address of the source host node to a unique path identifier (e.g., HopID) that refers to a logical connection from the source host node to the (destination) host node 204. As described herein, the unique path identifier may represent a communication path that is compatible with the interconnect controller 220 or that is generated from the interconnect controller 220. Based on the unique path identifier, the interconnect controller 220 identifies the appropriate switch port to transmit application data 218, such as ethernet frames, to ensure delivery to the host node 204. The application data 218 may reach an intermediate host node that routes the data to the next node along a compatible communication path.

The host node 204 includes various example components such as an emulation mechanism 214, host configuration data 216, application data 218, interconnect controller 220, and address resolution data 222. In an example embodiment, the emulation mechanism 214 may implement a data communication protocol (driver) in accordance with a networking standard (e.g., ethernet) and interoperable with the interconnection controller 220. The emulation mechanism 214 can provide higher layer protocols using various data network interface services that operate in compliance with networking standards. To perform these services, emulation mechanism 214 may invoke a device driver function (device driver function) associated with interconnection controller 220 to transfer application data 218 to a destination (node). For example, emulation mechanism 214 may transform a TCP/IP data sequence (e.g., a packet) into an Ethernet-formatted frame that can be transmitted over a communication path by interconnect controller 220.

The emulation mechanism 214 can store the physical address and network address associated with the host node 204 in the host configuration data 216. Emulation mechanism 214 may also store physical and network addresses associated with other host nodes, including root node 202, in address resolution data 222. In an example embodiment, emulation mechanism 214 may also store a set of (path) identifiers for one or more accessible communication paths between host node 204 and other host nodes. Each identifier may be translated by interconnect controller 220 into a set of interconnects that define a compatible communication path to a destination. Optionally, the address resolution data 222 may also include a topology identifier (e.g., TopologyID) for each intermediate switch between the host node 202 and the destination, as well as the destination itself.

The emulation mechanism 214 can include various example components such as kernel mode (driver) components and user mode (service) components that perform data communication protocol operations. In an example embodiment, kernel mode components and user mode components may coordinate requests (e.g., Dynamic Host Configuration Protocol (DHCP) requests) for host configuration data 216 to root node 202. In another example implementation, kernel mode components and user mode components may coordinate requests (e.g., Address Resolution Protocol (ARP) requests) for address resolution data 222 to root node 202.

In an example embodiment, the emulation mechanism 214 and the coordinator 104 may coordinate multicast and/or broadcast services over a connection-oriented interconnect technology. For example, when emulation mechanism 214 receives a request for address resolution data 222 (associated with a destination class D IP address for a multicast packet), emulation mechanism 214 can communicate the request to coordinator 104. The coordinator 104 responds with the MAC address associated with the switch 210 and the HopID path identifier associated with the local communication path 206. As a result, the address resolution data 222 includes the MAC address and the HopID path identifier as appropriate destination physical addresses and appropriate logical connections for the multicast and/or broadcast packets, respectively.

Upon receiving the multicast packet, coordinator 104 references the multicast group membership table within network configuration information 208, identifies one or more member nodes associated with the destination class D IP address, and generates a list including each member IP address. The coordinator 104 determines whether any member node is outside the subnet based on past participation in the corresponding multicast group. If any such nodes are present, the coordinator 104 adds each associated gateway authority IP address to the list. For each IP address in the list, the coordinator 104 creates a copy of the multicast packet and transmits the copy to the corresponding member node. According to an example embodiment, the coordinator 104 may resolve each IP address into a communication path identifier and a physical address for the respective member node.

For embodiments associated with receiving broadcast packets, coordinator 104 identifies each host node having the same subnet as host node 204 and creates a list that includes each IP address of other host nodes within the subnet. The coordinator 104 excludes from the list any host nodes outside the subnet. The coordinator 104 creates a copy of the broadcast packet and transmits the copy to each host node. In an example embodiment, coordinator 104 may resolve each IP address into a path identifier and a physical address associated with another subnet host node.

Generally, interconnect controller 220 is a building block for creating interconnect technology networking components such as switch 210 and switch 212. In one example embodiment, these switches may be high performance, non-blocking crossbar (bus) protocol switches. Interconnect controller 220 may be a chip that provides protocol switching capabilities such that multiple protocols (e.g., DisplayPort and PCI Express) may be run over a single cable (e.g., electrical or optical cable). In addition to one or more ports for switches, interconnect controller 220 also includes one or more bus protocol adapter ports. The external interface of interconnect controller 220 may provide functionality to a particular application.

Fig. 3 is a block diagram illustrating an example protocol stack interoperable with a communication network according to an example embodiment. Each layer of the example stack, such as protocol stack 302, may be associated with a well-known networking model. In an example embodiment, the protocol stack 302 may include a kernel mode component 304 and a user mode component 306 of the emulation mechanism 214 as shown in FIG. 2.

In an example embodiment, the kernel mode component 304 may serve as a data link layer protocol configured to perform various services, which may include transferring data between nodes in a network (i.e., a communications network) such as a local area network over a converged interconnect architecture. For example, the kernel mode component 304 can utilize a local miniport driver 308 associated with an interconnect technology device, the local miniport driver 308 including various networking hardware components such as a switch, one or more transceivers, one or more bus protocol modules, and the like. Various networking hardware components may implement a physical layer within the protocol stack 302 that manages the reception and transmission of unstructured raw bit streams over a physical medium (e.g., electrical conductors or optical fibers) to which interconnection technology equipment is attached.

In an example embodiment, the kernel mode component 304 may abstract vendor specific functionality provided by the local miniport driver 308 to the various networking hardware components. This abstraction may ensure that the kernel mode component 304 can emulate a data network interface using networking hardware components from different hardware vendors. In addition, the kernel mode component 304 may abstract hardware vendor specific functionality from a connection manager (such as the connection manager 102 of FIG. 1). The kernel mode component 304 may also use a local miniport driver 308 to control various hardware components for the purpose of transferring application data to a destination (node).

In addition to transferring application data, kernel mode component 304 can provide host configuration services and/or address resolution services. User mode component 306 may support these services by transmitting host configuration requests and/or address resolution requests to a coordinator running on a root node (e.g., root node 202 of fig. 2). For example, kernel mode component 304 can intercept such requests from upper layer protocol drivers, such as network layer protocol 310 and transport layer protocol 312, and can redirect those requests to user mode component 306, which user mode component 306 modifies the requests to communicate them to the root node. The address information provided by the root node in response to these requests may be stored in the host configuration data 216 and/or the address resolution data 222.

In an example embodiment, the kernel mode component 304 intercepts an Address Resolution Protocol (ARP) request associated with a destination and redirects the request to the user mode component 306, the user mode component 306 inserts a network address and a physical address associated with a root node into a destination address field. The purpose of the ARP request may be to determine a physical address (e.g., a data link layer protocol address such as a MAC address) of the destination that maps to a known network address (e.g., a network layer protocol address such as an IP address). When the root node responds with a physical address, the user mode component 306 stores the physical address associated with the destination in the address resolution data 222, and the kernel mode component 304 continues to route the application data. If another set of application data is to be transmitted to the destination in the future, the network layer protocol 310 may refer to the address resolution data 222 to resolve the known network address to the appropriate physical address. In this embodiment, the address resolution data 222 is used as a cache of known physical addresses of other host nodes.

In another example embodiment, kernel mode component 304 intercepts Dynamic Host Configuration Protocol (DHCP) requests and redirects the requests to user mode component 306, which user mode component 306 inserts the network address and physical address associated with root node 202 into the destination address field. The purpose of the DHCP request is to ascertain the appropriate and unique network address of host node 204. When root node 202 responds with a network address, user mode component 306 stores the network address associated with host node 204 in host configuration data 216.

In general, DHCP is a network configuration protocol for host nodes on a local area network, such as an Internet Protocol (IP) network. To communicate with other host nodes, the source host node is configured with a unique network address. The host node may also be configured with a physical address. The root node implements DHCP and provides a central database of network configuration information to prevent duplicate network address assignments. The root node may also provide additional network configuration information such as a network topology identifier. Alternatively, an external server residing outside the local area network implements DHCP and assigns a network address (i.e., IP address) to the host node. The server maps the network address to a physical address (i.e., MAC address) that may be assigned or statically assigned by the root node. Furthermore, the gateway mechanism of the local area network may act as a DHCP proxy and relay DHCP requests directly to the external server.

In yet another example embodiment, kernel mode component 304 may multicast and/or broadcast services over connection-oriented interconnect technologies. For example, when the kernel mode component 304 receives a request (e.g., an ARP request) to resolve a class D IP address that includes an arbitrary IP address (with a first byte value ranging from 224 to 247), the kernel mode component 304 can redirect the request to the user mode component 306, which user mode component 306 queries the coordinator running on the root node. The class D IP address may refer to a destination of the multicast packet. Instead of responding with a specific MAC address for the class D IP address, the coordinator provides the MAC address associated with the switch attached to the root node. As a result, the network layer protocol 310 resolves the class D IP address to the coordinator MAC address and the kernel mode component 304 transmits the multicast packet to the coordinator.

Upon receiving the multicast packet, the coordinator refers to the multicast group member table to identify one or more member nodes of the corresponding multicast group, and generates a list including an IP address of each member. The coordinator determines whether any member nodes are outside the subnet based on past participation in the corresponding multicast group. If there are any such nodes, the coordinator adds each associated gateway authority IP address to the list. For each IP address in the list, the coordinator creates a copy of the multicast packet and transmits the copy to the IP address. For broadcast packets, the coordinator creates another list including each IP address of the host nodes within the subnet and transmits a copy of the broadcast packet to each host node.

In an example embodiment, a local miniport driver 308 (e.g., a Media Access Controller (MAC) device driver) wraps a hardware implementation of various portions of the data link layer and/or physical layer of the (wrap) protocol stack 302 such that interconnect technology devices may be accessed using a common API such as a Network Driver Interface Specification (NDIS) 314. In general, NDIS 314 may define a standard Application Programming Interface (API) for networking devices, such as a Network Interface Card (NIC). NDIS 314 provides a service for simplifying the development and maintenance of local miniport drivers 308 and protocol drivers at upper layers of the protocol stack 302. In addition, the local miniport driver 308, the kernel mode component 304, and the network protocol layer 310 may be bound together by the NDIS 314.

The network layer protocol 310 may be configured for application packet delivery, which may include routing packets through intermediate nodes, while the data link layer protocol performs medium access control, physical addressing, flow control, and/or error checking. Network layer protocol 310 may implement various methods of transferring variable length data sequences to a destination via a network. For example, the network layer protocol 310 may include a set of internetworking methods in the internet protocol suite known as TCP/IP for transporting packet network boundaries to destinations specified by network addresses (e.g., IP addresses as defined by the Internet Protocol (IP)) when needed. The transport layer protocol 312 may provide end-to-end communication services for a socket (socket) 316 and an application layer (application) 318 within the layered architecture of the protocol stack 302. Transport layer protocol 312 provides various services such as connection-oriented data flow support, reliability, flow control, and multiplexing.

In an example embodiment, the kernel mode component 304 may be an NDIS intermediate driver (e.g., an NDIS filter intermediate driver) layered on a local miniport driver 308 (e.g., a third party interconnect technology miniport driver). The kernel mode component 304 and the user mode component 306 may emulate an ethernet Network Interface Controller (NIC) that provides a data network interface to the overlay protocol driver for connecting the host node to an ethernet network. In general, ethernet refers to a networking standard for Local Area Networks (LANs) (e.g., Institute of Electrical and Electronics Engineers (IEEE)802.3), which may be used to connect nearby computing devices together to share resources. In an example embodiment, the kernel mode component 304 can expose an ethernet miniport (e.g., an NDISMedium IEEE 802.3 networking standard miniport) to an overlay protocol driver in the protocol stack 302, which can transmit ethernet frames to a destination node using the ethernet miniport. The kernel mode component 304 can also expose the data communication protocol for consuming ethernet frames to the local miniport driver 308.

Because the NDIS intermediate driver operates between one or more overlay protocol drivers and the local miniport driver 308, the kernel mode component 304 may communicate with both the overlay protocol driver and the local miniport driver 308 to expose a protocol entry point and a miniport driver entry point, respectively. NDIS 314 calls a function at the protocol entry point on kernel mode component 304 to pass the request from the local miniport driver 308. NDIS 314 calls a miniport function at the miniport driver entry point on kernel mode component 304 to communicate the request of one or more overlapping protocol drivers. As a result, kernel mode component 304 may be represented as a protocol driver to local miniport driver 308 and a miniport driver to overlay protocol driver.

In an example embodiment, the kernel mode component 304 exposes one virtual miniport to each base miniport driver that may be bound to the kernel mode component 302, such as the local miniport driver 308. The kernel mode component 304 outputs one or more virtual miniports (i.e., adapters) to which the overlay protocol driver may bind. For each overlay protocol driver, the virtual miniport appears to be the physical data network interface that controls the networking hardware components of the interconnect technology device.

When the virtual miniport receives a data packet, the kernel mode component 304 forwards the data packet as an ethernet frame down to the local miniport driver 308. The kernel mode component 304 may also include an NDIS filter intermediate driver or an NDIS filter driver that modifies the data packet before sending it to the local miniport driver 308. For example, kernel mode component 304 may encrypt and compress the payload within the packet. In general, the NDIS filter driver may monitor and modify the interaction between the overlay protocol driver and the local miniport driver 308.

The kernel mode component 304 may expose an MTU (maximum transmission unit) size, such as forty-zero ninety-six (4096 or 4 kbytes), which may be the maximum possible (ethernet) payload frame size that may be fragmented (at the source host node) and reassembled (at the destination host node) by the interconnect controller. The interconnect technology media may support a maximum payload size of 256 bytes, but may be fragmented and reassembled such that the upper layers of the protocol stack 302 may essentially operate at a 4KB payload size. Alternatively, kernel mode component 304 can expose 256 bytes as the MTU size and have protocol stack 302 do fragmentation and reassembly of frames (e.g., ethernet frames).

Fig. 4 is a block diagram illustrating an example configuration of a local area network on a converged interconnect architecture between data network interfaces according to an example embodiment. An example configuration of a local area network, such as local area network 402, includes a plurality of data network interfaces 404 that communicate with each other through a converged interconnect fabric 406. Each of the plurality of nodes 408 may implement one or more of the data network interfaces 404. In an example embodiment, each of the data network interfaces 404 may include an implementation compliant with a networking standard (e.g., Ethernet) and with an interconnection technology (e.g., Ethernet)Thunderbolt^TMOr LightPeak^TM) Software and hardware components of interoperable data communication protocols.

In an example embodiment, the local area network 402 may be a communication network as follows: where one of the plurality of nodes 408 may be a root node that includes the connection manager 102 and the coordinator 104. For example, the plurality of nodes 408 may include a set of network configuration information that is provisioned into a rack-mounted computing system (e.g., servers) for which the coordinator 104 maintains consistency. In one embodiment, the converged interconnect architecture 406 may be configured to integrate computing, storage, and networking services with linked nodes within a data center environment, such as a rack-mounted computing system.

In an example embodiment, each interconnect within the converged interconnect fabric 406 may include a connection to a pair of the plurality of data network interfaces 404, such as the data network interfaces 404₅And a data network interface 404₆The cable of (2). Cables may be manufactured using one or more electrical conductors or optical fibers. The ports associated with the plurality of data network interfaces 404 may be configured to form a coupling with cable connectors such that the cables may be communicatively connected to networking hardware components such as non-blocking switches.

The example interconnect 410 may be coupled to a physical switch 412 with a local miniport driver (e.g., the local miniport driver 308 of FIG. 3) controlling access to the physical switch 412. The emulation mechanism 214 can be used as a data communication protocol (drive) to a local miniport drive. As described herein, the combination of the physical switch 412, the local miniport driver, and the kernel mode component 304 of the emulation mechanism 214 can be abstracted such that the data network interface 404₅A first emulated data network interface or Network Interface Controller (NIC) that appears as an overlay protocol driver to a protocol stack. For example, kernel mode component 304 may enable data network interface 404₅Appearing as a hardware driven device/object such as a (virtual) miniport.

According to another example embodiment, at node 408₂Internal, data network interface 404₃And/or data network interface 404₄May be a virtual data network interface. Interface 404 with a data network₅Similarly, the emulated data network interface 414 may be implemented using the physical switch and kernel mode component 304 and by abstracting the hardware vendor specific functionality provided by the local miniport driver. This abstraction may ensure that the emulation data network interface 414 is interoperable with networking hardware components from different interconnection technology hardware vendors. Alternatively, emulation mechanism 214 can specify the hardware vendor from a connection manager (such as connection manager 102 of FIG. 1)And (4) function abstraction.

At node 408₂Run-in virtualization manager (e.g., a virtual machine manager)Hyper-V) may unbind the protocol stack (e.g., TCP/IP stack) of the host operating system from the physical switch and bind the protocol stack to the virtual switch, the local miniport driver, and the kernel mode component 304 of the emulated data network interface 414. The virtual switch may be used to adjust the interface 404 with respect to the data network₃And/or data network interface 404₄To communicate data.

The virtualization manager may partition the physical switch and provide a data network interface 404₃And/or data network interface 404₄As virtual data network interfaces (e.g., virtual NICs), each of which may include a virtual version of a local miniport driver and emulation mechanism 214. For example, the data network interface 404₄A virtual protocol stack may be provided for a virtual machine, the virtual protocol stack including an ethernet-compatible data communication protocol interoperable with a virtual version of a local miniport driver. The virtual machine may request host configuration from the coordinator 104, the coordinator 104 interfacing 404 to the data network₄A network address and/or a physical address is assigned. Data network interface 404 when a virtual machine transfers data to a destination₄The data is transmitted to the virtual switch using a virtual network switch protocol. The virtual switch receives the data and uses the miniport exposed by the emulated data network interface 414 to route the data to the destination via the local miniport driver and the physical switch.

Optionally, emulation mechanism 214 may enable single root input/output virtualization (SR-IOV) features and/or Virtual Machine Queue (VMQ) features for the Virtual switch. For the VMQ feature, according to an example embodiment, the physical switch uses the destination Media Access Control (MAC) address to classify received packets and routes the packets to different receive queues. The connection manager 102 may configure separate paths and assign a different path identifier (e.g., HopID) to each virtual data network interface. The physical switch may also support other VMQ networking hardware requirements, such as discrete and aggregate I/O operations. Each receive/transmit queue pair may represent a single virtual switch port and/or may be processed by a dedicated processor. Alternatively, each receive queue/transmit queue pair may represent a particular communication path or grouping of communication paths for a particular virtual data network interface. Multiple packets in the receive queue may be directly transmitted to the virtual machine in one function call. For example, emulation mechanism 214 can transfer the packet directly to the shared memory of the virtual machine.

For the SR-IOV feature, the emulated data network interface 414 includes a PCIe device/interface that exposes physical and virtual functions through the local miniport driver. Emulation mechanism 214 can partition emulation data network interface 414 such that the PCIe device is presented to the host operating system or virtualization manager as a plurality of separate physical PCIe devices. For example, a four-port SR-IOV network interface controller may be divided into four devices each assigned a single port. For example, each of these devices may be further divided into two hundred fifty-six single port NICs (virtual functions) for a theoretical total of 1024 single NIC ports. In one example embodiment, a set of path identifiers associated with a particular destination physical address may be divided into packets such that each packet may be accessed as a separate PCIe device from a different virtual machine or physical machine.

Converged interconnect fabric 406 may provide connection-oriented communication in which each associated endpoint data network interface may use a protocol to establish an end-to-end logical or physical connection before any data may be sent. For example, an example data network interface pair may utilize a PCIe device to create a point-to-point communication channel between two PCIe ports, which enables both data network interfaces to send/receive normal PCI requests (e.g., configuration read/write, I/O read/write, memory read/write) and PCI interrupts (e.g., INTx, MSI-X).

In an example embodiment, the plurality of data network interfaces 404 use physical addresses (e.g., data link layer addresses such as MAC addresses) and path identifiers to route data along communication paths that may include one or more interconnects of the converged interconnect fabric 406. For example, two or more interconnects together may be a chain and enable one endpoint data network interface to communicate with another data network interface via one or more intermediate data network interfaces (e.g., hops). As the data is routed along the communication path, each interconnect transfers the data to an intermediate data network interface that relays the data to the next intermediate data network interface or ultimately to other data network interfaces.

FIG. 4 illustrates a data network interface 404₃And a data network interface 404₁₁Example communication paths between. It should be appreciated that data network interface 404 may be targeted₃Or data network interface 404₄Establishing an example communication path to interface 404 to a data network₁₁Data such as ethernet frames are transmitted. The interconnect 410 connects the data network interfaces 404 as described herein₃And a data network interface 404₅. Additionally, the example interconnect 416 couples the data network interface 404₅And a data network interface 404₆Data network interface 404₆Interface with data network 404 through example interconnect 418₉And (4) connecting. Data network interface 404₉Example interconnect 420 and data network interface 404 may be used₁₁And (4) communication. A set of such example interconnections defines an example communication path. In an example embodiment, the data network interface 404₃One or more of the example interconnects may also be used to communicate data to any intermediate data network interfaces within the example communication path.

Starting from each data network interface at the root node of the plurality of nodes 408, the connection manager 102 enumerates each of the data network interfaces 404 in the example configuration and establishes a topology graph. The connection manager 102 may be notified of topology changes caused by hot-plug and hot-unplug events. After initial enumeration, the connection manager 102 configures the communication paths to enable data transfer between the plurality of data network interfaces 404.

Fig. 5 is a flowchart illustrating example steps for providing a local area network over a converged interconnect fabric between data network interfaces according to an example embodiment. The exemplary steps may begin at step 502 and proceed to step 504 where the coordinator 104 accesses a local communication path associated with the interconnect technology at step 504. As described herein, a local communication path may be a communication path from a root node to a host node compatible with an interconnection controller (e.g., an electrical or optical interconnection controller). In an example embodiment, the coordinator 104 may configure the host node with a network address and a physical address associated with the root node.

Step 506 is directed to configuring a data network interface on the host node. In one example embodiment, the coordinator 104 communicates physical addresses to the host nodes, which store the addresses in the host configuration information. In another example embodiment, the coordinator 104 transmits a message indicating physical address assignment to each host node, which facilitates the binding process between the kernel mode component 304 and the overlay protocol driver. If the host node does not acknowledge receipt of the message, the coordinator 104 resends the message at a later point in time. Alternatively, the coordinator 104 may instruct the connection manager 102 to program the sequence number register with the lower portion of the MAC address assigned to the host node, which may be combined with a predefined MAC prefix to form a locally unique 48-bit MAC address. Alternatively, the physical address of the host node may be derived from a locally unique identifier provided by the interconnect technology.

Once the coordinator configures a particular host node with a physical address, the particular host node may request a network address to complete the host configuration process. In one example embodiment, the emulation mechanism 214 communicates a DHCP request for which the coordinator replies with a network address, such as an IP address. The emulation mechanism 214 can store the network address in the host configuration data and proceed to handle ARP requests, provide multicast/broadcast services, and/or transmit application data.

Step 508 involves determining whether one or more current packets include a multicast request, a broadcast request, or an ARP request. If the coordinator 104 receives the broadcast request, step 508 proceeds to step 510, and in step 510, the coordinator 104 accesses the network configuration information and describes an IP address for each host node within the same subnet as the source node of the broadcast request. The coordinator 104 replies to the broadcast request with the IP address associated with the root node so that subsequent broadcast packets arrive at the root node. Step 512 is intended to transmit a copy of the subsequent broadcast packet to each host node within the subnet. Accordingly, the coordinator 104 may act as a proxy or gateway broadcasting application data to these host nodes.

If the coordinator 104 receives the ARP request, step 508 proceeds to step 514, where the coordinator 104 proposes the network address from the ARP request and uses the network configuration information to access a mapping between the network address and a physical address associated with the destination host node, step 514. In an example embodiment, the coordinator 104 also identifies a mapping between the communication path identifier and the physical addresses of the destination node and the host node. Step 516 is directed to communicating the physical address of the destination node and the communication path identifier to the host node in response to the ARP request.

If the coordinator 104 receives a multicast request, step 508 proceeds to step 518, where the coordinator 104 uses the network configuration information to access the members of the multicast group associated with the multicast request and enumerates an IP address for each host node within the members of the multicast group, step 518. The coordinator 104 replies to the multicast request with the IP address associated with the root node so that subsequent multicast packets arrive at the root node. Step 520 is intended to transmit a copy of the subsequent multicast packet to each host node within the subnet. If a particular host node is located outside the same subnet as the source node, the coordinator 104 uses the gateway authority IP address to route the multicast packet.

Step 522 is directed to determining whether there are more requests from host nodes within the network. If there are more requests, step 522 returns to step 508. If there are no more requests, step 522 proceeds to step 524. Step 524 represents terminating the steps described in fig. 5.

FIG. 6 is a flowchart illustrating example steps for emulating a data communication protocol according to a networking standard, according to an example embodiment. The example steps begin at step 602 and proceed to step 604 where emulation mechanism 214 stores the data communication protocol address in the host configuration data at step 604. The data communication protocol address may be referred to as a physical or hardware address assigned to the attached switch. In an example embodiment, the emulation mechanism 214 requests a physical address from a coordinator 104 running within a root node within a network (such as a local area network on a converged interconnect architecture).

Step 606 is directed to intercepting and redirecting host configuration data requests. In one example embodiment, the overlay protocol layer driver wants a network layer protocol address to transmit application data to another node in a manner that conforms to a networking standard, such as ethernet. The coordinator 104 may reply with a locally unique network layer protocol address assignment. Step 608 is directed to processing the network layer protocol address (i.e., network address) stored in the host configuration data.

Step 610 represents receiving application data to be transmitted to the destination node. Step 612 determines whether a physical address resolving to the network layer protocol address of the destination node is stored in a cache (e.g., an ARP cache). If the physical address is not stored in the cache, step 612 proceeds to step 614. Step 614 is directed to intercept the address resolution data request and redirect it to the coordinator 104. Step 616 is intended to store the physical address and/or path identifier in the address resolution data. The path identifier may refer to one or more intermediate data network interfaces along the communication path to the destination node. If the physical address is stored in the cache, step 612 proceeds to step 618. Step 618 involves instructing the interconnect controller to route the application data frames (e.g., ethernet frames) to the destination node via the communication path. Step 620 involves the termination of the steps described in fig. 6.

Example networked and distributed environments

It will be appreciated by those of ordinary skill in the art that the various embodiments and methods described herein may be implemented in connection with any computer or other client or server device that may be deployed as part of a computer network or in a distributed computing environment and that may be connected to any kind of data storage. In this regard, the various embodiments described herein may be implemented in any computer system or environment having any number of storage or memory units and any number of applications and processes occurring across any number of memory units. This includes, but is not limited to, the following environments: where server computers and client computers are deployed in network environments or distributed computing environments, having remote or local storage.

Distributed computing provides sharing of computer resources and services through the exchange of communications between computing devices and systems. These resources and services include the exchange of information, cache storage, and disk storage for objects such as files. These resources and services also include sharing processing power across multiple processing units for load balancing, resource expansion, processing customization, and so forth. Distributed computing takes advantage of network connectivity so that clients can leverage (leveraging) their collective power to benefit the entire enterprise. In this regard, a variety of devices may have applications, objects, or resources that may participate in the resource management mechanisms as described for various embodiments of the subject disclosure.

FIG. 7 provides a schematic diagram of an example networked or distributed computing environment. The distributed computing environment comprises computing objects 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc., which may include programs, methods, data stores, programmable logic, etc., as represented by example applications 730, 732, 734, 736, 738. It is to be appreciated that computing objects 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. can comprise different devices such as a Personal Digital Assistant (PDA), audio/video device, mobile phone, MP3 player, personal computer, laptop, etc.

Each computing object 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. can communicate with one or more other computing objects 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. by way of the communications network 740, either directly or indirectly. Although illustrated as a single element in fig. 7, communications network 740 may comprise other computing objects and computing devices that provide services to the system of fig. 7, and/or may represent multiple interconnected networks, which are not shown. Each computing object 710, 712, etc. or computing object or device 720, 722, 724, 726, 728, etc. can also contain an application, such as applications 730, 732, 734, 736, 738, which can utilize an API or other object, software, firmware and/or hardware suitable for communicating with or implementing applications provided in accordance with various embodiments of the present disclosure.

There are a variety of systems, components, and network configurations that support distributed computing environments. For example, computing systems may be connected together by wired or wireless systems, by local networks or widely distributed networks. Currently, many networks are coupled to the internet, which provides the infrastructure for widely distributed computing and includes many different networks, although any network infrastructure may be used for example communications associated with the system as described in various embodiments.

Thus, numerous network topologies and network infrastructures, such as client/server, peer-to-peer, or hybrid architectures, may be utilized. A "client" is a member of a class or group that uses the services of another class or group to which it is not related. A client may be a process, e.g., roughly a collection of instructions or tasks, that requests a service provided by another program or process. The client process utilizes the requested service without having to "know" any working details about the other program or the service itself.

In a client/server architecture, particularly a networked system, a client is typically a computer that accesses shared network resources provided by another computer, such as a server. In the illustration of FIG. 7, as a non-limiting example, computing objects or devices 720, 722, 724, 726, 728, etc. can be thought of as clients and computing objects 710, 712, etc. can be thought of as servers where computing objects 710, 712, etc. acting as servers provide data services, such as receiving data from client computing objects or devices 720, 722, 724, 726, 728, etc., storing data, processing data, transmitting data to client computing objects or devices 720, 722, 724, 726, 728, etc., although any computer can be considered a client, a server, or both, depending on the circumstances.

A server is typically a remote computer system accessible over a remote or local network, such as the internet or wireless network infrastructure. Client processes may be active in a first computer system and server processes may be active in a second computer system, communicating with each other over a communications medium, thereby providing distributed functionality and enabling multiple clients to take advantage of the information-gathering capabilities of the server.

In a network environment in which the communications network 740 or bus is the Internet, for example, the computing objects 710, 712, etc. can be Web (website) servers with which other computing objects or devices 720, 722, 724, 726, 728, etc. communicate via any of a number of known protocols, such as the Hypertext transfer protocol (HTTP). Computing objects 710, 712, etc. acting as servers can also act as clients, e.g., computing objects or devices 720, 722, 724, 726, 728, etc., as can be characteristic of a distributed computing environment.

Example computing device

As mentioned, the techniques described herein may be advantageously applied to any device. It is therefore to be understood that handheld, portable and other computing devices and computing objects of all kinds are contemplated for use in connection with the various embodiments. Accordingly, the below general purpose remote computer described below in FIG. 8 is but one example of a computing device.

Embodiments may be implemented in part via an operating system, for use by a developer of services for a device or object, and/or may be included in part within application software that operates to perform one or more functional aspects of the various embodiments described herein. Software may be described in the general context of computer-executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices. Those skilled in the art will appreciate that computer systems have a variety of configurations and protocols that can be used to transfer data, and thus no particular configuration or protocol is considered limiting.

FIG. 8 thus illustrates an example of a suitable computing system environment 800 in which one or aspects of the embodiments described herein may be implemented, although as made clear above, the computing system environment 800 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality. Additionally, the computing system environment 800 is not intended to be interpreted as having any dependency relating to any one or combination of components illustrated in the exemplary computing system environment 800.

With reference to FIG. 8, an exemplary remote device for implementing one or more embodiments includes a general purpose computing device in the form of a computer 810. Components of computer 810 may include, but are not limited to, a processing unit 820, a system memory 830, and a system bus 822 that couples various system components including the system memory to the processing unit 820.

Computer 810 typically includes a variety of computer readable media and can be any available media that can be accessed by computer 810. The system memory 830 may include computer storage media in the form of volatile and/or nonvolatile memory such as Read Only Memory (ROM) and/or Random Access Memory (RAM). By way of example, and not limitation, system memory 830 may also include an operating system, application programs, other program modules, and program data.

A user may enter commands and information into the computer 810 through input device 840. A monitor or other type of display device is also connected to the system bus 822 via an interface, such as output interface 850. In addition to a monitor, computers may also include other peripheral output devices such as speakers and a printer, which may be connected through output interface 850.

The computer 810 may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as a remote computer 870. The remote computer 870 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 810. The logical connections depicted in fig. 8 include a network 872, such Local Area Network (LAN) or a Wide Area Network (WAN), but may also include other networks/buses. Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets and the Internet.

As mentioned above, while example embodiments have been described in connection with various computing devices and network architectures, the underlying concepts may be applied to any network system and any computing device or system in which it is desirable to improve the efficiency of resource usage.

Further, there are numerous ways of implementing the same or similar functionality, e.g., appropriate APIs, tool components, driver code, operating systems, controls, stand-alone or downloadable software objects, etc., which enable applications and services to utilize the techniques provided herein. Thus, embodiments herein are contemplated from the perspective of an API (or other software object), as well as from a software or hardware object that implements one or more embodiments as described herein. Thus, various embodiments described herein may have aspects that are wholly in hardware, partly in hardware and partly in software, as well as in software.

The word "example" is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by this example. Moreover, any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms "includes," "including," "has," "contains," and other similar words are used, for the avoidance of doubt, when used in the claims, these terms are intended to be inclusive in a manner similar to the term "comprising" as an open-ended transitional word, without precluding any additional or other elements.

As mentioned, the various techniques described herein may be implemented in connection with hardware or software or, where appropriate, with a combination of both. As used herein, the terms "component," "module," "system" and the like are likewise intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

The foregoing system has been described with respect to interaction between several components. It will be understood that such systems and components may include such components or specified sub-components, specified components or portions of sub-components, and/or additional components, and in various permutations and combinations in accordance with the foregoing. The sub-components may also be implemented as components communicatively coupled to other components rather than included within the parent component (hierarchical). Additionally, it may be noted that one or more components may be combined into a single component providing aggregate (aggregate) functionality or divided into several separate sub-components, and any one or more middle layers, such as a management layer, may be provided to communicatively couple to these sub-components to provide integrated functionality. Any components described herein may also interact with one or more other components not specifically described herein but generally known by those of skill in the art.

Methods that may be implemented in accordance with the described subject matter may also be understood with reference to the flowcharts of the various figures in view of the example systems described herein. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the various embodiments are not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Where discontinuous or branched flow is illustrated via flow diagrams, it is to be understood that various other branches, flow paths, and orders of the blocks, which achieve the same or similar results, may be implemented. Furthermore, some of the illustrated blocks are optional in implementing the methods described below.

Conclusion

While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.

In addition to the various embodiments described herein, it is to be understood that other similar embodiments may be used or modifications and additions may be made to the described embodiments for performing the same or equivalent function of the respective embodiments without deviating therefrom. In addition, multiple processing chips or multiple devices may share the performance of one or more functions described herein, and storage may similarly be effected across multiple apparatuses. Accordingly, the present invention is not limited to any single embodiment, but rather its breadth, spirit and scope should be construed in accordance with the appended claims.

Claims (10)

1. In a computing environment, a method executed at least in part on at least one processor, comprising: emulating a data network interface (414) according to a networking standard, wherein the data network interface (414) works with an interconnection controller (220) comprising: providing address resolution data (222) to identify communication paths (200) within a converged interconnect fabric (406) that are compatible with the interconnect controller (220) and associated with a destination (202) of application data (218); and routing the application data (218) to the destination using the interconnection controller (220) based on the address resolution data (222), wherein the application data (218) conforms to the networking standard.

2. The method of claim 1, wherein providing the address resolution data further comprises: intercepting a request for the address resolution data associated with the destination, redirecting the request to a root node via the interconnect controller, and storing a path identifier representing the communication path and a physical address associated with the destination in the address resolution data.

3. The method of claim 1, wherein providing the address resolution data further comprises: a local communication path from the interconnect controller to a root node is processed, and host configuration data communicated via the local communication path is processed, the host configuration data including at least one of a network address or a physical address associated with a switch.

4. The method of claim 1, wherein routing the application data using the interconnection controller further comprises: transmitting a multicast packet including the application data to a root node that routes a copy of the multicast packet to each member of a multicast member group, or transmitting a broadcast packet including the application data to the root node that routes a copy of the broadcast packet to each host node within a subnet.

5. A system in a computing environment, comprising: a coordinator configured to: enabling a local area network (108) on a converged interconnect fabric (406) between data network interfaces (404), wherein the coordinator (104) is further configured to: accessing network configuration information (208), the network configuration information (208) including a physical address of each data network interface (404) compatible with an associated interconnect controller (220); creating a mapping between each pair of physical addresses and a path identifier associated with an accessible communication path (206) from a respective data network interface (404) using the network configuration information (208); and communicating each mapping to a respective node (106) within the local area network (108) via the converged interconnect fabric (406).

6. The system of claim 5, wherein the coordinator is further configured to assign the physical address to the data network interface within the local area network within a data center.

7. The system of claim 5, wherein the system further comprises: an emulation mechanism configured to implement a data communication protocol that routes application data to a destination according to a networking standard, wherein the emulation mechanism comprises an intermediate driver interoperable with an optical interconnect controller to communicate the application data via a plurality of optical interconnects in the converged interconnect fabric.

8. The system of claim 7, wherein the emulation mechanism is further configured to partition the emulated data network interfaces into virtual data network interfaces, and wherein the coordinator is further configured to assign a network address and a physical address to each virtual network interface.

9. One or more computer-readable media having computer-executable instructions that, when executed, perform steps comprising:

accessing (504), using a coordinator (104) of a local area network (108), a local communication path (206), wherein the local communication path (206) includes one or more interconnections (416,418,420);

configuring (506) a node (204) using a physical address transmitted by the coordinator (104) via the local communication path (206);

providing a data communication protocol (302) to a local miniport driver (308) for controlling a switch (412) within the node (204), wherein the switch (412) corresponds to an interconnect technology;

providing a miniport to an overlay protocol layer driver according to a networking standard;

requesting a network address of the node from the coordinator via the local communication path;

requesting a destination physical address of a data network interface from the coordinator via the local communication path; and

routing an application data frame to the destination physical address using the miniport driver, wherein the application data frame conforms to the networking standard.

10. The one or more computer-readable media of claim 9, having further computer-executable instructions comprising:

dividing the switch into one or more virtual data network interfaces of one or more virtual machines.