Method and system for routing network information

1. Field of the Invention

The present invention relates to networks, and more particularly, to routing and address translation in Fibre Channel networks.

2. Background of the Invention

Fibre Channel is a set of American National Standard Institute (ANSI) standards, which provide a serial transmission protocol for storage and network protocols such as HIPPI, SCSI, IP, ATM and others. Fibre Channel provides an input/output interface to meet the requirements of both channel and network users.

Fibre Channel standards are now being extended for use with expanded Fabrics and in storage virtualization. Storage virtualization defines virtual storage units for end-users and maps virtual storage units to actual physical storage locations.

Conventional Fibre Channel switches fail to provide a system and method that can efficiently support such expanded functionality and accommodate various addressing schemes that are required to enable a switch to function properly in Inter-Fabric and virtual Fabric routing.

Therefore, there is a need for a method and system for handling address translation for a Fibre Channel switch that may operate in different environments, for example, multiple Fabrics, virtual Fabrics and storage virtualization.

In one aspect of the present invention, a method for processing frames in a Fibre Channel network is provided. The method includes receiving a frame at a receive port; determining if a translation cache is enabled; determining if there is a match between a received frame header and an entry in the translation cache; generating an encapsulation signal, a de-encapsulation signal, a translation signal or a routing signal; removing data words in the received frame header, if de-encapsulation signal is set; translating the received frame header, if the translation signal is set; encapsulating the frame with an encapsulation header, if the encapsulation signal is set; and routing the frame using translation cache routing if the routing signal is set.

In another aspect of the present invention a Fibre Channel switch element for processing frames is provided. The switch element includes a port for receiving a Fibre Channel frame; and a translation cache that compares a Fibre Channel frame header to plural fields in plural control words to determine if there is a match and generates an encapsulation signal, a de-encapsulation signal, a translation signal or a routing signal; and de-encapsulates the Fibre Channel frame header, if a de-encapsulation signal is active; translates the Fibre Channel frame header, if the translation signal is active; encapsulates the frame, if the encapsulation signal is active; and routes the frame using the translation cache if the routing signal is active.

This brief summary has been provided so that the nature of the invention may be understood quickly. A more complete understanding of the invention can be obtained by reference to the following detailed description of the preferred embodiments thereof concerning the attached drawings.

The foregoing features and other features of the present invention will now be described with reference to the drawings of a preferred embodiment. In the drawings, the same components have the same reference numerals. The illustrated embodiment is intended to illustrate, but not to limit the invention. The drawings include the following Figures:

FIG. 1A shows an example of a Fibre Channel system;

FIG. 1B shows an example of a Fibre Channel switch element, according to one aspect of the present invention;

FIG. 1C shows a block diagram of a 20-channel switch chassis, according to one aspect of the present invention;

FIG. 1D shows a block diagram of a Fibre Channel switch element with sixteen GL_Forts and four 10 G ports, according to one aspect of the present invention;

FIG. 1E shows a block diagram of a switch port using an address mapping cache, according to one aspect of the present invention;

FIG. 1F shows a block diagram of a system with multiple Fabrics that can use the address translation scheme, according to one aspect of the present invention;

FIG. 1G shows a block diagram of a system with VSAN's that can use the address translation scheme, according to one aspect of the present invention;

FIG. 2A shows a receive pipeline used to process receive frames, according to one aspect of the present invention;

FIG. 2B shows Inter Fabric Header, Virtual Fabric Header and standard Fibre Channel Header, according to one aspect of the present invention;

FIG. 2C shows control words used to translate data and manipulate headers, according to one aspect of the present invention;

FIG. 2D shows a schematic of a translation cache used for address translation and header manipulation, according to one aspect of the present invention;

FIG. 2E shows a flow chart for performing address translation, header encapsulation and header de-encapsulation, according to one aspect of the present invention;

FIG. 2F shows a flow chart for processing received frames, according to one aspect of the present invention;

FIG. 3 shows a translation table, according to one aspect of the present invention; and

FIG. 4 shows an example for translating standard Fibre Channel Header to an Encapsulated header, according to one aspect of the present invention.

The following definitions are provided as they are typically (but not exclusively) used in the Fibre Channel environment, implementing the various adaptive aspects of the present invention.

“DF_ID”: A 12-bit destination Fabric identifier.

“D_ID”: A 24-bit Fibre Channel header field that includes the destination address for a frame.

“E_Port”: A Fabric expansion port that attaches to another inter-connect port to create an Inter-Switch Link.

“F_Port”: A port to which non-loop N_Ports are attached to a Fabric and does not include FL_ports.

“Fibre Channel ANSI Standard” (“FC-FS-2”) The standard (incorporated herein by reference in its entirety) describes the physical interface, transmission and signaling protocol of a high performance serial link for support of other high level protocols associated with IPI, SCSI, IP, ATM and others. This standard includes information regarding Virtual Fabric headers.

“Fabric”: The structure or organization of a group of switches, target and host devices (NL_Port, N_Ports etc.).

“Fabric Identifier” (may also be referred to as “Fabric ID”): An identifier (“ID”) that is used to identify a Fabric for a Fabric Router function.

“Fabric Router”: A Fibre Channel device that allows Fibre Channel Devices, via N_Ports to be shared among multiple independent Fibre Channel Fabrics.

“Fabric Topology”: A topology where a device is directly attached to a Fibre Channel Fabric that uses destination identifiers embedded in frame headers to route frames through a Fibre Channel Fabric to a desired destination.

