BACKGROUND

[0001] Various modem switches (e.g., Ethernet switches) continue to increase in scale, with more ports per switch and greater bandwidth per port.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] The following detailed descnption references the drawings, wherein:

[0003] FIG. 1 is a block diagram of an example system for auto-negotiation over extended backplane;

[0004] FIG. 2A is a block diagram of an example system for auto-negotiation over extended backplane;

[0005] FIG. 2B is a block diagram of an example rack capable of supporting auto- negotiation over extended backplane;

[0006] FIG. 3 is a flowchart of an example method for auto-negotiation over extended backplane; and

[0007] FIG. 4 is a flowchart of an example method for auto-negotiation over extended backplane. DETAILED DESCRIPTION

[0008] As mentioned above, various modern switches (e.g., Ethernet switches) continue to increase in scale, with more ports per switch and greater bandwidth per port. However, in some server environments (e.g., blade servers), enclosure sizes are such that a relatively low number of servers are housed per enclosure, e.g., to support small data center environments. It may not be efficient for every enclosure to have its own high-powered switch.

[0009] In some situations, it may be desirable to create a network fabric solution that allows a number of the above mentioned enclosures to be used in a logical group. In some configurations, this may be done by stacking switches, in these configurations, each enclosure may include its own switch, and the switches may be linked together to support inter-enclosure communication. Among other issues, these configurations may utilize more switches than is desirable or efficient, Each enclosure may include a switch that is capable of handling traffic for many more servers than can fit in the enclosure. This may lead to many ports of the switches being unused and wasted. Furthermore, if multiple high-powered switches are unnecessarily used, space, power and money may be unnecessarily expended. High powered switches are relatively large, expensive and power-hungry, and may experience higher latency than may a simpler circuit (e.g., a DEM as described below). Additionally, such switches may need to be managed (e.g., with management software or additional control chip).

