Line side multiplexers with protection switching

The present invention is directed to data communication systems and techniques thereof. In a specific embodiment, the present invention provides a network connector that includes an interface for connecting to a host. The interface includes a circuit for utilizing two data paths for the host. The circuit is configured to transform the host address to different addresses based on the data path being used. There are other embodiments as well.

CROSS-REFERENCES TO RELATED APPLICATIONS

NOT APPLICABLE

NOT APPLICABLE

NOT APPLICABLE

BACKGROUND OF THE INVENTION

The present invention is directed to data communication systems and techniques thereof.

Over the last few decades, the use of communication networks has exploded. In the early days of the Internet, popular applications were limited to emails, bulletin board, and mostly informational and text-based web page surfing, and the amount of data transferred was relatively small. Today, the Internet and mobile applications demand a huge amount of bandwidth for transferring photo, video, music, and other multimedia files. For example, a social network like Facebook processes than terabytes of data daily. With such high demands on data storage and data transfer, existing data communication systems need to be improved to address these needs.

For high-speed data communication applications, it is important to ensure system and link reliability. Over the past, various conventional techniques have been proposed and implemented, but unfortunately they have been inadequate. It is thus desirable to have new and improved systems and methods.

BRIEF SUMMARY OF THE INVENTION

The present invention is directed to data communication systems and techniques thereof. In a specific embodiment, the present invention provides a network connector that includes an interface for connecting to a host. The interface includes a circuit for utilizing two data paths for the host. The circuit is configured to transform the host address to different addresses based on the data path being used. There are other embodiments as well.

According to an embodiment, the present invention provides a network connector device, which includes a first connector coupled to a first switch. The device also includes a second connector coupled to a second switch. The device further includes a third connector coupled to a host. The third connector includes a communication chip. The host is associated with a host address. The communication chip includes a first data path section for connecting the first switch and the host. The communication chip also includes a second data path section for connecting the second switch to the host. The communication chip additionally includes a logic unit configured to assigning the host a first address associated with the first data path section and a second address associated with the second data path section.

According to another embodiment, the present invention provides a communication system. The system includes a first network switch. The system also includes a second network switch. The system additionally includes a host that is associated with a host address. The system also includes a connector connecting the host to the first network switch and the second network switch. The connector comprises a communication chip for interfacing with the host. The communication chip comprises a logic unit for modifying the host address. A first data path is formed between the first network switch and the host. A second data path is formed between the second network switch and the host. The logic unit is configured to transform the host address with a first address for data going to the first network switch. The logic unit is further configured to transform the host address with a second address for data going to the second network switch.

According to yet another embodiment, the present invention provides a network connector device. The device includes a first connector coupled to a first switch. The device also includes a second connector coupled to a second switch. The device further includes a third connector coupled to a host, which is associated with a host address. The third connector includes a first chip for connecting the first switch and the host through a first data path. The third connector also includes a chip for connecting the second switch to the host through a second data path. The third connector additionally includes a control module for connecting the first chip and the second chip.

It is to be appreciated that embodiments of the present invention provide many advantages over conventional techniques. Among other things, by integrating various components needed for redundant data paths in a network connector device, host devices without such redundancies can be allowed to work with different data paths through the connector device, which transform the host address as needed. Devices and methods of the present invention allows for high reliable fault tolerant network systems.

Embodiments of the present invention can be implemented in conjunction with existing systems and processes. For example, the network connectors according to embodiments of the present invention comply with existing communication standards and form factors, and can thus be implemented for a wide range of applications.

The present invention achieves these benefits and others in the context of known technology. However, a further understanding of the nature and advantages of the present invention may be realized by reference to the latter portions of the specification and attached drawings.

DETAILED DESCRIPTION OF THE INVENTION

The present invention is directed to data communication systems and techniques thereof. In a specific embodiment, the present invention provides a network connector that includes an interface for connecting to a host. The interface includes a circuit for utilizing two data paths for the host. The circuit is configured to transform the host address to different addresses based on the data path being used. There are other embodiments as well.

An important aspect of communication network is to maintain system reliability. One of the techniques is to provide redundant communication devices; when an in-use communication path is encountering network problems or failures, the communication system would switch from the problem communication path to an alternative communication path. There a few criteria to evaluate a redundant communication system. A first criterium is the seamlessness of the switching process; another is amount of redundant hardware required. It is to be appreciated that embodiments of the present invention provide both substantially seamless switching process and relatively small amount of redundant hardware. For example, a streamlined “dovetail” module—described in further details below—is configured with its host device to allows for efficient switching of a communication path. Among other features, a dovetail module according to embodiments of the present invention efficiently provided multiple redundant components that a conventional host may lack. For example, data path switching is described in U.S. Pat. No. 10,009,214, issued Jun. 26, 2018, which is commonly owned and incorporated by reference herein in its entirety.