“FR_Header”: A header format (shown in FIG. 1G ) defined by T11/04-520v0 for a Fabric Router for routing frames between different Fabrics.

“N_Port”: A direct Fabric attached port, for example, a disk drive or a HBA.

“NL_Port”: An L_Port that can perform the function of an N_Port.

“OX_ID”: An Originator (i.e., a device/port that originates an exchange) Exchange identification field in a Fibre Channel frame header.

“Port”: A general reference to N. Sub.-Port or F.Sub.-Port.

“RX_ID”: A responder (i.e., a device/port that responds) exchange identification field in a Fibre Channel frame header.

“SAN”: Storage Area Network

“S_ID”: A 24-bit field in a Fibre Channel frame header that includes the source address for a frame.

“SF_ID”: A 12-bit source Fabric identifier.

“Switch”: A Fabric element conforming to the Fibre Channel Switch standards.

“VFT_Header”: A Virtual Fabric tagging header as described in FC-FS-2 standard that allows a Fibre Channel frame to be tagged with a VF_ID. Frames with a VFT_Header may be transmitted over the same physical link.

“VF_ID” (or “VSANID”): A Virtual Fabric identifier that identifies a frame's Virtual Fabric.

“Virtual Fabric” (“VSAN”): These are Fabrics that are created by using virtual partitions in a physical Fibre Channel Fabric.

“VSAN”: Virtual Storage Area Network

To facilitate an understanding of the preferred embodiment, the general architecture and operation of a Fibre Channel System and a Fibre Channel switch element will be described. The specific architecture and operation of the preferred embodiment will then be described with reference to the general architecture.

Fibre Channel supports three different topologies: point-to-point, arbitrated loop and Fibre Channel Fabric. The point-to-point topology attaches two devices directly. The arbitrated loop topology attaches devices in a loop. The Fibre Channel Fabric topology attaches host systems directly to a Fabric, which are then connected to multiple devices. The Fibre Channel Fabric topology allows several media types to be interconnected.

A Fibre Channel switch is a multi-port device where each port manages a point-to-point connection between itself and its attached system. Each port can be attached to a server, peripheral, I/O subsystem, bridge, hub, router, or even another switch. A switch receives messages from one port and routes it to another port.

Fibre Channel switches use memory buffers to hold frames received and sent across a network. Associated with these buffers are credits, which are the number of frames that a buffer can hold per Fabric port.

Fibre Channel proposed standard, T11/04-5200v0, incorporated herein by reference in its entirety describes multiple Fabrics and how they should be interconnected.

Fibre Channel proposed standard T11/04-395V2, incorporated herein by reference in its entirety, describes how Virtual Fabrics operate.

Network System:

FIG. 1A is a block diagram of a network system 100 implementing the methods and systems in accordance with the adaptive aspects of the present invention. Network system 100 may be based on Fibre Channel, IB or any other protocol. The examples below are described with respect to Fibre Channel but are applicable to IB and other network standards.

System 100 includes plural devices that are interconnected. Each device includes one or more ports, classified as for example, node ports (N_Ports), Fabric ports (F_Ports), and expansion ports (E_Ports) Node ports may be located in a node device, e.g. server 103 , disk array 105 and storage device 104 . Fabric ports are located in Fabric devices such as switch 101 and 102 . Arbitrated loop 106 may be operationally coupled to switch 101 using arbitrated loop ports (FL_Ports).

The devices of FIG. 1A are operationally coupled via “links” or “paths”. A path may be established between two N_ports, e.g. between server 103 and storage 104 . A packet-switched path may be established using multiple links, e.g. an N-Port in server 103 may establish a path with disk array 105 through switch 102

Switch Element:

FIG. 1B is a block diagram of a 20-port ASIC Fabric element according to one aspect of the present invention. FIG. 1B provides the general architecture of a 20-channel switch chassis using the 20-port Fabric element. Fabric element includes ASIC 120 with non-blocking Fibre Channel class 2 (connectionless, acknowledged) service and class 3 (connectionless, unacknowledged) service between any ports. It is noteworthy that ASIC 120 may also be designed for class 1 (connection-oriented) service, within the scope and operation of the present invention as described herein.

The Fabric element of the present invention is presently implemented as a single CMOS ASIC, and for this reason the term “Fabric element” and ASIC are used interchangeably to refer to the preferred embodiments in this specification. Although FIG. 1B shows 20 ports, the present invention is not limited to any particular number of ports.

ASIC 120 has 20 ports numbered in FIG. 1B as GL 0 through GL 19 . These ports are generic to common Fibre Channel port types, for example, F_Port, FL_Port and E-Port. In other words, depending upon what it is attached to, each GL port can function as any type of port. Also, the GL port may function as a special port useful in Fabric element linking, as described below.

For illustration purposes only, all CL ports are drawn on the same side of ASIC 120 in FIG. 1B . However, the ports may be located on any or all sides of ASIC 120 as shown in other Figures. This does not imply any difference in port or ASIC design Actual physical layout of the ports will depend on the physical layout of the ASIC.

Each port GL 0 -GL 19 includes transmit and receive connections to switch crossbar 115 . Within each port, one connection is through receive buffer 121 , which functions to receive and temporarily hold a frame during a routing operation. The other connection is through transmit buffer 122 .