[0010] It may be desirable to reduce the number of switches used when creating a logical group of enclosures. In some examples, the connectivity of a single switch (e.g., in one enclosure) may be "extended" such that servers in other enclosures can utilize the switch (e.g., use the switch's spare ports). In these examples, for an enclosure to utilize a switch that is external to the enclosure, the enclosure may include a Downlink Extension Module (DEM) that connects to a backplane of the enclosure and also connects to the switch via an external connection. The DEM provides a datapath between a NIC (network interface controller) of a server in the enclosure and the external switch. In these examples, the DEM may include two PHYs. The term PHY is used to refer to a circuit implementing the physical layer of the Open System Interconnection (OSI) seven-layer network model, e.g., a physical computer chip. In these twr-PHY examples, one PHY may communicate with the external switch via the external connection and the other PHY may communicate with the NIC via the backplane (backplane connection). The external connection may be via one or more copper or optical cables/connectors and the backplane connection may be via copper backplane traces/connectors. For the external connection and the backplane connection, two different interfacing technologies (or communication protocols) may be used. For example, for external connections over copper or optical cables, IEEE 802.3ba specifies Clause 86 (for 40GBASE-SR4) and Clause 85 (for 40GBASE-CR4). For backplane connections, IEEE 802.3ba specifies Clause 84 (for 40GBASE-KR4),

[0011] In the above mentioned two-PHY examples, the mixture of physical communication media in the datapath and the mixture of communication protocols pose a challenge. Various PHY devices that may be used in such a DEM support only auto-negotiation across one communication medium/protocol. Auto-negotiation is a communication procedure (e.g., an Ethernet procedure) by which two connected devices choose common transmission parameters, such as speed, duplex mode, and flow control. In this procedure, the connected devices first share their capabilities regarding these parameters and then choose the highest performance transmission mode they both support. In the two-PHY examples described above, the two PHYs (one that supports each type of communication media/protocol) must be connected in a back to back manner. This configuration does not support auto-negotiation across the entire datapath from NIC to switch. If communication is desired across the datapath (i.e., over both PHYs), manual configuration may be required, for example, management software or an additional control chip external to the DEM PHY may be needed to bridge the two PHYs. Additional management components and/or control chips to detect, setup., and ensure that the two different connections are established at the same speed, abilities, etc. adds complexity in hardware and software, raises reliability risks, and increases the cost of the solution.

[0012] The present disclosure describes auto-negotiation over an extended backplane. According to the present disclosure, a system may include an enclosure (e.g., a blade enclosure) and a switch external to the enclosure. The enclosure may include a NIC (network interface controller) for a server in the enclosure. The enclosure may include a DEM (downlink extension module) that provides a datapath between the NIC and the switch. The DEM has a single PHY (referred to as a DEM PHY) in the datapath. The DEM PHY is connected to the NIC via a backplane and also connected to the switch via an external connection. The DEM PHY facilitates auto-negotiation between the switch and the NIC by bridging a first communication protocol used over the backplane and a second communication protocol used over the external connection. The DEM PHY facilitates the auto-negotiation completely in-band, without the use of management software or any other control chip external to the DEM PHY, which would add complexity, timing variations and synchronization issues. According to the present disclosure, multiple enclosures may be connected to a single switch, thereby extending the functionality of the switch. Because DEMs are utilized in the enclosures instead of additional switches, this solution lowers costs, reduces power and reduces latency. This allows for improved scalability, better performance.

[0013] FIG. 1 is a block diagram of an example system 100 for auto-negotiation over extended backplane. System 100 may include a switch 102 and an enclosure 120 (e.g., a blade enclosure). System 100 may include any number of enclosures connected to switch 102; however, for ease of description, one enclosure will be described with reference to FIG. 1. Enclosure 120 may foe connected to switch 102 via an external connection (e.g., connection 132), for example, via one or more copper or optical cables. Each optical cable may have at least one optical connector on each end as well. Connection 132 may connect to the switch 102 on one end, and to a DEM (128) in the enclosure on the other end. Connection 132 may be various other types of communication media (e.g., wired or wireless) in other examples; however, for ease of description, the following examples will describe an external connection that is one or more copper or optical cables.

[0014] Switch 102 may provide network access to multiple components (e.g., to at least one server in enclosure 120 and perhaps to other servers in other enclosures). Switch 102 may include a switch ASIC (application-specific integrated circuit) 104 that performs the particular processing tasks of the switch 102, Switch 102 may include at least one switch PHY (e.g., 106). Each switch PHY may provide an interface between a port of the switch and the switch ASIC 104. In the particular example of FIG. 1, switch PHY 106 provides an interface between a port of switch 102 (the port being connected to enclosure 120) and switch ASIC 104. Switch PHY 106 may be a physical computer chip that includes electronic circuitry (i.e., hardware) that implements the functionality of the PHY. Switch PHY 106 may also include instructions (e.g., firmware) that, when executed by the circuitry of switch PHY 106, implements the functionality of the PHY. In some examples, switch PHY 106 may be included as part of switch ASIC 104 (e.g., a single circuit, chip, etc.) and in other examples, switch PHY 106 may be separate from ASIC 104.

[0015] Switch 102, may, in some examples, be included in an enclosure (e.g., separate from enclosure 120), as is explained in more detail below with regard to FIG. 2A. In other examples, switch 102 may be a top-of-rack (ToR) switch (e.g., as shown in FIG. 2B) or other standalone switch.

[0016] Enclosure 120 may house at feast one server that gains network access by ultimately connecting with switch 102. Enclosure 120 includes a NIC (network interface controller) of a server. In the example of FIG. 1, NIC 124 is shown attached to a computer board 122. Computer board 122 may also include the various components of the server, or computer board 122 may be a computer card of sorts that houses NIC 124 and then interfaces with a different computer board that includes the various components of the server. In any case, NIC 124 provides the server with network access. Enclosure 120 may include a backplane 126 that is essentially a computer bus that acts as a backbone to connect several computer components together. In some examples, a backplane (e.g., 126) may connect a NIC (e.g., 124) to a switch of the enclosure (e.g., 120). In the example of FIG. 1, however, enclosure 120 may not include Its own switch. In this example, backplane 128 connects NIC 124 to a OEM (downlink extension module) 128, which in turn, connects to an external switch (102). DEM 128 provides a datapath between NIC 124 (in enclosure 120) and the external switch 102. Thus, connection 132 is sometimes referred to as an "extended backplane." Via an extended backplane, functionality of a switch (e.g., 102) may be extended to servers in enclosures (e.g., 120) that are external to the switch.

[0017] DEM 128 includes a single PHY (DEM PHY 130) in the datapath between switch 102 and NIC 124, as opposed to the examples described above that use two PHYs in the DEM. OEM PHY 130 communicates with the external switch 102 via external connection 132. DEM PHY 130 also communicates with NIC 124 via backplane 126 (via backplane connection 127). Whereas external connection 132 may be via one or more copper or optical cables/connectors, backplane connection 127 may be via copper backplane traces/connectors. As described above, the externa! connection 132 and the backplane connection 127 may use different interfacing technologies (or communication protocols). For example, external connection 132 may abide by IEEE 802.3ba Clause 86 (for 40GBASE-SR4) or Clause 85 (for 40GBASE-CR4). Backplane connection 127 may abide by IEEE 802.3ba Clause 84 (for 40GBASE-KR4), for example. The single PHY (DEM PHY 130) may handle both of these different interfacing technologies (communication protocols). DEM PHY 130 may be capable of auto-negotiation with switch 102, and may also be capable of auto-negotiation with NIC 124, even though each of these connections may use a different communication protocol.

[0018] DEM PHY 130 may be a physical computer chip that includes electronic circuitry (i.e., hardware) that implements the functionality of the PHY, DEM PHY 130 may a!so include instructions (e.g... firmware) that, whan executed by the circuitry of OEM PHY 130, implements the functionality of the PHY. In some examples, DEM PHY 130 may be configured (e.g., via hardware design and/or firmware programming) to handle both the interface/connection to switch 102 and the interface/connection to NIC 124, even though both of these connections use different communication protocols. Specifically, DEM PHY may be configured to facilitate an end-to-end auto-negotiation scheme between switch 102 and NIC 124, and may be configured to bridge these two different interfaces/connections (i.e., external connection and backplane connection).

[0019] OEM PHY 130 may be configured to listen for and receive (over backplane connection 12?) auto-negotiation information (e.g., capabilities) from NIC 124. OEM PHY 130 may then "pass through" these capabilities and "advertise" them (over external connection 132) to switch 102 (e.g., specifically, to switch PHY 106), whereas some chips, when receiving auto-negotiation capabilities may attempt to interpret the capabilities and then complete the auto-negotiation process with the initiating component. Switch 102 (e.g., switch PHY 106, and then switch ASIC 104) may then receive the auto-negotiation capabilities of NIC 124 and may, in turn, send its auto-negotiation capabilities (e.g., the auto-negotiation capabilities of switch ASIC 104) back to OEM PHY 130. DEM PHY 130 may then complete the auto-negotiation process with NIC 124 and with switch 102. In order to carry out the above described process, OEM PHY 130 may need to maintain or remember the "state" of the auto-negotiation process for NIC 124 and switch 102, so that DEM PHY 130 can then complete the auto-negotiation process with each of these end points. More details of this auto-negotiation process performed over an extended backplane are provided below with regard to the description of method 300 of FIG. 3.

[0020] OEM PHY 130 may perform auto-negotiation over an extended backplane as just described, and may do so completely in band. ^* In band signaling refers to the sending of information within the same band or channel used for the main purpose of the channel. In this example, the "channel" may be the datapath between switch 102 and NIC 124. and the main purpose of this channel/datapath may be to pass networking information. DEM PHY 130 may perform auto-negotiation completely "in band" by using the same cabling, traces, etc. in the datapath that are used to pass networking information. OEM PHY 130 may perform auto-negotiation without the use of management software or any other control chip external to the OEM PHY or any other high layer software.

[0021] FIG. 2A is a block diagram of an example system 200 for auto-negotiation over extended backplane. System 200 includes a first enclosure 210 and a second enclosure 220, Enclosure 220 may be similar to enclosure 120 of FIG. 1, where like-named components and associated described behaviors are similar. Enclosure 210 may include a switch 202 that is similar to switch 102 of FIG. 1, where like-named components and associated described behaviors are similar. Enclosure 210 may also include a NIC 114 that is connected to switch 202 via a backplane 116 in a manner similar to how NIC 124 of FIG. 1 is connected to DEM 128 via backplane 126. In this example of FIG. 2A, switch 202 of enclosure 210 may "extended" to a server in enclosure (e.g., 220) in a manner similar to how the capabilities of switch 102 may be extended to servers in enclosure 120, as described above.

[0022] FIG. 2B is a block diagram of an example rack 250 capable of supporting auto-negotiation over extended backplane. Rack 250 includes at least one enclosure, for example, enclosure 320. Enclosure 320 may be similar to enclosure 120 of FIG. 1, where like-named components and associated described behaviors are similar. Rack 250 includes a ToR (top of rack) switch 302, which in many respects may be similar to switch 102 of FIG. 1, where like-named components and associated described behaviors are similar, ToR switch 302 may include at least one switch PHY (e.g., 306). Each switch PHY may be associated with a port of the ToR switch, e.g., where each port is connected to a DEM PHY (e.g., 330) associated with a NIC of a server (e.g., in enclosure 320 or another enclosure inside rack 250). In this example of FIG. 2B, ToR switch 302 may provide network access to servers in various enclosures of the rack 250. According to the solutions described herein, various DEM PHYs (e.g., 330) in rack 250 may allow for auto- negotiation over extended backplane such that various NICs (e.g., 324) may auto- negotiation with ToR switch 302 as is described in more detail herein.

[0023] FIG 3 Is a flowchart of an example method 300 for auto-negotiation over extended backplane. Method 300 may be described below as being executed or performed by a system, for example, system 100 of FIG. 1. Other suitable systems may be used as well. Method 300 may be implemented in the form of electronic circuitry (e.g., hardware). In some examples, method 300 may be implemented as a combination of electronic circuitry and executable instructions (e.g., firmware) executed by at least one processor of the system. In alternate embodiments of the present disclosure, one or more steps of method 300 may be executed substantially concurrently or in a different order than shown in FIG 3. In alternate embodiments of the present disclosure, method 300 may include more or less steps than are shown in FIG. 3. In some embodiments, one or more of the steps of method 300 may, at certain times, be ongoing and/or may repeat.

[0024] Method 300 may start at step 302 and continue to step 304, where a NIC (e.g., 124} for a server in an enclosure (e.g., 120) of the system may initiate auto- negotiation by sending its capabilities to a DEM (downlink extension module) PHY (e.g., 130) included in a DEM (e.g., 128) of the enclosure. The DEM PHY may be connected to the NIC via a backplane (e.g., 126, 127). The NIC may be configured to communicate according to a first communication protocol for a backplane connection (e.g., 10GBase-KR, 20GBase-KR2, 40GBase-KR4, etc.) and to perform auto-negotiation. At step 306, the DEM PHY may listen for and receive the auto- negotiation capabilities of the NIC; however, the DEM PHY may not at this time complete the auto- negotiation process with the NIC. At step 308, the DEM PHY may pass through and advertise the auto-negotiation capabilities of the NIC to a switch (e.g.. 102) external to the enclosure. More specifically, the auto-negotiation capabilities of the NIC may be sent to a switch PHY (e.g., 106) of the switch. The OEM PHY may be connected to the switch (i.e., the switch PHY) via an external connection (e.g., 132) that uses a second communication protocol.

[0025] At step 310, the switch PHY may listen for and receive the auto- negotiation capabilities of the NIC from the DEM PHY and may store these capabilities. At step 312. a switch ASIC (e.g., 104} of the switch may read the switch PHY to receive the NIC capabilities. At step 314, the switch ASIC (e.g., in response to receiving the NIC capabilities) may initiate auto-negotiation by sending its capabilities to the switch PHY. At step 316, the switch PHY may pass through and advertise the switch ASIC capabilities to the DEM PHY, At step 318, the DEM PHY may listen for and receive the auto-negotiation capabilities of the switch (e.g., of the switch ASIC). The DEM PHY now has (e.g., stored temporarily) the auto- negotiation capabilities of the NIC and of the switch (e.g., the switch ASIC). The DEM PHY also remembers the "state" of the auto-negotiation process for the NiC and the switch. At step 320, the DEM PHY may complete auto-negotiation with the NIC and with the switch to facilitate end-to-end auto-negotiation between the NIC and the switch. Completing auto-negotiation with the switch may include passing auto-negotiation data back to the switch PHY and in turn on to the switch ASIC. At this time, the end-to-end link between the switch (e.g., the switch ASIC) and the NIC is established. The switch has automatically adapted to the speed of the NIC (i.e., auto-negotiation) over the extended backplane as if the NIC were directly connected to the switch (e.g., over a standard backplane). Method 300 may eventually continue to step 322, where method 300 may stop.

[0026] FIG. 4 is a flowchart of an example method 400 for auto-negotiation over extended backplane. In some examples, method 400 may be executed or performed by a system, for example, system 100 of FIG. 1. In some examples, method 400 may be executed or performed by an enclosure, for example, enclosure 120 of FIG. 1. Other suitable systems or enclosures may be used as well. Method 400 may be implemented in the form of electronic circuitry (e.g., hardware), in some examples, method 400 may be implemented as a combination of electronic circuitry and executable instructions (e.g., firmware) executed by at least one processor of the system or enclosure. In alternate embodiments of the present disclosure, one or more steps of method 400 may be executed substantially concurrently or in a different order than shown in FIG. 4. In alternate embodiments of the present disclosure, method 400 may include more or less steps than are shown in FIG. 4 In some embodiments, one or more of the steps of method 400 may, at certain times, be ongoing and/or may repeat.

[0027] Method 400 may start at step 402 and continue to step 404, where a DEM PHY (e.g., 130) may listen for and receive auto-negotiation capabilities of a NIC (e.g., 124) for a server. The DEM PHY and the NIC may be included in an enclosure (e.g., 120) and connected to each other via a backplane (e.g., 126) that uses a first communication protocol. At step 406, the DEM PHY may pass through and advertise the auto-negotiation capabilities of the NIC to a switch (e.g., 102) external to the enclosure. The DEM PHY may be connected to the switch via an external connection (e.g., 132) that uses a second communication protocol. At step 408, the DEM PHY may listen for and receive auto-negotiation capabilities of the switch. At step 410, the DEM PHY may complete auto-negotiation with the NIC and with the switch to facilitate auto-negotiation between the NIC and the switch.