US7916628B2 - Trunking for fabric ports in fibre channel switches and attached devices - Google Patents

Trunking for fabric ports in fibre channel switches and attached devices Download PDF

Info

Publication number
US7916628B2
US7916628B2 US10/979,886 US97988604A US7916628B2 US 7916628 B2 US7916628 B2 US 7916628B2 US 97988604 A US97988604 A US 97988604A US 7916628 B2 US7916628 B2 US 7916628B2
Authority
US
United States
Prior art keywords
port
trunking
virtual
sans
ports
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US10/979,886
Other versions
US20060092932A1 (en
Inventor
Kalyan K. Ghosh
Praveen Jain
Shashank Gupta
Tushar Desai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cisco Technology Inc
Original Assignee
Cisco Technology Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cisco Technology Inc filed Critical Cisco Technology Inc
Priority to US10/979,886 priority Critical patent/US7916628B2/en
Assigned to CISCO TECHNOLOGY, INC. reassignment CISCO TECHNOLOGY, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: DESAI, TUSHAR, GHOSH, KALYAN K., GUPTA, SHASHANK, JAIN, PRAVEEN
Publication of US20060092932A1 publication Critical patent/US20060092932A1/en
Priority to US13/031,013 priority patent/US8750094B2/en
Application granted granted Critical
Publication of US7916628B2 publication Critical patent/US7916628B2/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/25Routing or path finding in a switch fabric
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/30Peripheral units, e.g. input or output ports
    • H04L49/3009Header conversion, routing tables or routing tags
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00Packet switching elements
    • H04L49/35Switches specially adapted for specific applications
    • H04L49/356Switches specially adapted for specific applications for storage area networks
    • H04L49/357Fibre channel switches

Definitions

  • This invention pertains to Fibre Channel networks and the devices and methods implemented therein. More specifically, the invention pertains to devices and methods for extending trunking functionality to fabric ports on switches and attached devices.
  • SAN Storage Area Network
  • a storage area network is a high-speed special-purpose network that interconnects different data storage devices and associated data hosts on behalf of a larger network of users.
  • a SAN may use various types of network traffic, but more often than not it employs Fibre Channel frames.
  • SAN islands For example, a business might employ one SAN island for human resources applications, another SAN island for engineering applications, another for marketing, etc. Each SAN island contains a physically isolated switch or a group of switches for connecting hosts to storage devices. While this approach may enforce separation of data between various groups in an organization, it frequently under utilizes hardware and management resources.
  • VSANs virtual SANs
  • MDS9000 family of switches from Cisco Systems, Inc. of San Jose, Calif.
  • Cisco Systems, Inc. of San Jose, Calif.
  • VSANs virtual SANs
  • a multiple SAN islands may be collapsed to a single physical infrastructure, thereby reducing hardware costs and improving manageability while maintaining the stability and traffic isolation of the SAN island model.
  • Each VSAN is logically separate and may be assigned to a separate group, e.g., marketing, engineering, etc.
  • this collapsed fabric model some or all switches and inter-switch links in the fabric carry traffic for multiple VSANs.
  • E_Ports interconnect ports
  • HBAs host bus adaptors
  • F_Ports or FL_Ports could be configured in one VSAN only.
  • the VSAN of the attached switch port also called the “port VSAN” is implicitly assigned to the HBA and all traffic transmitted or received by the HBA belongs to that VSAN.
  • Fibre Channel VSAN implementations require that node devices employ multiple HBAs to connect to multiple switchports—one for each supported VSAN—to achieve multi-homing (participation in multiple VSANs). This redundancy is wasteful. So while the deployment of multiple VSANs on a common topology represents a significant advance in storage area network technology, the requirement that a node have a separate physical interface for each of its VSANs presents a significant waste of resources. Therefore, an improved protocol and apparatus design to provide more efficient use of N_Port and F_Port resources is needed.
  • the present invention addresses this need by providing new logic for node ports and fabric ports.
  • the logic allows designation of multiple virtual interfaces on a single host bus adaptor or other Fibre Channel interface, with one virtual interface for each VSAN available on the node interface.
  • Node ports with this additional functionality are referred to as trunking N_Ports or TN_Ports.
  • These ports have a functional design allowing creation of the multiple virtual interfaces as appropriate for the application at hand.
  • This port design also includes logic for communicating with a peer fabric port to initialize and modify the configuration of the virtual interfaces on the TN_Port.
  • the invention further provides a corresponding functional design and communication logic in fabric ports, referred to herein as trunking F_Ports or TF_Ports.
  • the port includes a controller for managing trunking on the port by communicating with a peer port over the Fibre Channel link. Through the communication, the port can determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces, with each virtual SAN interface providing the functionality of a single virtual SAN. For determining whether virtual SAN functionality is available, the controller is designed or configured to negotiate a mode of operation with the peer, with the available modes of operation include trunking and non-trunking over the Fibre Channel link.
  • the controller is designed or configured to identify VSANs common to the switch port and the node port.
  • the communication for managing trunking takes place using an Exchange Peer Parameter (EPP) protocol.
  • EPP Exchange Peer Parameter
  • the port may be implemented in hardware, software, or a combination of the two.
  • the trunking N_Port may be characterized by the following features: (a) a physical N_Port interface designed or configured to provide functionality of a non-trunking N_Port when virtual SAN functionality is not available; and (b) a controller for managing trunking on the trunking N_Port.
  • the controller in this aspect is designed or configured to communicate with an F_Port on a Fibre Channel switch and determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces on the trunking N_Port, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN.
  • the physical N_Port functionality provides no information regarding virtual SANs in frames transmitted therefrom.
  • the one or more of the virtual SAN interfaces are designed or configured to provide frames containing information identifying the particular virtual SAN to which it belongs. Such information may be provided in an EISL header for the frames. Such frames may also specify QoS parameters, MPLS features, etc. available for the virtual SANs.
  • the controller has a Fibre Channel well known address but is typically designed such that it does not take part in data traffic.
  • a further aspect of the invention pertains to methods of establishing a link between a trunking N_Port on a node and an F_Port on a Fibre Channel switch.
  • Such methods may be characterized by the following sequence: (a) determining whether virtual SAN functionality exists on the F_Port; and (b) defining one or more virtual SAN interfaces on the trunking N_Port, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN.
  • both (a) and (b) are both implemented by communicating between the trunking N_Port on a node and the F_Port. Such communication may be accomplished using the EPP protocol, for example.
  • Another aspect of the invention pertains to storage networks including multiple nodes having trunking N_Ports and a fabric comprised of switches having F_Ports linked to the trunking N_Ports.
  • the trunking N_Ports comprise controllers designed or configured to communicate with F_Ports on a Fibre Channel switch and determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces on their trunking N_Ports, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN.
  • Still another aspect of the invention pertains to computer program products including machine-readable media on which are stored program instructions for implementing at least some portion of the methods described above. Any of the methods of this invention may be directed, in whole or in part, by executing program instructions provided on such computer readable media.
  • the invention pertains to various combinations of data and data structures generated and/or used as described herein.
  • FIG. 1A is a diagram of a simple storage area network including a storage area network fabric and associated end nodes, which belong to two different VSANs.
  • FIG. 1B is a diagram of a simple storage area network including a storage area network fabric and associated end nodes employing trunking N_Ports, which support traffic for two different VSANs.
  • FIG. 2 is a block diagram showing various functional components of trunking N_Port in accordance with an embodiment of this invention.
  • FIG. 3 is an interaction diagram depicting, at a relatively high level, some interactions between a trunking F_Port and a trunking N_Port in setting up a trunking link that supports multiple VSANs, in accordance with an embodiment of this invention.
  • FIG. 4 is a table showing how different configurations of the F_Port and TN_Port may result in different modes of operation on a shared link.
  • FIG. 5A is an interaction diagram showing a message exchange in which a TN_Port learns that an F_Port does not support a protocol (EPP) for determining trunking parameters on a link.
  • EPP protocol
  • FIG. 5B is an interaction diagram showing a message exchange in which a TN_Port learns that an F_Port supports a protocol (EPP) for determining trunking parameters on a link.
  • EPP protocol
  • FIG. 6A is a schematic representation of an EPP frame format including TLV sections in the EPP payload.
  • FIG. 6B is a table showing a matrix for trunk mode negotiation between a TN_Port and an F_Port in accordance with one embodiment of this invention.
  • FIG. 7 is an interaction diagram showing how the EPP protocol may be used to negotiate trunking parameters in accordance with one embodiment of this invention.
  • FIG. 8 depicts a switch or other network device that may be configured to perform the methods of the present invention.
  • Trunking allows a single port and associated link to carry traffic for multiple different virtual groups of network devices (e.g., multiple VSANs).
  • a single physical infrastructure can support these separate groups, each of which may require its own security policy, quality of service parameters (QoS), communications protocols, etc.
  • QoS quality of service parameters
  • VSANs may also be designed to support MPLS in Fibre Channel infrastructures.
  • N_Ports reside network end nodes such as hosts and disks.
  • F_Ports reside on fabric switches and connect to N_Ports to provide links between nodes and fabric switches.
  • E_Ports are used for links between fabric switches, inter-switch links (ISLs). To date only E_Ports have been designed to carry traffic for multiple VSANs.
  • the present invention allows for an improved SAN design in which the HBAs or other node interfaces can be configured in multiple VSANs. In this manner, multi-homing is achieved even while attaching a single N_Port to a single F_Port. This improves the utilization factor of bandwidth in HBAs (and the attached switch ports), reducing the overall port count requirement in the SAN, and hence, reducing the overall Total Cost of Ownership (TCO).
  • One example application for trunking with HBAs is the tape backup application where instead of having one HBA for each VSAN to be backed up, one HBA may be used for backup of multiple VSANs.
  • FIG. 1A depicts a simple storage area network including a storage area network fabric 101 and associated end nodes. These nodes include hosts 114 , 116 , and 128 , as well as storage disks 104 , 106 , and 108 . The hosts may be servers or other computers requiring access to the data on the disks. Fabric 101 is comprised of switches 118 , 120 , and 122 coupled by inter-switch links 124 , 127 , and 126 . These switches run a storage area network protocol such as Fibre Channel, which provides communication between the nodes via Fibre Channel frames.
  • Fibre Channel Fibre Channel
  • a single infrastructure such as fabric 101 can support multiple VSANs, each associated with a distinct group of nodes.
  • VSAN 1 and VSAN 2 two VSANs are implemented on the storage area network, VSAN 1 and VSAN 2 .
  • the nodes belonging to VSAN 1 are hosts 114 and 128 and disk 106 . All three switches have dedicated ports that support traffic on VSAN 1 .
  • the nodes belonging to VSAN 2 are hosts 116 and 128 , as well as disks 104 and 108 . Only switches 120 and 122 allow traffic on both VSAN 1 and VSAN 2 .
  • Switch 118 is dedicated to traffic on VSAN 1 . Note that links carrying traffic on VSAN 1 are indicated by solid lines while links carrying traffic on VSAN 2 are indicated by dashed lines.
  • Inter-switch links employ Fibre Channel E_Ports.
  • Fabric ports are ports on switches that communicate over links with node ports (N_Ports).
  • E_Ports are referred to trunking E_Ports or “TE_Ports.” It is important to note that in current technology, as depicted in FIG. 1A , trunking is limited to inter-switch links. Links between N_Ports and F_Ports are necessarily non-trunking. As indicated, this presents a burden if a particular node needs to communicate on multiple VSANs.
  • node 128 belongs to both VSAN 1 and VSAN 2 .
  • hosts 128 must include separate ports (network interfaces such as HBAs) for each VSAN.
  • each switch must provide a separate F_Port for each VSAN over which it and its associated node will communicate. This situation is depicted in switch 122 of fabric 101 .
  • trunking N_Ports (TN_Ports) and trunking F_Ports (TF_Ports). These allow a single HBA or other node interface to communicate with a single F_Port and provide edge traffic for two separate VSANs over a single link.
  • FIG. 1B where host 128 , which belongs to both VSAN 1 and VSAN 2 , contains a single HBA 134 connected to switch 122 via a link 136 . This link is coupled to a trunking F_Port 138 on switch 122 .
  • link 136 carries traffic for both VSAN 1 and VSAN 2 , and is thus deemed a trunking link.
  • the principal difference between the networks depicted in FIGS. 1A and 1B is in the use of a single HBA 134 and a single F_Port 138 for communications between node 128 and switch 122 , which communications may include traffic on both VSAN 1 and VSAN 2 .
  • a TN_Port will include some control logic that can set up and initialize multiple virtual interfaces in a single node port.
  • the control logic will need to communicate with corresponding logic on a trunking fabric port to negotiate and identify supported VSANs on the common link.
  • the control logic may also communicate and negotiate to the extent needed state changes in existing trunk links. Such changes may include conversion from trunking to non-trunking, change in the list of supported or available VSANs, changes from non-trunking to trunking, etc.
  • the control logic initially determines whether its peer fabric port supports or currently permits establishment of VSANs and/or trunking. It may use a conventional node login procedure for this purpose, e.g., FLOGI in the case of Fibre Channel. If it is determined that the fabric port cannot or currently does not support trunking, then it may configure the TN_Port to act as a conventional N_Port which does not explicitly recognize VSANs. If the control logic does find that its peer F_Port supports and permits trunking, it may then negotiate with the F_Port to determine which VSANs will be supported in the trunking link.
  • a conventional node login procedure for this purpose, e.g., FLOGI in the case of Fibre Channel. If it is determined that the fabric port cannot or currently does not support trunking, then it may configure the TN_Port to act as a conventional N_Port which does not explicitly recognize VSANs. If the control logic does find that its peer F_Port supports and permits trunking, it may then negotiate with the F_Port to determine which VSANs will be supported in
  • the fabric port will similarly contain control logic for confirming that it supports trunking and for negotiating appropriate parameters (list of supported VSANs for the link, etc.) with the TN_Port.
  • Appropriate functional designs for the TN_Port and TF_Port will be described below.
  • Fibre Channel node device e.g., a host bus adaptor
  • TN_Port Trunking N port
  • Such a device when attached to a switchport in TF_Port mode can transmit and receive frames in one or more VSANs over the same physical link. In one embodiment, this is accomplished when using the EISL frame format.
  • FIG. 2 One example of a TN_Port model is shown in FIG. 2 .
  • a fabric switch 205 is coupled to a node 201 by a Fibre Channel link 203 .
  • Data transmission and management of the link is provided by a fabric port 211 in switch 205 and a node port 207 in node 201 . These are configured as trunking ports having functionality described herein.
  • TN_Port 207 includes three types of logical entities: an HBA Controller N_Port 213 , a Physical HBA interface 215 , and one or more virtual HBA interfaces (one for each VSAN configured) 217 .
  • Each of these logical entities exchanges frames over the same physical link 203 attached to the TN_Port.
  • the physical link 203 can receive frames specifying a VSAN or other virtual fabric (in for example EISL format).
  • the TN_Port 207 can operate in various modes as explained below. Even if it is in a mode that does not support trunking, it can implicitly support a single VSAN, as with current technology.
  • the HBA Controller N_Port 213 is a logical entity that is responsible for communicating with attached TF_Port 211 for configuration and management of trunking feature on TN_Port 207 . It may accomplish this using any appropriate communication protocol.
  • the configuration and management communications take the form of Fibre Channel exchanges using the Exchange Peer Parameter (EPP) protocol.
  • EPP Exchange Peer Parameter
  • the entity may behave like an N_Port with a well-known address, but it does not take part in data traffic.
  • the HBA Controller N_Port 213 may be given a well-known address (WKA), e.g., the value hex FFFFFD. It may also be given a unique VSAN tag or ID (e.g., 4094) to use during these configuration and management communications.
  • WKA well-known address
  • a virtual HBA interface 217 is a logical entity of the TN_Port that mimics the functionality of a physical N_Port attached to an F_Port, but exchanges traffic in one VSAN only. Configuration exchanges, as described below, are established to specify the number and identities of virtual HBA interfaces 217 .
  • the VSAN IDs are assigned by the controller 213 to individual virtual HBA interfaces based upon parameter values established during set up with the TF_Port 211 .
  • a WWN is assigned by node device 201 .
  • each TN_Port has the ability to instantiate one or more such virtual HBAs, one for each configured VSAN.
  • Three virtual HBA interfaces 217 are shown in TN_Port 207 . Each has the ability to apply its own VSAN tag to outgoing frames. Each also has the ability to process incoming frames sorted to it based on VSAN tag.
  • Applications running on node 201 communicate with individual ones of the virtual HBA interfaces 217 based on their participation in the various supported VSANs.
  • the virtual HBA interfaces 217 each perform FLOGI in the manner of a conventional N_Port and take part in data traffic in the configured VSAN.
  • All frames transmitted and received by the virtual HBAs 217 are carried over the same physical link 203 between the TN_Port 207 and the attached F_Port 211 . If link 203 is operational in trunking, all frames are tagged in EISL format (or other VSAN aware format); otherwise, all frames are untagged.
  • the Physical HBA Interface 215 is an optional logical entity that mimics the functionality of a physical N_Port attached to an F_Port but is not VSAN aware. It comes into play when either virtual HBA support of the TN_Port is disabled or the attached F_Port does not support VSANs, as well as a communication protocol for configuring VSANs on N_Port 207 . This interface is not used when any of the virtual HBAs 217 are instantiated and active. Most commonly, this interface is used when the TN_Port is attached to a switch that is not VSAN aware or when the applications running on node 201 do not support virtual HBA interfaces.
  • Physical HBA Interface 215 When activated, Physical HBA Interface 215 exchanges all traffic originating with and received by TN_port 207 . All such traffic is untagged. In all other aspects, data transfer on interface 215 resembles that on conventional HBAs, which have no knowledge of VSANs. For Physical Interface 215 , a VSAN ID may be implicitly assigned by the F_Port, and a WWN is assigned by node device 201 .
  • Physical HBA interface 215 may be unnecessary.
  • One such implementation could, for example, employ at least one instance of block 217 and this could also perform the function of the Physical HBA when needed.
  • the HBA controller block 213 is also shown as one possible way to implement the functionality required. It may not be required in alternate implementations.
  • TF_Port The logical design of a TF_Port is generally similar to that of the TN_Port and mirrors its functionality in many ways. It supports multiple VSANs and may be viewed as creating a virtual interface for each separate VSAN, in the manner depicted for the TN_Port in FIG. 2 . Each virtual interface may have the ability to apply a VSAN label to outgoing frames. And incoming VSAN frames are sorted to the individual virtual interfaces for separate handling. Generally, however, the F_Port virtual interfaces need not have the ability to handle FLOGI frames or provide as much support to higher level applications as is provided by the virtual HBA interfaces in TN_Ports, at least in some implementations.
  • an F_Port becomes operational in TF_Port mode, if the attached Fibre Channel node supports EPP services and the trunk mode configuration at both ends of the link allows trunking.
  • Various methods and functional designs may be employed to configure linked N_Ports and F_Ports for trunking.
  • a three-phase procedure is employed. First, the N_Port determines whether the F_Port can communicate via a protocol intended to allow configuration. Assuming that the N_Port confirms this, the ports then use such protocol to negotiate parameter values needed to configure their link. Examples of such parameters include mode of operation for the ports (trunking versus non-trunking), number of VSANs supported, and identification of VSANs supported. Finally, after the negotiation is complete and the link VSANs are identified (if any), each individual virtual HBA interface separately logs into the fabric (for its particular VSAN). Any other pre-login protocols, as applicable shall be performed before the logins performed by individual virtual HBA interfaces.
  • FIG. 3 This basic procedure is illustrated in FIG. 3 , where interactions between an F_Port 301 and a TN_Port 303 are depicted as diagonal lines.
  • the process begins with TN_Port 303 sending a frame 305 to F_Port 303 proposing trunking (or at least some form of communication under a defined protocol for configuring trunking).
  • the F_Port then recognizes that it is being asked to communicate in the protocol and responds with a frame 307 confirming that it can and will communicate in such protocol.
  • TN_Port 303 receives this message, it prepares to enter the second phase of the setup. Note that if the TN_Port has a functional design as illustrated in FIG. 2 , the logic to send frame 305 and interpret frame 307 may reside with the Physical HBA Interface 215 . No VSAN support has yet been confirmed, so communication via a conventional HBA is appropriate.
  • HBA controller N_Port 213 takes over (again assuming the functional design of FIG. 2 ).
  • a series of communications may be required to fully negotiate the parameter set going forward.
  • two communications are intended to represent the entire negotiation phase of setup. These are a message 309 from the TN_Port to initiate negotiation and a message 311 from F_Port 301 to conclude negotiation.
  • the negotiation takes place in an EPP protocol.
  • each of these may initiate a separate fabric login for its specific VSAN. This is indicated by FLOGI messages 313 and 315 from the TN_Port 303 .
  • the active virtual HBA interfaces ( 217 from FIG. 2 ) send the FLOGI messages.
  • Corresponding logic in F_Port 301 provides the fabric side of the login for each virtual HBA interface.
  • the particular mode of operation is governed by the current states of the node and fabric ports.
  • the switchport state may or may not support the chosen communication protocol for negotiating VSAN services on the link (e.g., EPP).
  • the current trunking configurations may be different at the two ends.
  • the particular mode adopted at any time is determined in large measure by the current configuration of the fabric switchport.
  • the TN_Port itself may be configured to enable or disable virtual VSAN support based on the applications supported by the HBA. If, for example, the supported and active applications do not require VSAN differentiation, then it may be appropriate to disable virtual VSAN support.
  • FIG. 4 depicts the various modes of operation in accordance the described embodiment. As shown, the port settings and capabilities specify modes of operation as follows:
  • TN_Port When virtual HBA support is disabled in the TN_Port, its trunking capability is necessarily disabled, and the physical HBA interface is used for all traffic; the HBA contoller N_Port and the virtual HBA interfaces are not used.
  • the TN_Port is thus configured if, for example, (a) the applications supported do not require operation in multiple VSANs or cannot make use VSAN specific features such as QoS or (b) the TN_Port is intended to be attached to a switch that does not support trunking.
  • the node applications are expected to work with one or more of the virtual HBA interfaces, and the TN_Port is expected to be attached to a switch that can support trunking.
  • the TN_Port is thus configured but attached to a switch that does not support the defined negotiation protocol or has such support disabled, the TN_Port will behave like a normal N_Port, as mentioned above, and the physical HBA interface will be used.
  • the operational trunk mode of the link is determined during negotiation of services, and it depends on the trunk mode configuration at both endpoints (discussed later). In this case, the physical HBA interface is not used irrespective of the operational trunk mode of the link.
  • the virtual HBA interface for the port VSAN of the attached port is used instead of the physical HBA interface to ensure smooth transition from non-trunking to trunking mode of the link.
  • the node and fabric ports must first agree on a set of parameters for their link. To accomplish this, they must employ a common protocol for the setup. Thus, as an initial matter, the ports must determine that their peer is prepared to communicate using such common protocol.
  • a common protocol is the Exchange Peer Parameter (EPP) protocol, and an implementation of the invention employing EPP will be described below.
  • EPP Exchange Peer Parameter
  • Other examples setup protocols include the existing FC SW-ILS request response based protocol.
  • the EPP protocol may be enabled as a registration/set-up protocol for TN_Ports.
  • One procedure for detecting EPP capability will now be described. In this procedure, if EPP capability is not detected, then the peer node port and switch port do not use a VSAN-specific communication for any set-up or data traffic purposes. In this case, there will be no negotiation of VSAN parameters. And in the embodiment depicted in FIG. 2 , all subsequent communication from the TN_Port will take place via the physical HBA interface.
  • the TN_Port and the F_Port subsequently negotiate appropriate VSAN parameters for future data traffic. As indicated elsewhere, this entails determining common features for the link including the mode of operation, a particular port VSAN (for non-trunking applications), and a list of common VSANs to be supported by the link. Other link-related parameters may be negotiated at this time as well.
  • One mechanism for detecting EPP capability employs the Fibre Channel log in sequence, wherein the N_Port begins the process by sending an FLOGI. This implementation is depicted in FIGS. 5A and 5B . Because Fibre Channel requires the N_Port to send an FLOGI message after link initialization, EPP detection can be conveniently implemented during this stage.
  • FIG. 5A depicts a scenario in which the F_Port does not support EPP and hence trunking is not enabled over the link.
  • the TN_Port 501 begins the process with an FLOGI frame 505 .
  • This message has been slightly modified from the standard FLOGI frame format in that it has some indication that specifies to a capable F_Port that an EPP exchange is desired.
  • an F_Port 503 does not support EPP and/or has its trunking feature disabled.
  • F_Port 503 receives FLOGI frame 505 , it responds in a manner indicating to TN_Port 501 that it either did not detect the indication of EPP support and/or it does not support EPP or trunking currently.
  • the message 507 sent by F_Port 503 to indicate this is an accept message for fabric login (LS_ACC) having a fabric address.
  • TN_Port 501 now understands that F_Port 503 will not participate in the desired parameter exchange to support VSAN trunking, the physical HBA interface of the TN_Port becomes active and the link operates in a non-trunking mode. Note that even though the F_Port does not participate in the trunking negotiation, it may still support VSAN applications. It simply may not have been prepared to participate in a parameter exchange or trunking. In this case, F_Port 503 will treat all frames as belonging to its port VSAN.
  • FIG. 5B depicts a different scenario in which F_Port 503 supports EPP and is prepared to engage in a parameter exchange with TN_Port 501 .
  • TN_Port 501 again begins the process by sending a modified FLOGI message 505 .
  • F_Port 503 which supports EPP and desires to define parameters for the link, responds with a different message, one that indicates to TN_Port 501 that it should initiate parameter exchange.
  • F_Port 503 transmits a login reject message (LS_RJT) frame in response to the FLOGI message.
  • This frame contains a specific indication that EPP is supported.
  • the HBA controller N_Port (assuming the FIG. 2 architecture) takes over and begins negotiation on the EPP protocol.
  • Various options can be employed for embedding a request for EPP communication in the FLOGI frame.
  • the existing FLOGI frame format is employed and some field in that frame has a value specifically chosen to indicate EPP support.
  • a particular value is inserted into the vendor specific information field of the FLOGI frame payload.
  • a vendor version value may be set to hex 01 .
  • a 16 bit field defined for vendor specific service parameters can have a bit reserve to identify EPP support.
  • the standard format for FLOGI frames is modified to accommodate a flag or other indicator for EPP support.
  • the standard is modified to define a new field understood by all devices to indicate a desire to communicate by EPP.
  • the F_Port may send a reject frame (LS_RJT) as indicated in FIG. 5B .
  • the frame includes a vendor unique error code (e.g., hex FF) with an explanation that EPP is not supported (as understood by TN_Ports).
  • the most significant byte of the ELS command code can be passed on in the reject message (e.g., AB when EPP uses 0xAB000000 as the ELS command code). This allows the HBA controller N_Port (assuming a FIG. 2 architecture) to use this value to receive and send EPP service frames.
  • the F_Port replies to the FLOGI message by sending a conventional login accept frame (LS_ACC), but with some special indication that EPP is supported.
  • the accept frame contains a fabric address of all zeros.
  • the F_Port may make note of the values of various parameters specified in the FLOGI message for later use during logins by the individual virtual HBAs defined during the EPP parameter exchange.
  • the F_Port may also perform configuration of relevant hardware and software elements before sending its LS_RJT response shown in FIG. 5B . Examples of parameters that may be noted by the F_Port include BB_credit, receive data field size, E_D_TOV, etc. If any of these values is not acceptable, the F_Port may respond with an LS_RJT frame having appropriate reason codes as specified in the Fibre Channel standard. If the TN_Port receives such a rejection, it may first take care of the specified issue and then try again with another FLOGI to detect EPP capability.
  • an EPP frame format is shown in FIG. 6A .
  • an EPP frame 601 includes an EISL header 603 , a 24 byte Fibre Channel header 605 , a 20 byte EPP header 607 , and multiple “TLV” payloads 609 .
  • the EISL header is optional on EPP frames.
  • EISL header 603 indicates that trunking for multiple VSANs may be supported. As mentioned, some embodiments of the invention set aside a particular VSAN for the sole purpose of management and configuration of trunking on a node-fabric link. As an example, VSAN number 4094 may be reserved for this purpose. Regarding the appropriate fields and format for the EISL header, further discussion is provided in U.S. Patent publication No. US-2003-0118053-A1, previously incorporated by reference.
  • the Fibre Channel header 605 employs the format specified in the ANSI Fibre Channel standard. However, because EPP is implemented as an ELS-bases service, the Fibre Channel header format will be set forth in more detail by the ELS specification. See the ANSI T11 standard specification for Fibre Channel.
  • EPP is a two-phase protocol in which (1) information is exchanged about peer port configurations of interest and (2) results of the exchange of information are applied to hardware and/or software of the peer ports, as needed.
  • the first phase is referred to a “SYNC” phase and the second phase is referred to as a “COMMIT” phase.
  • the EPP protocol may be employed for diverse purposes such as, for example, transitioning port channel configurations and negotiating ISL trunk parameters for supporting multiple VSANs.
  • EPP is described generally in U.S. patent application Ser. No.
  • EPP is but one example of a communication protocol that can be employed for this purpose.
  • the communication protocol need not even be a two-phase protocol; some single-phase protocols can work equally well.
  • the existing FC SW-ILS definition in Fibre Channel can be employed.
  • FC SW-ILS is a request-response based protocol with delivery acknowledgement.
  • the EPP header 607 may also employ a well-known format. Examples of relevant fields in the EPP header include a command code, which indicates whether the EPP exchange is in the SYNC phase or the COMMIT phase, a payload length based upon a calculation involving the number of TLV segments in the payload, and a command identifier specifying whether the frame is an EPP request, an EPP accept, or an EPP reject.
  • a command code which indicates whether the EPP exchange is in the SYNC phase or the COMMIT phase
  • a payload length based upon a calculation involving the number of TLV segments in the payload
  • a command identifier specifying whether the frame is an EPP request, an EPP accept, or an EPP reject.
  • the command identifier for the EPP request used in the exchange to identify trunking parameters will be chosen from the range of vendor specific command identifiers.
  • the proposed value is 0x7f000000.
  • the values for LS_ACC and LS_RJT are specified by ELS.
  • the EPP payload is provided as a collection of TLV sections 609 of frame 601 , each specifying a particular type, length and value.
  • the type also indicates how the EPP frame is to be handled if TLV is not supported at the receiving port. If TLV is not supported, the typical response is either skip procedures involving the TLV information or abort the EPP exchange altogether.
  • the length component of the TLV format specifies the length of the entire TLV portion of the payload for the parameter under consideration.
  • the value component specifies the particular value of the parameter in question.
  • a separate TLV portion is employed for each parameter to be negotiated. These include the mode for communication, a specific port VSAN if communication is to take place in non-trunking mode, and a list of available VSANs to be supported in trunking mode. Together the three TLV portions for these parameters comprise the EPP payload of frame 601 .
  • trunk mode there are three different administrative trunk modes. The first one of these is “OFF” which explicitly indicates that the port should never operate in a trunking mode. The second mode is “ON” which explicitly indicates that the port should operate in trunking mode so long as its peer does not explicitly prohibit that. Finally, a third mode of operation is called “AUTO” which indicates that the port can operate in a trunking mode, so long as the peer is explicitly configured to support trunk mode.
  • Each port will have its own currently activated trunk mode, which is one of these three values.
  • the trunk mode value for that port is specified in its EPP SYNC message at the appropriate location in a TLV portion of its payload.
  • Negotiation of the agreed upon mode for the F_Port and N_Port may be decided based upon a table as shown in FIG. 6B . As shown there, the agreed upon mode is trunking only when one of the ports has its mode set to “ON” and the other port's mode is not “OFF”.
  • this portion of the EPP frame is used by the F_Port to notify its counterpart TN_Port of the VSAN number to be used when the link is operational in non-trunking mode (as determined by the trunk mode negotiation).
  • the allowed VSAN TLV contains a list of allowed VSANs on the port sending the EPP SYNC message.
  • the value field of the allowed VSAN TLV is structured as a bit map with a single bit designated for each VSAN identifier. For the current VSAN ID space, the TLV value field should be at least 512 bytes.
  • the VSAN number N is represented by a bit number N, left to right.
  • the local port logic calculates using a bit-wise AND operator on the received VSAN list (for the EPP frame) and the locally configured VSAN list for that port.
  • TLV-implemented parameters may handle additional parameters to be set up during negotiation. These additional parameters may be identified in additional TLV fields if EPP is employed as the negotiation protocol. These may enhance the functionality of the invention. Examples of other TLV-implemented parameters may include security information.
  • the ports commit negotiated configurations (decided during the sync phase) to there appropriate hardware to make these configurations operational.
  • all EPP service exchanges are preferably performed by controllers in the N_Port and F_Port using a control VSAN (e.g., 4094). If the link is operational in non-trunking mode, the EPP services may need to occur in the port VSAN of the attached F_Port. However, if the TN_Port is not aware of the port VSAN of the attached F_Port (for example, during TN_Port initialization) it may assume that the EPP service exchanges are to take place using the control VSAN.
  • a control VSAN e.g. 4094
  • a TN_Port 701 initiates the EPP sequence by sending an EPP_SYNC frame 705 to an F_Port 703 .
  • the frame will be created as instructed by the HBA controller N_Port using the control VSAN (e.g. 4094).
  • the EPP_SYNC exchange will be transmitted in an untagged format; note the designation “u” in the message sequence.
  • F_Port 703 Upon receiving the EPP_SYNC frame, F_Port 703 will respond back with an LS_ACC frame 707 (also in untagged format) with its configuration information, which includes its trunk mode and VSAN list. Note that EPP_SYNC frame 705 also included this configuration information for the TN_Port.
  • the port applies the rules for parameter negotiation to determine the operational trunk mode and the list of operational VSANs on the link. See action 709 in FIG. 7 . Assuming that the operational trunk mode is ON, then TN_Port 701 will do the necessary hardware and software programming to transmit frames in tagged format and then send an EPP_COMMIT frame 711 from the control VSAN. Thus, this exchange occurs in VSAN 4094 .
  • F_Port 703 On receiving the EPP_COMMIT frame 711 , F_Port 703 then does its own corresponding hardware and software programming to enable transmission of frames in tagged format. See action 714 in FIG. 7 . The F_Port also responds back with an LS_ACC frame 715 , upon successful completion of its own configuration. F_Port 703 will also notify its local applications about the availability of VSANs on that port.
  • LS_ACC message 715 When LS_ACC message 715 is received by TN_Port 701 , it notifies its local operation about the availability of VSANs, which will trigger FLOGIs in each of those VSANs. See action 717 in FIG. 7 . Then, the individual virtual HBA interfaces on TN_Port 701 perform FLOGI in their respective VSANs. As depicted in FIG. 7 , these are VSANs 100 and 200 . FLOGIs 719 and 721 correspond to FLOGIs 313 and 315 in FIG. 3 . The various login parameters (except the port WWN) in these FLOGIs should be the same as in the first FLOGI. This enables the active virtual HBA interface(s) to support data traffic per Fibre Channel standards.
  • EPP_SYNC EPP_SYNC frame with the new VSAN configuration.
  • this exchange is conducted in a control VSAN.
  • the receiver of the EPP_SYNC frame will respond back with an LS_ACC message identifying its current trunk configuration.
  • the initiator receives this LS_ACC message, it will do the necessary hardware and software programming to effect the changes in the operational VSANs.
  • it will send an EPP_COMMIT frame to its peer.
  • the receiver will do the necessary hardware and software programming on its end to reflect the changes in operational VSANs. When it completes this, it will respond with an LS_ACC frame to the initiator and also notify its local applications about the availability of the new VSANs. When receiving the LS_ACC frame, the initiator will notify its local applications about the availability of the new VSANs. Finally, availability of the VSANs on the TN_Port will trigger submission of FLOGI message from the TN_Port, as before. Note that in this scenario, where the link is already trunking before the VSAN configuration has changed, all communications associated with the change take place in tagged format.
  • the trunk mode could change from trunking to non-trunking. This may arise if the mode of operation was changed from ON to OFF or AUTO in a port at one end of the link. If the port where this change is occurring is transitioning from ON mode to AUTO mode, then that port will need to initiate an exchange to determine if the link should continue to operate as trunking or will become non-trunking. This will depend on whether the other port is currently in ON or AUTO mode, as indicated in the table of FIG. 6B .
  • the link will be re-initialized by the F_Port. This is to avoid any merging of VSAN specific traffic into non-tagged traffic.
  • VSAN specific traffic coming out of that port will be transmitted without an EISL header.
  • the receiver will then receive untagged frames, which will be processed in the port VSAN of the receiver.
  • Link re-initialization entails a complete re-initialization of the link, including standard primitive sequences and the FLOGI request-response exchange followed by EPP parameter negotiation as described earlier.
  • the final scenario to be described involves a change from non-trunking mode to trunking.
  • the side on which the trunk mode is changed will initiate EPP by sending an EPP_SYNC payload. This exchange will be conducted in the port VSAN of the attached F_Port.
  • the peer receiving EPP_SYNC frame will respond back with an LS_ACC frame presenting its own trunk configuration information.
  • the initiator receives the LS_ACC frame, it will determine the new operational trunk mode and the list of operational VSANs. Using this information, it will do the necessary hardware and/or software programming.
  • On successful completion of this programming it will send an EPP_COMMIT frame to its peer. When the peer receives this message, it will also determine the new operational trunk mode and the list of operational VSANs.
  • the receiver will then also do the necessary programming on its side and then send an LS_ACC frame back to the initiator. It will also notify its local applications about the availability of VSANs. When the initiator receives the LS_ACC frame, it will notify its local applications about the newly available VSANs. Regardless of whether the F_Port or the TN_Port initiated the mode change from non-trunking to trunking, the TN_Port will initiate fabric login for each of the new VSANs by sending FLOGI messages from its virtual HBA interfaces (assuming an architecture as depicted in FIG. 2 ).
  • the transition is non-disruptive. In other words, the transition did not involve link re-initialization.
  • the transition to trunking mode may be disruptive. In other words, the transition would involve a complete re-initialization including standard primitive sequences as well as the FLOGI request-response exchange and the EPP negotiation as described above.
  • the techniques of the present invention may be implemented on software and/or hardware.
  • they can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card.
  • the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system.
  • a software or software/hardware hybrid implementation of the techniques of this invention may be implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory.
  • a programmable machine may be a network device designed to handle network traffic, such as, for example, a router or a switch, particularly a Fibre Channel switch.
  • network devices may have multiple network interfaces including frame relay and ISDN interfaces, for example.
  • the methods of this invention may be implemented in specially configured network devices such as the MDS 9000 family of switches manufactured by Cisco Systems, Inc. of San Jose, Calif. A generalized architecture for some such machines will appear from the description given below.
  • the techniques of this invention may be implemented on a general-purpose network host machine such as a personal computer or workstation.
  • the invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.
  • a network device 860 suitable for implementing the techniques of the present invention includes a master central processing unit (CPU) 862 , interfaces 868 , and a bus 867 (e.g., a PCI bus).
  • the CPU 862 may be responsible for implementing specific functions associated with the functions of a desired network device.
  • the CPU 862 may be responsible for analyzing frames, encapsulating frames, and forwarding frames for transmission on an inter-switch link.
  • the CPU 862 preferably accomplishes all these functions under the control of software including an operating system (e.g. Windows NT), and any appropriate applications software.
  • CPU 862 may include one or more processors 863 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 863 is specially designed hardware for controlling the operations of network device 860 . In a specific embodiment, a memory 861 (such as non-volatile RAM and/or ROM) also forms part of CPU 862 . However, there are many different ways in which memory could be coupled to the system. Memory block 861 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.
  • the interfaces 868 are typically provided as interface cards (sometimes referred to as “line cards”). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 860 .
  • interfaces that may be provided are Fibre Channel interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like.
  • various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like.
  • these interfaces may include ports appropriate for communication with the appropriate media.
  • they may also include an independent processor and, in some instances, volatile RAM.
  • the independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 862 to efficiently perform routing computations, network diagnostics, security functions, etc.
  • FIG. 8 illustrates one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented.
  • an architecture having a single processor that handles communications as well as routing computations, etc. is often used.
  • other types of interfaces and media could also be used with the network device.
  • the network device may employ one or more memories or memory modules (such as, for example, memory block 865 ) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein.
  • the program instructions may control the operation of an operating system and/or one or more applications, for example.
  • machine-readable media that include program instructions, state information, etc. for performing various operations described herein.
  • machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; semiconductor memory media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM).
  • program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.