Switch crossbar 115 includes a number of switch crossbars for handling specific types of data and data flow control information. For illustration purposes only, switch crossbar 115 is shown as a single crossbar. Switch crossbar 115 is a connectionless crossbar (packet switch) of known conventional design, sized to connect 21×21 paths. This is to accommodate 20 GL ports plus a port for connection to a Fabric controller, which may be external to ASIC 120 .

In the preferred embodiments of switch chassis described herein, the Fabric controller is a firmware-programmed microprocessor, also referred to as the input/output processor (“IOP”). As seen in FIG. 1B , bi-directional connection to IOP 110 is routed through port 111 , which connects internally to a control bus 112 . Transmit buffer 116 , receive buffer 118 , control register 113 and Status register 114 (within block 113 A) connect to bus 112 . Transmit buffer 116 and receive buffer 118 connect the internal connectionless switch crossbar 115 to IOP 110 so that it can source or sink frames.

Control register 113 receives and holds control information from IOP 110 , so that IOP 110 can change characteristics or operating configuration of ASIC 120 by placing certain control words in register 113 . IOP 110 can read status of ASIC 120 by monitoring various codes that are placed in status register 114 by monitoring circuits (not shown).

FIG. 1C shows a 20-channel switch chassis S 2 using ASIC 120 and LOP 110 . IOP 110 in FIG. 1C is shown as a part of a switch chassis utilizing one or more of ASIC 20 . S 2 also includes other elements, for example, a power supply (not shown) The 20 GL_Ports correspond to channels C 0 -C 19 .

Each GL_Port has a serial/deserializer (SERDES) designated as S 0 -S 19 . Ideally, the SERDES functions are implemented on ASIC 120 for efficiency, but may alternatively be external to each GL_Port. The SERDES converts parallel data into a serial data stream for transmission and converts received serial data into parallel data.

Each GL_Port may have an optical-electric converter, designated as OE 0 -OE 19 connected with its SERDES through serial lines, for providing fibre optic input/output connections, as is well known in the high performance switch design. The converters connect to switch channels C 0 -C 19 . It is noteworthy that the ports can connect through copper paths or other means instead of optical-electric converters.

FIG. 1D shows a block diagram of ASIC 120 with sixteen GL ports and four 10 G (Gigabyte) port control modules designated as XG 0 -XG 3 for four 10 G ports designated as XGPO-XGP 3 . ASIC 120 includes a control port 113 A that is coupled to IOP 110 through a PCI connection 110 A.

FIGS. 1 E(i)/ 1 E(ii) (jointly referred to as FIG. 1E ) show yet another block diagram of ASIC 120 with sixteen GL and four XG port control modules. Each GL port control module has a Receive port (RPORT) 132 with a receive buffer (RBUF) 132 A (similar to 121 , FIG. 1B ) and a transmit port 130 with a transmit buffer (TBUF) 130 A (similar to 122 , FIG. 1B ). GL and XG port control modules are coupled to physical media devices (“PMD”) 134 and 135 respectively.

Control port module 113 A includes control buffers 113 B and 113 D for transmit and receive sides, respectively. Module 113 A also includes a PCI interface module 113 C that allows interface with IOP 110 via a PCI bus 110 A. It is noteworthy that the present invention is not limited to the PCI bus standard, any other protocol/standard may be used to interface control port 113 A components with IOP 110 .

XC_Port (for example 136 ) includes RPORT 138 A with RBUF 138 similar to RPORT 132 and RBUF 132 A and a TBUF 137 and TPORT 137 A similar to TBUF 130 A and TPORT 130 . Protocol module 139 interfaces with SERDES to handle protocol based functionality.

Incoming frames are received by RPORT 132 via SERDES 131 and then transmitted using TPORT 130 . Buffers 132 A and 130 A are used to stage frames in the receive and transmit paths.

Inter-Fabric Routing:

FIG. 1F shows a block diagram of a system with multiple Fabrics where Inter-Fabric routing is applicable. Fabrics A, B, C, D, E and F are individual Fabrics. Fabric A is coupled to Fabric Router 1 and Fabric Router 3 and host I 1 (Initiator 1 ) and device T 1 (target 1 ).

Fabric D is coupled to Fabric Router 2 and Fabric Router 4 ; while Fabric C is coupled to Fabric Router 3 and Fabric Router 4 . Fabric F is coupled to Fabric Router 4 and target T 3 ; while Fabric E is coupled to Fabric Router 2 and target 2 (T 2 ).

Targets T 2 ′ and T 3 ′ are virtualized targets and initiator (host) I 1 ′ is a virtualized host. Host I 1 uses Fabric Routers 1 and 2 to communicate with device T 2 and Fabric Routers 3 and 4 to communicate with device T 3 . A Fabric Router is a Fibre Channel device that facilitates the remapping/translation or virtualization of a device address allowing select devices to be shared among multiple independent Fibre Channel Fabrics.

Virtual Fabrics:

FIG. 1G shows a top-level block diagram for Virtual Fabrics (VSANs), which use the extended headers, according to one aspect of the present invention. FIG. 1G shows three Fabric switches, 1 , 2 and 3 . Each switch has 8-ports labeled 0 - 7 . It is noteworthy that the present invention is not limited to any particular number/type of ports.

VSAN # 1 is the first Virtual Fabric that includes ports 0 - 3 for Switch # 1 . VSAN # 2 includes Switch # 1 , ports 4 - 7 ; Switch # 2 , ports 0 - 3 ; and Switch # 3 , ports 4 - 7 . VSAN # 3 includes Switch # 1 , ports 4 - 7 and Switch # 3 , ports 0 - 3 . VSAN # 4 includes Switch # 2 , ports 4 - 7 .

