Method and apparatus for a Gigabit Ethernet MAC (GMAC)

[0002] This application claims the benefit of U.S. Provisional Application No. 60/063,970 filed on Oct. 31, 1997.

[0003] Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.

[0004] 1. Field of the Invention

[0005] The invention relates generally to the field of computer networking devices. More particularly, the invention relates to a Gigabit media access controller (GMAC) having support for redundant physical links.

[0006] 2. Background Information

[0007] With Local Area Network (LAN) switches now operating at data transfer rates of up to 1 Gigabit per second (Gbps), switch-over from a failed physical link to another physical link is of critical importance.

[0008] As used herein, the terms Ethernet, Fast Ethernet, and Gigabit Ethernet shall apply to Local Area Networks (LANs) employing Carrier Sense, Multiple Access with Collision Detection (CSMA/CD) as the medium access method, generally operating at a signaling rate of 10 Megabits per second (Mbps), 100 Mbps, and 1,000 Mbps, respectively over various media types and transmitting Ethernet formatted or Institute of Electrical and Electronic Engineers (IEEE) standard 802.3 formatted data packets.

[0009] In the prior art there are methods and systems which support redundancy of signals, however, the switch-over from the failed data stream to the redundant data stream in the prior methods and systems tend to have a long latency.

[0010] In one prior art switch system two media access controllers (MACs) are used to create a redundancy of signals between the switch and the respective source and/or destination port. FIG. 1 illustrates a switch 150 that uses two MACs 160 & 165 to create redundant links between the switch 150 and at least one of input/output (I/O) devices 101-104. One of the MACs 160 & 165 is the primary MAC and the other is the redundant (or backup) MAC. Both MACs 160 & 165 set up links to the desired source and/or destination port, here one of the I/O devices 101-104. For the sake of an example, MAC 160 sets up a primary link to I/O device 102 and MAC 165 sets up the redundant link to the same I/O device 102. While MAC 160 communicates with I/O device 102 along the primary link, the redundant link remains idle with no communication between MAC 165 and I/O device 102.

[0011] However, when a link failure or interrupt occurs along the primary link, the system must switch over to the redundant (or backup) link. For the purposes of the example given above, this means that the system must shut down (or set to idle) the primary link between primary MAC 160 and I/O device 102 and switch over to the redundant link between the redundant MAC 165 and I/O device 102. This “switch-over” is sometimes done using a software algorithm, for example Spanning Tree Protocol, which takes a long time, i.e. a few to several seconds, to switch from the broken or interrupted link to the redundant or backup link. On a high-speed link, such as a Gigabit Ethernet, a few to several seconds may equate to a large amount of traffic lost at the core of the enterprise network.

[0012] Thus, what is needed is a method and system for supporting redundant links with fast switch-over times.

[0013] A method and apparatus for a media access controller supporting redundant links are described. According to one aspect of the present invention a media access controller includes a two transceivers for communication with an source and/or destination port. Each transceiver has a receiver and transmitter. When the media access controller sets up a physical link to the desired source and/or destination port each transceiver sets up a separate physical link to the source and/or destination port. One of the physical links is the primary physical link and the other is a redundant or backup physical link. By using two physical links if a failure of interrupt occurs on the primary physical link then a switch-over is performed to use the redundant physical link.

[0014] Additional features and benefits of the present invention will become apparent from the detailed description, figures, and claims set forth below.

[0015] The present invention is illustrated by way of example and not limitation in the accompanying figures in which:

[0016] FIG. 1 illustrates a block diagram of a switch using multiple media access controllers to create redundant links.

[0017] FIG. 2 illustrates an embodiment of a switch according to the teachings of the present invention.

[0018] FIG. 3 illustrates a block diagram of a media access controller according to one embodiment of the present invention.

[0019] FIG. 4 illustrates a flow diagram for the creation of redundant links according to one embodiment of the present invention.

[0020] A Method and Apparatus for a Gigabit Ethernet MAC (GMAC) is disclosed. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[0021] The present invention includes various steps, which will be described below. The steps of the present invention may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware and software. Importantly, while embodiments of the present invention will be described with reference to a switch for an Ethernet network, the method and apparatus described herein are equally applicable to other types of switches and networks.

[0022] An Exemplary Switching Device Architecture

[0023] An overview of the architecture of a network device, e.g., switching device 200, in which an embodiment of the present invention may be implemented is illustrated by FIG. 2. According to the embodiment depicted, switching device 200 is an output buffered, shared memory switch.