Abstract

N_Ports and F_Ports are provided with logic allowing designation of multiple virtual interfaces on a single host bus adaptor or other Fiber Channel interface, one virtual interface for each VSAN operating on the node interface. Node ports with this additional functionality are referred to as trunking N_Ports or TN_Ports. These ports have a functional design allowing creation of the multiple virtual interfaces as appropriate for the application at hand. This port design also includes logic for communicating with a peer fabric port to initialize and modify the configuration of the virtual interfaces on the TN_Port. A corresponding functional design and communication logic is provided for fabric ports, referred to herein as trunking F_Ports or TF_Ports.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
This application is related to U.S. patent application Ser. No. 10/430,491, (U.S. Publication No. US-2004-0100910-A1, published May 27, 2004), filed May 5, 2003 and titled METHODS AND DEVICES FOR EXCHANGING PEER PARAMETERS BETWEEN NETWORK DEVICES, by Desai et al., which is incorporated herein by reference for all purposes. This application is also related to U.S. patent application Ser. No. 10/034,160, (U.S. Publication No. US-2003-0118053-A1, published Jun. 26, 2003), filed Dec. 26, 2001, titled METHODS AND APPARATUS FOR ENCAPSULATING A FRAME FOR TRANSMISSION IN A STORAGE AREA NETWORK, by Gai et al., which is incorporated herein by reference for all purposes.
FIELD OF INVENTION
This invention pertains to Fibre Channel networks and the devices and methods implemented therein. More specifically, the invention pertains to devices and methods for extending trunking functionality to fabric ports on switches and attached devices.
BACKGROUND
In recent years, the capacity of storage devices has not increased as fast as the demand for storage. Therefore a given server or other host must access multiple, physically distinct storage nodes (typically disks). In order to solve these storage limitations, the Storage Area Network (“SAN”) was developed. Generally, a storage area network is a high-speed special-purpose network that interconnects different data storage devices and associated data hosts on behalf of a larger network of users. A SAN may use various types of network traffic, but more often than not it employs Fibre Channel frames.
Traditionally, designers of storage area networks built separate fabrics, otherwise known as SAN islands. For example, a business might employ one SAN island for human resources applications, another SAN island for engineering applications, another for marketing, etc. Each SAN island contains a physically isolated switch or a group of switches for connecting hosts to storage devices. While this approach may enforce separation of data between various groups in an organization, it frequently under utilizes hardware and management resources.
More recently, some switches such as the MDS9000 family of switches from Cisco Systems, Inc. of San Jose, Calif. have provided the capability to deploy virtual SANs (“VSANs”). With this approach, a multiple SAN islands may be collapsed to a single physical infrastructure, thereby reducing hardware costs and improving manageability while maintaining the stability and traffic isolation of the SAN island model. Each VSAN is logically separate and may be assigned to a separate group, e.g., marketing, engineering, etc. In this collapsed fabric model, some or all switches and inter-switch links in the fabric carry traffic for multiple VSANs.
Until now, only the interconnect ports (called “E_Ports”) that connect the VSAN switches could be configured to carry the traffic of multiple VSANs. Therefore, host bus adaptors (“HBAs”) or other interfaces in hosts or disks attached to F_Ports or FL_Ports could be configured in one VSAN only. The VSAN of the attached switch port (also called the “port VSAN”) is implicitly assigned to the HBA and all traffic transmitted or received by the HBA belongs to that VSAN. In this approach, all traffic between the HBA and the switch port is transmitted in standard Fibre Channel frame format, commonly termed “untagged format.” This should be contrasted with the format of frames exchanged between trunking E_Ports, which are encapsulated in Extended Inter-Switch Link (“EISL”) format, commonly termed “tagged format”. The format specifically identifies the VSAN of each frame and thereby allows enforcement of VSAN specific security policies, quality of service, etc. The use of trunking E_Ports and the EISL format is described in detail in US Patent Publication No. US-2003-0118053-A1, previously incorporated by reference.
Today, Fibre Channel VSAN implementations require that node devices employ multiple HBAs to connect to multiple switchports—one for each supported VSAN—to achieve multi-homing (participation in multiple VSANs). This redundancy is wasteful. So while the deployment of multiple VSANs on a common topology represents a significant advance in storage area network technology, the requirement that a node have a separate physical interface for each of its VSANs presents a significant waste of resources. Therefore, an improved protocol and apparatus design to provide more efficient use of N_Port and F_Port resources is needed.
SUMMARY
The present invention addresses this need by providing new logic for node ports and fabric ports. The logic allows designation of multiple virtual interfaces on a single host bus adaptor or other Fibre Channel interface, with one virtual interface for each VSAN available on the node interface. Node ports with this additional functionality are referred to as trunking N_Ports or TN_Ports. These ports have a functional design allowing creation of the multiple virtual interfaces as appropriate for the application at hand. This port design also includes logic for communicating with a peer fabric port to initialize and modify the configuration of the virtual interfaces on the TN_Port. The invention further provides a corresponding functional design and communication logic in fabric ports, referred to herein as trunking F_Ports or TF_Ports.
One aspect of the invention provides a Fibre Channel switch port or node port that controls trunking over a Fibre Channel link coupling a node to a fabric switch. The port includes a controller for managing trunking on the port by communicating with a peer port over the Fibre Channel link. Through the communication, the port can determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces, with each virtual SAN interface providing the functionality of a single virtual SAN. For determining whether virtual SAN functionality is available, the controller is designed or configured to negotiate a mode of operation with the peer, with the available modes of operation include trunking and non-trunking over the Fibre Channel link. For defining one or more virtual SAN interfaces, the controller is designed or configured to identify VSANs common to the switch port and the node port. In a specific embodiment, the communication for managing trunking takes place using an Exchange Peer Parameter (EPP) protocol. The port may be implemented in hardware, software, or a combination of the two.
Another aspect of the invention provides trunking N_Port for a Fibre Channel node. The trunking N_Port may be characterized by the following features: (a) a physical N_Port interface designed or configured to provide functionality of a non-trunking N_Port when virtual SAN functionality is not available; and (b) a controller for managing trunking on the trunking N_Port.
Similar to the controller described for the first aspect of the invention, the controller in this aspect is designed or configured to communicate with an F_Port on a Fibre Channel switch and determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces on the trunking N_Port, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN. Typically, the physical N_Port functionality provides no information regarding virtual SANs in frames transmitted therefrom. In contrast, the one or more of the virtual SAN interfaces are designed or configured to provide frames containing information identifying the particular virtual SAN to which it belongs. Such information may be provided in an EISL header for the frames. Such frames may also specify QoS parameters, MPLS features, etc. available for the virtual SANs. The controller has a Fibre Channel well known address but is typically designed such that it does not take part in data traffic.
A further aspect of the invention pertains to methods of establishing a link between a trunking N_Port on a node and an F_Port on a Fibre Channel switch. Such methods may be characterized by the following sequence: (a) determining whether virtual SAN functionality exists on the F_Port; and (b) defining one or more virtual SAN interfaces on the trunking N_Port, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN. Preferably, both (a) and (b) are both implemented by communicating between the trunking N_Port on a node and the F_Port. Such communication may be accomplished using the EPP protocol, for example.
Another aspect of the invention pertains to storage networks including multiple nodes having trunking N_Ports and a fabric comprised of switches having F_Ports linked to the trunking N_Ports. The trunking N_Ports comprise controllers designed or configured to communicate with F_Ports on a Fibre Channel switch and determine whether virtual SAN functionality is available and if so define one or more virtual SAN interfaces on their trunking N_Ports, with each virtual SAN interface providing the functionality of an N_Port for a single virtual SAN.
Still another aspect of the invention pertains to computer program products including machine-readable media on which are stored program instructions for implementing at least some portion of the methods described above. Any of the methods of this invention may be directed, in whole or in part, by executing program instructions provided on such computer readable media. In addition, the invention pertains to various combinations of data and data structures generated and/or used as described herein.
These and other features and advantages of the present invention will be described in more detail below with reference to the associated figures.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1A is a diagram of a simple storage area network including a storage area network fabric and associated end nodes, which belong to two different VSANs.
FIG. 1B is a diagram of a simple storage area network including a storage area network fabric and associated end nodes employing trunking N_Ports, which support traffic for two different VSANs.
FIG. 2 is a block diagram showing various functional components of trunking N_Port in accordance with an embodiment of this invention.
FIG. 3 is an interaction diagram depicting, at a relatively high level, some interactions between a trunking F_Port and a trunking N_Port in setting up a trunking link that supports multiple VSANs, in accordance with an embodiment of this invention.
FIG. 4 is a table showing how different configurations of the F_Port and TN_Port may result in different modes of operation on a shared link.
FIG. 5A is an interaction diagram showing a message exchange in which a TN_Port learns that an F_Port does not support a protocol (EPP) for determining trunking parameters on a link.
FIG. 5B is an interaction diagram showing a message exchange in which a TN_Port learns that an F_Port supports a protocol (EPP) for determining trunking parameters on a link.
FIG. 6A is a schematic representation of an EPP frame format including TLV sections in the EPP payload.
FIG. 6B is a table showing a matrix for trunk mode negotiation between a TN_Port and an F_Port in accordance with one embodiment of this invention.
FIG. 7 is an interaction diagram showing how the EPP protocol may be used to negotiate trunking parameters in accordance with one embodiment of this invention.
FIG. 8 depicts a switch or other network device that may be configured to perform the methods of the present invention.
DETAILED DESCRIPTION
Introduction
As indicated, many embodiments of this invention pertain to trunking. Trunking allows a single port and associated link to carry traffic for multiple different virtual groups of network devices (e.g., multiple VSANs). Thus, a single physical infrastructure can support these separate groups, each of which may require its own security policy, quality of service parameters (QoS), communications protocols, etc. And, as explained in US Patent Publication No. US-2003-0118053-A1, VSANs may also be designed to support MPLS in Fibre Channel infrastructures.
In the Fibre Channel standard, multiple types of ports are defined. These include N_Ports, F_Ports, and E_Ports. N_Ports reside network end nodes such as hosts and disks. F_Ports reside on fabric switches and connect to N_Ports to provide links between nodes and fabric switches. E_Ports are used for links between fabric switches, inter-switch links (ISLs). To date only E_Ports have been designed to carry traffic for multiple VSANs.
The present invention allows for an improved SAN design in which the HBAs or other node interfaces can be configured in multiple VSANs. In this manner, multi-homing is achieved even while attaching a single N_Port to a single F_Port. This improves the utilization factor of bandwidth in HBAs (and the attached switch ports), reducing the overall port count requirement in the SAN, and hence, reducing the overall Total Cost of Ownership (TCO). One example application for trunking with HBAs is the tape backup application where instead of having one HBA for each VSAN to be backed up, one HBA may be used for backup of multiple VSANs.
FIG. 1A depicts a simple storage area network including a storage area network fabric 101 and associated end nodes. These nodes include hosts 114, 116, and 128, as well as storage disks 104, 106, and 108. The hosts may be servers or other computers requiring access to the data on the disks. Fabric 101 is comprised of switches 118, 120, and 122 coupled by inter-switch links 124, 127, and 126. These switches run a storage area network protocol such as Fibre Channel, which provides communication between the nodes via Fibre Channel frames.
As indicated above, a single infrastructure such as fabric 101 can support multiple VSANs, each associated with a distinct group of nodes. In the example of FIG. 1A, two VSANs are implemented on the storage area network, VSAN1 and VSAN2. The nodes belonging to VSAN1 are hosts 114 and 128 and disk 106. All three switches have dedicated ports that support traffic on VSAN1. The nodes belonging to VSAN2 are hosts 116 and 128, as well as disks 104 and 108. Only switches 120 and 122 allow traffic on both VSAN1 and VSAN2. Switch 118 is dedicated to traffic on VSAN1. Note that links carrying traffic on VSAN1 are indicated by solid lines while links carrying traffic on VSAN2 are indicated by dashed lines.
Each link has an associated port. Inter-switch links employ Fibre Channel E_Ports. Fabric ports (F_Ports) are ports on switches that communicate over links with node ports (N_Ports). To date, the ability to carry traffic for multiple VSANs over a single link has been reserved for inter-switch links supporting EISL, as mentioned above. In some contexts, such E_Ports are referred to trunking E_Ports or “TE_Ports.” It is important to note that in current technology, as depicted in FIG. 1A, trunking is limited to inter-switch links. Links between N_Ports and F_Ports are necessarily non-trunking. As indicated, this presents a burden if a particular node needs to communicate on multiple VSANs. For example, as depicted in FIG. 1A, node 128 belongs to both VSAN1 and VSAN2. To allow for this, hosts 128 must include separate ports (network interfaces such as HBAs) for each VSAN. Similarly, each switch must provide a separate F_Port for each VSAN over which it and its associated node will communicate. This situation is depicted in switch 122 of fabric 101.
To remedy this problem, the present invention provides trunking N_Ports (TN_Ports) and trunking F_Ports (TF_Ports). These allow a single HBA or other node interface to communicate with a single F_Port and provide edge traffic for two separate VSANs over a single link. This is shown in FIG. 1B where host 128, which belongs to both VSAN1 and VSAN2, contains a single HBA 134 connected to switch 122 via a link 136. This link is coupled to a trunking F_Port 138 on switch 122. As shown, link 136 carries traffic for both VSAN1 and VSAN2, and is thus deemed a trunking link. The principal difference between the networks depicted in FIGS. 1A and 1B is in the use of a single HBA 134 and a single F_Port 138 for communications between node 128 and switch 122, which communications may include traffic on both VSAN1 and VSAN2.
Various techniques for implementing multi-homing in node ports and fabric ports are within the scope of this invention. Some will be described the following sections. Typically, a TN_Port will include some control logic that can set up and initialize multiple virtual interfaces in a single node port. The control logic will need to communicate with corresponding logic on a trunking fabric port to negotiate and identify supported VSANs on the common link. The control logic may also communicate and negotiate to the extent needed state changes in existing trunk links. Such changes may include conversion from trunking to non-trunking, change in the list of supported or available VSANs, changes from non-trunking to trunking, etc.
In a specific embodiment, the control logic initially determines whether its peer fabric port supports or currently permits establishment of VSANs and/or trunking. It may use a conventional node login procedure for this purpose, e.g., FLOGI in the case of Fibre Channel. If it is determined that the fabric port cannot or currently does not support trunking, then it may configure the TN_Port to act as a conventional N_Port which does not explicitly recognize VSANs. If the control logic does find that its peer F_Port supports and permits trunking, it may then negotiate with the F_Port to determine which VSANs will be supported in the trunking link.
In this embodiment, the fabric port will similarly contain control logic for confirming that it supports trunking and for negotiating appropriate parameters (list of supported VSANs for the link, etc.) with the TN_Port. Appropriate functional designs for the TN_Port and TF_Port will be described below.
Functional Design of a TN_Port
As indicated, a Fibre Channel node device (e.g., a host bus adaptor) that supports trunking is termed a Trunking N port (TN_Port) herein. Such a device when attached to a switchport in TF_Port mode can transmit and receive frames in one or more VSANs over the same physical link. In one embodiment, this is accomplished when using the EISL frame format.
One example of a TN_Port model is shown in FIG. 2. As shown there, a fabric switch 205 is coupled to a node 201 by a Fibre Channel link 203. Data transmission and management of the link is provided by a fabric port 211 in switch 205 and a node port 207 in node 201. These are configured as trunking ports having functionality described herein.
In the depicted model, TN_Port 207 includes three types of logical entities: an HBA Controller N_Port 213, a Physical HBA interface 215, and one or more virtual HBA interfaces (one for each VSAN configured) 217. Each of these logical entities exchanges frames over the same physical link 203 attached to the TN_Port. The physical link 203 can receive frames specifying a VSAN or other virtual fabric (in for example EISL format). The TN_Port 207 can operate in various modes as explained below. Even if it is in a mode that does not support trunking, it can implicitly support a single VSAN, as with current technology.
The HBA Controller N_Port 213 is a logical entity that is responsible for communicating with attached TF_Port 211 for configuration and management of trunking feature on TN_Port 207. It may accomplish this using any appropriate communication protocol. In a specific example detailed below, the configuration and management communications take the form of Fibre Channel exchanges using the Exchange Peer Parameter (EPP) protocol. During these communications, the entity may behave like an N_Port with a well-known address, but it does not take part in data traffic. Thus, the HBA Controller N_Port 213 may be given a well-known address (WKA), e.g., the value hex FFFFFD. It may also be given a unique VSAN tag or ID (e.g., 4094) to use during these configuration and management communications.
A virtual HBA interface 217 is a logical entity of the TN_Port that mimics the functionality of a physical N_Port attached to an F_Port, but exchanges traffic in one VSAN only. Configuration exchanges, as described below, are established to specify the number and identities of virtual HBA interfaces 217. The VSAN IDs are assigned by the controller 213 to individual virtual HBA interfaces based upon parameter values established during set up with the TF_Port 211. A WWN is assigned by node device 201.
Typically, each TN_Port has the ability to instantiate one or more such virtual HBAs, one for each configured VSAN. Three virtual HBA interfaces 217 are shown in TN_Port 207. Each has the ability to apply its own VSAN tag to outgoing frames. Each also has the ability to process incoming frames sorted to it based on VSAN tag. Applications running on node 201 communicate with individual ones of the virtual HBA interfaces 217 based on their participation in the various supported VSANs. In some embodiments presented herein, the virtual HBA interfaces 217, each perform FLOGI in the manner of a conventional N_Port and take part in data traffic in the configured VSAN.
All frames transmitted and received by the virtual HBAs 217 are carried over the same physical link 203 between the TN_Port 207 and the attached F_Port 211. If link 203 is operational in trunking, all frames are tagged in EISL format (or other VSAN aware format); otherwise, all frames are untagged.
The Physical HBA Interface 215 is an optional logical entity that mimics the functionality of a physical N_Port attached to an F_Port but is not VSAN aware. It comes into play when either virtual HBA support of the TN_Port is disabled or the attached F_Port does not support VSANs, as well as a communication protocol for configuring VSANs on N_Port 207. This interface is not used when any of the virtual HBAs 217 are instantiated and active. Most commonly, this interface is used when the TN_Port is attached to a switch that is not VSAN aware or when the applications running on node 201 do not support virtual HBA interfaces.
When activated, Physical HBA Interface 215 exchanges all traffic originating with and received by TN_port 207. All such traffic is untagged. In all other aspects, data transfer on interface 215 resembles that on conventional HBAs, which have no knowledge of VSANs. For Physical Interface 215, a VSAN ID may be implicitly assigned by the F_Port, and a WWN is assigned by node device 201.
In some implementations, Physical HBA interface 215 may be unnecessary. One such implementation could, for example, employ at least one instance of block 217 and this could also perform the function of the Physical HBA when needed. Similarly, the HBA controller block 213 is also shown as one possible way to implement the functionality required. It may not be required in alternate implementations.
Functional Design of TF_Port
The logical design of a TF_Port is generally similar to that of the TN_Port and mirrors its functionality in many ways. It supports multiple VSANs and may be viewed as creating a virtual interface for each separate VSAN, in the manner depicted for the TN_Port in FIG. 2. Each virtual interface may have the ability to apply a VSAN label to outgoing frames. And incoming VSAN frames are sorted to the individual virtual interfaces for separate handling. Generally, however, the F_Port virtual interfaces need not have the ability to handle FLOGI frames or provide as much support to higher level applications as is provided by the virtual HBA interfaces in TN_Ports, at least in some implementations.
In one embodiment detailed below, an F_Port becomes operational in TF_Port mode, if the attached Fibre Channel node supports EPP services and the trunk mode configuration at both ends of the link allows trunking.
Configuration and Initialization
Various methods and functional designs may be employed to configure linked N_Ports and F_Ports for trunking. In some embodiments, a three-phase procedure is employed. First, the N_Port determines whether the F_Port can communicate via a protocol intended to allow configuration. Assuming that the N_Port confirms this, the ports then use such protocol to negotiate parameter values needed to configure their link. Examples of such parameters include mode of operation for the ports (trunking versus non-trunking), number of VSANs supported, and identification of VSANs supported. Finally, after the negotiation is complete and the link VSANs are identified (if any), each individual virtual HBA interface separately logs into the fabric (for its particular VSAN). Any other pre-login protocols, as applicable shall be performed before the logins performed by individual virtual HBA interfaces.
This basic procedure is illustrated in FIG. 3, where interactions between an F_Port 301 and a TN_Port 303 are depicted as diagonal lines. The process begins with TN_Port 303 sending a frame 305 to F_Port 303 proposing trunking (or at least some form of communication under a defined protocol for configuring trunking). The F_Port then recognizes that it is being asked to communicate in the protocol and responds with a frame 307 confirming that it can and will communicate in such protocol. When TN_Port 303 receives this message, it prepares to enter the second phase of the setup. Note that if the TN_Port has a functional design as illustrated in FIG. 2, the logic to send frame 305 and interpret frame 307 may reside with the Physical HBA Interface 215. No VSAN support has yet been confirmed, so communication via a conventional HBA is appropriate.
After port 303 enters the second phase of set up, HBA controller N_Port 213 takes over (again assuming the functional design of FIG. 2). Depending upon the particular protocol employed, a series of communications may be required to fully negotiate the parameter set going forward. In FIG. 3, two communications are intended to represent the entire negotiation phase of setup. These are a message 309 from the TN_Port to initiate negotiation and a message 311 from F_Port 301 to conclude negotiation. In a specific embodiment described below, the negotiation takes place in an EPP protocol.
At the end of the negotiation protocol, there may be one or more virtual HBA interfaces defined on TN_Port 303. As indicated in FIG. 3, each of these (two in this example), initiate a separate fabric login for its specific VSAN. This is indicated by FLOGI messages 313 and 315 from the TN_Port 303. As shown, the active virtual HBA interfaces (217 from FIG. 2) send the FLOGI messages. Corresponding logic in F_Port 301 provides the fabric side of the login for each virtual HBA interface.
Before describing the initial phase of this process in more detail, various TN_Port modes of operation will be described, in accordance with a preferred embodiment of this invention. The particular mode of operation is governed by the current states of the node and fabric ports. For example, the switchport state may or may not support the chosen communication protocol for negotiating VSAN services on the link (e.g., EPP). Further, the current trunking configurations may be different at the two ends. Thus, the particular mode adopted at any time is determined in large measure by the current configuration of the fabric switchport. The TN_Port itself may be configured to enable or disable virtual VSAN support based on the applications supported by the HBA. If, for example, the supported and active applications do not require VSAN differentiation, then it may be appropriate to disable virtual VSAN support.
FIG. 4 depicts the various modes of operation in accordance the described embodiment. As shown, the port settings and capabilities specify modes of operation as follows:
i) When virtual HBA support is disabled in the TN_Port, its trunking capability is necessarily disabled, and the physical HBA interface is used for all traffic; the HBA contoller N_Port and the virtual HBA interfaces are not used. The TN_Port is thus configured if, for example, (a) the applications supported do not require operation in multiple VSANs or cannot make use VSAN specific features such as QoS or (b) the TN_Port is intended to be attached to a switch that does not support trunking.
ii) When virtual HBA support is enabled for a TN_Port, the node applications are expected to work with one or more of the virtual HBA interfaces, and the TN_Port is expected to be attached to a switch that can support trunking. However, if the TN_Port is thus configured but attached to a switch that does not support the defined negotiation protocol or has such support disabled, the TN_Port will behave like a normal N_Port, as mentioned above, and the physical HBA interface will be used.
iii) When the virtual HBA support is enabled for the TN_Port and it is attached to a fabric port with negotiation protocol support enabled, the operational trunk mode of the link is determined during negotiation of services, and it depends on the trunk mode configuration at both endpoints (discussed later). In this case, the physical HBA interface is not used irrespective of the operational trunk mode of the link.
iv) For case (iii) above, if the link is operational in non-trunking mode, only one virtual HBA interface (identified by the port VSAN of the attached F_Port, communicated to the TN_Port through negotiation services) is used along with the HBA Controller N_Port. All traffic is untagged in such configuration, and assumed to be in the port VSAN of the attached F_Port.
v) For case (iii) above, if the link is operational in trunking mode, one or more virtual HBA interfaces (one for each operational VSAN determined during the negotiation) are used along with the HBA Controller N_Port. All traffic is exchanged in tagged format, and the VSAN information is embedded in the VSAN header.
In case (iv) above, the virtual HBA interface for the port VSAN of the attached port is used instead of the physical HBA interface to ensure smooth transition from non-trunking to trunking mode of the link.
Configuration Protocol Detection
As indicated, to setup a TN_Port of this invention, the node and fabric ports must first agree on a set of parameters for their link. To accomplish this, they must employ a common protocol for the setup. Thus, as an initial matter, the ports must determine that their peer is prepared to communicate using such common protocol. One specific example of such protocol is the Exchange Peer Parameter (EPP) protocol, and an implementation of the invention employing EPP will be described below. Other examples setup protocols include the existing FC SW-ILS request response based protocol.
As indicated above, the EPP protocol may be enabled as a registration/set-up protocol for TN_Ports. One procedure for detecting EPP capability will now be described. In this procedure, if EPP capability is not detected, then the peer node port and switch port do not use a VSAN-specific communication for any set-up or data traffic purposes. In this case, there will be no negotiation of VSAN parameters. And in the embodiment depicted in FIG. 2, all subsequent communication from the TN_Port will take place via the physical HBA interface.
On the other hand, if EPP capability is detected, then the TN_Port and the F_Port subsequently negotiate appropriate VSAN parameters for future data traffic. As indicated elsewhere, this entails determining common features for the link including the mode of operation, a particular port VSAN (for non-trunking applications), and a list of common VSANs to be supported by the link. Other link-related parameters may be negotiated at this time as well.
One mechanism for detecting EPP capability employs the Fibre Channel log in sequence, wherein the N_Port begins the process by sending an FLOGI. This implementation is depicted in FIGS. 5A and 5B. Because Fibre Channel requires the N_Port to send an FLOGI message after link initialization, EPP detection can be conveniently implemented during this stage.
FIG. 5A depicts a scenario in which the F_Port does not support EPP and hence trunking is not enabled over the link. In this example, the TN_Port 501 begins the process with an FLOGI frame 505. This message has been slightly modified from the standard FLOGI frame format in that it has some indication that specifies to a capable F_Port that an EPP exchange is desired.
In this example, an F_Port 503 does not support EPP and/or has its trunking feature disabled. Thus, when F_Port 503 receives FLOGI frame 505, it responds in a manner indicating to TN_Port 501 that it either did not detect the indication of EPP support and/or it does not support EPP or trunking currently. In a specific embodiment, described below, the message 507 sent by F_Port 503 to indicate this is an accept message for fabric login (LS_ACC) having a fabric address.
Because TN_Port 501 now understands that F_Port 503 will not participate in the desired parameter exchange to support VSAN trunking, the physical HBA interface of the TN_Port becomes active and the link operates in a non-trunking mode. Note that even though the F_Port does not participate in the trunking negotiation, it may still support VSAN applications. It simply may not have been prepared to participate in a parameter exchange or trunking. In this case, F_Port 503 will treat all frames as belonging to its port VSAN.
FIG. 5B depicts a different scenario in which F_Port 503 supports EPP and is prepared to engage in a parameter exchange with TN_Port 501. In this case, a different fabric login exchange results. As shown there, TN_Port 501 again begins the process by sending a modified FLOGI message 505. In this case, however, F_Port 503, which supports EPP and desires to define parameters for the link, responds with a different message, one that indicates to TN_Port 501 that it should initiate parameter exchange. In the specific example depicted in FIG. 5B, F_Port 503 transmits a login reject message (LS_RJT) frame in response to the FLOGI message. This frame contains a specific indication that EPP is supported. When TN_Port 501 receives this frame, the HBA controller N_Port (assuming the FIG. 2 architecture) takes over and begins negotiation on the EPP protocol.
Various options can be employed for embedding a request for EPP communication in the FLOGI frame. In one option, the existing FLOGI frame format is employed and some field in that frame has a value specifically chosen to indicate EPP support. In one specific embodiment, a particular value is inserted into the vendor specific information field of the FLOGI frame payload. For example, a vendor version value may be set to hex 01. In addition, a 16 bit field defined for vendor specific service parameters can have a bit reserve to identify EPP support.
In another option, the standard format for FLOGI frames is modified to accommodate a flag or other indicator for EPP support. In other words, the standard is modified to define a new field understood by all devices to indicate a desire to communicate by EPP.
Correspondingly, various options exist for indicating EPP support in the F_Port reply to the FLOGI message. In the first example, the F_Port may send a reject frame (LS_RJT) as indicated in FIG. 5B. In one example, the frame includes a vendor unique error code (e.g., hex FF) with an explanation that EPP is not supported (as understood by TN_Ports). In a specific embodiment, the most significant byte of the ELS command code can be passed on in the reject message (e.g., AB when EPP uses 0xAB000000 as the ELS command code). This allows the HBA controller N_Port (assuming a FIG. 2 architecture) to use this value to receive and send EPP service frames.
In a second option, the F_Port replies to the FLOGI message by sending a conventional login accept frame (LS_ACC), but with some special indication that EPP is supported. In a specific example, the accept frame contains a fabric address of all zeros.
If FLOGI is used as the mechanism for indicating EPP support, in preparation for an exchange to define link parameters, then the F_Port may make note of the values of various parameters specified in the FLOGI message for later use during logins by the individual virtual HBAs defined during the EPP parameter exchange. The F_Port may also perform configuration of relevant hardware and software elements before sending its LS_RJT response shown in FIG. 5B. Examples of parameters that may be noted by the F_Port include BB_credit, receive data field size, E_D_TOV, etc. If any of these values is not acceptable, the F_Port may respond with an LS_RJT frame having appropriate reason codes as specified in the Fibre Channel standard. If the TN_Port receives such a rejection, it may first take care of the specified issue and then try again with another FLOGI to detect EPP capability.
Negotiation (EPP Example)
The exchange of peer parameters establishes the operating environment between the two ports on the link for subsequent support of one or more VSANs during data traffic across the link. In an embodiment described herein, this negotiation is done during the SYNC phase of EPP. An EPP frame format is shown in FIG. 6A. As illustrated there, an EPP frame 601 includes an EISL header 603, a 24 byte Fibre Channel header 605, a 20 byte EPP header 607, and multiple “TLV” payloads 609. Note that the EISL header is optional on EPP frames.
EISL header 603 indicates that trunking for multiple VSANs may be supported. As mentioned, some embodiments of the invention set aside a particular VSAN for the sole purpose of management and configuration of trunking on a node-fabric link. As an example, VSAN number 4094 may be reserved for this purpose. Regarding the appropriate fields and format for the EISL header, further discussion is provided in U.S. Patent publication No. US-2003-0118053-A1, previously incorporated by reference.
The Fibre Channel header 605 employs the format specified in the ANSI Fibre Channel standard. However, because EPP is implemented as an ELS-bases service, the Fibre Channel header format will be set forth in more detail by the ELS specification. See the ANSI T11 standard specification for Fibre Channel.
Before discussing EPP header 607, a brief introduction to EPP will be provided. EPP is a two-phase protocol in which (1) information is exchanged about peer port configurations of interest and (2) results of the exchange of information are applied to hardware and/or software of the peer ports, as needed. The first phase is referred to a “SYNC” phase and the second phase is referred to as a “COMMIT” phase. The EPP protocol may be employed for diverse purposes such as, for example, transitioning port channel configurations and negotiating ISL trunk parameters for supporting multiple VSANs. EPP is described generally in U.S. patent application Ser. No. 10/430,491, filed May 5, 2003, entitled, “METHODS AND DEVICES FOR EXCHANGING PEER PARAMETERS BETWEEN NETWORK DEVICES”, Publication No. US-2004-0100910-A1, published on May 27, 2004, which is incorporated herein by reference. It is important to remember that EPP is but one example of a communication protocol that can be employed for this purpose. Generally, the communication protocol need not even be a two-phase protocol; some single-phase protocols can work equally well. As an example, the existing FC SW-ILS definition in Fibre Channel can be employed. FC SW-ILS is a request-response based protocol with delivery acknowledgement.
Returning to FIG. 6A, the EPP header 607 may also employ a well-known format. Examples of relevant fields in the EPP header include a command code, which indicates whether the EPP exchange is in the SYNC phase or the COMMIT phase, a payload length based upon a calculation involving the number of TLV segments in the payload, and a command identifier specifying whether the frame is an EPP request, an EPP accept, or an EPP reject.
In one embodiment, the command identifier for the EPP request used in the exchange to identify trunking parameters will be chosen from the range of vendor specific command identifiers. The proposed value is 0x7f000000. The values for LS_ACC and LS_RJT are specified by ELS.
In the specific embodiment described here, the EPP payload is provided as a collection of TLV sections 609 of frame 601, each specifying a particular type, length and value. The type also indicates how the EPP frame is to be handled if TLV is not supported at the receiving port. If TLV is not supported, the typical response is either skip procedures involving the TLV information or abort the EPP exchange altogether. The length component of the TLV format specifies the length of the entire TLV portion of the payload for the parameter under consideration. Finally, the value component specifies the particular value of the parameter in question.
In the embodiment described here, a separate TLV portion is employed for each parameter to be negotiated. These include the mode for communication, a specific port VSAN if communication is to take place in non-trunking mode, and a list of available VSANs to be supported in trunking mode. Together the three TLV portions for these parameters comprise the EPP payload of frame 601.
In a specific example, there are three different administrative trunk modes. The first one of these is “OFF” which explicitly indicates that the port should never operate in a trunking mode. The second mode is “ON” which explicitly indicates that the port should operate in trunking mode so long as its peer does not explicitly prohibit that. Finally, a third mode of operation is called “AUTO” which indicates that the port can operate in a trunking mode, so long as the peer is explicitly configured to support trunk mode. Each port will have its own currently activated trunk mode, which is one of these three values. The trunk mode value for that port is specified in its EPP SYNC message at the appropriate location in a TLV portion of its payload. Negotiation of the agreed upon mode for the F_Port and N_Port may be decided based upon a table as shown in FIG. 6B. As shown there, the agreed upon mode is trunking only when one of the ports has its mode set to “ON” and the other port's mode is not “OFF”.
Regarding the port VSAN TLV, this portion of the EPP frame is used by the F_Port to notify its counterpart TN_Port of the VSAN number to be used when the link is operational in non-trunking mode (as determined by the trunk mode negotiation).
The allowed VSAN TLV contains a list of allowed VSANs on the port sending the EPP SYNC message. In one embodiment, the value field of the allowed VSAN TLV is structured as a bit map with a single bit designated for each VSAN identifier. For the current VSAN ID space, the TLV value field should be at least 512 bytes. The VSAN number N is represented by a bit number N, left to right. To negotiate an operational VSAN, the local port logic (a controller in case of the TN_Port) calculates using a bit-wise AND operator on the received VSAN list (for the EPP frame) and the locally configured VSAN list for that port.
Other implementations of this invention may handle additional parameters to be set up during negotiation. These additional parameters may be identified in additional TLV fields if EPP is employed as the negotiation protocol. These may enhance the functionality of the invention. Examples of other TLV-implemented parameters may include security information.
During the EPP commit phase, the ports commit negotiated configurations (decided during the sync phase) to there appropriate hardware to make these configurations operational.
As indicated, when the link is operational in trunking mode, all EPP service exchanges are preferably performed by controllers in the N_Port and F_Port using a control VSAN (e.g., 4094). If the link is operational in non-trunking mode, the EPP services may need to occur in the port VSAN of the attached F_Port. However, if the TN_Port is not aware of the port VSAN of the attached F_Port (for example, during TN_Port initialization) it may assume that the EPP service exchanges are to take place using the control VSAN.
An example of the negotiation and login protocol is depicted in FIG. 7. As shown there, a TN_Port 701 initiates the EPP sequence by sending an EPP_SYNC frame 705 to an F_Port 703. In the architecture depicted in FIG. 2, the frame will be created as instructed by the HBA controller N_Port using the control VSAN (e.g. 4094). In this example, however, the EPP_SYNC exchange will be transmitted in an untagged format; note the designation “u” in the message sequence. Upon receiving the EPP_SYNC frame, F_Port 703 will respond back with an LS_ACC frame 707 (also in untagged format) with its configuration information, which includes its trunk mode and VSAN list. Note that EPP_SYNC frame 705 also included this configuration information for the TN_Port.
If the LS_ACC frame 707 is received by TN_Port 701, then the port applies the rules for parameter negotiation to determine the operational trunk mode and the list of operational VSANs on the link. See action 709 in FIG. 7. Assuming that the operational trunk mode is ON, then TN_Port 701 will do the necessary hardware and software programming to transmit frames in tagged format and then send an EPP_COMMIT frame 711 from the control VSAN. Thus, this exchange occurs in VSAN 4094.
On receiving the EPP_COMMIT frame 711, F_Port 703 then does its own corresponding hardware and software programming to enable transmission of frames in tagged format. See action 714 in FIG. 7. The F_Port also responds back with an LS_ACC frame 715, upon successful completion of its own configuration. F_Port 703 will also notify its local applications about the availability of VSANs on that port.
When LS_ACC message 715 is received by TN_Port 701, it notifies its local operation about the availability of VSANs, which will trigger FLOGIs in each of those VSANs. See action 717 in FIG. 7. Then, the individual virtual HBA interfaces on TN_Port 701 perform FLOGI in their respective VSANs. As depicted in FIG. 7, these are VSANs 100 and 200. FLOGIs 719 and 721 correspond to FLOGIs 313 and 315 in FIG. 3. The various login parameters (except the port WWN) in these FLOGIs should be the same as in the first FLOGI. This enables the active virtual HBA interface(s) to support data traffic per Fibre Channel standards.
Modification of Trunking During Operation
Various modifications may occur to an operating link between an F_Port and a TN_Port. These modifications can be effected in many different ways using many different protocols. Some examples will now be described.
As an initial matter, note that if the link is in a non-trunking mode and new VSANs are added or existing VSANs are deleted, then there is no need to undertake a parameter exchange by EPP or any other protocol, as the change in active VSANs will not effect the operational state of the link until it becomes trunking.
The situation is different if the link is already trunking and the VSAN configuration is to be changed with the addition or deletion of VSANs (on either the F_Port or the TN_Port). Then an EPP exchange may be initiated by either side of the link. The side initiating EPP will, in this embodiment, send an EPP_SYNC frame with the new VSAN configuration. As in the above scenarios, this exchange is conducted in a control VSAN. The receiver of the EPP_SYNC frame will respond back with an LS_ACC message identifying its current trunk configuration. When the initiator receives this LS_ACC message, it will do the necessary hardware and software programming to effect the changes in the operational VSANs. On completion of the programming, it will send an EPP_COMMIT frame to its peer. Then, on receiving the EPP_COMMIT frame, the receiver will do the necessary hardware and software programming on its end to reflect the changes in operational VSANs. When it completes this, it will respond with an LS_ACC frame to the initiator and also notify its local applications about the availability of the new VSANs. When receiving the LS_ACC frame, the initiator will notify its local applications about the availability of the new VSANs. Finally, availability of the VSANs on the TN_Port will trigger submission of FLOGI message from the TN_Port, as before. Note that in this scenario, where the link is already trunking before the VSAN configuration has changed, all communications associated with the change take place in tagged format.
It is also possible that during normal operation, the trunk mode could change from trunking to non-trunking. This may arise if the mode of operation was changed from ON to OFF or AUTO in a port at one end of the link. If the port where this change is occurring is transitioning from ON mode to AUTO mode, then that port will need to initiate an exchange to determine if the link should continue to operate as trunking or will become non-trunking. This will depend on whether the other port is currently in ON or AUTO mode, as indicated in the table of FIG. 6B.
If the link is to become non-trunking, then it will be re-initialized by the F_Port. This is to avoid any merging of VSAN specific traffic into non-tagged traffic. In particular, if a link was supporting traffic in VSANs 100 and 200, while operational as trunking, then when one side is programmed to become non-trunking, VSAN specific traffic coming out of that port will be transmitted without an EISL header. The receiver will then receive untagged frames, which will be processed in the port VSAN of the receiver.
Note that, in this embodiment, a trunk mode change from trunking to non-trunking will be disruptive on the link. Link re-initialization entails a complete re-initialization of the link, including standard primitive sequences and the FLOGI request-response exchange followed by EPP parameter negotiation as described earlier.
The final scenario to be described involves a change from non-trunking mode to trunking. In one embodiment, the side on which the trunk mode is changed will initiate EPP by sending an EPP_SYNC payload. This exchange will be conducted in the port VSAN of the attached F_Port. The peer receiving EPP_SYNC frame will respond back with an LS_ACC frame presenting its own trunk configuration information. When the initiator receives the LS_ACC frame, it will determine the new operational trunk mode and the list of operational VSANs. Using this information, it will do the necessary hardware and/or software programming. On successful completion of this programming, it will send an EPP_COMMIT frame to its peer. When the peer receives this message, it will also determine the new operational trunk mode and the list of operational VSANs. The receiver will then also do the necessary programming on its side and then send an LS_ACC frame back to the initiator. It will also notify its local applications about the availability of VSANs. When the initiator receives the LS_ACC frame, it will notify its local applications about the newly available VSANs. Regardless of whether the F_Port or the TN_Port initiated the mode change from non-trunking to trunking, the TN_Port will initiate fabric login for each of the new VSANs by sending FLOGI messages from its virtual HBA interfaces (assuming an architecture as depicted in FIG. 2).
In the above-described procedure for transitioning from non-trunking to trunking mode, the transition is non-disruptive. In other words, the transition did not involve link re-initialization. In an alternative embodiment, the transition to trunking mode may be disruptive. In other words, the transition would involve a complete re-initialization including standard primitive sequences as well as the FLOGI request-response exchange and the EPP negotiation as described above.
Device Implementation
Generally, the techniques of the present invention may be implemented on software and/or hardware. For example, they can be implemented in an operating system kernel, in a separate user process, in a library package bound into network applications, on a specially constructed machine, or on a network interface card. In a specific embodiment of this invention, the technique of the present invention is implemented in software such as an operating system or in an application running on an operating system.
A software or software/hardware hybrid implementation of the techniques of this invention may be implemented on a general-purpose programmable machine selectively activated or reconfigured by a computer program stored in memory. Such a programmable machine may be a network device designed to handle network traffic, such as, for example, a router or a switch, particularly a Fibre Channel switch. Such network devices may have multiple network interfaces including frame relay and ISDN interfaces, for example.
For example, the methods of this invention may be implemented in specially configured network devices such as the MDS 9000 family of switches manufactured by Cisco Systems, Inc. of San Jose, Calif. A generalized architecture for some such machines will appear from the description given below. In an alternative embodiment, the techniques of this invention may be implemented on a general-purpose network host machine such as a personal computer or workstation. Further, the invention may be at least partially implemented on a card (e.g., an interface card) for a network device or a general-purpose computing device.
Referring now to FIG. 8, a network device 860 suitable for implementing the techniques of the present invention includes a master central processing unit (CPU) 862, interfaces 868, and a bus 867 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 862 may be responsible for implementing specific functions associated with the functions of a desired network device. For example, the CPU 862 may be responsible for analyzing frames, encapsulating frames, and forwarding frames for transmission on an inter-switch link. The CPU 862 preferably accomplishes all these functions under the control of software including an operating system (e.g. Windows NT), and any appropriate applications software.
CPU 862 may include one or more processors 863 such as a processor from the Motorola family of microprocessors or the MIPS family of microprocessors. In an alternative embodiment, processor 863 is specially designed hardware for controlling the operations of network device 860. In a specific embodiment, a memory 861 (such as non-volatile RAM and/or ROM) also forms part of CPU 862. However, there are many different ways in which memory could be coupled to the system. Memory block 861 may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, etc.
The interfaces 868 are typically provided as interface cards (sometimes referred to as “line cards”). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 860. Among the interfaces that may be provided are Fibre Channel interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, ASI interfaces, DHEI interfaces and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 862 to efficiently perform routing computations, network diagnostics, security functions, etc.
Although the system shown in FIG. 8 illustrates one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. Further, other types of interfaces and media could also be used with the network device.
Regardless of the network device's configuration, it may employ one or more memories or memory modules (such as, for example, memory block 865) configured to store data, program instructions for the general-purpose network operations and/or other information relating to the functionality of the techniques described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example.
Because such information and program instructions may be employed to implement the systems/methods described herein, the present invention relates to machine-readable media that include program instructions, state information, etc. for performing various operations described herein. Examples of machine-readable media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media; semiconductor memory media; and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM) and random access memory (RAM). Examples of program instructions include both machine code, such as produced by a compiler, and files containing higher level code that may be executed by the computer using an interpreter.
OTHER EMBODIMENTS
While the invention has been particularly shown and described with reference to specific embodiments thereof, it will be understood by those skilled in the art that changes in the form and details of the disclosed embodiments may be made without departing from the spirit or scope of the invention. For instance, while the above protocol has been described for trunking N_Port and F_Port applications, it may be easily extended to work with devices attached to loop ports if such protocol is supported by the respective device vendors. Further this invention may be extended to network technologies other than Fibre Channel. Considering these and other variations, the scope of the invention should be determined with reference to the appended claims.