FIG. 1is a simplified diagram illustrating illustration a communication system100according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Communication system100is implemented as a ring configuration. Host101and host104are connected to each other via top of rack (ToR) switches102and103. For example, a network connector (with Y-split configuration) is provide to connect host101to ToR12and ToR103: a QSFP connector interface is connected to host101, and two network connector interfaces are connected to ToR102and ToR103.

Communication system100is configured to operate in a normal operation mode and a degraded operation mode. In the normal operation mode, there is bi-directional traffic between Host A101and ToR switch102, and there is also bi-directional traffic between Host B104and ToR switch103. Additionally, ToR switch102sends IDLE signals to Host B104, and ToR switch103sends IDLE signals to Host A101. As shown inFIG. 1, Host A101includes a quad small form-factor pluggable (QSFP) port for connecting to ToR switch102, which allows for high bandwidth communication; similarly, Host B104includes QSFP port for high bandwidth connection to ToR switch103. Each of the host includes its own network interface card (NIC). For example, traffic from the NICs can be routed by dove tail modules described below. Degraded operation mode activates when there is a link failure. For example, when ToR switch102fails, host101and host104remain in service, and ToR switch103services traffic from both NIC105and NIC106.

During the mode switch process, hardware and software at the physical layer may be configured to couple the host with one of ToR switches on the line side. If the currently-coupled ToR switch (or the path to this ToR) fails or the path to the ToR is severed, the host may reconfigure the hardware/software at the physical layer, such that the host is now re-coupled with another ToR switch (the “spare”), thereby allowing it to resume normal operation. In various implementations, the mechanism does not take into consideration of upper layer protocol-level implications. As a result, while the host may bring up the link again (to a spare ToR switch) after the failure event, the connection is non-negligibly disrupted; a variety of upper-layer protocol handshakes may need to be re-performed before normal traffic can resume.

For various high-speed communication applications, there are various design parameters for the switch-over process (e.g., from normal operation mode to degraded mode, and vice versa). In operation, physical layer of the communication modules does not make switch-over decisions, and they follow upper layer commend.

FIG. 2Ais a simplified block diagram illustrating a communication device200according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. As shown inFIG. 2A, communication module201is coupled to communication module202via a microcontroller203that handles QSFP interface. Both communication modules include multiple network ports for connections, and support different communication modes, such as 4×25 (100G) mode. The redundancy of these module connections as shown inFIG. 2Aallows for switching to different modes in case of link problems. For example, communication module201and communication202are used for different data paths, and they each contain independently operable components for independent data path operations.

FIG. 2Bis a simplified diagram illustrating network connector250with built in a built-in communication circuit according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. In various embodiments, network connector250has a form factor resembling a network cable. Connector251is configured to connect to a host device and it conforms to the form factor of QSFP interface. Connectors252and253are configured to connect to network switches (e.g., ToR switches). For example, connector251is connected to connectors252and253via data cables. Connector251includes a communication circuit (e.g., communication device200) that is capable for transforming MAC IDs for the host device, thereby allowing the host device to switch to a different communication path to overcome link failures. For example, the connector251includes a dovetail module that is described below.

FIG. 3Ais a simplified block diagram illustrating a communication platform300with an external PLL according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Communication platform300includes a primary communication device302and a secondary communication device301, and each is associated with its respective communication path. FIFOs303and304provide buffers for data communication. For example, separate data paths may be associated with different clock signals, and upon a failover event, PLL308tracks the correct clock signal that is to be used for the operating data path. PLL308provide clock signal generation based on data streams from communication devices301and302. For example, communication path associated with communication device301includes buffer FIFO303and a signal path to external PLL308; communication path associated with communication device302includes buffer FIFO304and a signal path to external PLL308. The external PLL308ensures that the HTX output frequency is matched to the frequency of the communication path that is in used (e.g., for data stream coming from a ToR). In various embodiments, communication devices200inFIG. 2are used to implemented blocks301and302. The two communication paths provide redundancy, and when one of the communication paths fails, communication is switched to the other communication path. Data MUX305selects between the two data streams, and the selected data stream is provided to HTX connector306.

FIG. 3Bis a simplified block diagram illustrating a communication platform350with a clock crossbar according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Communication platform350selects between data two communication paths: a first path with communication device354and FIFO352, a second path with communication device353and FIFO351. The two communication paths provide redundancy: when the first data path fails, the data communication switches to the second data path, and vice versa. InFIG. 3B, instead of using an external PLL (as used inFIG. 3A) for clock signal, an on-chip PLL357is used and receives the data stream selected by MUX358. The clock selection mechanism provided by mux358is used to ensure that the HTX output frequency is matched to the frequency of the communication path that is in used (e.g., for data stream coming from a ToR). Data MUX355selects between the two data streams, and the selected data stream is provided to HTX connector356.