The extended headers are used to route frames between the plural Fabrics, for example, between Fabric 1 and Fabric 4 . It is noteworthy that the present invention is not limited to any particular number of Fabrics or switches.

Frame Header Translation:

FIG. 2A shows a receive pipeline in a RPORT 132 used to process receive frames, according to one aspect of the present invention. Receive pipeline 200 is enabled when a frame is received.

Receive pipeline 200 includes plural stages, shown as Stage 1 , Stage 2 . . . Stage N ( 203 ). Stage 1 201 receives data 200 A and output data 201 A from stage 1 201 passes through several stages and output 203 A from Stage N is input to Multiplexer (Mux) 204 . It is noteworthy that the present invention is not limited to any particular number of stages.

Mux 204 also receives translation data 202 A from translation data block 202 , which is used to translate addresses in a received frame header, as described below with respect to FIG. 2D . Output 204 A from Mux 204 is then written in receive buffer 132 A. Control signal 204 B is used to activate Mux 204 .

In a conventional switch, frame header translation may be performed by a microprocessor According to one aspect of the present invention, a multiple stage pipeline enables frame translation to be performed in specialized hardware without involving a microprocessor.

Fibre Channel Headers:

FIG. 2B shows Inter Fabric Header, Virtual Fabric Header and standard Fibre Channel Header, according to one aspect of the present invention.

VSAN VFT Header 250 is used for routing frames between VSAN's. Header 250 includes 12 bit wide virtual Fabric identifier (“VF_ID”) 252 C (VF_ID or VSAN_ID are used interchangeably throughout this specification) VF_ID 252 C is used for routing frames to a virtual Fabric, which has an ID equal to VF_ID 252 C. According to one aspect of the present invention, VF_ID 252 C of a received frame is compared with VF_ID 242 C in control word 1 242 as described below with respect to FIG. 2D . VFT_Header 250 also includes a routing control field 253 A (R_CTL) that is used for frame header category identification. FR Header 251 is used for routing frames between Fabrics. Header 251 includes 12 bit wide source Fabric ID 252 B (SF_ID) and a destination Fabric ID 252 A (DF_ID). DF_ID 252 A is used for routing frames to a Fabric, which has an ID equal to DF_ID 252 A. According to one aspect of the present invention, DF_ID 252 A and SF_ID 252 B of a received frame are compared with DF_ID 242 A and SF_ID 242 B respectively as described below with respect to FIG. 2D . Header 251 also includes a routing control field 253 A (R_CTL) that is used for frame header category identification.

FC Header 252 is used for routing frames between Fibre Channel devices Header 252 includes a 24 bit wide source ID 251 A (S_ID) and a destination ID 253 B (D_ID). D_ID 253 B is used for routing frames to a Fibre Channel device, which has an ID equal to D_ID 253 B. According to one aspect of the present invention, D_ID 253 B and SF_ID 251 A of a received frame are compared with D_ID 243 B and S_TD 241 A respectively as described below in FIG. 2D . Header 252 also includes a routing control field 253 A (R_CTL) that is used for frame header and frame category identification.

FIG. 2C shows control words that are used to translate data and manipulate headers, according to one aspect of the present invention. Control words may be stored in registers that are accessible by IOP 110 . Control words are used to compare certain fields in received frames for special routing, as described below with respect to FIG. 2D .

Turning in detail to FIG. 2C , control Word 0 240 may be a 32-bit wide word that includes the following fields.

Valid bit (“V”) 240 A: This bit indicates if a cache entry is valid.

Field Enable (‘FE’) 240 B, Field Negate (“FN”) 240 C: These fields may be 12 bits wide and include control information to compare fields in a received frame header. Each bit in Field Enable signal 240 B has a corresponding bit in Field Negate signal 240 C. If a bit in Field Enable signal 240 B is set, then the particular field corresponding to the bit is compared. The compared result is inverted if the bit corresponding to the field is set in Field Negate signal 240 C. For example, if bit 30 is set in Field Enable 240 B, then received frame's DF_ID 252 A is compared against Rx DF_ID 242 A in control word 1 242 . The output is inverted if a bit 30 is set/asserted in Field Negate 240 C signal.

Function Code 240 D is used by Translation Cache State Machine 220 to determine what action to perform on a frame that generated a hit. Function Code 240 D is also used by control module 222 (as shown in FIG. 2D ) for generating control signals to blocks 221 , 223 , 223 A and 223 B.

The following provides an example of plural bit values in control word 0 240 .

Bit 30 : compare Receive (“Rx”) DF_ID

Bit 29 : compare Rx SF_ID or VSAN_ID

Bit 28 : compare Rx and Tx Upper 4 bits of R_CTL

Bit 27 : compare Rx and Tx Lower 4 bits of R_CTL

Bit 26 : compare Rx D_ID Domain

Bit 25 : compare Rx D_ID Area

Bit 24 : compare Rx D_ID AL_PA

Bit 23 : compare Rx S_ID Domain

Bit 22 : compare Rx S_ID Area

Bit 21 : compare Rx S_ID AL_PA

Bit 20 : compare Transmit (“Tx”) DF_ID

Bit 19 : compare Tx SF_ID or VSAN_ID

Bit 18 : negate compare for Receive (“Rx”) DF_ID