Claims (42)

1. A trunking N_Port for a Fibre Channel node, the trunking N_Port comprising:
a physical N_Port interface designed or configured to provide functionality of a non-trunking N_Port when virtual Storage Area Network (SAN) functionality is not available; and
a controller for managing trunking on the trunking N_Port, wherein the controller is designed or configured to communicate with an F_Port on a Fibre Channel switch and determine whether virtual SAN functionality exists on the F_Port and if so define one or more virtual SAN interfaces on the trunking N_Port for one or more virtual SANs that are common to the F_Port and the trunking N_Port, with each of the virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of the one or more virtual SANs that are common to the F_Port and the trunking N_Port;
wherein the controller is designed or configured to identify the one or more virtual SANs that are common to the F_Port and the trunking N_Port, to thereby define the one or more virtual SAN interfaces on the trunking N_Port.
2. The trunking N_Port of claim 1, wherein the trunking N_Port is implemented at least partially as software.
3. The trunking N_Port of claim 1, further comprising one or more instances of said virtual SAN interfaces.
4. The trunking N_Port of claim 1, wherein the physical N_Port functionality provides no information regarding virtual SANs in frames transmitted therefrom.
5. The trunking N_Port of claim 1, wherein each of one or more of the virtual SAN interfaces is designed or configured to provide frames containing information identifying the corresponding one of the one or more virtual SANs.
6. The trunking N_Port of claim 5, wherein the information identifying the particular virtual SAN to which it belongs is provided in an Extended Inter-Switch Link (EISL) header for the frames.
7. The trunking N_Port of claim 5, wherein the frames comprise QoS parameters defining levels of quality of service available for the virtual SANs.
8. The trunking N_Port of claim 1, wherein the controller is designed or configured to communicate with the F_Port using Exchange Peer Parameter (EPP) protocol.
9. The trunking N_Port of claim 1, wherein the controller has a Fibre Channel well known address but is designed or configured such that it does not take part in data traffic.
10. The trunking N_Port of claim 1, wherein the controller is designed or configured to negotiate a mode of operation with the F_Port and available modes of operation include trunking and non-trunking
11. The trunking N_Port of claim 1, wherein the controller is designed or configured to use EPP protocol to identify the VSANs common to the F_Port and the trunking N_Port.
12. The trunking N_Port of claim 1, wherein the controller is designed or configured to identify the one or more virtual SANs that are common to the F_Port and the trunking N_Port based upon a list of supported virtual SANs that is received from the F_Port, the list of supported virtual SANs identifying the one or more virtual SANs.
13. The trunking N_Port of claim 1, wherein the one or more virtual SANs that are common to the F_Port and the trunking N_Port includes two or more virtual SANs, wherein the controller defines two or more virtual SAN interfaces on the trunking N_Port for the two or more virtual SANs, with each of the two or more virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of the two or more virtual SANs, thereby enabling the trunking N_Port to carry traffic for the two or more virtual SANs over a single link between the trunking N_Port and the F_Port.
14. A trunking N_Port or F_Port for a Fibre Channel device, the trunking N_Port or F_Port comprising a controller for managing trunking on the trunking N_Port or F_Port, wherein the controller is designed or configured to communicate with a peer port over a Fibre Channel link and determine whether virtual SAN functionality exists on the peer port and if so define one or more virtual Storage Area Network (SAN) interfaces on the trunking N_Port or F_Port for one or more virtual SANs that are common to the trunking N_Port or F_Port and the peer port, with each of the virtual SAN interfaces providing the functionality of a corresponding one of the one or more virtual SANs that are common to the trunking N_Port or F_Port and the peer port, wherein the controller is further designed or configured to identify the one or more virtual SANs that are common to the trunking N_Port or F_Port and the peer port, to thereby define the one or more virtual SAN interfaces on the trunking N_Port or F_Port.
15. The trunking N_Port or F_Port of claim 14, wherein the controller is designed or configured to negotiate a mode of operation with the peer and available modes of operation include trunking and non-trunking
16. The trunking N_Port or F_Port of claim 14, wherein the controller is designed or configured to identify the VSANs common to the F_Port or the trunking N_Port and the peer port based upon a list of supported virtual SANs that is received from the peer port, the list of supported virtual SANs identifying the one or more virtual SANs, to thereby define the one or more virtual SAN interfaces on the trunking N_Port or F_Port.
17. The trunking N_Port or F_Port of claim 15, wherein the controller is designed or configured to use Exchange Peer Parameter (EPP) protocol to identify VSANs common to the F_Port and the trunking N_Port.
18. The trunking N_Port or F_Port of claim 14, wherein each of the virtual SAN interfaces providing the functionality of a corresponding one of the one or more virtual SANs that are common to the trunking N_Port or F_Port and the peer port by providing frames containing information identifying the corresponding one of the one or more virtual SANs.
19. A storage area network comprising:
(a) two or more nodes, each comprising a trunking N_Port coupled to a Fibre Channel link; and
(b) one or more Fibre Channel switches comprising multiple F_Ports in communication with the trunking N_Ports and defining a fabric allowing communication among the two or more nodes,
wherein the trunking N_Ports comprise controllers designed or configured to communicate with F_Ports on a Fibre Channel switch and determine whether virtual Storage Area Network (SAN) functionality exists on the F_Ports and if so define one or more virtual SAN interfaces on their trunking N_Ports for one or more virtual SANs that are common to the trunking N_Ports and the F_Ports, with each of the one or more virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of the one or more virtual SANs, wherein each of the controllers is further designed or configured to identify virtual SANs that are common to the corresponding one of the trunking N_Ports and a corresponding one of the F_Ports, to thereby define the one or more virtual SAN interfaces on the trunking N_Ports.
20. The storage area network of claim 19, wherein the two or more nodes comprise one or more storage nodes and one or more host nodes.
21. The storage area network of claim 19, wherein the controllers communicate with the F_Ports using Exchange Peer Parameter (EPP) protocol.
22. The storage area network of claim 19, wherein the controllers employ the Exchange Peer Parameter (EPP) protocol to identify VSANs common to the F_Ports and the trunking N_Ports.
23. A method of establishing a link between a trunking N_Port on a node and an F_Port on a Fibre Channel switch, the method comprising:
(a) determining whether virtual Storage Area Network (SAN) functionality exists on the F_Port; and
(b) defining two or more virtual SAN interfaces on the trunking N_Port, with each of the two or more virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of two or more virtual SANs that are supported by the link between the trunking N_Port and the F_Port, wherein the functionality of an N_Port for a corresponding one of the two or more virtual SANs includes transmitting frames containing information identifying the corresponding one of the two or more virtual SANs.
24. The method of claim 23, wherein (a) and (b) are both implemented by communicating between the trunking N_Port on a node and the F_Port, the method further comprising:
identifying the two or more virtual SANs that are supported by the link between the trunking N_Port and the F_Port.
25. The method of claim 24, wherein the communicating comprises exchanging frames in Exchange Peer Parameter (EPP) protocol.
26. The method of claim 23, further comprising transmitting frames from one of the two or more of the virtual SAN interfaces, which frames containing information identifying the corresponding one of the two or more virtual SANs to which it belongs.
27. The method of claim 26, wherein the information identifying the particular virtual SAN to which it belongs is provided in an Extended Inter-Switch Link (EISL) header for the frames.
28. The method of claim 26, wherein the frames comprise QoS parameters defining levels of quality of service available for the virtual SANs.
29. The method of claim 23, further comprising conducting a negotiation between the trunking N_Port and the F_Port to determine a mode of operation with the F_Port, wherein available modes of operation include trunking and non-trunking.
30. A computer program product comprising a non-transitory computer-readable storage medium on which is provided program instructions for establishing a link between a trunking N_Port on a node and an F_Port on a Fibre Channel switch, wherein the program instructions comprise:
(a) code for determining by the N_Port whether virtual Storage Area Network (SAN) functionality exists on the F_Port;
(b) code for defining one or more virtual SAN interfaces on the trunking N_Port for one or more virtual SANs that are supported by the link between the trunking N_Port and the F_Port, with each of the virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of the one or more virtual SANs that are supported by the link between the trunking N_Port and the F_Port; and
(c) code for identifying the one or more virtual SANs that are supported by the link between the F_Port and the trunking N_Port, to thereby define the one or more virtual SAN interfaces on the trunking N_Port.
31. The computer program product of claim 30, wherein the program code for both (a) and (c) comprises code for communicating between the trunking N_Port on a node and the F_Port.
32. The computer program product of claim 31, wherein the code for communicating comprises code for exchanging frames in Exchange Peer Parameter (EPP) protocol.
33. The computer program product of claim 30, further comprising code for transmitting frames from the one or more of the virtual SAN interfaces, which frames containing information identifying the corresponding one of the one or more virtual SANs to which it belongs.
34. The computer program product of claim 33, wherein the code for transmitting frames comprises code for providing an Extended Inter-Switch Link (EISL) header for the frames.
35. The computer program product of claim 33, wherein the code for transmitting frames comprises code for providing QoS parameters defining levels of quality of service available for the virtual SANs.
36. The computer program product of claim 30, further comprising code for conducting a negotiation between the trunking N_Port and the F_Port to determine a mode of operation with the F_Port, wherein available modes of operation include trunking and non-trunking.
37. A trunking N_Port for a Fibre Channel node, the trunking N_Port comprising:
(a) means for determining whether virtual Storage Area Network (SAN) functionality exists on a F_Port to which the trunking N_Port is linked;
(b) means for defining one or more virtual SAN interfaces on the trunking N_Port for one or more virtual SANs that are supported by the F_Port, with each of the virtual SAN interfaces providing the functionality of an N_Port for a corresponding one of the one or more virtual SANs that are supported by the F_Port; and
(c) means for identifying the one or more virtual SANs that are supported by the F_Port, to thereby define the one or more virtual SAN interfaces on the trunking N_Port.
38. The trunking N_Port of claim 37, wherein the means for determining is designed or configured to exchange frames in Exchange Peer Parameter (EPP) protocol.
39. The trunking N_Port of claim 37, further comprising means for transmitting frames from the one or more of the virtual SAN interfaces, which frames containing information identifying the corresponding one of the one or more virtual SANs to which it belongs.
40. The trunking N_Port of claim 39, wherein the information identifying the particular virtual SAN to which it belongs is provided in an Extended Inter-Switch Link (EISL) header for the frames.
41. The trunking N_Port of claim 39, wherein the frames comprise QoS parameters defining levels of quality of service available for the virtual SANs.
42. The trunking N_Port of claim 37, further comprising means for conducting a negotiation between the trunking N_Port and the F_Port to determine a mode of operation with the F_Port, wherein available modes of operation include trunking and non-trunking.
US10/979,886 2004-11-01 2004-11-01 Trunking for fabric ports in fibre channel switches and attached devices Active 2029-05-02 US7916628B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US10/979,886 US7916628B2 (en) 2004-11-01 2004-11-01 Trunking for fabric ports in fibre channel switches and attached devices
US13/031,013 US8750094B2 (en) 2004-11-01 2011-02-18 Trunking for fabric ports in Fibre channel switches and attached devices

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/979,886 US7916628B2 (en) 2004-11-01 2004-11-01 Trunking for fabric ports in fibre channel switches and attached devices

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/031,013 Continuation US8750094B2 (en) 2004-11-01 2011-02-18 Trunking for fabric ports in Fibre channel switches and attached devices