[0024] Starting at a high level, switching device 200 includes a plurality of input/output (I/O) interfaces 210, e.g., I/O slots, coupled in communication with a switch core. The switch core comprises a switch fabric 250 and a fabric interface 275. Also coupled to the switch core via interface 285 is a central processing unit (CPU) 290 which may facilitate management of forwarding and filtering databases of the I/O interfaces 210.

[0025] Packets enter the switching device 200 via one of the plurality of I/O interfaces 210. The inbound packet data is provided by the I/O interface 210 to the fabric interface 275 which steers the data through the switch fabric 250. When the packet data exits the switch fabric 250 it passes again through fabric interface 275 and ultimately to one or more I/O interfaces 210 from which the packet data is to be transmitted.

[0026] The I/O interfaces 210 are coupled to the switch core through a bus interface 235 (also referred to as the “switch tap”, or “tap bus”). The switch tap 235 moves packet data between the fabric interface 275 and the I/O interface 210. While for convenience, only one I/O interface 210 has been depicted, it should be appreciated the tap bus 235 may comprise a plurality of point-to-point buses coupling each I/O interface 210 to the fabric interface 275. The fabric interface 275 may be thought of conceptually as a large multiplexer (MUX)/demultiplexer (demux) with storage.

[0027] The fabric interface 275 muxes the tap buses 235 into a bus 276 coupled to the switch fabric 250. Forwarding control bits from the packet data are also presented by the fabric interface 275 to the switch fabric 250 to facilitate cell queuing. The switch fabric 250 includes a switch memory 255 and a switch processor (SWIP) 260. The SWIP 260 logically organizes the packet data read into the switch memory 255 by associating the packet data with one of a plurality of output queues. Additionally, the SWIP 260 controls the flow of data between the fabric interface 275 and the switch memory 255 and the flow of data between the fabric interface 275 and the I/O interfaces 210.

[0028] Referring again to the I/O interfaces 210, each may include one or more Port Interface Devices (PIDs), such as a Quad-port Interface Device (QUID) 220 or a Gigabit Interface Device (GID) not shown. The I/O interfaces 210 may each additionally include one or more Media Access Controllers (MACs) 225, Address Resolution Units (ARUs) 230, and memories 215. In one embodiment, one or more of the MACs 225 include 84C301 Seeq Quad 10/100 MAC devices which may support up to four 10/100 Megabit per second (Mbps) ports (not shown). While, for the sake of explanation, (CSMA/CD) is assumed to be the medium access method employed by the MACs 225, it is appreciated that the MACs 225 may operate according to other communication protocols, such as the well-known Fiber Distributed Data Interface (FDDI) or Asynchronous Transfer Mode (ATM) communication protocols. In one embodiment of the switching device 200, MAC 225 supports redundant physical links between the switching device and the I/O devices with which switching device 200 communicates. An embodiment of the MAC with support for redundant physical links will be described in more detail below.

[0029] In the embodiment of the switching device 200 illustrated in FIG. 2, packets are forwarded among QUIDs 220 through the switch core in the form of fixed-length cells. The QUID 220 fragments inbound packets (i.e., those received from the MAC 225) prior to providing them to the fabric interface 275 and performs reassembly upon outbound cells (i.e., those received from the fabric interface 275). As packets are read from the MAC 225, forwarding control information necessary for steering the packet through the switch fabric 250 to the QUID 220 at which the packet will exit (e.g., the egress PID) may be prepended and/or appended to packets and/or the associated fixed-length cells by the ingress PID (e.g., the QUID 220 upon which a particular packet is received). The forwarding control information may also include information indicating the need for certain other packet/cell processing. For instance, a multicast flag may be provided in the cell header to cause the egress PID to replace the source MAC address for IP Multicast routed packets.

[0030] The ingress PID interfaces with its associated ARU 230 to acquire the forwarding control information associated with a packet. As the QUID 220 performs packet fragmentation, an address look-up request, which contains the destination Network layer address to which the packet is addressed (e.g., the destination Internet Protocol (IP) address), may be sent to the ARU 230. Upon completion of the address look-up, the ARU 230 returns the forwarding control information associated with the packet. Typically, the ARU 230 processes address look-up requests in the order received. The ARU processing may include performing Layer 2, e.g., Media Access Control (MAC) layer, or Layer 3, e.g., Network layer, address look-up to determine the forwarding control information such as, the destination address (e.g., a multicast address or egress PID and egress port identifier pair). The forwarding control information may then be inserted into packet and/or cell headers or trailers before the cells are provided to the fabric interface 275.

