|Publication number||US20050025075 A1|
|Application number||US 10/791,143|
|Publication date||3 Feb 2005|
|Filing date||1 Mar 2004|
|Priority date||26 Dec 2001|
|Also published as||CA2472056A1, CA2472056C, CN1620784A, CN100348000C, DE60220313D1, DE60220313T2, EP1459485A1, EP1459485B1, US7599360, US20030118053, WO2003058891A1|
|Publication number||10791143, 791143, US 2005/0025075 A1, US 2005/025075 A1, US 20050025075 A1, US 20050025075A1, US 2005025075 A1, US 2005025075A1, US-A1-20050025075, US-A1-2005025075, US2005/0025075A1, US2005/025075A1, US20050025075 A1, US20050025075A1, US2005025075 A1, US2005025075A1|
|Inventors||Dinesh Dutt, Silvano Gai, Bruno Raimondo, Thomas Edsall, Subrata Banerjee, Rajeev Bhardwaj, Ankur Jain, Davide Bergamasco|
|Original Assignee||Cisco Technology, Inc.|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (23), Referenced by (71), Classifications (11), Legal Events (1)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention is a Continuation-in-Part of co-pending, commonly assigned, application Ser. No. 10/034,160 filed Dec. 26, 2001 and entitled “Methods and Apparatus for Encapsulating a Frame for Transmission in a Storage Area Network”, incorporated herein for all purposes.
1. Field of the Invention
The present invention relates to storage area networks, and more particularly, to a Fibre Channel Switch that enables the end devices in different Fabrics to communicate with one another while retaining their unique Fibre Channel IDs.
2. Background of the Invention
With the increasing popularity of Internet commerce and network centric computing, businesses and other organizations are becoming more and more reliant on information. To handle all of this data, storage area networks or SANs have become very popular. A SAN typically includes a number of storage devices, a plurality of Hosts, and a number of Switches arranged in a Switching Fabric that connects the storage devices and the Hosts.
Most SANs rely on the Fibre Channel protocol for communication within the Fabric. For a detailed explanation of the Fibre Channel protocol and Fibre Channel Switching Fabrics and Services, see the Fibre Channel Framing and Signaling Standard, Rev 1.70, American National Standard of Accredited Standards Committee (NCITS), Feb. 8, 2002, and the Fibre Channel Switch Fabric—2, Rev. 5.4, NCITS, Jun. 26, 2001, and the Fibre Channel Generic Services—3, Rev. 7.01, NCITS, Nov. 28, 2000, all incorporated by reference herein for all purposes.
In Fibre Channel, each device (Hosts, storage devices and Switches) is identified by a globally unique, eight (8) byte wide World Wide Name (WWN) assigned by the manufacturer. There are two kinds of WWNs used in FC networks. If you consider a device with one or more FC adapters (or HBAs or ports) to connect to a FC network, every device is assigned a node WWN (nWWN) and each adapter is assigned a port WWN (pWWN). The nWWN and pWWN are different from each other. When the Fibre Channel devices are interconnected to form a SAN, the WWN (along with other parameters) is the primary mechanism to identify each device. Fibre Channel frames are used for communication among the devices in the SAN. The WWN, however, is not used by the frames. Each adapter or port must login to the FC network. At this time, each port is dynamically assigned a unique Fibre Channel address (FC_ID) by the Fabric. The FC_ID is used in FC networks for end devices to address each other.
The three byte wide Fibre Channel addresses are hierarchically structured in three fields, each one byte long: Domain_ID, Area_ID, and Port_ID. Each Switch within the Fabric is assigned a Domain_ID. The end devices attached to a particular Switch are assigned the Domain_ID of that Switch. The Switch manages the allocation of the Area_ID and Port_ID fields for each end device to guarantee the uniqueness of the assigned addresses in that Domain. For example, if a Switch is assigned a Domain number five and the Switch subdivides its address space in two areas each having three connected end devices, then a possible Fibre Channel address allocation is: 5:1:1, 5:1:2, 5:1:3, 5:2:1, 5:2:2, and 5:2:3.
Fibre Channel based SANs are often organized into zones. Within each zone, Hosts can see and access only storage devices or other Hosts belonging to that zone. This allows the coexistence on the same SAN of different computing environments. For example, it is possible to define on a SAN a Unix zone and a separate Windows zone. Unix servers belonging to the Unix zone may access only storage or Hosts devices within the Unix zone, and do not interfere with the other devices connected to the SAN. In the same manner, Windows servers belonging to the Windows zone may access storage or Hosts devices only within the Windows zone, without interfering with the other devices connected to the SAN. The SAN administrator may define in a SAN multiple zones, as required or dictated by the computing and storage resources connected to it. The Switching Fabric allows communications only between devices belonging to the same zone, preventing a device of one zone from seeing or accessing a device of another zone.
The information infrastructure within a large enterprise will typically have a number of SANs, each dedicated for a different organization or application within the enterprise. For example, a large corporation may have different SANs for corporate, for the sales department, the marketing department, etc. Each SAN will typically include redundant Fibre Channel fabrics connecting a plurality of Hosts and storage devices. The redundant Switches in the Fibre Channel fabrics are provided in the event a Switch or link in one Fabric goes down. If this were to occur, the redundant fabric would be used enabling normal operation of SAN. Another example is the use of a dedicated SAN for managing a mail server such as Microsoft Exchange.
The aforementioned arrangement has a number of disadvantages. Foremost, the Hosts in a given SAN can communicate only with the storage devices in that same SAN. There is no way that a Host in one SAN can directly communicate with a storage device in a second SAN. This arrangement is not only inefficient, it is expensive. Since storage devices cannot be shared among SANs, separate storage devices are required for each SAN.
The above-identified parent application partially addresses this problem by introducing the concept of a Virtual SAN or “VSAN”. The implementation of a VSAN is based on the concept of dividing the switching fabric of a single physical SAN into logical SANs, each called a VSAN. The properties of each VSAN are similar to a standard SAN, in particular: (i) unicast, broadcast and multicast traffic is confined to a VSAN and does not span multiple VSANs; (ii) Fibre Channel identifiers (FC_IDs) are assigned per VSAN. This means that a given FC address may be assigned to two different Hosts in two different VSANs; and (iii) routing and distributed Fabric Services, such as Name Server, Zone Server, etc. are maintained independently for each VSAN. This results in constraining the effect of a configuration or topology change to only the affected VSAN. Within each VSAN, a frame is forwarded as in any normal SAN, using the FC_ID.
One known solution for enabling end devices in different VSANs to communicate with one another involves the virtualization of the end devices so that there are “local instances” of each end device in the Fabric within each VSAN. See for example US Patent Publication 2003/0012204. One problem with this approach is that the border Switches between the VSANs perform FC_ID translations (i.e., Network Address translations or NATs) for the source and destination end devices. If a border Switch goes down, an alternative or fail-over path needs to be created. In addition, with certain frames, both the source and/or destination FC_IDs may be defined in the payload. A mechanism that identifies and translates these IDs must therefore be provided. This solution also does not work if encryption or a proprietary protocol is used between the source and destination end devices because there is no way for the border Switches to process the proprietary payloads or de-crypt the frames to identify the source and destination FC_IDs.
A Fibre Channel Switch and Fabric is needed which enables end devices in different Fabrics to communicate with one another while retaining their unique Fibre Channel Domain_IDs.
To achieve the foregoing, and in accordance with the purpose of the present invention, a Switch is disclosed which enables end devices in different Fabrics to communicate with one another while retaining their unique Fibre Channel Domain_IDs. The Switch is coupled to a first fabric having a first set of end devices and a second fabric having a second set of end devices. The Switch is configured to enable communication by the first set of end devices associated with the first fabric with the second set of end devices associated with the second fabric using the unique Domain_IDs of each of the first set and the second set of end devices. In one embodiment of the invention, the first and second fabrics are first and second Virtual Storage Area Networks (VSANs) respectively. In an alternative embodiment, the first fabric and the second fabric are separate physical fabrics.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention.
In a Fibre Channel SAN, the main services provided by the fabric include: Dynamic Address Allocation, Routing, Name Service Zone Service, and event notification. The present invention relates to Inter-VSAN and/or Inter-Fabric routing using unique Domain_IDs. Terminology specific to the present invention and defined herein includes:
With the present invention, the end devices pWWN1 and pWWN4 can communicate with one another while retaining their respective FC_ID addresses. This is accomplished through the Border Switch B1 that straddles both VSANs. In a single step process, packets originating from end device pWWN1 are injected from VSAN 102 to VSAN 104 and pWWN4, and vice-versa, through the border Switch B1.
It should be noted that as used herein, the term “Fabric” generally implies a single physical Fabric that is divided into separate Virtual SANs. The two VSANs 102 and 104 as illustrated in
The Inter-VSAN routing using unique Domain_IDs of the present invention initially requires an administrator to define one or more Inter-VSANs and the end devices that can communicate with one another in the Fabric. After the Fabric is configured, the Border Switches: (i) exchange the Inter-VSAN routing protocol (IVRP) messages with the other Border Switches in the fabric in order to determine the topology and shortest paths to the different VSANs. In the absence of a routing protocol, a static configuration is needed to decide the set of VSANs that must be transited by frames from an origination Edge VSAN to a terminating Edge VSAN; (ii) exchange Fabric Shortest Path First (FSPF) information between the neighbor Switches in each VSAN and the neighbor VSANs. Specifically, Border Switches inject routes into either Transit VSANs; and/or Edge VSANs connected to the Border Switch; (iii) propagate FSPF updates between the Edge and Transit VSANs only if the updates affect routes and link cost to any of the exported Domain_IDs; (iv) exchange zoning information with its neighbor Switches on linkup; (v) exchange name server databases with its neighbor Switches. Only those entries in the Inter-VSAN zone relevant to a VSAN are exchanged across VSANs; (vi) proxy as the name server for each switch in a remote Edge VSAN for queries received from Switches in the local VSAN; (vii) translates the VSAN of a frame received from an Edge VSAN to the Transit VSAN for outbound traffic and conversely translates the VSAN of a received frame from the Transit VSAN to the appropriate Edge VSAN; and (viii) terminates all control traffic including FSPF, zone server, and name server in the adjacent Edge VSAN. Each of the functions performed by the Border Switches is defined in more detail below.
The Transit VSAN 12 switches traffic from the disconnected Edge VSAN pairs 1-3 and 2-3 and vice-versa. The link between the Switches B and C can be according to various embodiments a standard FC link or remote (e.g., FCIP, FC over DWDM, etc) link. The transit VSAN 12 is similar to any other VSAN and can potentially have its own end devices attached to it. The Transit VSAN 12 does not care about the nature of the neighbor Edge VSANs that it is switching traffic either to or from. In other words, a transit VSAN can switch traffic to or from another transit VSAN.
The EISL CRC value differs or is a modification of a standard CRC value calculated for a regular ISL frame due to the corresponding longer length of the EISL frame 30 with the appended EISL header field 34. The EOF field 40 delineates the end of the frame 30.
Priority field 50 indicate the user priority of the EISL frame 30. Priority may be defined in a number of ways. As one example, the user priority may be a generic numeric priority, without a guaranteed level of service. For instance, higher values represent higher user priority while lower values may represent lower priority. Higher priorities receive available bandwidth first, regardless of how much total bandwidth is available. As another example, the user priority may indicate a quality of service (QoS) of the payload of the EISL frame. Generally, the width of the Priority field 50 depends on the priority type and/or the number of priority levels.
The VSAN identifier field 52 or “tag” is used to identify the frame 30 as belonging to a particular VSAN. More particularly, the VSAN identifier field 52 identifies the payload of the EISL frame 30 as belonging to a particular VSAN. In accordance with one embodiment, the VSAN identifier field 412 is a twelve-bit wide field. The format of the identifier may be identical to or similar to VLAN identifiers as well as similar to addresses employed in certain standard protocols such as Ethernet.
In some SANs, there may be topology as well as routing problems that could cause a frame to traverse a loop within the network. Such a loop will consume bandwidth unnecessarily. In order to address this problem, a Time To Live (TTL) field 54 may be used to indicate a TTL value specifying the number of remaining hops that can be traversed before the frame is dropped. The TTL value inserted into field 54 is initialized by the network device (e.g., a Switch) that generates the EISL frame 30. A TTL default value is initially set to an arbitrary number, for example sixteen. With each hop, subsequent network devices (e.g., Switches) receiving the EISL frame decrement the TTL value by one. A TTL value of one indicates to the receiving network device (e.g., Switch) that the EISL frame should be dropped. When the EISL frame is dropped, an error message may be sent to the intended recipient of the frame as well as to the sender of the frame. Similarly, a TTL value of 0 may indicate that the TTL field 54 should be ignored, allowing the EISL frame to be forwarded by the switch.
On a link carrying multiple VSANs, Switches communicate using frames 30. Each frame 30 also includes, in addition to the above, the Fibre Channel addresses (FC_IDs) of the source and destination end devices. The VSAN ID 52 qualifies a particular frame 30 as belonging to a particular VSAN, transparent to the end devices. For more information on the switching of frames 30 within a VSAN, see the aforementioned parent application.
Using the inter-VSAN zone, Border Switches decide: (i) the content of the name server database that is exported into the Transit VSAN from the adjacent Edge VSAN and vice versa; (ii) the set of FSPF domains to export in Link State Update (LSU) messages; (iii) the set of addresses to switch from adjacent Edge VSANs to Transit VSANs and vice versa; (iv) the set of adjacent Edge VSANs to which SW_RSCNs received from a Transit VSAN are propagated; (v) the set of SW_RSCNs received from adjacent Edge VSANs to propagate into the Transit VSAN. In other words, the Inter-VSAN zone is the point from which the import and export data and control traffic occurs. Since zone configuration is a well known concept, the configuration of Inter-VSAN routing via Inter-VSAN zones simplifies management and administration in the Fabric.
Similar to a regular zone in a VSAN, Inter-VSAN zones are contained within a zoneset and there is an active zoneset. The Border Switches thus determine the import and export traffic from the Inter-VSAN zones in the active zoneset.
In a typical SAN, a number of protocols are implemented when a link is established between two Switches. These include the Port Manager; Domain Manager; Zone Server; Fabric Shortest Path First (FSPF); Name_Server; and Switch Register State Change Notification (SW_RSCN) protocols, as described in the above-referenced NCITS documents. The aforementioned protocols have been modified for Inter-VSAN routing as contemplated with the present invention as described below.
Port Manager Protocol: The Port manager protocol negotiates parameters between two Switches and determines if the link is an Inter-Switch Link (ISL) or an Extended Inter-Switch Link (EISL). If the link is EISL, then it means that the link is capable of carrying VSAN frames. Otherwise, the Port Manager protocol operates the same with VSANs as with a regular SAN.
Domain Manager Protocol: The Domain Manager Protocol is responsible for the allocation of Domain_IDs and/or Fibre Channel addresses (FC_ID) for each Switch, Host and storage device in the SAN. As noted above, a FC_ID includes three components, a Domain_ID, an Area_ID, and a Port_ID. During initialization, a Principal Switch is selected for the SAN. The Principal Switch is responsible for assigning a Domain_ID for each Switch. Each Switch is then responsible for selecting the Area_ID and Port_ID for each end device connected to that Switch.
According to the present invention, the domain number space must be unique across the VSANs that are going to communicate with one another. There are a number of ways in which this uniqueness can be maintained, including: (i) administratively partitioning the domain number space across the VSANs; or (ii) associate a set of Domain_IDs to be used only for biter-VSAN routing. For example, Domain_IDs between 200-239 (or any other arbitrary range) can be dedicated for VSAN routing. A Switch that needed to communicate across VSANs could administratively be configured to request Domain_IDs in the dedicated number space range.
Zone Server Protocol: In a standard SAN, the Zone Server Protocol is responsible for creating and maintaining a database within each Switch that defines each zone in the SAN. The zones in the table are defined in terms of the Host(s) and storage device(s) in each zone. A Host and/or storage device can belong to multiple zones. To ensure a consistent zoning database across a SAN, when an ISL link comes up between two switches, the zone database is exchanged between the switches to ensure consistency and to prevent conflicting zone definitions. If there are no conflicts, the zone databases are merged. If there are conflicts, the link is isolated and no data traffic can flow through that link until the conflicts are resolved. As part of the zone server protocol, whenever a zone is added, deleted or modified, the changes are propagated throughout the Fabric.
To support Inter-VSAN routing, the Zone Server Protocol is modified to accommodate Inter-VSAN zones having members in different VSANs. Further, existing mechanisms or new mechanisms can be devised to ensure consistency of inter-VSAN zones. Since VSANS are terminated at the border switches, intra-domain zones are not propagated to the Transit VSAN.
Fabric Shortest Path First (FSPF) Protocol: The FSPF is a link state path selection protocol. FSPF keeps track of the state of the links on all the Switches in the Fabric and associates the cost with each link. The protocol computes paths from each Switch to all the other Switches in the Fabric by adding the cost of all the links traversed by the path, and choosing or selecting the path that minimizes the cost. The collection of the link state records (LSR's) (including the cost) of all the Switches in the Fabric constitutes the topology database of the Fabric, called the Link State Database.
The FSPF protocol has four major components, including: (i) a “Hello” protocol used to establish connectivity between neighbor Switches, to establish the identity of neighbor Switches, and to exchange FSPF parameters and capabilities between the neighbor Switches; (ii) a replicated fabric topology or Link State Database, with protocols and mechanisms to keep the databases synchronized across the Fabric; (iii) a path computation algorithm; and (iv) a routing table update.
The Link State Database synchronization in turn consists of two major components, an initial database synchronization and an update mechanism. The initial database synchronization is used when a Switch is initialized or when an inter-Switch Link (ISL) comes up. The update mechanism is used when either (i) there is a link state change, for example when an ISL goes up or down; or (ii) on a periodic basis, to prevent Switches from deleting topology information from the database.
With the FSPF protocol, the term “path selection” indicates the lowest cost or “best” path between a source and destination in the Fabric. The term “routing” indicates the actual forwarding of frames to a specific destination. FSPF performs hop-by-hop routing, which means that a Switch in the Fabric only needs to know the next hop on the best path to the destination. The replicated topology database insures that every Switch in the Fabric has the same definition of the Fabric, and therefore, all the Switches will make consistent routing decisions. Typically, a Switch needs to know, for each destination domain in the Fabric, which path should be used to route a frame to a domain. A routing table entry therefore requires at a minimum a destination Domain_ID and an E_Port to which frames are forwarded.
Since the FSPF protocol is contained within a VSAN, in order to support routing for domains that are in other VSANs, the following modifications are implemented:
For each Domain_ID of a device that is part of an inter-VSAN zone, a border switch considers the Domain_ID for announcement into the adjacent VSANs. An adjacent VSAN may be a transit VSAN or an edge VSAN. A thus selected Domain ID is announced into an adjacent VSAN if either that VSAN is a transit VSAN or there is a device in the VSAN that is part of the same inter-VSAN zone.
In addition to this, a border switch rewrites the VSAN of a frame that is being routed across VSANs to that of the adjacent VSAN. So, for frames being routed from an edge VSAN to a transit VSAN, a border switch rewrites the VSAN from the edge VSAN to the transit VSAN.
Name Server Protocol: With the Name Server Protocol, each Switch exchanges information regarding its locally attached end devices with the other Switches in the SAN. The information that is exchanged for each end device includes the world wide name (pWWN), the Fibre Channel address (FC_ID), the type of protocol (SCSI, IP, etc.) the end device supports, and if the end device is an initiator (i.e., a Host) or a target (i.e., a storage device).
To support Inter-VSAN routing, the changes to the name server on a Border Switch are: (i) build the list of name server entries to be exported to a Transit VSAN or Edge VSAN. This list is created from the defined Inter-VSAN zones, and (ii) terminate and proxy name server queries for the domains associated with the remote domain and respond on behalf of the name server of the queried Switch.
Referring again to
SW_RSCNs are exchanged between switches whenever the name server database changes. The change is usually due to a change in the state of a locally connected port, a locally connected switch or to the zone server database. SW_RSCNs are originated by the Switch detecting the change and sent to every other Switch in the VSAN. The SW_RSCN contains information about the affected end devices or Domain_ID (Domain_ID is used when changes affect the entire switch as specified in the FC-MI Technical Report, incorporated by reference herein for all purposes. This information includes the port WWN of the end device and its FC_ID. An SW_RSCN can contain notification about multiple end devices.
With Inter-VSAN routing, changes in one VSAN must be propagated to other VSANs if the change affects a device in an Inter-VSAN zone. Consider the topology in
The replication of SW_RSCN frames can be prevented by selecting a single Switch to be responsible for distributing SW_RSCN from one VSAN to another. The selection of such a switch can be done in multiple ways, for example, either: (i) statically configured by a system administrator; (ii) selecting the principal Switch in a VSAN to be designated as the Switch for distributing SW_RSCNs; (iii) the border switches can then announce the SW_RSCN from an adjacent VSAN to only the principal switch which then distributes the SW_RSCN within its VSAN or (iv) one of the Border Switches can be selected based on some scheme such as shortest path to the VSAN for which it is advertising, the switch with the highest “switch WWN” etc. Regardless of the responsible Switch, each switch receiving a SW_RSCN notifies registered end hosts of the change as per normal RSCN rules.
When the transits VSANs are the same, in order to have pWWN1 communicate with pWWN3, an Inter-VSAN zone is defined containing the two devices. There must be one or more links connecting switches S2 and S3 that carry the Transit VSAN traffic. If the link between the switches is not direct, all the switches in the path between S2 and S3 must carry the transit VSAN.
When the transit VSANs are not the same, the Inter-VSAN zones must be defined such that frames can be switched from one Transit VSAN to the other. In
The embodiments of the present invention described above are to be considered as illustrative and not restrictive. The various change commands described herein are only exemplary and any other types of commands may be used. The invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5740171 *||28 Mar 1996||14 Apr 1998||Cisco Systems, Inc.||Address translation mechanism for a high-performance network switch|
|US5742604 *||28 Mar 1996||21 Apr 1998||Cisco Systems, Inc.||Interswitch link mechanism for connecting high-performance network switches|
|US5764636 *||28 Mar 1996||9 Jun 1998||Cisco Technology, Inc.||Color blocking logic mechanism for a high-performance network switch|
|US5809285 *||21 Dec 1995||15 Sep 1998||Compaq Computer Corporation||Computer system having a virtual drive array controller|
|US5999930 *||1 Aug 1997||7 Dec 1999||Hewlett-Packard Company||Method and apparatus for distributed control of a shared storage volume|
|US6101497 *||25 Apr 1997||8 Aug 2000||Emc Corporation||Method and apparatus for independent and simultaneous access to a common data set|
|US6188694 *||23 Dec 1997||13 Feb 2001||Cisco Technology, Inc.||Shared spanning tree protocol|
|US6202135 *||23 Dec 1996||13 Mar 2001||Emc Corporation||System and method for reconstructing data associated with protected storage volume stored in multiple modules of back-up mass data storage facility|
|US6205488 *||13 Nov 1998||20 Mar 2001||Nortel Networks Limited||Internet protocol virtual private network realization using multi-protocol label switching tunnels|
|US6208649 *||11 Mar 1998||27 Mar 2001||Cisco Technology, Inc.||Derived VLAN mapping technique|
|US6209059 *||25 Sep 1997||27 Mar 2001||Emc Corporation||Method and apparatus for the on-line reconfiguration of the logical volumes of a data storage system|
|US6219699 *||26 Mar 1999||17 Apr 2001||Cisco Technologies, Inc.||Multiple VLAN Architecture system|
|US6226771 *||14 Dec 1998||1 May 2001||Cisco Technology, Inc.||Method and apparatus for generating error detection data for encapsulated frames|
|US6260120 *||29 Jun 1998||10 Jul 2001||Emc Corporation||Storage mapping and partitioning among multiple host processors in the presence of login state changes and host controller replacement|
|US6266705 *||29 Sep 1998||24 Jul 2001||Cisco Systems, Inc.||Look up mechanism and associated hash table for a network switch|
|US6269381 *||30 Jun 1998||31 Jul 2001||Emc Corporation||Method and apparatus for backing up data before updating the data and for restoring from the backups|
|US6269431 *||13 Aug 1998||31 Jul 2001||Emc Corporation||Virtual storage and block level direct access of secondary storage for recovery of backup data|
|US6295575 *||29 Jun 1998||25 Sep 2001||Emc Corporation||Configuring vectors of logical storage units for data storage partitioning and sharing|
|US20010049739 *||12 Feb 2001||6 Dec 2001||Koji Wakayama||Apparatus and method for interworking between MPLS network and non-MPLS network|
|US20020110125 *||29 Jan 2002||15 Aug 2002||David Banks||Method and system for creating and implementing zones in hardware within a fibre channel system|
|US20020176434 *||17 Apr 2002||28 Nov 2002||Brocade Communications Systems, Inc.||Fibre channel zoning by logical unit number in hardware|
|US20030012204 *||11 Jul 2001||16 Jan 2003||Sancastle Technologies, Ltd||Extension of fibre channel addressing|
|US20030118053 *||26 Dec 2001||26 Jun 2003||Andiamo Systems, Inc.||Methods and apparatus for encapsulating a frame for transmission in a storage area network|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US7466712||30 Jul 2004||16 Dec 2008||Brocade Communications Systems, Inc.||System and method for providing proxy and translation domains in a fibre channel router|
|US7483387||23 May 2005||27 Jan 2009||Cisco Technology, Inc.||Hierarchical label distribution for inter-area summarization of edge-device addresses|
|US7533175 *||24 Oct 2003||12 May 2009||Network Appliance, Inc.||Network address resolution and forwarding TCP/IP packets over a fibre channel network|
|US7577134||19 Aug 2005||18 Aug 2009||Brocade Communications Systems, Inc.||Port expander for fibre channel fabrics in storage area networks|
|US7644179 *||1 Dec 2005||5 Jan 2010||Cisco Technology, Inc.||Inter-VSAN routing with NAT|
|US7707309||29 Jan 2004||27 Apr 2010||Brocade Communication Systems, Inc.||Isolation switch for fibre channel fabrics in storage area networks|
|US7734808||11 Feb 2004||8 Jun 2010||Cisco Technology, Inc.||End-to-end congestion control in a Fibre Channel network|
|US7742484||30 Jul 2004||22 Jun 2010||Brocade Communications Systems, Inc.||Multifabric communication using a backbone fabric|
|US7760717 *||25 Oct 2005||20 Jul 2010||Brocade Communications Systems, Inc.||Interface switch for use with fibre channel fabrics in storage area networks|
|US7769023||21 Dec 2005||3 Aug 2010||Cisco Technology, Inc.||Fibre channel traffic redirect scheme using access control lists|
|US7877512||11 Mar 2010||25 Jan 2011||Brocade Communications Systems, Inc.||Isolation switch for fibre channel fabrics in storage area networks|
|US7890654 *||15 Dec 2005||15 Feb 2011||Cisco Technology, Inc.||Dynamic inter-VSAN topology discovery|
|US7936769||30 Jul 2004||3 May 2011||Brocade Communications System, Inc.||Multifabric zone device import and export|
|US7984253||30 Sep 2010||19 Jul 2011||Emc Corporation||Architecture for virtualization of networked storage resources|
|US7992038||1 Jul 2010||2 Aug 2011||Emc Corporation||Failure protection in an environment including virtualization of networked storage resources|
|US8018936||26 May 2005||13 Sep 2011||Brocade Communications Systems, Inc.||Inter-fabric routing|
|US8032701 *||30 Mar 2007||4 Oct 2011||Emc Corporation||System and method for managing provisioning of storage resources in a network with virtualization of resources in such a network|
|US8040795||10 May 2006||18 Oct 2011||Cisco Technology, Inc.||Backup path convergence in the APS environment|
|US8055794||10 Jan 2011||8 Nov 2011||Brocade Communications Systems, Inc.||Isolation switch for fibre channel fabrics in storage area networks|
|US8059664 *||30 Jul 2004||15 Nov 2011||Brocade Communications Systems, Inc.||Multifabric global header|
|US8125992||17 Nov 2008||28 Feb 2012||Brocade Communications Systems, Inc.||System and method for providing proxy and translation domains in a fibre channel router|
|US8135858||21 Sep 2011||13 Mar 2012||Brocade Communications Systems, Inc.||Isolation switch for fibre channel fabrics in storage area networks|
|US8214599||23 Oct 2009||3 Jul 2012||Gridiron Systems, Inc.||Storage device prefetch system using directed graph clusters|
|US8214608||23 Oct 2009||3 Jul 2012||Gridiron Systems, Inc.||Behavioral monitoring of storage access patterns|
|US8228820||9 Jul 2009||24 Jul 2012||Brocade Communications System, Inc.||Port expander for fibre channel fabrics in storage area networks|
|US8285961||11 Nov 2009||9 Oct 2012||Grid Iron Systems, Inc.||Dynamic performance virtualization for disk access|
|US8307048||15 Jul 2008||6 Nov 2012||International Business Machines Corporation||Network system with initiator subnetwork communication to target subnetwork communication including fibre channel over ethernet to fibre channel over internet protocol conversion|
|US8310953||21 Aug 2007||13 Nov 2012||International Business Machines Corporation||Method and apparatus for enabling an adapter in a network device to discover the name of another adapter of another network device in a network system|
|US8396009||21 Aug 2007||12 Mar 2013||International Business Machines Corporation||Method and apparatus for an adapter in a network device to discover its adapter name in a network system|
|US8402198||28 May 2010||19 Mar 2013||Violin Memory, Inc.||Mapping engine for a storage device|
|US8402246||26 Aug 2010||19 Mar 2013||Violin Memory, Inc.||Alignment adjustment in a tiered storage system|
|US8417871||13 Apr 2010||9 Apr 2013||Violin Memory Inc.||System for increasing storage media performance|
|US8417895||4 Jun 2010||9 Apr 2013||Violin Memory Inc.||System for maintaining coherency during offline changes to storage media|
|US8442059 *||12 Aug 2010||14 May 2013||Gridiron Systems, Inc.||Storage proxy with virtual ports configuration|
|US8443150||24 Sep 2010||14 May 2013||Violin Memory Inc.||Efficient reloading of data into cache resource|
|US8446913||10 Mar 2011||21 May 2013||Brocade Communications Systems, Inc.||Multifabric zone device import and export|
|US8472482||27 Oct 2008||25 Jun 2013||Cisco Technology, Inc.||Multiple infiniband ports within a higher data rate port using multiplexing|
|US8532119||30 Jul 2004||10 Sep 2013||Brocade Communications Systems, Inc.||Interfabric routing header for use with a backbone fabric|
|US8594080 *||29 Oct 2010||26 Nov 2013||International Business Machines Corporation||Multiple functionality in a virtual storage area network device|
|US8605624 *||29 Aug 2008||10 Dec 2013||Cisco Technology, Inc.||Methods and devices for exchanging peer parameters between network devices|
|US8627005||15 Nov 2010||7 Jan 2014||Emc Corporation||System and method for virtualization of networked storage resources|
|US8635375||14 Apr 2010||21 Jan 2014||Brocade Communications Systems, Inc.||Remote F—ports|
|US8635416||2 Mar 2011||21 Jan 2014||Violin Memory Inc.||Apparatus, method and system for using shadow drives for alternative drive commands|
|US8650362||13 Apr 2010||11 Feb 2014||Violin Memory Inc.||System for increasing utilization of storage media|
|US8656100 *||25 Aug 2011||18 Feb 2014||Emc Corporation||System and method for managing provisioning of storage resources in a network with virtualization of resources in such a network|
|US8667366||18 Nov 2010||4 Mar 2014||Violin Memory, Inc.||Efficient use of physical address space for data overflow and validation|
|US8713252||4 May 2010||29 Apr 2014||Violin Memory, Inc.||Transactional consistency scheme|
|US8730977 *||1 Jun 2007||20 May 2014||Thomson Licensing||Method of transferring data between a sending station in a first network and a receiving station in a second network, and apparatus for controlling the communication between the sending station in the first network and the receiving station in the second network|
|US8775741||8 Jan 2010||8 Jul 2014||Violin Memory Inc.||Using temporal access patterns for determining prefetch suitability|
|US8782245||10 Apr 2012||15 Jul 2014||Emc Corporation||System and method for managing provisioning of storage resources in a network with virtualization of resources in such a network|
|US8788758||12 Jan 2011||22 Jul 2014||Violin Memory Inc||Least profitability used caching scheme|
|US8830836||3 Jan 2013||9 Sep 2014||Violin Memory, Inc.||Storage proxy with virtual ports configuration|
|US8832384||29 Jul 2010||9 Sep 2014||Violin Memory, Inc.||Reassembling abstracted memory accesses for prefetching|
|US8838850||16 Nov 2009||16 Sep 2014||Violin Memory, Inc.||Cluster control protocol|
|US8856589||22 Jun 2011||7 Oct 2014||Emc Corporation||Failure protection in an environment including virtualization of networked storage resources|
|US8886771||15 May 2006||11 Nov 2014||Cisco Technology, Inc.||Method and system for providing distributed allowed domains in a data network|
|US8897294||21 May 2010||25 Nov 2014||Brocade Communications Systems, Inc.||Interface switch for use with fibre channel fabrics in storage area networks|
|US8959288||3 Aug 2010||17 Feb 2015||Violin Memory, Inc.||Identifying invalid cache data|
|US8972689||2 Feb 2011||3 Mar 2015||Violin Memory, Inc.||Apparatus, method and system for using real-time performance feedback for modeling and improving access to solid state media|
|US9069676||12 Feb 2013||30 Jun 2015||Violin Memory, Inc.||Mapping engine for a storage device|
|US20050198523 *||29 Jan 2004||8 Sep 2005||Brocade Communications Systems, Inc.||Isolation switch for fibre channel fabrics in storage area networks|
|US20060023707 *||30 Jul 2004||2 Feb 2006||Makishima Dennis H||System and method for providing proxy and translation domains in a fibre channel router|
|US20060023708 *||30 Jul 2004||2 Feb 2006||Snively Robert N||Interfabric routing header for use with a backbone fabric|
|US20060023726 *||30 Jul 2004||2 Feb 2006||Chung Daniel J Y||Multifabric zone device import and export|
|US20060023751 *||30 Jul 2004||2 Feb 2006||Wilson Steven L||Multifabric global header|
|US20060034302 *||26 May 2005||16 Feb 2006||David Peterson||Inter-fabric routing|
|US20070058619 *||19 Aug 2005||15 Mar 2007||Gopal Gowda Manjunath A||Port expander for fibre channel fabrics in storage area networks|
|US20070058620 *||31 Aug 2005||15 Mar 2007||Mcdata Corporation||Management of a switch fabric through functionality conservation|
|US20070091903 *||25 Oct 2005||26 Apr 2007||Brocade Communications Systems, Inc.||Interface switch for use with fibre channel fabrics in storage area networks|
|US20080316942 *||29 Aug 2008||25 Dec 2008||Cisco Technology, Inc.||Methods and devices for exchanging peer parameters between network devices|
|US20120110385 *||3 May 2012||International Business Machines Corporation||Multiple functionality in a virtual storage area network device|
|International Classification||G06F13/10, H04L12/28, H04L12/44, H04L29/08, H04L12/46|
|Cooperative Classification||H04L2212/00, H04L67/1097, H04L12/4641|
|European Classification||H04L12/46V, H04L29/08N9S|
|17 Sep 2004||AS||Assignment|
Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DUTT, DINESH G.;GAI, SILVANO;RAIMONDO, BRUNO;AND OTHERS;REEL/FRAME:015792/0176;SIGNING DATES FROM 20040824 TO 20040901