Publications (2)

Publication Number Publication Date
US20060092932A1 US20060092932A1 (en) 2006-05-04
US7916628B2 true US7916628B2 (en) 2011-03-29

Family

ID=36261770

Family Applications (2)

Application Number Title Priority Date Filing Date
US10/979,886 Active 2029-05-02 US7916628B2 (en) 2004-11-01 2004-11-01 Trunking for fabric ports in fibre channel switches and attached devices
US13/031,013 Active 2025-04-07 US8750094B2 (en) 2004-11-01 2011-02-18 Trunking for fabric ports in Fibre channel switches and attached devices

Family Applications After (1)

Application Number Title Priority Date Filing Date
US13/031,013 Active 2025-04-07 US8750094B2 (en) 2004-11-01 2011-02-18 Trunking for fabric ports in Fibre channel switches and attached devices

Country Status (1)

Country Link
US (2) US7916628B2 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100008375A1 (en) * 2002-04-01 2010-01-14 Cisco Technology, Inc. Label switching in fibre channel networks
US20110255533A1 (en) * 2010-04-14 2011-10-20 Brocade Communications Systems, Inc. Remote F_Ports
US20120110385A1 (en) * 2010-10-29 2012-05-03 International Business Machines Corporation Multiple functionality in a virtual storage area network device
US8605624B2 (en) 2002-11-27 2013-12-10 Cisco Technology, Inc. Methods and devices for exchanging peer parameters between network devices
US8972611B2 (en) 2011-08-11 2015-03-03 Cisco Technology, Inc. Multi-server consolidated input/output (IO) device
US20150188753A1 (en) * 2013-12-27 2015-07-02 Dell Products L.P. N-node virtual link trunking (vlt) systems fault management
US20150188760A1 (en) * 2013-12-27 2015-07-02 Dell Products L.P. N-node virtual link trunking (vlt) systems management plane