[0031] The fabric interface 275 comprises a plurality of fabric access devices (FADs) 280. Cells may be exchanged between the QUIDs 220 and the FADs 280 by handshaking with the SWIP 260. Each FAD 280 muxes the tap buses 235 coupled to the PIDs 210 into the bus 276 coupled to the switch memory 255. Each FAD 280 may buffer a plurality of cells in either direction (e.g., transmit or receive). Additionally, FADs 280 include two separate and independent paths, e.g., data path 276 and control path 265, the former conveying cell data as a whole to the switch memory 255 and the latter providing to the SWIP 260 a subset of the data associated with a cell, such as the forwarding control information.

[0032] The switch fabric 250, in one embodiment the switch memory 255 is implemented with a 64 K×256 pipelined synchronous static random access memory (SRAM). However, it is appreciated that various other types of random access memory (RAM) may be employed to provide for the temporary storage of cells received from the fabric interface 275. Above, it was mentioned that the SWIP 260 controls the movement of cells between the fabric interface 275 and the QUIDs 220 and manages the storage and retrieval of data to and from the switch memory 255. Many different handshaking mechanisms are available for coordinating the exchange of cells between the QUIDs 220 and the FADs 280 and between the FADs 280 and the switch memory 255. For instance, the SWIP 260 may present read and write ready signals and receive read and write enable signals to control the flow of cells. Various alternative approaches will no doubt be recognized by those of ordinary skill in the art.

[0033] It is appreciated that each of the functional units described above may be implemented with hard wired circuitry, Application Specific Integrated Circuits (ASICs), by causing a processor to execute instructions, or a combination thereof. Importantly, the present invention is not limited to a particular implementation of these functional units.

[0034] MAC With Support for Redundant Physical Links

[0035] FIG. 3 illustrates a block diagram of a media access controller 300 according to one embodiment of the present invention. Media access controller (MAC) 300 provides media access between a port interface device (PID) (e.g., a QUID as illustrated in FIG. 2, or a GID, not shown) and input/output (I/O) devices. In one embodiment, MAC 300 interfaces to the PID via a two 16 bit bus interfaces, one for transmit and one for receive. Referring to FIG. 3, these bus interfaces are referred to as RXOUT 350 and TXIN 370. MAC 300 also includes a 16 bit CPU interface (UPIF) 360 which provides interrupts for selectable status events.

[0036] Additionally, MAC 300 provides support for two separate physical transceivers, which will be referred to as Transceiver-A and Transceiver-B (not illustrated). One of the transceivers of MAC 300 is selected as the primary or in-use transceiver for setting up the primary physical link with a source and/or destination port (an I/O device) and the other transceiver serves as a redundant or backup transceiver setting up a separate redundant or backup physical link with the same I/O device. Each Transceiver includes a receiver and a transmitter. For example as illustrated in FIG. 3, Transceiver-A includes a receiver labeled RXIN-A 310 and a transmitter labeled TXOUT-A 315 and Transceiver-B includes a receiver labeled RXIN-B 320 and a transmitter labeled TXOUT-B 325.

[0037] In one embodiment, MAC 300 does not provide first-in/first-out (FIFO) functions to the PID (i.e., the GID or QUID) for the sake of adjusting an arbitrary PID-to-MAC clock rate required by the Ethernet network. Instead in this embodiment the clock domains are setup such that the MAC is a straight flow-through device, with the FIFO functions most typically thought of as being part of the MAC, being performed by the PID itself. This is due in large part to the setup of the clock domains for the MAC.

[0038] In one embodiment, MAC 300 contains four clock domains. Two of the clock domains RXACLK 311 and RXBCLK 316 are set up at each of the receivers RXIN-A and RXIN-B, respectively. For example, each of the receivers may extract a 62.5 MHz clock from the receive data that the transceiver is accepting. Another clock domain, TXCLK 371, is set up at the transmit input (TXIN) 370 which accepts packet data from the PID. For example, TXIN370 may be driven by a TXCLK 371 which is an external 62.5 MHz clock. The last clock domain drives the remainder of the MAC from an external clock CLKIN 380. For example, CLKIN 380 may be an external 125 MHz clock. CLKIN 380 is used to clock the transmit data out to the external devices (e.g., via RXCLK 351, CLKOUT 390, TXACLK 321, and TXBCLK 326) and to create an internal clock which runs the rest of the MAC logic.

[0039] Redundancy of Physical Links

[0040] In order to create redundant physical links, each of the receivers, RXIN-A 310 and RXIN-B 320 of MAC 300 syncs itself to a transmitter on the other end of the line at the desired I/O device. Each receiver then captures data from the line and then runs an auto-negotiation process to bring the physical link up into a normal data transfer state. During the auto-negotiation process RXIN manages the transmit side of the process by controlling TXOUT. In other words, RXIN-A 310 controls TXOUT-A 315 and RXIN-B 320 controls TXOUT-B 325. RXIN also captures the configuration of the I/O device and relays this information to the CPU status registers.