Bit 17 : negate compare for Rx SF_ID or VSAN_ID

Bit 16 : negate compare for Rx and Tx Upper 4 bits of R_CTL

Bit 15 : negate compare for Rx and Tx Lower 4 bits of R_CTL

Bit 14 : negate compare for Rx D_ID Domain

Bit 13 : negate compare for Rx D_ID Area

Bit 12 : negate compare for Rx D_ID AL_PA

Bit 11 : negate compare for Rx S_ID Domain

Bit 10 : negate compare for Rx S_ID Area

Bit 09 : negate compare for Rx S_ID AL_PA

Bit 08 : negate compare for Transmit (“Tx”) DF_ID

Bit 07 : negate compare for Tx SF_ID or VSAN_ID

It is noteworthy that although various bit values are shown in FIG. 2B , the adaptive aspects of the present invention are not limited to any particular bit value.

Control Word 1 242 is used to compare received IFR_Header data 251 or VFT_Header data 250 in a Fibre Channel frame. Control Word 1 242 may be 32-bit wide word and may include the following fields.

Destination Fabric ID (“DF_ID”) 242 A: This field may include information, which is compared with DF_ID field 252 A in a received or to be transmitted frame header as described below with respect to FIG. 2D . Setting a bit in Field Enable field 240 B enables the comparison. In one aspect of the present invention, DF_ID 242 A may be 12 bits wide.

Source Fabric ID (“SF_ID”) 242 B: This field may include information, which is compared with SF_ID field 252 B in a received or to be transmitted frame header as described below with respect to FIG. 2D . Setting a bit in FE 240 B enables the comparison. In one aspect of the present invention, SF_ID 242 B may be 12 bits wide.

Virtual SAN ID (“VSAN_ID”) 242 C: This field includes information, which is compared with VF_ID field 252 C in a received or to be transmitted frame header as described below with respect to FIG. 2D . Setting a bit in FE 240 B enables the comparison. In one aspect of the present invention, VSAN_ID 242 C may be 12 bits wide.

Control Word 2 243 is used to compare received Fibre Channel header 252 data for standard Fibre Channel frames and the standard Fibre Channel frame header that follows IFR_Header data 251 and VFT_Header data 250 . Control Word 2 243 may be a 32-bit wide word that includes the following fields.

Routing control 243 A (“R_CTL”): This field includes information, which is compared with R_CTL field 253 A in a received or to be transmitted frame header as described below with respect to FIG. 2D . Setting a bit in FE 240 B enables the comparison. In one aspect of the present invention, R_CTL 243 A may be 8 bits wide.

Destination ID 243 B: This field includes information, which is compared with D_ID field 253 B in a received frame header as described below with respect to FIG. 2D . Setting a bit in FE 240 B enables the comparison. In one aspect of the present invention, D_ID 243 B may be 24 bits wide.

Control Word 3 241 has fields that are compared to received Fibre Channel header 252 in a Fibre Channel frame. Control Word 3 241 may be a 32-bit wide word that includes the following fields.

Source ID 241 A (“S_ID”): This field includes information, which is compared with S_ID field 251 A in a received frame header as described below with respect to FIG. 2D Setting a bit in FE 240 B enables the comparison. In one aspect of the present invention, S_ID 241 A may be 24 bits wide.

Frame Header Translation Cache 206 :

FIG. 2D shows a schematic of a translation cache 206 (may also be referred to as Cache 206 ) that is used for address translation and header manipulation for routing Fibre Channel frames, according to one aspect of the present invention. Cache 206 is used to compare received frame header data with plural control word fields (described above with respect to FIG. 2C ) to determine the action that needs to be taken. Based on the comparison results, the receive frame header is translated/encapsulated/de-encapsulated/passed unchanged and a routing option is selected.

Cache 206 includes plural entries that are shown as entry 00 (referred to as 200 A 0 in FIG. 2D ) to entry 31 (referred to as 200 A 31 in FIG. 2D ). Each Cache 206 entry uses a unique set of control word 240 , 241 , 242 and 243 fields for simultaneously comparing against the receive frame header fields. Although FIG. 2D shows 32 entries (0 to 31), the present invention is not limited to any particular number of entries.

Cache 206 includes control block 222 . Transmit request signal/command (“Tx Trans_Req”) 232 B (may also be referred to as “signal 232 B) and receive request signal/command (“Rx_Trans_Req”) 232 C (may also be referred to as “signal 232 C”) are inputs to control block 222 . Signal 232 C may indicate arrival of a frame. Signal 232 B may indicate that a frame needs to be transmitted. The term signal and command are used interchangeably throughout this specification.

Signal 232 C enables frame header comparison in the receive path. Signal 232 B enables frame header comparison in the transmit path.

Control block 222 also receives input data from control word 240 fields. Valid bit 240 A is set for a valid cache entry and FE 240 B and FN 240 C have been described above.

Control block 222 generates a select signal 222 A based on inputs from Control Word 240 , if valid bit 240 A is enabled. Control word 240 fields in conjunction with a frame word count determine what fields in control word 241 , 242 and 243 are sequenced through for comparison. The frame word count is a running count of the number of frame words that have been received at a given time.

Multiplexer (“Mux”) 221 receives signal 222 A and based on that, Mux 221 selects fields from Control Words 241 , 242 and 243 for comparison, as shown in FIG. 2D .