FIG. 4is a simplified diagram illustrating a communication system400according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Communication system400are shown with two hosts410and420for illustrative purpose. But for the purpose of describing switching data path, the text focuses on host410, which can be configured with two data paths and two MAC IDs, depending the mode of operation. The first data path and the second data path are configured as redundant data path, and each includes its own components. As illustrated earlier, the redundancy configuration includes a mechanism for selecting the correct clock signal corresponding to the respective data path. Additionally, since the host for each data path has its own media access control (MAC) ID, for redundant data paths to be viewed and used as a single data path in operation, a mechanism for manipulating the MAC ID for operating host is needed. That is, switching from one data path to another (e.g., due to link failure or other problems) involves the host to assume the MAC ID along the newly selected data path. Each of the data paths inFIG. 4includes a connection between a host and a switch. For example, host410is connected to switch430via a network connector that includes dovetail module411; host420is connected to switch440via a network connector that includes dovetail module421. In various embodiments, network connector250illustrated inFIG. 2Bare used to provide connections between hosts and switches.

Dovetail modules411and421, which are respectively configured as parts of the host410and host421, include logic units for transforming MAC IDs of their hosts. From the switch side, there are two sets of physical medium dependent (PMD) sublayers for each data path, and when they interface with hosts410and420through dovetail modules411and412, they see different MAC IDs depending on the configuration (e.g., each host may have two distinct MAC IDs provided by the corresponding dovetail module). For example, PMD431and PMD433both interface with dovetail module411. As indicated inFIG. 4, a distinct MAC ID is used for communication along each data path. During the data path switching process, each data path use the same MAC IDs they have used before.

As an example, host410would show up on ToR #1 (not shown) with MAC ID 0xAAAA, and show up on ToR #2 (also not shown) with MAC ID 0xBBBB. Host420is independent of host410, and host420would should up with MAC ID 0xCCCC and 0xDDDD respectively at ToR #1 and ToR #2. The MAC ID transformation process is setup from the beginning. There is no change in the MAC ID transformation mechanism before/after the switch over. Before the switch over, ToR #2 thinks that host410has MAC ID 0xBBBB (but host410is sending IDLEs to ToR #2). This does not change after the switch over, except that ToR #2 starts seeing traffic from host410now.

Without the MAC ID transformation function provided by the dovetail modules411and421, the stack in blocks432and433would have seen the same MAC ID. This may be unexpected in a regular point-to-point connected network, since it would appear that the same MAC ID is reachable via two distinct paths. Instead, when dovetail modules transforms the MAC ID on the spare path, it gives the appearance that each of blocks432and433is connected to a distinct MAC (or NIC), even the cost of redundancy is only one copy of NIC in the host. As such, various existing redundancy mechanisms in the upper layers (which rely on having redundant NICs on the host) can continue to be effective with little to no modifications.

As shown, PMD433and PMD434both interface with dovetail module421, and they see distinct MAC IDs. More specifically, dovetail modules replace the source MAC ID of each outgoing ethernet frame with a programmable value. This allows the host MAC to take on two distinct identities (e.g., PMD432and PMD434distinct IDs when connected to the same host420via dovetail module421), such that each ToR switch thinks it is coupled to a distinct MAC. Each egress path independently has its own MAC ID replacement logic.

It is to be appreciated that the dovetail modules411and421provide the MAC ID transformation mechanism of MAC IDs for host devices, which may not have such capability (e.g., legacy host systems). For example, without dovetail module411, a conventional host410would need two sets of layer components (PMD, FEC, PCS, and MAC), each sets of the physical layer components having their own MAC IDs. InFIG. 4, Host410is configured with only a single set of these physical layer components, and it has distinct MAC IDs generated by dovetail module411as shown. Host410by itself is not capable of switching data path, but the dovetail module411enables host410to switch data path (e.g., in a link failure event) manipulating MAC Ids of the data path. For example, host410commands dovetail module511to connect its traffic with the spare ToR (and to fill the path to the failed ToR with IDLEs). For example, referring toFIG. 3A, the process of switching data path involves MUX305and MUX308both point to the spare data path (in the LINE to HOST direction).