[0041] Additionally, RXIN detects error events in the receiver operation and signals these to the CPU status logic so that they may be captured and interrupts generated if desired to solicit the inspection of the event by the CPU. This may be used, for example, to signal the CPU that the primary link has failed, when an I/O device has come up or gone down, or when the I/O device has decided to switch the communication stream from the primary link to the redundant link without a prompt from the MAC to do so.

[0042] In one embodiment, RXIN-A 310 and RXIN-B 320 implement Gigabit Ethernet 802.3z Draft 3.2 compliant receivers and include: a stage to widen the data path from byte wide to 16-bits wide, two 8B10B decoders, a synchronization state machine, a receive state machine, and an auto-negotiation state machine. RXIN-A 310 and RXIN-B 320 may also include an LED to reflect the state of its receiver.

[0043] Once the RXIN-A 310 and RXIN-B 320 have accepted data or packets from the I/O device, RXIN-A 310 and RXIN-B 320 then send the packets on to RX-FIFO 330. RX-FIFO 330 accepts two 16-bit wide data paths, one from each RXIN-A 310 and RXIN-B 320, respectively. Within RX-FIFO 330, each data path is run through an independent FIFO in order to adjust for small differences in frequency and phase between the RXIN clock domain and the internal clock domain created by CLKIN 380. The outputs of each of the independent FIFOs are collected by a multiplexer (mux), also contained within the RX-FIFO 330, which passes data packets from the primary physical link through while discarding any data from the redundant physical link.

[0044] During the next stage of the RX-FIFO 330, the data stream from the primary physical link is passed through another FIFO, for example a 72-byte FIFO, in order to filter out any runt packets. If enabled, one embodiment of the RX-FIFO 330 will automatically detect, remove from the data stream, and act upon IEEE flow control packets. RX-FIFO 330 may also detect oversized packets (>1535 bytes) and tag these as “bad” during output to the next stage. Additionally, RX-FIFO 330 performs a byte count on each packet received and drives stat counters to collect statistics on the received packets.

[0045] The last stage of the receive path for MAC 300 is RXOUT 350. RXOUT 350 accepts packets from RX-FIFO 330, generates an Ethernet Cyclic Redundancy Check (CRC) for the packet, and passes the packet on to the PID. RXOUT 350 acts as a master on the receive data interface to the PID. RXOUT 350 drives a clock, RXCLK 351, out along with the 16-bit data path to the GID. An Rx_DataValid signal driven by RXOUT 350 frames the packet data and an Rx_EOP signals the last word of the packet data. RXOUT 350 also sets an Rx_ByteValid signal if both bytes of the last word are valid. RXOUT 350 raises an Rx_Err output signal during the last word transferred to the PID if the packet is errored, for example, if the CRC generated by RXOUT 350 fails to check against the CRC received with the packet then the Rx_Err output signal is raised.

[0046] The first stage of the transmit path for MAC 300 is TXIN 370. TXIN 370 acts as a slave on the transmit data interface from the PID. TXIN 370 accepts packets from the PID, filters out runts, adds a CRC when asked, and checks the CRC when not asked to add one. In order to accomplish runt filtering TXIN 370 passes the packets received from the PID through an FIFO, for example a 76-byte FIFO, and flushes any packets which fall below the acceptable minimum size for that particular MAC. TXIN 370 also accepts a clock, TXCLK 371, from the PID along with the 16-bit data path. A Tx_WrEn_L signal driven by the PID frames the packet data. A Tx_EOP input to TXIN 370 signals the last word of the packet data at which time Tx_ByteValid signals TXIN 370 if both bytes of the last word are valid and Tx_CRC_L instructs TXIN 370 as to whether or not it should append its computed CRC to the end of the packet. Additionally, TXIN 370 performs a byte count on each packet received and drives stat counters to collect statistics on the transmitted packets.

[0047] TXIN 370 then passes the packet on to FIFO 340. FIFO 340 is used to cross from the TXIN 370 clock domain to the internal clock domain which drives the final transmit stage. FIFO 340, for example may be an 8×18 FIFO.