Comparator 223 compares output of Mux 221 (i.e. selected fields from Control Word 240 - 243 ) with fields that are included in incoming frame data 232 A. Output from comparator 223 passes through logic blocks 223 A and 223 B. Logic block 223 B generates a command/signal 223 B 1 that is transmitted to control block 222 which generates receive hit signal 236 R 0 after the control word fields have been compared.

Comparator 235 A compares transmit Tx_R_CTL 231 A with R_CTL 243 A and generates command/signal 235 A 1 . Comparator 235 B compares transmit SF_ID/VSAN_ID 231 B with SF_ID/VSAN_ID 242 C and generates signal 235 B 1 . Similarly, comparator 235 C compares transmit DF_ID 231 C with DF_ID 242 A and generates signal 235 C 1 .

Output signals 235 A 1 , 235 B 1 and 235 C 1 pass through logic blocks 236 A, 236 B and 236 C and generate signals 236 A 1 , 236 B 1 and 236 C 1 , respectively, which are input to logic block 224 . Logic block 224 generates a hit signal 236 T 0 based on input signals 236 A, 236 B, 236 C, 222 A and activation from Control 222 .

“Hit-miss” module 238 (may also be referred to as “module 238 ” or “circuit 238 ”) receives signals 236 R 0 and 236 T 0 from entry 200 A 0 . Circuit 238 also receives similar receive/transmit signals (shown as 236 T 0 / 236 R 0 and 236 T 31 and 236 R 31 ) from other entries ( 200 A 0 - 200 A 31 ). Based on the inputs, circuit 238 generates an output receive hit signal 238 C (shown as “Rx Trans_Hit”) or transmit hit signal 238 B (shown as “Tx_Trans_Hit”) or a multi hit signal 238 A (shown as “Trans_Multi_Hit”).

Transmit hit signal 238 B indicates a match in the transmit path and receive hit signal 238 C indicates a match for the receive path. If multiple hit signal 238 A is generated, then the lowest entry number, with a hit, will be used and an error or warning status is set and sent to IOP 110 .

An encoder module 239 also receives hit signals ( 236 T 0 - 236 T 31 , 236 R 0 - 236 R 31 ) from all the entries. Encoder 239 generates output signals 239 A, 239 B and 239 ′. Signal 239 A is used for hardware-enforced zoning. Signal 239 B is used for column selection in frame routing. These values are similar to output 239 C except that they have limited range corresponding to the number of columns and hardware enforced zone groups supported by the overall design.

Output 239 C of encoder 239 is also sent to a state machine 220 . State machine 220 receives some fields of the incoming frame data words 232 A, control word field 240 D for each entry, RX_Trans_Hit 238 C and translation data 202 for each entry ( 200 A 0 - 200 A 31 ) in cache 206 . Translation data 202 includes data that is used to substitute received frame header information. The contents of translation data 202 are further described below with respect to FIG. 3 .

Based on the input signals, state machine 220 may generate the following output signals that are used for translation/encapsulation/de-encapsulation as well as routing of a received frame.

Trans_Done 220 A: This signal indicates that a translation comparison process has been completed on a frame header.

Unencap_Valid 220 B: This signal indicates that receive side de-encapsulation needs to be performed on a frame header.

Unencap_Code 220 C: This signal is used when Unencap_Valid 220 B signal is asserted, to indicate the number of bytes or data word (“dwords”) that need to be removed from a frame header. For example if the Unencap_Code is set to a binary value of 01, it may indicate that 1 data word (“dword”) of a frame header needs to be removed.

TR_Route_Valid 220 D: This signal is used to indicate that routing of a received frame is to be performed by Translation Cache 206 instead of a conventional steering mechanism. The matching entries sub-function in translation data 202 defines the routing action to be taken. The sub-function is an encoded version of Route_Code 220 F.

Rx_Domain_Valid 220 E: This signal is used to indicate if Translation Cache 206 is providing the Native Domain_ID for routing instead of a conventional Native Domain_ID stored in other port control registers. When Rx_Domain_Valid 220 E is asserted, the Native Domain_ID generated by Translation Cache 206 is provided on Route_Data 220 F 1 .

Route_Code 220 F: This signal is used when TR_Route_Valid signal 220 D is asserted. This signal indicates the type of routing that needs to be performed on the frame. For example, if the binary Route_Code value is 01, then it may indicate routing by column A method. Similarly, if the binary Route_Code value is 10, then it may indicate routing by OX_ID hashing method and if the binary Route_Code value is 11, then it may indicate routing to IOP 110 . The above methods of routing are described in detail in a co-pending US patent application, entitled “Method and System for Data Dependent Network Routing”; Ser. No. 10/894,627, filed on Jul. 20, 2004, incorporated herein by reference in its entirety.

Route_Data 220 F 1 : This may be a 32-bit routing field used in conjunction with Route_Code 220 F to route data using the method indicated by the Route_Code 220 F. Route_Data 220 F 1 also indicates the Native Domain_ID when the Rx_Domain_Vaild 220 E signal is asserted.

Trans_Mask 220 G, Trans_Data 220 H: These may be 32-bit wide signals indicating that a translation function needs to be performed. If a bit in Trans_Mask 220 G is active, then a corresponding bit in the Trans_Data field 220 H is substituted in a receive frame header. For example, if bits 28 and 13 are set in the Trans_Mask signal 220 G, then the corresponding bits 28 and 13 are substituted in the receive frame header. No substitution may be performed on the remaining dword bits. A different Trans_Mask 220 G and Trans_Data 220 H are sent for each frame header word to be processed. The timing of these signals is such as to be aligned with the incoming frame in the Receive Pipeline 200 discussed in FIG. 2A .