Families Citing this family (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7599360B2 (en) * 2001-12-26 2009-10-06 Cisco Technology, Inc. Methods and apparatus for encapsulating a frame for transmission in a storage area network
US7499410B2 (en) * 2001-12-26 2009-03-03 Cisco Technology, Inc. Fibre channel switch that enables end devices in different fabrics to communicate with one another while retaining their unique fibre channel domain—IDs
US7406034B1 (en) 2002-04-01 2008-07-29 Cisco Technology, Inc. Methods and apparatus for fibre channel frame delivery
US7206288B2 (en) * 2002-06-12 2007-04-17 Cisco Technology, Inc. Methods and apparatus for characterizing a route in fibre channel fabric
US8081642B2 (en) 2003-01-31 2011-12-20 Brocade Communications Systems, Inc. Method and apparatus for routing between fibre channel fabrics
US7707309B2 (en) * 2004-01-29 2010-04-27 Brocade Communication Systems, Inc. Isolation switch for fibre channel fabrics in storage area networks
US7907626B2 (en) * 2004-08-12 2011-03-15 Broadcom Corporation Method and system to allocate exchange identifications for Fibre Channel N-Port aggregation
US7796627B2 (en) * 2004-08-12 2010-09-14 Broadcom Corporation Apparatus and system for coupling and decoupling initiator devices to a network using an arbitrated loop without disrupting the network
US7814189B2 (en) * 2004-08-12 2010-10-12 Broadcom Corporation Method and system to connect multiple SCSI initiators to a fibre channel fabric topology using a single N-port
US8396061B2 (en) * 2004-08-12 2013-03-12 Broadcom Corporation Apparatus and system for coupling and decoupling initiator devices to a network without disrupting the network
US7593324B2 (en) * 2004-10-25 2009-09-22 Cisco Technology, Inc. Graceful port shutdown protocol for fibre channel interfaces
US7649844B2 (en) * 2004-12-29 2010-01-19 Cisco Technology, Inc. In-order fibre channel packet delivery
US7577134B2 (en) * 2005-08-19 2009-08-18 Brocade Communications Systems, Inc. Port expander for fibre channel fabrics in storage area networks
US7760717B2 (en) * 2005-10-25 2010-07-20 Brocade Communications Systems, Inc. Interface switch for use with fibre channel fabrics in storage area networks
US7484021B2 (en) * 2005-10-27 2009-01-27 Cisco Technology, Inc. Technique for implementing virtual fabric membership assignments for devices in a storage area network
US7644179B1 (en) 2005-12-01 2010-01-05 Cisco Technology, Inc. Inter-VSAN routing with NAT
US7769023B2 (en) * 2005-12-21 2010-08-03 Cisco Technology, Inc. Fibre channel traffic redirect scheme using access control lists
US8218968B2 (en) * 2006-10-16 2012-07-10 Fujitsu Limited System and method for discovering neighboring nodes
US7986623B2 (en) * 2006-10-16 2011-07-26 Fujitsu Limited System and method for rejecting a request to alter a connection
US7688834B2 (en) * 2006-10-16 2010-03-30 Fujitsu Limited System and method for providing support for multiple control channels
US7889640B2 (en) * 2006-10-16 2011-02-15 Fujitsu Limited System and method for establishing protected connections
US8036229B2 (en) 2007-10-08 2011-10-11 Cisco Technology, Inc. Switch with virtual network identifier re-write capability
US9342339B2 (en) * 2007-11-07 2016-05-17 Brocade Communications Systems, Inc. Method and system for congestion management in a fibre channel network
US8374502B2 (en) * 2009-02-27 2013-02-12 Futurewei Technologies, Inc. Open shortest path first extensions in support of wavelength switched optical networks
US7948920B2 (en) * 2009-03-03 2011-05-24 Cisco Technology, Inc. Trunking with port aggregation for fabric ports in a fibre channel fabric and attached devices
US8493983B2 (en) 2010-06-02 2013-07-23 Cisco Technology, Inc. Virtual fabric membership assignments for fiber channel over Ethernet network devices
US8625595B2 (en) 2010-11-29 2014-01-07 Cisco Technology, Inc. Fiber channel identifier mobility for fiber channel and fiber channel over ethernet networks
US8842670B2 (en) 2010-12-21 2014-09-23 Cisco Technology, Inc. Scaling number of virtual links in a fiber channel forwarder device
CN102148760B (en) * 2011-04-02 2014-01-22 福建星网锐捷网络有限公司 Identification (ID) application method, device and system
WO2015050861A1 (en) * 2013-10-04 2015-04-09 Brocade Communication Systems, Inc. 128 gigabit fibre channel speed negotiation
US11206226B1 (en) 2020-06-10 2021-12-21 International Business Machines Corporation Switched fabric network routing mode selection
US11405333B2 (en) 2020-06-10 2022-08-02 International Business Machines Corporation Switched fabric network routing mode support

Citations (149)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428471A (en) 1992-07-30 1995-06-27 Alcatel Network Systems, Inc. Fail-safe automatic shut-down apparatus and method for high output power optical communications system
US5506838A (en) 1994-12-29 1996-04-09 Emc Corporation Packet propagation and dynamic route discovery apparatus and techniques
US5617421A (en) 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5619497A (en) 1994-12-22 1997-04-08 Emc Corporation Method and apparatus for reordering frames
EP0772121A1 (en) 1995-10-26 1997-05-07 Hewlett-Packard Company Method and apparatus for memory sequencing
US5675741A (en) 1994-10-25 1997-10-07 Cabletron Systems, Inc. Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network
US5682479A (en) 1995-05-05 1997-10-28 Silicon Graphics, Inc. System and method for network exploration and access
US5708659A (en) 1993-10-20 1998-01-13 Lsi Logic Corporation Method for hashing in a packet network switching system
US5740171A (en) 1996-03-28 1998-04-14 Cisco Systems, Inc. Address translation mechanism for a high-performance network switch
US5740159A (en) 1996-05-23 1998-04-14 Northern Telecom Limited Loopback mechanism for frame relay OAM
US5742604A (en) 1996-03-28 1998-04-21 Cisco Systems, Inc. Interswitch link mechanism for connecting high-performance network switches
US5764636A (en) 1996-03-28 1998-06-09 Cisco Technology, Inc. Color blocking logic mechanism for a high-performance network switch
US5793976A (en) 1996-04-01 1998-08-11 Gte Laboratories Incorporated Method and apparatus for performance monitoring in electronic communications networks
US5809285A (en) 1995-12-21 1998-09-15 Compaq Computer Corporation Computer system having a virtual drive array controller
US5818603A (en) 1996-03-29 1998-10-06 Ricoh Company, Ltd. Method and system for controlling and communicating with machines using multiple communication formats
US5819112A (en) 1995-09-08 1998-10-06 Microsoft Corporation Apparatus for controlling an I/O port by queuing requests and in response to a predefined condition, enabling the I/O port to receive the interrupt requests
US5862125A (en) 1995-06-07 1999-01-19 Mci Communication Corporation Automated restoration of unrestored link and nodal failures
US5959972A (en) 1997-05-27 1999-09-28 3Com Corporation Method of port/link redundancy in an ATM switch
US5959990A (en) 1996-03-12 1999-09-28 Bay Networks, Inc. VLAN frame format
US5964841A (en) 1997-03-03 1999-10-12 Cisco Technology, Inc. Technique for handling forwarding transients with link state routing protocol
US5999930A (en) 1996-08-02 1999-12-07 Hewlett-Packard Company Method and apparatus for distributed control of a shared storage volume
US6035105A (en) 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
US6046985A (en) 1996-04-10 2000-04-04 International Business Machines Corporation Communication system with exchange of capability information
US6101497A (en) 1996-05-31 2000-08-08 Emc Corporation Method and apparatus for independent and simultaneous access to a common data set
US6160813A (en) 1997-03-21 2000-12-12 Brocade Communications Systems, Inc. Fibre channel switching system and method
US6188668B1 (en) 1998-05-01 2001-02-13 Emulex Corporation Automatic isolation in loops
US6188694B1 (en) 1997-12-23 2001-02-13 Cisco Technology, Inc. Shared spanning tree protocol
US6202135B1 (en) 1996-12-23 2001-03-13 Emc Corporation System and method for reconstructing data associated with protected storage volume stored in multiple modules of back-up mass data storage facility
US6205488B1 (en) 1998-11-13 2001-03-20 Nortel Networks Limited Internet protocol virtual private network realization using multi-protocol label switching tunnels
US6209059B1 (en) 1997-09-25 2001-03-27 Emc Corporation Method and apparatus for the on-line reconfiguration of the logical volumes of a data storage system
US6208649B1 (en) 1998-03-11 2001-03-27 Cisco Technology, Inc. Derived VLAN mapping technique
US6208623B1 (en) 1998-04-13 2001-03-27 3Com Corporation Method of combining PNNI and E-IISP in an asynchronous transfer mode network
US6226771B1 (en) 1998-12-14 2001-05-01 Cisco Technology, Inc. Method and apparatus for generating error detection data for encapsulated frames
US6243358B1 (en) 1997-02-07 2001-06-05 France Telecom Process and device for allocating resources in a packet transmission digital network
JP2001154929A (en) 1999-11-29 2001-06-08 Nec Software Shikoku Ltd Management method and system for substituting path system
US6260120B1 (en) 1998-06-29 2001-07-10 Emc Corporation Storage mapping and partitioning among multiple host processors in the presence of login state changes and host controller replacement
US6262977B1 (en) 1998-08-28 2001-07-17 3Com Corporation High availability spanning tree with rapid reconfiguration
US6266705B1 (en) 1998-09-29 2001-07-24 Cisco Systems, Inc. Look up mechanism and associated hash table for a network switch
US6269381B1 (en) 1998-06-30 2001-07-31 Emc Corporation Method and apparatus for backing up data before updating the data and for restoring from the backups
US6269431B1 (en) 1998-08-13 2001-07-31 Emc Corporation Virtual storage and block level direct access of secondary storage for recovery of backup data
US20010020254A1 (en) 1998-06-30 2001-09-06 Blumenau Steven M. Method and apparatus for managing access to storage devices in a storage system with access control
EP1134938A1 (en) 2000-03-17 2001-09-19 Nortel Networks Corporation System, device and method for supporting a label switched path across a non-MPLS compliant segment
US6295296B1 (en) 1998-09-08 2001-09-25 Cisco Technology, Inc. Use of a single data structure for label forwarding and imposition
US6295575B1 (en) 1998-06-29 2001-09-25 Emc Corporation Configuring vectors of logical storage units for data storage partitioning and sharing
US6310884B1 (en) 1998-05-21 2001-10-30 Lsi Logic Corporation Data transfer method and apparatus that allocate storage based upon a received relative offset
JP2001320420A (en) 2000-03-01 2001-11-16 Fujitsu Ltd Transmission path control apparatus and transmission path control method, and medium with recorded transmission path control program
US20010049739A1 (en) 2000-06-02 2001-12-06 Koji Wakayama Apparatus and method for interworking between MPLS network and non-MPLS network
US6330614B1 (en) 1998-03-20 2001-12-11 Nexabit Networks Llc Internet and related networks, a method of and system for substitute use of checksum field space in information processing datagram headers for obviating processing speed and addressing space limitations and providing other features
US6337861B1 (en) 1999-02-02 2002-01-08 Cisco Technology, Inc. Method and apparatus to properly route ICMP messages in a tag-switching network
US20020009081A1 (en) 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with frame forwarding and address learning
US20020034178A1 (en) 2000-06-02 2002-03-21 Inrange Technologies Corporation Fibre channel address adaptor having data buffer extension and address mapping in a fibre channel switch
US6388995B1 (en) 1997-12-24 2002-05-14 Cisco Technology, Inc. Method and apparatus for rapidly reconfiguring computers networks executing the spanning tree algorithm
US6408001B1 (en) 1998-10-21 2002-06-18 Lucent Technologies Inc. Method for determining label assignments for a router
US20020075873A1 (en) 2000-12-20 2002-06-20 Gwenda Lindhorst-Ko Method of protecting traffic in a mesh network
US20020085493A1 (en) 2000-12-19 2002-07-04 Rick Pekkala Method and apparatus for over-advertising infiniband buffering resources
US6426952B1 (en) 1998-09-18 2002-07-30 The United States Of America As Represented By The Secretary Of The Navy Multi-interface point-to-point switching system (MIPPSS) having an internal universal signal format
US20020101868A1 (en) 2001-01-30 2002-08-01 David Clear Vlan tunneling protocol
US20020110125A1 (en) 1998-10-23 2002-08-15 David Banks Method and system for creating and implementing zones in hardware within a fibre channel system
US6438612B1 (en) 1998-09-11 2002-08-20 Ssh Communications Security, Ltd. Method and arrangement for secure tunneling of data between virtual routers
US20020133740A1 (en) 2001-03-15 2002-09-19 Oldfield Barry J. Redundant controller data storage system having system and method for handling controller resets
US20020150039A1 (en) 2001-03-30 2002-10-17 Ezio Valdevit In-order delivery of frames during topology change
US20020152338A1 (en) 1998-10-14 2002-10-17 Elliott Joseph C. Method, system and program product for detecting lost sequences within an exchange on fibre channel
US20020156924A1 (en) 2001-04-23 2002-10-24 Moshe Czeiger Method for communicating between fibre channel systems
US20020156918A1 (en) 2001-04-23 2002-10-24 Brocade Communications Systems, Inc. Dynamic path selection with in-order delivery within sequence in a communication network
US6473421B1 (en) 1999-03-29 2002-10-29 Cisco Technology, Inc. Hierarchical label switching across multiple OSPF areas
US20020176434A1 (en) 2001-04-18 2002-11-28 Brocade Communications Systems, Inc. Fibre channel zoning by logical unit number in hardware
US6493349B1 (en) 1998-11-13 2002-12-10 Nortel Networks Limited Extended internet protocol virtual private network architectures
US20020188754A1 (en) 2001-04-27 2002-12-12 Foster Michael S. Method and system for domain addressing in a communications network
US20030012204A1 (en) 2001-07-11 2003-01-16 Sancastle Technologies, Ltd Extension of fibre channel addressing
US20030016624A1 (en) 1998-05-04 2003-01-23 Bare Ballard C. Path recovery on failure in load balancing switch protocols
US6529963B1 (en) 1998-12-29 2003-03-04 Lsi Logic Corporation Methods and apparatus for interconnecting independent fibre channel fabrics
US6532212B1 (en) 2001-09-25 2003-03-11 Mcdata Corporation Trunking inter-switch links
US20030067925A1 (en) 2001-10-05 2003-04-10 Samsung Electronics Co., Ltd. Routing coordination protocol for a massively parallel router architecture
US20030101239A1 (en) 2001-11-27 2003-05-29 Takeshi Ishizaki Storage device with VLAN support
US20030107987A1 (en) 2001-12-07 2003-06-12 Kinstler Gary A. Reconfiguration system for a communication network
US20030118053A1 (en) * 2001-12-26 2003-06-26 Andiamo Systems, Inc. Methods and apparatus for encapsulating a frame for transmission in a storage area network
US20030145116A1 (en) 2002-01-24 2003-07-31 Andrew Moroney System for communication with a storage area network
US20030149848A1 (en) 2001-09-07 2003-08-07 Rahim Ibrahim Wire-speed data transfer in a storage virtualization controller
US6604407B2 (en) 2001-04-03 2003-08-12 Denso Corporation Leak check apparatus for fuel vapor purge system
US20030163727A1 (en) 2002-01-31 2003-08-28 Brocade Communications Systems, Inc. Network security through configuration servers in the fabric environment
US20030189929A1 (en) 2002-04-04 2003-10-09 Fujitsu Limited Electronic apparatus for assisting realization of storage area network system
US20030198247A1 (en) 1999-09-21 2003-10-23 Gardner Steven Lyle Advanced ethernet auto negotiation
US6643287B1 (en) 1999-11-24 2003-11-04 Pluris, Inc. Apparatus and method for forwarding encapsulated data packets on a network having multiple links between nodes
US6661773B1 (en) 1999-06-07 2003-12-09 Intel Corporation Method for detection of stale cells following route changes in a data communication
US6674760B1 (en) 1999-09-28 2004-01-06 Extreme Networks, Inc. Method and system for implementing end-to-end QoS in packet-switched networks
US20040028060A1 (en) 2002-08-08 2004-02-12 Samsung Electronics Co., Ltd. Link state synchronization method and apparatus on ad-hoc network, and data structure therefor
EP1187406B1 (en) 2000-06-28 2004-02-18 Nortel Networks Limited Label switched communications network
US6728848B2 (en) 2001-06-11 2004-04-27 Hitachi, Ltd. Method and system for backing up storage system data
US6728220B2 (en) 2001-05-24 2004-04-27 Riverstone Networks, Inc. Method and system for preventing transmission loops in a label switching domain
US6766482B1 (en) 2001-10-31 2004-07-20 Extreme Networks Ethernet automatic protection switching
US20040151188A1 (en) * 2003-01-31 2004-08-05 Brocade Communications Systems, Inc. Method and apparatus for providing virtual ports with attached virtual devices in a storage area network
US20040151174A1 (en) 2003-01-31 2004-08-05 Brocade Communications Systems, Inc. Method and apparatus for routing between fibre channel fabrics
US6775230B1 (en) 2000-07-18 2004-08-10 Hitachi, Ltd. Apparatus and method for transmitting frames via a switch in a storage area network
US6804776B1 (en) 1999-09-21 2004-10-12 Cisco Technology, Inc. Method for universal transport encapsulation for Internet Protocol network communications
US20040230787A1 (en) 1999-04-21 2004-11-18 Emc Corporation Method and apparatus for dynamically modifying a computer system configuration
US20040233921A1 (en) 2003-05-23 2004-11-25 Krieg William R. Virtual switch for use in fibre channel applications
US6848007B1 (en) 1999-11-12 2005-01-25 Crossroads Systems, Inc. System for mapping addresses of SCSI devices between plurality of SANs that can dynamically map SCSI device addresses across a SAN extender
US20050018663A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for power control of fibre channel switches
US20050018606A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for congestion control based on optimum bandwidth allocation in a fibre channel switch
US20050018701A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for routing fibre channel frames
US20050036499A1 (en) 2001-12-26 2005-02-17 Andiamo Systems, Inc., A Delaware Corporation Fibre Channel Switch that enables end devices in different fabrics to communicate with one another while retaining their unique Fibre Channel Domain_IDs
US6859435B1 (en) 1999-10-13 2005-02-22 Lucent Technologies Inc. Prevention of deadlocks and livelocks in lossless, backpressured packet networks
US6879560B1 (en) 2000-12-08 2005-04-12 At&T Corp. System and method for limiting congestion over a switch network
US20050080903A1 (en) 2003-09-30 2005-04-14 Moshe Valenci Method, system, and program for maintaining a link between two network entities
US20050088969A1 (en) 2001-12-19 2005-04-28 Scott Carlsen Port congestion notification in a switch
US20050108444A1 (en) 2003-11-19 2005-05-19 Flauaus Gary R. Method of detecting and monitoring fabric congestion
US20050117562A1 (en) 2000-09-26 2005-06-02 Wrenn Richard F. Method and apparatus for distributing traffic over multiple switched fibre channel routes
US6904053B1 (en) 1997-02-18 2005-06-07 Emulux Design & Manufacturing Corporation Fibre Channel switching fabric
US6915358B2 (en) 2001-09-24 2005-07-05 Broadcom Corporation System and method for hardware based reassembly of a fragmented packet
US6920153B2 (en) 2000-07-17 2005-07-19 Nortel Networks Limited Architecture and addressing scheme for storage interconnect and emerging storage service providers
US6920133B1 (en) 2000-06-07 2005-07-19 At&T Corp. Techniques for introducing in-band network management packets in multi-protocol label switching networks
US6920154B1 (en) 2001-12-17 2005-07-19 Supergate Technology Usa, Inc. Architectures for a modularized data optimization engine and methods therefor
US20050177634A1 (en) 2004-02-10 2005-08-11 Scudder John G. Technique for graceful shutdown of a routing protocol in a network
US6947379B1 (en) 2001-04-03 2005-09-20 Cisco Technology, Inc. Packet routing to reduce susceptibility to disturbances
US6959151B1 (en) 1999-05-11 2005-10-25 British Telecommunications Public Limited Company Communication network
US20050249123A1 (en) 2004-05-10 2005-11-10 Finn Norman W System and method for detecting link failures
US20050267965A1 (en) 2004-05-13 2005-12-01 Ixi Mobile (R&D) Ltd. Mobile router graceful shutdown system and method
US6975589B2 (en) 2000-12-30 2005-12-13 Redback Networks Inc. Method and apparatus for a hybrid variable rate pipe
US20060034302A1 (en) 2004-07-19 2006-02-16 David Peterson Inter-fabric routing
US20060038263A1 (en) 2003-02-26 2006-02-23 Infineon Technologies Ag Semiconductor chip arrangement
US7006525B1 (en) 2000-02-23 2006-02-28 Cypress Semiconductor Corp. Hybrid data transport scheme over optical networks
US7027406B1 (en) 1998-04-16 2006-04-11 Avaya Communication Israel Ltd. Distributed port-blocking method
US7026288B2 (en) 2000-05-02 2006-04-11 Theravance, Inc. Pharmaceutical compositions containing a glycopeptide antibiotic and a cyclodextrin
US20060087963A1 (en) 2004-10-25 2006-04-27 Cisco Technology, Inc. Graceful port shutdown protocol for fibre channel interfaces
US7054304B2 (en) 2001-01-19 2006-05-30 Terited International , Inc. Method and protocol for managing broadband IP services in a layer two broadcast network
US20060117212A1 (en) 2001-02-13 2006-06-01 Network Appliance, Inc. Failover processing in a storage system
US7061858B1 (en) 2000-08-23 2006-06-13 Cisco Technology, Inc. High availability architecture for network devices
US7072298B2 (en) 2001-06-13 2006-07-04 Computer Network Technology Corporation Method and apparatus for rendering a cell-based switch useful for frame based protocols
US7076594B2 (en) 2000-12-22 2006-07-11 Cisco Technology, Inc. Apparatus and method for preventing one way connectivity loops in a computer network
US20060153186A1 (en) 2004-12-29 2006-07-13 Cisco Technology, Inc. In-order fibre channel packet delivery
US20060159081A1 (en) 2005-01-18 2006-07-20 Dropps Frank R Address translation in fibre channel switches
US7085846B2 (en) 2001-12-31 2006-08-01 Maxxan Systems, Incorporated Buffer to buffer credit flow control for computer network
US7155494B2 (en) 2002-01-09 2006-12-26 Sancastle Technologies Ltd. Mapping between virtual local area networks and fibre channel zones
US7161935B2 (en) 2002-01-31 2007-01-09 Brocade Communications Stystems, Inc. Network fabric management via adjunct processor inter-fabric service link
US7206288B2 (en) 2002-06-12 2007-04-17 Cisco Technology, Inc. Methods and apparatus for characterizing a route in fibre channel fabric
US7216158B2 (en) 2002-01-18 2007-05-08 Bea Systems, Inc. System, method and interface for controlling server lifecycle
US7221652B1 (en) 2001-12-14 2007-05-22 Applied Micro Circuits Corporation System and method for tolerating data link faults in communications with a switch fabric
US7275103B1 (en) * 2002-12-18 2007-09-25 Veritas Operating Corporation Storage path optimization for SANs
US7301898B1 (en) 2002-07-29 2007-11-27 Brocade Communications Systems, Inc. Credit sharing for fibre channel links with multiple virtual channels
US7302494B2 (en) 2000-12-21 2007-11-27 Fujitsu Limited Traffic engineering method and node apparatus using traffic engineering method
US7319669B1 (en) 2002-11-22 2008-01-15 Qlogic, Corporation Method and system for controlling packet flow in networks
US20080028096A1 (en) * 2003-10-21 2008-01-31 Henderson Alex E Transporting fibre channel over ethernet
US7328260B1 (en) * 2002-06-04 2008-02-05 Symantec Operating Corporation Mapping discovered devices to SAN-manageable objects using configurable rules
US7376755B2 (en) 2002-06-11 2008-05-20 Pandya Ashish A TCP/IP processor and engine using RDMA
US7406034B1 (en) 2002-04-01 2008-07-29 Cisco Technology, Inc. Methods and apparatus for fibre channel frame delivery
US7433326B2 (en) 2002-11-27 2008-10-07 Cisco Technology, Inc. Methods and devices for exchanging peer parameters between network devices
US7443799B2 (en) 2003-10-31 2008-10-28 Brocade Communication Systems, Inc. Load balancing in core-edge configurations
US7586947B2 (en) 2000-05-30 2009-09-08 Hitachi, Ltd. Label switching type of packet forwarding apparatus
US7616637B1 (en) 2002-04-01 2009-11-10 Cisco Technology, Inc. Label switching in fibre channel networks

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0858036A3 (en) 1997-02-10 1999-12-22 Compaq Computer Corporation Fibre channel attached storage architecture
JP3538707B2 (en) 2000-02-21 2004-06-14 株式会社村田製作所 Silicone rubber curing method and curing device
JP2002027544A (en) * 2000-07-04 2002-01-25 Fujitsu Ltd Data storing system
CA2439692A1 (en) 2001-03-01 2002-09-12 Storeage Networking Technologies Storage area network (san) security
US7336194B2 (en) * 2005-05-19 2008-02-26 Apwh Limited Closure for bottle/container

Patent Citations (168)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5428471A (en) 1992-07-30 1995-06-27 Alcatel Network Systems, Inc. Fail-safe automatic shut-down apparatus and method for high output power optical communications system
US5708659A (en) 1993-10-20 1998-01-13 Lsi Logic Corporation Method for hashing in a packet network switching system
US5617421A (en) 1994-06-17 1997-04-01 Cisco Systems, Inc. Extended domain computer network using standard links
US5675741A (en) 1994-10-25 1997-10-07 Cabletron Systems, Inc. Method and apparatus for determining a communications path between two nodes in an Internet Protocol (IP) network
US5619497A (en) 1994-12-22 1997-04-08 Emc Corporation Method and apparatus for reordering frames
US5506838A (en) 1994-12-29 1996-04-09 Emc Corporation Packet propagation and dynamic route discovery apparatus and techniques
US5682479A (en) 1995-05-05 1997-10-28 Silicon Graphics, Inc. System and method for network exploration and access
US5862125A (en) 1995-06-07 1999-01-19 Mci Communication Corporation Automated restoration of unrestored link and nodal failures
US5819112A (en) 1995-09-08 1998-10-06 Microsoft Corporation Apparatus for controlling an I/O port by queuing requests and in response to a predefined condition, enabling the I/O port to receive the interrupt requests
EP0772121A1 (en) 1995-10-26 1997-05-07 Hewlett-Packard Company Method and apparatus for memory sequencing
US5809285A (en) 1995-12-21 1998-09-15 Compaq Computer Corporation Computer system having a virtual drive array controller
US6219699B1 (en) 1996-01-02 2001-04-17 Cisco Technologies, Inc. Multiple VLAN Architecture system
US6035105A (en) 1996-01-02 2000-03-07 Cisco Technology, Inc. Multiple VLAN architecture system
US5959990A (en) 1996-03-12 1999-09-28 Bay Networks, Inc. VLAN frame format
US5740171A (en) 1996-03-28 1998-04-14 Cisco Systems, Inc. Address translation mechanism for a high-performance network switch
US5764636A (en) 1996-03-28 1998-06-09 Cisco Technology, Inc. Color blocking logic mechanism for a high-performance network switch
US5742604A (en) 1996-03-28 1998-04-21 Cisco Systems, Inc. Interswitch link mechanism for connecting high-performance network switches
US5818603A (en) 1996-03-29 1998-10-06 Ricoh Company, Ltd. Method and system for controlling and communicating with machines using multiple communication formats
US5793976A (en) 1996-04-01 1998-08-11 Gte Laboratories Incorporated Method and apparatus for performance monitoring in electronic communications networks
US6046985A (en) 1996-04-10 2000-04-04 International Business Machines Corporation Communication system with exchange of capability information
US5740159A (en) 1996-05-23 1998-04-14 Northern Telecom Limited Loopback mechanism for frame relay OAM
US6101497A (en) 1996-05-31 2000-08-08 Emc Corporation Method and apparatus for independent and simultaneous access to a common data set
US5999930A (en) 1996-08-02 1999-12-07 Hewlett-Packard Company Method and apparatus for distributed control of a shared storage volume
US6202135B1 (en) 1996-12-23 2001-03-13 Emc Corporation System and method for reconstructing data associated with protected storage volume stored in multiple modules of back-up mass data storage facility
US6243358B1 (en) 1997-02-07 2001-06-05 France Telecom Process and device for allocating resources in a packet transmission digital network
US6904053B1 (en) 1997-02-18 2005-06-07 Emulux Design & Manufacturing Corporation Fibre Channel switching fabric
US6597663B1 (en) 1997-03-03 2003-07-22 Cisco Technology, Inc. Technique for handling forwarding transients with link state routing protocol
US5964841A (en) 1997-03-03 1999-10-12 Cisco Technology, Inc. Technique for handling forwarding transients with link state routing protocol
US6160813A (en) 1997-03-21 2000-12-12 Brocade Communications Systems, Inc. Fibre channel switching system and method
US5959972A (en) 1997-05-27 1999-09-28 3Com Corporation Method of port/link redundancy in an ATM switch
US6209059B1 (en) 1997-09-25 2001-03-27 Emc Corporation Method and apparatus for the on-line reconfiguration of the logical volumes of a data storage system
US6188694B1 (en) 1997-12-23 2001-02-13 Cisco Technology, Inc. Shared spanning tree protocol
US6388995B1 (en) 1997-12-24 2002-05-14 Cisco Technology, Inc. Method and apparatus for rapidly reconfiguring computers networks executing the spanning tree algorithm
US6208649B1 (en) 1998-03-11 2001-03-27 Cisco Technology, Inc. Derived VLAN mapping technique
US6330614B1 (en) 1998-03-20 2001-12-11 Nexabit Networks Llc Internet and related networks, a method of and system for substitute use of checksum field space in information processing datagram headers for obviating processing speed and addressing space limitations and providing other features
US6208623B1 (en) 1998-04-13 2001-03-27 3Com Corporation Method of combining PNNI and E-IISP in an asynchronous transfer mode network
US7027406B1 (en) 1998-04-16 2006-04-11 Avaya Communication Israel Ltd. Distributed port-blocking method
US6188668B1 (en) 1998-05-01 2001-02-13 Emulex Corporation Automatic isolation in loops
US20030016624A1 (en) 1998-05-04 2003-01-23 Bare Ballard C. Path recovery on failure in load balancing switch protocols
US6310884B1 (en) 1998-05-21 2001-10-30 Lsi Logic Corporation Data transfer method and apparatus that allocate storage based upon a received relative offset
US6260120B1 (en) 1998-06-29 2001-07-10 Emc Corporation Storage mapping and partitioning among multiple host processors in the presence of login state changes and host controller replacement
US6295575B1 (en) 1998-06-29 2001-09-25 Emc Corporation Configuring vectors of logical storage units for data storage partitioning and sharing
US6269381B1 (en) 1998-06-30 2001-07-31 Emc Corporation Method and apparatus for backing up data before updating the data and for restoring from the backups
US20010020254A1 (en) 1998-06-30 2001-09-06 Blumenau Steven M. Method and apparatus for managing access to storage devices in a storage system with access control
US6269431B1 (en) 1998-08-13 2001-07-31 Emc Corporation Virtual storage and block level direct access of secondary storage for recovery of backup data
US6262977B1 (en) 1998-08-28 2001-07-17 3Com Corporation High availability spanning tree with rapid reconfiguration
US6295296B1 (en) 1998-09-08 2001-09-25 Cisco Technology, Inc. Use of a single data structure for label forwarding and imposition
US6438612B1 (en) 1998-09-11 2002-08-20 Ssh Communications Security, Ltd. Method and arrangement for secure tunneling of data between virtual routers
US6426952B1 (en) 1998-09-18 2002-07-30 The United States Of America As Represented By The Secretary Of The Navy Multi-interface point-to-point switching system (MIPPSS) having an internal universal signal format
US6266705B1 (en) 1998-09-29 2001-07-24 Cisco Systems, Inc. Look up mechanism and associated hash table for a network switch
US20020152338A1 (en) 1998-10-14 2002-10-17 Elliott Joseph C. Method, system and program product for detecting lost sequences within an exchange on fibre channel
US6408001B1 (en) 1998-10-21 2002-06-18 Lucent Technologies Inc. Method for determining label assignments for a router
US20020110125A1 (en) 1998-10-23 2002-08-15 David Banks Method and system for creating and implementing zones in hardware within a fibre channel system
US6205488B1 (en) 1998-11-13 2001-03-20 Nortel Networks Limited Internet protocol virtual private network realization using multi-protocol label switching tunnels
US6493349B1 (en) 1998-11-13 2002-12-10 Nortel Networks Limited Extended internet protocol virtual private network architectures
US6226771B1 (en) 1998-12-14 2001-05-01 Cisco Technology, Inc. Method and apparatus for generating error detection data for encapsulated frames
US6529963B1 (en) 1998-12-29 2003-03-04 Lsi Logic Corporation Methods and apparatus for interconnecting independent fibre channel fabrics
US6337861B1 (en) 1999-02-02 2002-01-08 Cisco Technology, Inc. Method and apparatus to properly route ICMP messages in a tag-switching network
US6473421B1 (en) 1999-03-29 2002-10-29 Cisco Technology, Inc. Hierarchical label switching across multiple OSPF areas
US20040230787A1 (en) 1999-04-21 2004-11-18 Emc Corporation Method and apparatus for dynamically modifying a computer system configuration
US6959151B1 (en) 1999-05-11 2005-10-25 British Telecommunications Public Limited Company Communication network
US6661773B1 (en) 1999-06-07 2003-12-09 Intel Corporation Method for detection of stale cells following route changes in a data communication
US6804776B1 (en) 1999-09-21 2004-10-12 Cisco Technology, Inc. Method for universal transport encapsulation for Internet Protocol network communications
US20030198247A1 (en) 1999-09-21 2003-10-23 Gardner Steven Lyle Advanced ethernet auto negotiation
US6674760B1 (en) 1999-09-28 2004-01-06 Extreme Networks, Inc. Method and system for implementing end-to-end QoS in packet-switched networks
US6859435B1 (en) 1999-10-13 2005-02-22 Lucent Technologies Inc. Prevention of deadlocks and livelocks in lossless, backpressured packet networks
US6848007B1 (en) 1999-11-12 2005-01-25 Crossroads Systems, Inc. System for mapping addresses of SCSI devices between plurality of SANs that can dynamically map SCSI device addresses across a SAN extender
US6643287B1 (en) 1999-11-24 2003-11-04 Pluris, Inc. Apparatus and method for forwarding encapsulated data packets on a network having multiple links between nodes
JP2001154929A (en) 1999-11-29 2001-06-08 Nec Software Shikoku Ltd Management method and system for substituting path system
US7006525B1 (en) 2000-02-23 2006-02-28 Cypress Semiconductor Corp. Hybrid data transport scheme over optical networks
JP2001320420A (en) 2000-03-01 2001-11-16 Fujitsu Ltd Transmission path control apparatus and transmission path control method, and medium with recorded transmission path control program
US7082140B1 (en) 2000-03-17 2006-07-25 Nortel Networks Ltd System, device and method for supporting a label switched path across a non-MPLS compliant segment
EP1134938A1 (en) 2000-03-17 2001-09-19 Nortel Networks Corporation System, device and method for supporting a label switched path across a non-MPLS compliant segment
US7026288B2 (en) 2000-05-02 2006-04-11 Theravance, Inc. Pharmaceutical compositions containing a glycopeptide antibiotic and a cyclodextrin
US7586947B2 (en) 2000-05-30 2009-09-08 Hitachi, Ltd. Label switching type of packet forwarding apparatus
US20020034178A1 (en) 2000-06-02 2002-03-21 Inrange Technologies Corporation Fibre channel address adaptor having data buffer extension and address mapping in a fibre channel switch
US7079544B2 (en) 2000-06-02 2006-07-18 Hitachi, Ltd. Apparatus and method for interworking between MPLS network and non-MPLS network
JP2001345865A (en) 2000-06-02 2001-12-14 Hitachi Ltd Packet transfer device, packet transfer control method and setting method for the packet transfer device
US20010049739A1 (en) 2000-06-02 2001-12-06 Koji Wakayama Apparatus and method for interworking between MPLS network and non-MPLS network
US6920133B1 (en) 2000-06-07 2005-07-19 At&T Corp. Techniques for introducing in-band network management packets in multi-protocol label switching networks
US7046679B2 (en) 2000-06-09 2006-05-16 Broadcom Corporation Gigabit switch with frame forwarding and address learning
US20020009081A1 (en) 2000-06-09 2002-01-24 Broadcom Corporation Gigabit switch with frame forwarding and address learning
EP1187406B1 (en) 2000-06-28 2004-02-18 Nortel Networks Limited Label switched communications network
US6920153B2 (en) 2000-07-17 2005-07-19 Nortel Networks Limited Architecture and addressing scheme for storage interconnect and emerging storage service providers
US6775230B1 (en) 2000-07-18 2004-08-10 Hitachi, Ltd. Apparatus and method for transmitting frames via a switch in a storage area network
US7061858B1 (en) 2000-08-23 2006-06-13 Cisco Technology, Inc. High availability architecture for network devices
US20050117562A1 (en) 2000-09-26 2005-06-02 Wrenn Richard F. Method and apparatus for distributing traffic over multiple switched fibre channel routes
US6879560B1 (en) 2000-12-08 2005-04-12 At&T Corp. System and method for limiting congestion over a switch network
US20020085493A1 (en) 2000-12-19 2002-07-04 Rick Pekkala Method and apparatus for over-advertising infiniband buffering resources
US20020075873A1 (en) 2000-12-20 2002-06-20 Gwenda Lindhorst-Ko Method of protecting traffic in a mesh network
US7302494B2 (en) 2000-12-21 2007-11-27 Fujitsu Limited Traffic engineering method and node apparatus using traffic engineering method
US7076594B2 (en) 2000-12-22 2006-07-11 Cisco Technology, Inc. Apparatus and method for preventing one way connectivity loops in a computer network
US6975589B2 (en) 2000-12-30 2005-12-13 Redback Networks Inc. Method and apparatus for a hybrid variable rate pipe
US7054304B2 (en) 2001-01-19 2006-05-30 Terited International , Inc. Method and protocol for managing broadband IP services in a layer two broadcast network
US20020101868A1 (en) 2001-01-30 2002-08-01 David Clear Vlan tunneling protocol
US20060117212A1 (en) 2001-02-13 2006-06-01 Network Appliance, Inc. Failover processing in a storage system
US20020133740A1 (en) 2001-03-15 2002-09-19 Oldfield Barry J. Redundant controller data storage system having system and method for handling controller resets
US20020150039A1 (en) 2001-03-30 2002-10-17 Ezio Valdevit In-order delivery of frames during topology change
US7050392B2 (en) 2001-03-30 2006-05-23 Brocade Communications Systems, Inc. In-order delivery of frames during topology change
US6604407B2 (en) 2001-04-03 2003-08-12 Denso Corporation Leak check apparatus for fuel vapor purge system
US6947379B1 (en) 2001-04-03 2005-09-20 Cisco Technology, Inc. Packet routing to reduce susceptibility to disturbances
US7366194B2 (en) 2001-04-18 2008-04-29 Brocade Communications Systems, Inc. Fibre channel zoning by logical unit number in hardware
US20020176434A1 (en) 2001-04-18 2002-11-28 Brocade Communications Systems, Inc. Fibre channel zoning by logical unit number in hardware
US20020156924A1 (en) 2001-04-23 2002-10-24 Moshe Czeiger Method for communicating between fibre channel systems
US20020156918A1 (en) 2001-04-23 2002-10-24 Brocade Communications Systems, Inc. Dynamic path selection with in-order delivery within sequence in a communication network
US20020188754A1 (en) 2001-04-27 2002-12-12 Foster Michael S. Method and system for domain addressing in a communications network
US6728220B2 (en) 2001-05-24 2004-04-27 Riverstone Networks, Inc. Method and system for preventing transmission loops in a label switching domain
US6728848B2 (en) 2001-06-11 2004-04-27 Hitachi, Ltd. Method and system for backing up storage system data
US7072298B2 (en) 2001-06-13 2006-07-04 Computer Network Technology Corporation Method and apparatus for rendering a cell-based switch useful for frame based protocols
US20030012204A1 (en) 2001-07-11 2003-01-16 Sancastle Technologies, Ltd Extension of fibre channel addressing
US6985490B2 (en) 2001-07-11 2006-01-10 Sancastle Technologies, Ltd. Extension of fibre channel addressing
US7330892B2 (en) 2001-09-07 2008-02-12 Network Appliance, Inc. High-speed data transfer in a storage virtualization controller
US20030149848A1 (en) 2001-09-07 2003-08-07 Rahim Ibrahim Wire-speed data transfer in a storage virtualization controller
US6915358B2 (en) 2001-09-24 2005-07-05 Broadcom Corporation System and method for hardware based reassembly of a fragmented packet
US6532212B1 (en) 2001-09-25 2003-03-11 Mcdata Corporation Trunking inter-switch links
US20030067925A1 (en) 2001-10-05 2003-04-10 Samsung Electronics Co., Ltd. Routing coordination protocol for a massively parallel router architecture
US6766482B1 (en) 2001-10-31 2004-07-20 Extreme Networks Ethernet automatic protection switching
US20030101239A1 (en) 2001-11-27 2003-05-29 Takeshi Ishizaki Storage device with VLAN support
US20030107987A1 (en) 2001-12-07 2003-06-12 Kinstler Gary A. Reconfiguration system for a communication network
US7221652B1 (en) 2001-12-14 2007-05-22 Applied Micro Circuits Corporation System and method for tolerating data link faults in communications with a switch fabric
US6920154B1 (en) 2001-12-17 2005-07-19 Supergate Technology Usa, Inc. Architectures for a modularized data optimization engine and methods therefor
US20050088969A1 (en) 2001-12-19 2005-04-28 Scott Carlsen Port congestion notification in a switch
US20050036499A1 (en) 2001-12-26 2005-02-17 Andiamo Systems, Inc., A Delaware Corporation Fibre Channel Switch that enables end devices in different fabrics to communicate with one another while retaining their unique Fibre Channel Domain_IDs
US20030118053A1 (en) * 2001-12-26 2003-06-26 Andiamo Systems, Inc. Methods and apparatus for encapsulating a frame for transmission in a storage area network
US7599360B2 (en) 2001-12-26 2009-10-06 Cisco Technology, Inc. Methods and apparatus for encapsulating a frame for transmission in a storage area network
US7085846B2 (en) 2001-12-31 2006-08-01 Maxxan Systems, Incorporated Buffer to buffer credit flow control for computer network
US7155494B2 (en) 2002-01-09 2006-12-26 Sancastle Technologies Ltd. Mapping between virtual local area networks and fibre channel zones
US7216158B2 (en) 2002-01-18 2007-05-08 Bea Systems, Inc. System, method and interface for controlling server lifecycle
US20030145116A1 (en) 2002-01-24 2003-07-31 Andrew Moroney System for communication with a storage area network
US20030163727A1 (en) 2002-01-31 2003-08-28 Brocade Communications Systems, Inc. Network security through configuration servers in the fabric environment
US7161935B2 (en) 2002-01-31 2007-01-09 Brocade Communications Stystems, Inc. Network fabric management via adjunct processor inter-fabric service link
US20100008375A1 (en) 2002-04-01 2010-01-14 Cisco Technology, Inc. Label switching in fibre channel networks
US7406034B1 (en) 2002-04-01 2008-07-29 Cisco Technology, Inc. Methods and apparatus for fibre channel frame delivery
US7616637B1 (en) 2002-04-01 2009-11-10 Cisco Technology, Inc. Label switching in fibre channel networks
US20030189929A1 (en) 2002-04-04 2003-10-09 Fujitsu Limited Electronic apparatus for assisting realization of storage area network system
US7328260B1 (en) * 2002-06-04 2008-02-05 Symantec Operating Corporation Mapping discovered devices to SAN-manageable objects using configurable rules
US7376755B2 (en) 2002-06-11 2008-05-20 Pandya Ashish A TCP/IP processor and engine using RDMA
US20070153816A1 (en) 2002-06-12 2007-07-05 Cisco Technology, Inc. Methods and apparatus for characterizing a route in a fibre channel fabric
US7206288B2 (en) 2002-06-12 2007-04-17 Cisco Technology, Inc. Methods and apparatus for characterizing a route in fibre channel fabric
US7301898B1 (en) 2002-07-29 2007-11-27 Brocade Communications Systems, Inc. Credit sharing for fibre channel links with multiple virtual channels
US20040028060A1 (en) 2002-08-08 2004-02-12 Samsung Electronics Co., Ltd. Link state synchronization method and apparatus on ad-hoc network, and data structure therefor
US7319669B1 (en) 2002-11-22 2008-01-15 Qlogic, Corporation Method and system for controlling packet flow in networks
US20080316942A1 (en) 2002-11-27 2008-12-25 Cisco Technology, Inc. Methods and devices for exchanging peer parameters between network devices
US7433326B2 (en) 2002-11-27 2008-10-07 Cisco Technology, Inc. Methods and devices for exchanging peer parameters between network devices
US7275103B1 (en) * 2002-12-18 2007-09-25 Veritas Operating Corporation Storage path optimization for SANs
US20040151188A1 (en) * 2003-01-31 2004-08-05 Brocade Communications Systems, Inc. Method and apparatus for providing virtual ports with attached virtual devices in a storage area network
US20040151174A1 (en) 2003-01-31 2004-08-05 Brocade Communications Systems, Inc. Method and apparatus for routing between fibre channel fabrics
US20060038263A1 (en) 2003-02-26 2006-02-23 Infineon Technologies Ag Semiconductor chip arrangement
US20040233921A1 (en) 2003-05-23 2004-11-25 Krieg William R. Virtual switch for use in fibre channel applications
US20090141657A1 (en) 2003-06-26 2009-06-04 Cisco Systems, Inc. FIBRE CHANNEL SWITCH THAT ENABLES END DEVICES IN DIFFERENT FABRICS TO COMMUNICATE WITH ONE ANOTHER WHILE RETAINING THEIR UNIQUE FIBRE CHANNEL DOMAIN_IDs
US20050018663A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for power control of fibre channel switches
US20050018606A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for congestion control based on optimum bandwidth allocation in a fibre channel switch
US20050018701A1 (en) 2003-07-21 2005-01-27 Dropps Frank R. Method and system for routing fibre channel frames
US7447224B2 (en) 2003-07-21 2008-11-04 Qlogic, Corporation Method and system for routing fibre channel frames
US20050080903A1 (en) 2003-09-30 2005-04-14 Moshe Valenci Method, system, and program for maintaining a link between two network entities
US20080028096A1 (en) * 2003-10-21 2008-01-31 Henderson Alex E Transporting fibre channel over ethernet
US7443799B2 (en) 2003-10-31 2008-10-28 Brocade Communication Systems, Inc. Load balancing in core-edge configurations
US20050108444A1 (en) 2003-11-19 2005-05-19 Flauaus Gary R. Method of detecting and monitoring fabric congestion
US20050177634A1 (en) 2004-02-10 2005-08-11 Scudder John G. Technique for graceful shutdown of a routing protocol in a network
US7355983B2 (en) 2004-02-10 2008-04-08 Cisco Technology, Inc. Technique for graceful shutdown of a routing protocol in a network
US20050249123A1 (en) 2004-05-10 2005-11-10 Finn Norman W System and method for detecting link failures
US20050267965A1 (en) 2004-05-13 2005-12-01 Ixi Mobile (R&D) Ltd. Mobile router graceful shutdown system and method
US20060034302A1 (en) 2004-07-19 2006-02-16 David Peterson Inter-fabric routing
US7593324B2 (en) 2004-10-25 2009-09-22 Cisco Technology, Inc. Graceful port shutdown protocol for fibre channel interfaces
US20060087963A1 (en) 2004-10-25 2006-04-27 Cisco Technology, Inc. Graceful port shutdown protocol for fibre channel interfaces
US20060153186A1 (en) 2004-12-29 2006-07-13 Cisco Technology, Inc. In-order fibre channel packet delivery
US7649844B2 (en) 2004-12-29 2010-01-19 Cisco Technology, Inc. In-order fibre channel packet delivery
US20060159081A1 (en) 2005-01-18 2006-07-20 Dropps Frank R Address translation in fibre channel switches

Non-Patent Citations (151)

* Cited by examiner, † Cited by third party
Title
Allowed Claims for U.S. Appl. No. 10/430,491.
Armitage, Grenville, "MPLS: The Magic Behind the Myths," Jan. 2000, IEEE Communications Magazine, pp. 124-131.
ATM Forum Committee, Chapter 10, "Flush Message Protocol Procedures and Frame Formats," LAN Emulation Over ATM Version 2-LUNI Specification, AF-Lane-0084.000, Jul. 1997, pp. 111-115.
AU Office Action (Mar. 16, 2007) from AU Patent Application No. 2002364204.
AU Office Action (May 23, 2007) from AU Patent Application No. 2003226093.
AU Office Action dated May 30, 2007 from AU Patent Application No. 2003226022.
Australian Office Action dated Oct. 4, 2007 from related Australian Application No. 2003245492.
Brocade Communication Systems, Inc. (2002-2003), "Optimizing the performance and management of 2Gbit/sec SAN fabrics with ISL trunking," White Paper (webprint).
Brocade Communication Systems, Inc. (Jun. 2001), "Increasing Intelligence with the SAN Fabric," White Paper (webprint), XP002251362.
CA Office Action 2,487,071, dated Jun. 15, 2006.
CA Third Office Action dated Apr. 30, 2010 for Canadian Application No. 2,521,463.
Canadian Office Action dated Aug. 13, 2008 from related CA Application No. 2,472,056, 2 pgs.
Canadian Office Action mailed Jun. 17, 2009 in Application No. 2,472,056.
China Office Action dated Jun. 22, 2007 from related China Application No. 03813264.8.
China Office Action dated Mar. 7, 2008 from related China Application No. 03807560.1.
China Office Action issued Dec. 1, 2006 from related China Application No. 02828262.0.
Chinese Office Action, Chinese Patent Application No. 03807600.4, Issued May 8, 2009.
Cisco Systems, "Cisco MDS 9000 Family of Multilayer Directors and Fabric Switches", 1992-2003 Cisco Systems, Inc., pp. 1-4.
Cisco Systems, "Cisco SAN-OS", 1992-2003 Cisco Systems, Inc. pp. 1-7.
Cisco Systems, Inc. (1992-2004), "Cisco SAN-OS Reference Guide," pp. 1-13.
Claudio DeSanti, "Extended-Headers", VF N-Port Model, T11/04-627v1, Oct. 2004, 1 page.
Claudio DeSanti, "Virtual Fabrics N-Port Support", VF N-Port Support, T11/04-494v2, Oct. 2004, 14 pages.
Claudio DeSanti, "Virtual Fabrics N-Port Support", VF N-Support, T11/04-49v0, Jul. 2004, 13 pages.
Claudio DeSanti, "Virtual Fabrics Switch Support," VF Switch Support, T11/04-395v3, Oct. 2004, 15 pages.
Claudio DeSanti, "Virtual Fabrics", T11/03-220v0, PowerPoint presentation, Apr. 2003, 11 pages.
CN Office Action (Sep. 8, 2006) from CN Patent Application No. 03807600.4.
CN Office Action 200480010826.0, dated Oct. 19, 2007.
CN Office Action 200580034140.X dated Jun. 6, 2008.
CN Third Office Action dated Nov. 20, 2009 for Application No. 200380104466.6.
Cometto et al., Allowed Claims for U.S. Appl. No. 10/170,855.
D1: Yasumori Takizawa, "Technology Scope IP Storage Disk Divided by IP Network Wide Area Ethernet Encouraging the Same," Nikkei Communication, Mar. 4, 200, No. 361, pp. 106-113.
D2: Glenn Sullivan, "Building of Long Distance SAN", UNIX Magazine, Apr. 1, 2000, vol. 15, No. 4, pp. 133-137.
D4: Fujita et al., "SSE98-225 QoS Control Using MPLS over ATM," Technical Report of IEICE, Mar. 19, 1999, vol. 98, No. 668, pp. 81-86.
Desai, Tushar et al., "Methods and Devices for Exchanging Peer Parameters Between Network Devices", U.S. Appl. No. 10/430,491, filed May 5, 2003, Publication No. US-2004-0100910-A1.
DeSanti et al., "Tagged Frame Specification," Tagged Frame Spec., T11/03-353v0, May 2003, 4 pages.
EP Office Action (Apr. 5, 2006) from EP Patent Application No. 03739 127.3-2416.
EP Office Action (Mar. 28, 2007) from EP Patent Application No. 03746053.2-2416.
EP Office Action Application No. 03789766.7, mailed Nov. 6, 2007.
EP Office Action dated Feb. 20, 2006 from related EP Application No. 02799279.1-1525.
EP Office Action dated Feb. 9, 2010 from related EP Application No. 03 746062.3-1249.
EP Office Action dated Jan. 18, 2005 from related EP Application No. 02799279.1-1525.
EP Office Action dated May 30, 2006 from related EP Application No. 02799279.1-1525.
EP Office Action dated Oct. 1, 2007 from related EP Application No. 03746053.2-2416.
EP Office Action dated Oct. 18, 2005 from related EP Application No. 02799279.1-1525.
EP Search Report (Feb. 10, 2006) from EP Patent Application No. 03746053.2-2416.
EP Search Report (May 19, 2005) from EP Patent Application No. 03746062.3-1249.
Examination Report dated Jul. 14, 2008 from Australian Patent Application No. 2003296301.
Fabric Shortest Path First (FSPF) Project 1508-D Switch Fabric-3 Rev. 6.5, (http://t11/org/index.htm webprint), pp. 117-140 (Oct. 31, 2003).
Gai, Silvano et al., "Methods and Apparatus for Encapsulating a Frame for Transmission in a Storage Area Network," U.S. Appl. No. 10/034,160, filed Dec. 26, 2001, Publication No. US-2003-0118053-A1.
Guan et al., Inter-fabric FC Architecture, May 30, 2003, Brocade-The Intelligent Platform for Network Storage.
IEEE Std 802.3-2002, Chapter 43.5 Marker Protocol, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, 2002, pp. 329-345.
Japanese Application No. 2003-559086, Office Action dated May 19, 2008.
Japanese Application No. 2003-582973, Office Action dated Dec. 22, 2008.
Japanese Application No. 2003-582973, Office Action dated Jun. 2, 2008.
Japanese Office Action issued on May 25, 2009 for Patent Application No. 2003-582964.
JP Office Action mailed Jul. 27, 2009 for Japanese Application No. 2003-582973, Office Action.
K. White, IBM Corp, RFC 2925, Sep. 2000.
Kiiskilä, Marko, "Implementation of LAN Emulation of ATM in Linux," Tampereen Teknillinen Korkeakoulu, Oct. 1996, 57 pages.
Lee et al. (4/12002), "Label Switching in Fibre Channel Networks," U.S. Appl. No. 10/114,394.
Listanti et al., "Architectural and Technological Issues for Future Optical Internet Networks", IEEE Communication Magazine, Sep. 2000.
M. Rajagopal, R. et al., "Fibre Channel Over TCP/IP" DRAFT-IETF-IPS-FCOVERTCPIP-06.TXT, Mar. 1, 2002, pp. 1-46, XP015021184.
Mearian et al., "What's After Fibre Channel?", Computerworld, Online!, Oct. 15, 2001, XP002246206.
Mills (Jul. 1988), "Network Working Group Request for Comments 1059, Network Time Protocol (Version 1) Specification and Implementation," University of Delaware, pp. 1-50.
Molero et al. (Dec. 7-9, 2000), "On the effect of link failure in fibre channel sotrage area networks," Parallel Architectures, Algorithms and Networks 2000, I-Span 2000 Proceedings, Int'l Symposium.
Monia (Dec. 12, 2000), "iFCP- A Protocol for Internet Fibre Channel Storage Networking" Nishan Systems (webprint), P002246205.
Monia et al., "iFCP-A Protocol for Internet Fibre Channel Storage Networking" Feb. 2002.
Monia, et al., "iFCP - A Protocol for Internet Fibre Channel Storage", DRAFT-MONIA-IPS-IFCP-01.txt, Jan. 1, 2001, pp. 1-48, XP01502633.
NCITS (Feb. 19, 2003), "Fibre Channel Switch Fabric-3 (FC-SW-3)," working draft (XP002300830 (A,B,C)).
NCITS (Jun. 26, 2001), "Fibre Channel Switch Fabric-2 (FC-SW-2)." working draft.
NCITS (Nov. 28, 2000), "Fibre Channel Generic Services-3 (FC-GS-3)," working draft.
Non-Final Office Action for U.S. Appl. No. 11/027,252 mailed Oct. 29, 2007.
Notice of Allowance dated Jun. 25, 2009 from U.S. Appl. No. 10/114,394.
Notice of Allowance dated Jun. 26, 2009 from U.S. Appl. No. 11/027,252.
Notice of Allowance dated May 29, 2009 from U.S. Appl. No. 10/034,160.
Notice of Allowance dated Sep. 20, 2010, from related U.S. Appl. No. 12/343,843.
Notice of Allowance for U.S. Appl. No. 10/430,491 dated Apr. 23, 2008.
Notice of Allowance for U.S. Appl. No. 10/430,491 dated Aug. 8, 2008.
Notice of Allowance issued Dec. 6, 2006 for U.S. Appl. No. 10/170,855.
Notification of Provisional Rejection issued on Apr. 15, 2009 for KR Patent Application No. 2004-7010143.
Office Action dated May 2, 2008 for Japanese Patent Application No. 2003-582964.
Office Action for AU Patent Application No. 20043000650, dated Sep. 26, 2008.
Office Action for CA Patent Application No. 2,521,463 dated Sep. 24, 2008.
Office Action for CN Patent Application No. 200480010826.0, dated Nov. 7, 2008.
Office Action issued on Aug. 13, 2008 for Canadian Patent Application No. 2,480,462.
Office Action issued on Dec. 26, 2008 for CN Patent Application No. 03807560.1.
Office Action issued on Jan. 30, 2008 for Canadian Patent Application No. 2,480,461.
Office Action issued on Jun. 22, 2007 for Chinese Patent Application No. 03813264.8.
Office Action issued on Sep. 5, 2008 for CN Patent Application No. 200380104466.6.
Office Action mailed for U.S. Appl. No. 10/114,394, Mar. 23, 2009.
PCT International Preliminary Report on Patentability dated Dec. 29, 2004 from related PCT/US05/044726.
PCT International Search Report, PCT/US02/41072, mailed May 23, 2003, 5 pages.
Rajagopal et al. (Jun. 30, 1999), "IP and ARP Over Fibre Channel," Request for Comments: 2625 (webprint), XP002246207.
Rangan (Sep. 4, 2001), "Re: FCIP/1FCP: Gurantee In-Order delivery for FC N/NL ports," IP Storage-Mailing List Archive (http://www.pdl.cmu/edu/mailinglists/ips/mail/msg03069.html webprint).
Rosen et al. (Jan. 2001), "Multiprotocol Label Switching Architecture," Network Working Group, RFC 3031, XP002251364.
Second Office Action issued on Apr. 24, 2009 for Chinese Patent Application No. 200380104466.6.
Second Office Action issued on Apr. 28, 2009 for Canadian Patent Application No. 2,472,056.
Supplemental Notice of Allowance for U.S. Appl. No. 10/430,491 dated Aug. 26, 2008.
U.S Office Action mailed Aug. 18, 2009 in U.S. Appl. No. 12/202,004.
U.S. Allowed Claims (Apr. 21, 2009) from related U.S. Appl. No. 10/974,368.
U.S. Allowed Claims (Jun. 25, 2009) from related U.S. Appl. No. 10/114,394.
U.S. Allowed claims (Jun. 26, 2009) from related U.S. Appl. No. 11/027,252.
U.S. Appl. No. 10/114,394, Final Office Action mailed Aug. 21, 2008.
U.S. Appl. No. 10/114,568, Allowed claims.
U.S. Appl. No. 10/974,368, Notice of Allowance dated Apr. 21, 2009.
U.S. Appl. No. 10/974,368, Notice of Allowance dated Feb. 13, 2009.
U.S. Appl. No. 10/974,368, Office Action dated Sep. 12, 2008.
U.S. Appl. No. 11/027,252, Final Office Action mailed Aug. 7, 2008.
U.S. Appl. No. 11/027,252, Office Action mailed Dec. 12, 2008.
U.S. Appl. No. 12/343,843, filed Dec. 24, 2008.
U.S. Non-Final Office Action dated Oct. 1, 2010, from related U.S. Appl. No. 12/566,013.
U.S. Notice of Allowance issued Jul. 7, 2010 from related U.S. Appl. No. 11/713,341.
U.S. Notice of Allowance mailed Nov. 9, 2009 from related U.S. Appl. No. 11/027,252.
U.S. Office Action dated Apr. 28, 2010, from related U.S. Appl. No. 12/343,843.
U.S. Office Action dated Feb. 17, 2010 from related U.S. Appl. No. 12/202,004.
U.S. Office Action dated Feb. 23, 2007 from related U.S. Appl. No. 10/430,491.
U.S. Office Action dated Mar. 28, 2007 from related U.S. Appl. No. 10/791,143.
U.S. Office Action dated Nov. 19, 2008 from U.S. Appl. No. 10/034,160.
US Final Office Action for U.S. Appl. No. 10/034,160 mailed Jan. 29, 2008.
US Final Office Action for U.S. Appl. No. 10/430,491 mailed Aug. 9, 2007.
US Final Office Action for U.S. Appl. No. 10/609,442 mailed Sep. 5, 2007.
US Non-Final Office Action for U.S. Appl. No. 10/114,394 mailed Aug. 22, 2007.
US Non-Final Office Action for U.S. Appl. No. 10/114,394 mailed Feb. 6, 2008.
US Non-Final Office Action for U.S. Appl. No. 10/114,568 mailed Sep. 20, 2007.
US Non-Final Office Action for U.S. Appl. No. 10/609,442 mailed Mar. 28, 2007.
US Non-Final Office Action for U.S. Appl. No. 10/609,442 mailed Mar. 28, 2008.
US Non-Final Office Action for U.S. Appl. No. 10/974,368 mailed Sep. 10, 2007.
US Notice of Allowance for U.S. Appl. No. 10/114,568 mailed Mar. 26, 2008.
US Notice of Allowance for U.S. Appl. No. 10/430,491 mailed Nov. 23, 2007.
US Notice of Allowance for U.S. Appl. No. 10/974,368 mailed May 1, 2008.
US Office Action (Apr. 4, 2007) from U.S. Appl. No. 10/114,394.
US Office Action (Apr. 6, 2007) from U.S. Appl. No. 10/114,568.
US Office Action (Aug. 22, 2005) from U.S. Appl. No. 10/034,160.
US Office Action (Dec. 13, 2005) from U.S. Appl. No. 10/034,160.
US Office Action (Feb. 5, 2007) from U.S. Appl. No. 10/034,160.
US Office Action (Jul. 30, 2007) from U.S. Appl. No. 10/034,160.
US Office Action (May 22, 2006) from U.S. Appl. No. 10/114,568.
US Office Action (May 22, 2006) from U.S. Appl. No. 10/170,855.
US Office Action (May 31, 2006) from U.S. Appl. No. 10/034,160.
US Office Action (Oct. 17, 2006) from U.S. Appl. No. 10/114,394.
US Office Action (Oct. 23, 2006) from U.S. Appl. No. 10/114,568.
US Office Action (Sep. 26, 2006) from U.S. Appl. No. 10/034,160.
USPTO Notice of Allowance U.S. Appl. No. 10/609,442, mailed Sep. 26, 2008.
Valdevit (May 23, 2000), "Fabric Shortest Path First Version (FSPF) Rv. 0.2", Fabric Shortest Path (http://t11.org/index.htm webprint), XP002959525.
White Paper, Link Aggregation According to IEEE Standard 802.3ad, Oct. 10, 2002, v.1.10, pp. 1-21.
WO Search Report (Jul. 12, 2004) from International Patent Application No. PCT/US03/36452.
WO Search Report (Jul. 15, 2003) from International Patent Application No. PCT/US03/09442.
WO Search Report (Nov. 4, 2003) from International Patent Application No. PCT/US03/18765.
WO Search Report (Oct. 17, 2003) from International Patent Application No. PCT/US03/09328.
WO Search Report (Oct. 25, 2006) from International Patent Application No. PCT/US05/37763.
WO Search Report (Oct. 27, 2007) from International Patent Application No. PCT/US2004/020518.
WO Written Opinion (Oct. 25, 2006) from International Patent Application No. PCT/US05/37763.

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8462790B2 (en) * 2002-04-01 2013-06-11 Cisco Technology, Inc. Label switching in fibre channel networks
US9350653B2 (en) 2002-04-01 2016-05-24 Cisco Technology, Inc. Label switching in fibre channel networks
US20100008375A1 (en) * 2002-04-01 2010-01-14 Cisco Technology, Inc. Label switching in fibre channel networks
US8605624B2 (en) 2002-11-27 2013-12-10 Cisco Technology, Inc. Methods and devices for exchanging peer parameters between network devices
US8635375B2 (en) * 2010-04-14 2014-01-21 Brocade Communications Systems, Inc. Remote F—ports
US20110255533A1 (en) * 2010-04-14 2011-10-20 Brocade Communications Systems, Inc. Remote F_Ports
US8594080B2 (en) * 2010-10-29 2013-11-26 International Business Machines Corporation Multiple functionality in a virtual storage area network device
US20120110385A1 (en) * 2010-10-29 2012-05-03 International Business Machines Corporation Multiple functionality in a virtual storage area network device
US8972611B2 (en) 2011-08-11 2015-03-03 Cisco Technology, Inc. Multi-server consolidated input/output (IO) device
US9276815B2 (en) * 2013-12-27 2016-03-01 Dell Products L.P. N-node virtual link trunking (VLT) systems management plane
US9264347B2 (en) 2013-12-27 2016-02-16 Dell Products L.P. N-node virtual link trunking (VLT) systems control plane
US9264308B2 (en) 2013-12-27 2016-02-16 Dell Products L.P. N-node virtual link trunking (VLT) systems data plane
US20150188760A1 (en) * 2013-12-27 2015-07-02 Dell Products L.P. N-node virtual link trunking (vlt) systems management plane
US9288138B2 (en) 2013-12-27 2016-03-15 Dell Products L.P. N-node virtual link trunking (VLT) systems and methods
US9288105B2 (en) * 2013-12-27 2016-03-15 Dell Products L.P. N-node virtual link trunking (VLT) systems fault management
US20150188753A1 (en) * 2013-12-27 2015-07-02 Dell Products L.P. N-node virtual link trunking (vlt) systems fault management
US9379945B2 (en) 2013-12-27 2016-06-28 Dell Products L.P. N-node virtual link trunking (Vlt) supporting arbitrary topologies
US9584397B2 (en) 2013-12-27 2017-02-28 Dell Products L.P. Routing in spine-leaf networking systems
US9614727B2 (en) * 2013-12-27 2017-04-04 Dell Products L.P. N-node systems and methods for link aggregation groups (LAG)
US9628375B2 (en) 2013-12-27 2017-04-18 Dell Products Lp N-node link aggregation group (LAG) systems that can support various topologies

Also Published As

Publication number Publication date
US20110141906A1 (en) 2011-06-16
US8750094B2 (en) 2014-06-10
US20060092932A1 (en) 2006-05-04

Similar Documents

Publication Publication Date Title
US8750094B2 (en) Trunking for fabric ports in Fibre channel switches and attached devices
US8605624B2 (en) Methods and devices for exchanging peer parameters between network devices
US8862799B2 (en) Technique for implementing virtual fabric membership assignments for devices in a storage area network
US8108454B2 (en) Address assignment in Fibre Channel over Ethernet environments
US7599397B2 (en) Obtaining multiple port addresses by a fibre channel switch from a network fabric
US7729288B1 (en) Zone management in a multi-module fibre channel switch
US7640364B2 (en) Port aggregation for network connections that are offloaded to network interface devices
JP4515441B2 (en) Single logical network interface for improved load balancing and failover capabilities
US7948920B2 (en) Trunking with port aggregation for fabric ports in a fibre channel fabric and attached devices
US9660864B2 (en) Staged port initiation of inter switch links
US8625623B2 (en) Method and system to allocate exchange identifications for fibre channel N—PORT aggregation
US7953866B2 (en) Protocols for connecting intelligent service modules in a storage area network
US8140657B2 (en) Method and system to connect multiple SCSI initiators to a fibre channel fabric topology using a single N-PORT
US10341256B2 (en) Exchange switch protocol version in a distributed switch environment

Legal Events

Date Code Title Description
AS Assignment

Owner name: CISCO TECHNOLOGY, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GHOSH, KALYAN K.;JAIN, PRAVEEN;GUPTA, SHASHANK;AND OTHERS;REEL/FRAME:015956/0406

Effective date: 20041025

STCF Information on status: patent grant

Free format text: PATENTED CASE

FPAY Fee payment

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 12TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1553); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 12