In an example, example, a host may be coupled to two ToR switches (e.g., ToR #1 and ToR #2) via a dovetail module, and the two ToR switch would see two different MAC IDs coming from the same host, even though the host actually has only one MAC ID. For example, when the host is configured to conduct its normal operations using ToR #1, the spare ToR #2 may be already link-up.

From the perspective of the spare ToR #2, it was already fully “linked up” with the host, who “happens” to only be sending IDLEs to the ToR #2. Then, when the fail over happens, the ToR #2 merely starts seeing frames coming from the host, there is no need to re-link-up, no need to reestablish any upper layer handshakes. From the perspective of the spare ToR #2, it was already fully “linked up” with the host, which “happens” to only be sending IDLEs to the ToR #2. Then, when the failover happens, the ToR #2 merely starts seeing frames coming from the host, and there is no need to re-link-up, nor the need to reestablish any upper layer handshakes.

It is to be noted that ingress and egress (from the standpoint of hosts) data transmission involves different manipulation of MAC IDs by the dovetail modules. When a host transmits data (i.e., egress) via a dovetail module, the host MAC ID is replaced by a different MAC ID configured by the dovetail module; when the host receives data (i.e., ingress) via the dovetail module, the dovetail module changes the destination MAC ID to the actual host MAC ID so the host can receive the incoming data.

FIG. 5is a simplified diagram illustrating a host device500according to embodiments of the present invention. This diagram is merely an example, which should not unduly limit the scope of the claims. One of ordinary skill in the art would recognize many variations, alternatives, and modifications. Host510interfaces with dovetail module502as shown. Dovetail module502includes redundant components (e.g., PMD, FEC, PCS and other blocks) that host510lacks, and these redundant components allow host510to connect to different data paths (e.g., switching to a data path due to detected data path failure) with distinct MAC IDs. For example, dovetail module502can be implemented with communication device200or network connector250.

The communication between host510and dovetail module502includes both egress path section503and ingress path section504(e.g., both egress and ingress defined from the perspective of host510). Egress path section and ingress path section are configured differently, as different processes are performed. Processing egress data from host510involves transforming host MAC IDs to different MAC IDs to the data based on the destination; processing ingress data to be received by host501involves transforming different MAC IDs to the host MAC ID. Egress path section503includes logic block501, as shown, which include both ingress lock “igr xf” and egress logic “egr xf” for transforming MAC IDs for host510. Egress path section503additional includes IDLE generator blocks (e.g., “idlegen506”).

The ingress path section504—a part of the ingress data path—includes logic block507. Logic block507includes ingress lock “igr xf” and egress logic “egr xf” for transforming MAC IDs for host510. The ingress path section504also includes HMUX block505. The HMUX block505is quasi-statistically selectable, and a part of the ingress data path.

It is to be noted that while there is only a single host510, which has a single egress data path and a single ingress data path, dovetail module502includes two sets of egress data paths and two sets of ingress data paths, which are associated with different MAC IDs, depending on the implementation and operation mode.

The dovetail module502may include a “white list”, which specifies which ethernet frames to forward from the host510to ToR switches. For example, for the HOST to LINE direction, the “white list” mechanism ensures that each ToR sees only the frames meant for that path. As explained above, logic blocks are configured to transform MAC IDs for host510. In various embodiments, logic units inspect the destination MAC ID of each ethernet frame going through its path, and discards frames that are destined for a MAC ID which is not specified on its white list. For example, each egress path has its own independent white list, which enables the host510to control which frames are to be seen by which ToR switches. Section501comprises source MAC ID transformation logics that transforms source MAC ID of each outgoing ethernet frame with a programmable value. This allows the host510MAC to take on two distinct identities (provided by the dovetail module502), such that each ToR thinks it is coupled to distinct MACs, depending on the operation mode. Each egress path independently has its own MAC ID transformation logic. Thus, while host510only has a single set of components and a single MAC ID, it can still operate with two data paths with two MAC IDs afforded by the dovetail module502. It is to be appreciated that operation of dovetail module502minimizes of the impact of switching data paths (e.g., in a link failure event) to a communication system, as the MAC IDs manipulation and data path switching are configured to be “invisible” to upper layer protocols.

The ingress data path involves different transformation of MAC IDs. When a ToR sends frames back to the host510, the ToR would use the transformed (i.e., perform by dovetail module502in the process described above) MAC ID as the destination MAC ID in the frame that it sends to host510. In various implementations, a corresponding reverse-transformation of the destination MAC IDs is implemented on the ingress path so that when the incoming frame reaches host510, the host MAC properly sees its real mac ID in the destination MAC ID field of the incoming frames.

The switch of data path can be initiated in various scenarios (e.g., failover event, link interruption, link slow down, etc.). As example, Table 1 below processes performed (by communication devices described above) upon a failover event:

It is to be appreciated that the processes outlined in Table 1 can be modified in various ways, depending on the implementation.