Encap_H 1 _Valid 220 I, H 1 _Data 220 J: H 1 _Data 220 J is a 64-bit signal that is used to encapsulate a received frame header with a VSAN or IFR header. H 1 _Data 220 J is used when Encap_H 1 _Valid signal 220 I is active.

Encap_H 2 _Valid 220 K, H 2 _Data 220 L: may be a 64-bit signal that is used to encapsulate a received frame header. H 2 _Data 220 L is used when Encap_H 2 Valid signal 220 K is active.

Process Flow:

FIG. 2E shows a process flow chart for performing header translation, header encapsulation, header de-encapsulation and for special routing of a frame, according to one aspect of the present invention.

In step S 218 , the process starts and RPORT 132 waits for a frame. In step S 219 , RPORT 132 determines if it has received a frame. If no, then the process reverts to step S 218 If yes, then process moves to step S 220 .

In step S 220 , RPORT 132 determines if cache 206 is enabled. If cache 206 is not enabled, the process reverts to step S 223

If cache 206 is enabled, then in step S 221 , the frame header (not shown) is matched against entries in cache 206 as described above with respect to FIG. 2D .

In step S 222 , RPORT 132 determines if there is a match/hit. If there is no match/hit, then the frame is routed in step S 223 , by other methods, without changing the frame header.

If there is hit, then in step S 224 , state machine 220 generates translation mask 220 G, Route_valid signal 220 D, Encap_H 1 _Valid signal 220 I, Encap_H 2 _Valid signal 220 K and Unencap_Valid signal 220 B. The functionality of translation state machine 220 is described above with respect to FIG. 2D . Thereafter, Steps 225 A, 225 B, 225 C and 225 D are performed in parallel.

In step S 225 A, TPORT 130 determines if any of translation mask 220 G bits are not equal to zero. If yes, then the frame header is translated (substituted) in step S 226 A. Receive pipeline 200 substitutes frame header information with translation data 202 . Translation is performed on a frame header for bits that are not equal to zero in translation mask 220 G. For example, if bit 4 and bit 7 are not equal to zero in translation mask 220 D, then bit 4 and bit 7 of the frame header is substituted with bit 4 and bit 7 from translation data 202 .

In step S 225 B, RPORT 132 determines if Route_Valid signal/command 220 D is set/asserted. If yes, then in step S 226 B, the frame is tagged for routing by the method identified using sub-function code ( 240 D)

In step S 225 C, RPORT 132 determines if Un_Encap_Valid signal/command 220 B is set/asserted. If yes, then in step S 226 C data words in a frame header are removed. This step is further explained below with respect to FIG. 2F .

In step S 225 D, RPORT 132 determines if Encap_H 1 _Valid signal/command 220 I or Encap_H 2 _Valid signal/command 220 K is set/asserted. If yes, then in step 226 D the frame is tagged for encapsulation. The encapsulation process is further explained in step S 208 below with respect to FIG. 2F .

Thereafter, the process proceeds to step S 201 described below with respect to FIG. 2F .

The process reverts back to step S 218 , if translation mask 220 G bits are zero in step S 225 A; if Route_Valid signal 220 D is not set/asserted in step S 225 B; if Uncap_Valid signal 220 B is not set/asserted in step S 225 C; or if Encap_H 1 _Valid signal 220 I/Encap_H 2 _Valid signal 220 K signals are not set in step S 225 D.

FIG. 2F shows a flow chart for processing frames that are received at RPORT 132 , according to one aspect of the present invention.

In step S 201 , a frame is received by receive pipeline 200 at RPORT 132 .

In step S 202 , RPORT 132 determines if de-encapsulation is active, i.e., Un_Encap_Valid signal/command 220 B is set/asserted. As described above, Un_Encap_Valid signal/command 220 B is generated by state machine 220 . If Un_Encap_Valid signal 220 B is not set, then the frame header is unchanged and the process proceeds to step S 204 .

If Un_Encap_Valid 220 B is set, then in step S 203 , encapsulation header is removed. The number of data words to be removed is determined by Unencap_Code 220 C. The frame is also updated with a new cyclic redundancy code (“CRC”). Every frame has a CRC code that is used for data integrity, and by updating the CRC, data integrity is ensured, especially when changes are made to frame headers.

Conventional switches use standard Fibre Channel frames for receiving and transmitting information. When a conventional switch from a VSAN or a Fabric receives frames, then the frame header has additional data words that need to be de-encapsulated so that the frame header is converted to a standard Fibre Channel frame header. According to one aspect of the present invention, the frame de-encapsulation feature enables conventional switches to connect to VSAN's or Fabrics.

In step S 204 , RPORT 132 determines if frame translation is active i.e., if any of the bits in translation mask are not equal to zero. If yes, then in step S 205 , frame translation is performed and CRC is updated. The details of address translation are described above in step S 226 A with respect to FIG. 2E .

According to one aspect of the present invention, frame header translation enables Fibre Channel frames to move between VSAN's and Fabrics. A Fibre Channel frame in a VSAN could be routed to another Fabric by translating the VSAN header to an IFR header. Similarly, an IFR Fibre Channel frame can be translated to a VSAN frame. The frame can be translated from one VSAN header to another VSAN header or similarly from one IFR header to a different IFR header.

