Browse Prior Art Database

Scheme for Eliminating Ambiguities in Fibre Channel Port Names

IP.com Disclosure Number: IPCOM000132034D
Original Publication Date: 2005-Nov-29
Included in the Prior Art Database: 2005-Nov-29
Document File: 4 page(s) / 37K

Publishing Venue

IBM

Abstract

Enhancements to the process of N_Port ID assignment that prevent erroneous associations between N_Port IDs and WWPNs are described. The data integrity exposures, resource wasteage, and related problems that result from such erroneous associations between N_Port IDs and WWPNs prevented by this process are also summarized.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 32% of the total text.

Page 1 of 4

Scheme for Eliminating Ambiguities in Fibre Channel Port Names

Fibre Channel [1] allows multiple node ports (N_Ports) to intercommunicate. Each N_Port is assigned one or more N_Port Identifiers (N_Port IDs) according to a process described in [1]. One important reason for assigning multiple N_Port IDs to a single N_Port is when multiple independent logical partitions need to share the same physical N_Port. This allows each logical partition to be associated with its own N_Port ID and a corresponding worldwide-unique identifier. In order to obtain an N_Port ID, the physical N_Port first requests the Fabric to assign an N_Port ID by sending a Fabric Login (FLOGI) request to the Fabric.

The FLOGI request contains (among other information not important here) the worldwide-unique port identifier (WWPN) associated with the physical N_Port. Typically, this WWPN is "burned in" when the physical N_Port adapter is manufactured and cannot change. Since this WWPN is generated (and guaranteed to be unique) during a fully debugged manufacturing process, one can be reasonably certain that it is indeed unique and has not been generated incorrectly. When the Fabric receives this FLOGI request, it assigns an N_Port ID (provided there are necessary resources and an unassigned N_Port ID is available) by sending an ACCEPT response containing the assigned N_Port ID; otherwise it sends a REJECT response. After sending an ACCEPT response, the Fabric stores the WWPN and corresponding N_Port ID in a nameserver database. Storing the WWPN and corresponding N_Port ID in the nameserver database enables other devices attached to the fabric to determine the N_Port ID corresponding to a given WWPN and communicate with the device with the WWPN.

After the first N_Port ID is generated as described above, additional N_Port IDs may be requested and assigned to logical partitions that need to share the physical N_Port. These additional IDs are requested by sending a Fabric Discovery (FDISC) request. Just as the FLOGI request contained the WWPN associated with the physical N_Port adapter, the FDISC request contains the WWPN associated with the logical partition for which the additional N_Port ID is being requested. As opposed to the WWPN associated with the physical adapter (which is typically generated during manufacture), the WWPNs associated with each additional N_Port ID are generated either by control software associated with the physical N_Port or, in some cases, even by the logical partition itself. When the Fabric receives this FDISC request, it assigns an additional N_Port ID (provided there are necessary resources and an unassigned N_Port ID is available) in a similar manner as it assigned the first N_Port ID, That is, it either sends an ACCEPT response containing the assigned N_Port ID or it sends a REJECT response. Just as for the first assigned N_Port ID, the Fabric stores the WWPN and corresponding to the next N_Port ID in a nameserver database. It is impo...