1. Field of the Invention
This invention generally relates to systems and methods for providing network communications between computers or computer system components. More specifically, this invention relates to increasing the scalability of Fibre Channel networks through the use an extended registered state change notification (RSCN) packet payload.
2. Background of the Invention
Networking of high-performance computers has become the focus of much attention in the data communications industry. Performance improvements in processors and peripherals, along with the move to distributed architectures such as client/server configurations, have spawned increasingly data-intensive and high-speed network applications, such as medical imaging, multimedia, and scientific visualization.
One protocol that has been developed to provide the necessary communications capacity is the Fibre Channel protocol. The Fibre Channel protocol defines standard media and signaling conventions for transporting data in a serial fashion. It also provides an error correcting channel code and a frame structure for transporting the data. Further, the Fibre Channel protocol sets out a buffer-credit-based flow control methodology, and creates some common services (e.g., fabric controller, name server). The Fibre Channel protocol can be applied to various network topologies including point-to-point, ring, and switched fabric. Further details regarding the Fibre Channel protocol can be found online at www.fibrechannel.org.
Fibre Channel networks can grow quite large. The protocol theoretically allows for nearly 224 (over 16 million) node ports within a single fabric (a Fibre Channel network includes one or more Fibre Channel fabrics). Each node port supports one Fibre Channel device. As larger networks are implemented (e.g., more than about eight switches), various unforeseen weaknesses in the Fibre Channel protocol become evident. For example, the amount of network traffic necessary to support and use the name server grows as the square of the number of devices attached to the fabric, and this traffic can at times severely impair the performance of the network. It would be desirable to eliminate or mitigate the adverse effects of this traffic, thereby improving the speed, efficiency, and reliability of larger networks.
The problems outlined above are in large measure addressed by a Fibre Channel (Fibre Channel) fabric having switches that employ Registered State Change Notifications (RSCNs) with enhanced payloads. Two types of RSCN message formats are provided, both including status information about the affected device(s). In one embodiment, a RSCN message format for inter-switch communication provides various information about the affected devices according to one of a plurality of predetermined formats. In another embodiment, a node device RSCN message format provides information about a port state, the identification of the affected port, along with the port and node world wide names and the FC-4 types supported by the node.
While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
Turning now to the figures,
Although not shown in
In addition to providing basic connectivity between Fibre Channel node devices, the switches preferably provide additional Fibre Channel fabric services such as fabric controller, directory server (also known as a “name server”), time server, management server, quality of service facilitator, and alias server. These services may be localized to an individual switch, or they may be distributed among the switches.
Each of the node devices typically determines the properties of the other node devices with which it communicates. After connecting to the network, which is done with a fabric login (FLOGI) command, the node devices send a request addressed to the name server, which is then received by the resident name server on the entry switch. Typically, where such request forms are supported, the request takes the form of GE_PT (get entries of a given Port Type) or GE_FT (get entries of a given FC-4 Type). Where such forms are not supported, the request may take the form of GID_PT (get identifiers for ports of a given Port Type) or GID_FT (get identifiers for ports of a given FC-4 Type). Once the identifiers have been obtained, a series of GE_ID (get entry for a given identifier) requests may be used to obtain the corresponding entries. In either case, the effect is to cause the entry switch to request each of the other switches to send all name server database entries that satisfy the given criteria to the entry switch, which then forwards the entries to the requesting device. The requesting device then uses the returned information to log in to the port with which it needs to connect (using the PLOGI command) and initiates communication (using the PRLI command).
The requests to the name server can generate increasing amounts of traffic as the size of the network increases. The number of entries is generally proportional to the number of node devices, and each device will typically generate such a sequence of requests when it connects to the network, so the amount of traffic increases as the square of the number of node devices. The situation is exacerbated when one considers that node devices are not static. Their status or properties may change, e.g., when disconnected or reprogrammed. The frequency of change is generally proportional to the number of node devices. Each time a node device experiences an event that affects their name server entry, a Registered State Change Notification (RSCN) message is sent to all the node devices in the same zone (or, at least, those node devices in the same zone that have registered to receive such messages). Each of those node devices typically responds immediately with a GE_ID request, forcing the entry switch of the affected device to contend with a sudden influx of name server traffic.
Note that RSCN messages are classified into two types: inter-switch RSCN messages, and node device RSCN messages. RSCN messages exchanged between switches are given an inter-switch format, but this format is different from the node device format used by (and expected by) node devices. Both formats are discussed herein. New formats for each type of RSCN message are described in greater detail below. Not all switches or devices may support the new format, but it is generally possible for one device to determine the capabilities of the other devices with which it communicates. For example, the one switch may query other switches to determine their manufacturer and firmware version. Switches having a particular manufacturer and revision number may be presumed to support the new format. If for some reason it is not possible to determine the capability of another device, the devices communicating therewith can default to previous RSCN formats when communicating with that switch.
Referring to
The second nibble of the high order byte is used to indicate the address format used to identify the affected port. A value of 0×0 indicates that the address is in the port address format. A value of 0×1 indicates that the address is in area address format. A value of 0×2 indicates that the address is in domain address format. Finally, a value of 0×3 indicates that the address is in fabric address format. The remaining three bytes of the Affected N_Port field contain the 24-bit address in the format specified.
The next four bytes of the standard RSCN payload identify the “detection function,” which is the element that detected the change triggering the RSCN. A value of 0×00000001 indicates that the change was detected by the fabric, while a value of 0×00000002 indicates that the change was detected by an N_Port. The next four bytes of the RSCN payload indicate the number of device entries in the payload. For each of these device entries, there is a 20-bit device entry, which constitutes the remaining payload.
The 20-bit device entry data defined in the standard RSCN message format is somewhat limited. As indicated in
An inter-switch RSCN message payload according to the present invention to alleviate the problem of increased network traffic and increased switch workload is illustrated in
Format 00 is the large name server entry object. In this format, the device data field is a maximum of 624 bytes in length and includes the fields indicated with a “yes” in the third column of the chart in
With reference to
In the current payload, there is no indication of the device being online or offline, which requires the HBA to query back to the name server to ascertain the status of the affected device. Also, many HBAs are interested in the commonly used device data, such as port WWN, node WWN, and FC-4 types. Again, an HBA has to query the name server in response to the RSCN to determine this information. Typically, when an HBA receives a RSCN, it makes a name server query GID_FT first to get the fabric device port IDs given a specified FC-4 type. Then, for each device port ID, the HBA makes a name server query GPN_ID or GNN_ID to get the device WWN individually. Afterwards, the HBA sends a PLOGI to the targets to start IO traffic. According to the present invention, all of the above name server queries can be avoided if the required information is put in the RSCN payload, and if the host can interpret the RSCN intelligently.
This is accomplished by the preferred RSCN payload format illustrated in
The port state byte indicates the device's online or offline status. The state byte may be the same as for an inter-switch RSCN, and thus ‘0×’ indicates that no additional information on the state is available, ‘1×’ indicates that the port is online, ‘2×’ indicates that the port is offline. A device could support multiple FC-4 types, so all of the supported FC-4 types are listed in the payload. Each FC-4 type is an 8-bit encoded FC-PH value.
Because this RSCN format relies on the acceptance on the host side, the host can notify the switch about which type of RSCN it can support through a State Change Registration (SCR) frame. A prior art SCR payload is illustrated in
The preferred RSCN messages may take the physical form of modulated carrier signals traveling over fabric links. The carrier signals may be modulated into a sequential series of signal frames, each having a start of frame segment, a frame header, a content segment, and an end of frame segment. The field formats shown in the figures would describe the arrangement of information in the content segment following the frame header. The appropriate signaling protocols can be found in the Fibre Channel Framing and Signaling Draft Standard Rev. 1.70, FC-FS, published Feb. 8, 2002, and the Fibre Channel Physical and Signaling Interface, Rev. 4.3, FC-PH, published Jun. 4, 1994, both of which are incorporated herein by reference.
By providing additional information in the RSCN message, as described herein, it is possible to significantly reduce the amount of network traffic caused by state changes in one or more devices. By eliminating the need for each device receiving an RSCN message to query the name server to determine required details about the state change, the number of devices that may be connected to a fabric is effectively increased. Numerous variations and modifications of the techniques described herein will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
This application is related to and claims priority from U.S. Provisional Patent Application Ser. No. 60/502,367, filed Sep. 12, 2003, entitled “New RSCN Format,” which is hereby incorporated by reference. This application is also related to U.S. patent application Ser. No. 10/208,375, filed Jul. 30, 2002, entitled “Fibre Channel Network Employing Registered State Change Notifications with Enhanced Payload,” which is hereby incorporated by reference.
Number | Date | Country | |
---|---|---|---|
60502367 | Sep 2003 | US |