In step S 206 , if frame translation in not set in step S 204 , then the unchanged frame is written into receive buffer (RBUF) 132 A. If address translation is set in step S 204 , then the translated frame with updated CRC is written into RBUF 105 in step S 206 .

In step S 207 , the process determines if frame encapsulation is active. Frame encapsulation is active when signals/commands Encap_H 1 _Valid 220 I or Encap_H 2 _Valid 220 K are set/enabled.

If frame encapsulation is enabled, then in step S 208 , the frame is read from RBUF 132 A and the frame is encapsulated with a frame header. If Encap_H 1 _Validsignal 220 I is set/enabled, then the frame is encapsulated with H 1 _Data 220 J. If Encap_H 2 _Validsignal 220 K is set/enabled, then the frame is encapsulated with H 2 _Data 220 K. The CRC of the frame is updated after the frame is encapsulated. Thereafter, the process proceeds to step S 209 .

In step S 207 , if frame encapsulation is not active, then the process moves to step S 209 .

According to one aspect of the present invention, frame encapsulation enables standard switches and other devices to communicate with devices within VSANs and Fabrics. Conventional switches use only standard Fibre Channel frame headers. To route to a VSAN, a device needs to encapsulate the standard Fibre Channel header with a VSAN header. Moreover, the Fibre Channel frame can also be encapsulated with an IFR header, so that the frame could be routed to a Fibre Channel Fabric. FIG. 4A provides an example of the encapsulation process step.

In step S 209 , the process determines if translation cache routing is enabled. Translation cache routing is enabled if Route_Valid signal/command 220 D is asserted/set.

In step S 209 , if translation cache routing is not enabled, then the process moves to step S 210 .

In step S 209 , if translation cache routing is enabled, then in step S 211 the frame is routed by one of the methods described by Route_Code signal 220 F using Route_Data 220 F 1 . According to one aspect of the present invention, routing by translation cache enables a Fibre Channel switch to perform the functionality of a router.

In step S 210 , the process determines if Cache 202 Native Domain_ID is valid. If the Cache 202 Native Domain_ID is valid, then in step S 213 the frame is routed by other means using Cache 202 generated Native Domain_ID in the ports routing state machine.

If Cache 202 Native Domain_ID is not valid in step S 210 , then in step S 212 , the frame is routed by other means using a Native Domain_ID from control registers else where in the port (not shown). Cache 202 Native Domain_ID is provided on signal Route_Data 220 F 1 .

FIG. 3 shows a description of the Function Code 240 D assignment (table 300 ) that is used to identify the translation action to perform, according to one aspect of the present invention.

Table 300 includes a column to represent function code 240 D. Different bit values are used to indicate the different translation type. It is noteworthy that the bit values used for function code in table 300 are for illustration purposes only.

Column 302 shows a received header type and column 303 shows a transmitted header type. Column 304 describes the translation type that is performed. For example, if the function code ( 240 D) is set to 00100, then column 302 indicates that a received header is a standard Fibre Channel header and column 303 indicates the transmitted header is an encapsulated header. Hence, a transmitted header is encapsulated.

FIG. 4A shows an example for translating a received standard Fibre Channel header 401 (similar to Frame Header 252 ) to a translated encapsulated header 403 , according to one aspect of the present invention.

In this example, translation is based on function code 00100 as shown in table 300 . A standard Fibre Channel frame that is received is routed to a Fabric in this example.

When a frame is received at RPORT 132 and if cache 206 is enabled, then a match is performed against all entries in the cache. A hit happens, if D_ID 401 A of the received frame header matches with D_ID 243 B of control word 2 243 . The received frame's CS_CTL field is sent to a state machine 220 along with function code 00100 and translation data 202 .

In this example, state machine 220 generates a Trans_Mask 220 G, Encap_H 1 _Valid 220 I, H 1 _Data 220 J Encap_H 2 _Valid 220 K and H 2 _Encap_Data 220 L. Bits corresponding to D_ID and S_ID are set in translation mask 220 G as the fields that have to be translated.

Translation data 202 includes new D_ID 402 A (same as 253 B) and new S_ID 402 B (same as 251 A) values in the respective bit positions. D_ID 401 A and S_ID 401 B of the received frame are translated to new D_ID 402 A and 402 B values. R_CTL value in the received frame header is translated to a value of 52 h (shown as 402 C) to indicate an IFR frame. The new frame header is then written into RBUF 132 A. An updated CRC 402 D is also calculated for the frame.

The frame is then read out of RBUF 132 A and is tagged for encapsulation as signal Encap_H 1 _Valid 220 I and Encap_H 2 _Valid 220 K are set/asserted in this example.

When the frame is ready to be transmitted out of TPORT 130 , it is encapsulated with H 2 _Data 220 L and H 1 _Data 220 J. In this example, H 2 _Data 220 L and H 1 _Data 220 J are 128-bits of the extended IFR header 403 A. Header 403 A includes the updated D_ID 402 A and S_ID 402 B along with other fields like the Fabric destination ID (DF_ID) source ID (SF_ID). CRC value 403 D is updated when the frame is transmitted out on TPORT 130 .

The following provides an example of the Translation Data 202 word format for function code “00100 b ” used in the above example:

Although the present invention has been described with reference to specific embodiments these embodiments are illustrative only and not limiting. Many other applications and embodiments of the present invention will be apparent in light of this disclosure and the following claims.