[0048] FIFO 340 passes the packet data on to TXOUT-A 315 and TXOUT-B 325 which is the last stage of the transmit path for MAC 300. The TXOUT selected as the primary transmitter accepts packets from FIFO 340, establishes a primary link with the I/O device, and transmits the packets to the selected I/O device. The TXOUT selected as the redundant transmitter establishes a redundant or backup link with the same I/O device and dormantly sends idle signals to the I/O device. Primary TXOUT adds the appropriate preamble, start of frame, and end of frame delimiters to the packet data. During auto-negotiation TXOUT sends the proper configuration control symbols under the direction of it's respective RXIN. TXOUT transmits the configuration register as passed over to it from UPIF 360 via TXOUT's respective RXIN.

[0049] The final stage of TXOUT is passing the packets through a pair of 8B10B encoders that encode the packets. The encoded data packet which is a 20-bit data path is then clocked into a single 10-bit output register using the internal clock generated by CLKIN 380. In order to control the phase relationships between the clock and the data sent to the I/O device, the TXOUT sends both the data and the clock signal, TXACLK 321 or TXBCLK 326 depending upon which TXOUT is the primary physical link, to the I/O device.

[0050] It should be noted that in one embodiment, neither TXOUT-A 315, TXOUT-B 325, nor any other stage of the transmit path of MAC 300 does anything to guarantee that the minimum interpacket gap time of the particular network is observed. In such an embodiment it is the responsibility of the PID itself to ensure that the interpacket gap time is being observed when the PID transmits the packet to the MAC. Additionally, it should be noted that TXOUT-A 315 and TXOUT-B 325 may also include an LED to reflect the state of the transmitter.

[0051] Creation and Switch-Over of Redundant Physical Links

[0052] FIG. 4 illustrates a flow diagram for the creation and switch-over of redundant links according to one embodiment of the present invention. For the sake of simplicity, the following discussion presupposes the determination that Transceiver-A is the primary transceiver and that Transceiver-B is the redundant or backup transceiver. One with ordinary skill in the art would understand that either transceiver could be selected as the primary or redundant transceiver and that the transceiver selected as the primary transceiver at one time may be selected as the redundant transceiver at another time.

[0053] At step 410, Transceiver-A sets up the primary physical link with the selected I/O device and at step 420, Transceiver-B sets up the redundant physical link with the same I/O device. It should be noted that steps 410 and 420 may be performed at the same time or in the reverse order to which they are depicted in FIG. 4.

[0054] At step 430 the primary physical link is set to on-line status and the redundant physical link is set to off-line status. It should be noted that on-line and off-line is the configuration of the physical link and that communication is still occurring across the physical link. For example, on the receive end of MAC 300, RXIN-A is the primary link, has an on-line status, and is receiving data from the I/O device and RXIN-B is the redundant link, has an off-line status, but is receiving redundant data from the I/O device. Also for example, on the transmit end of MAC 300, TXOUT-A is the primary link, has an on-line status, and is transmitting data to the I/O device, however, TXOUT-B is the redundant link, has an off-line status, and although is not transmitting packet data from the PID, it is transmitting idle code to the I/O device. The data is received and/or transmitted during step 440.

[0055] During data reception and/or transmission if a link failure or an interrupt, such as a configuration change from the I/O device, occurs the MAC must switch from the primary physical link to the redundant physical link (step 450). For switch-over to occur the MAC must set the primary physical link to off-line status and the redundant physical link to on-line status. After switch-over occurs, the data is then received and/or transmitted over the redundant physical link, step 460. For example, on the receive end of MAC 300, RXIN-A is still the primary link but would now have an off-line status after switch-over, and is receiving data from the I/O device and RXIN-B is still the redundant link but would now have an on-line status after switch-over, and is receiving data from the I/O device. Also for example, on the transmit end of MAC 300, TXOUT-A is still the primary link, but would now have an off-line status after switch-over, and is transmitting idle code to the I/O device, and TXOUT-B would still be the redundant link but would now have an on-line status, and would be transmitting packet data from the PID to the I/O device.

[0056] Using a single MAC with two transceivers enables a switch system that supports redundant physical links. Such a system is advantageous because the time necessary to switch from one transceiver to another transceiver within the same MAC is much faster than the prior art method of using two MACs to set up redundant physical links and switching from one MAC to the other MAC. Additionally, by using a single MAC with support for redundant physical links the switch bandwidth is not wasted on maintaining the idle link. This results in a lower system cost because the switch bandwidth and physical channels connecting to a port do not have to be duplicated.

[0057] Thus, a method and apparatus for a gigabit ethernet MAC (GMAC) has been described. Although specific embodiments, including specific equipment, and methods have been described, various modifications to the disclosed embodiments will be apparent to one of ordinary skill in the art upon reading this disclosure. Therefore, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention and that this invention is not limited to the specific embodiments shown and described.