This chapter is from the book
This chapter is from the book
This chapter is from the book
FCP
This section provides a brief introduction to FCP.
FCP Functional Overview
As indicated in Chapter 2, "The OSI Reference Model Versus Other Network Models," FCP is a SCSI Transport Protocol. FCP was produced by ANSI T10 to facilitate block-level initiator-target communication over FC networks. FCP development began in 1991, and the first standard was published in 1996. In the FC network model, FCP is an FC-4 protocol. FCP uses the existing frame formats and services defined by the FC specifications, so no special modifications to FC are required by FCP. In theory, this allows FCP to share an FC network with other ULPs, but the vast majority of FC networks are deployed exclusively for FCP. FCP works with the existing SCSI architecture, so no special modifications to SCSI are required for FCP adoption. This ensures compatibility with a broad portfolio of host operating systems and applications.
Like the IP network model, the FC network model provides a robust set of network services to "application" protocols (that is, FC-4 protocols). FCP leverages the network services defined by the FC specifications. This simplifies FCP implementation for product vendors by reducing development overhead. Note that even OSI Session Layer login procedures are defined by the FC specifications (not the FCP specifications). This contrasts with the IP network model, in which each "application" protocol specifies its own OSI session layer login procedures. That said, FC-4 protocols are not required to use the services defined by the FC specifications.
There is a general perception that FC networks are inherently secure because they are physically separate (cabled independently) from the Internet and corporate intranets. This tenet is erroneous, but the FC user community is not likely to realize their error until FC security breaches become commonplace. For example, the vast majority of hosts that are attached to an FC-SAN are also attached to an IP network. If a host is compromised via the IP network, the host becomes a springboard for the intruder to access the FC-SAN. Moreover, FC-SANs are commonly extended across IP networks for disaster recovery applications. Such SAN extensions expose FC-SANs to a wide variety of attacks commonly perpetrated on IP networks. Authentication and encryption mechanisms are defined in the FC specifications, so FCP does not define its own security mechanisms. Unlike iSCSI, no security mechanisms are mandatory for FCP deployment. This fact and the misperception about the nature of FC network security have resulted in the vast majority of FC-SANs being deployed without any authentication or encryption.
Because FCP can be transported only by FC, the adoption rate of FCP is bound to the adoption rate of FC. The adoption rate of FC was relatively low in the late 1990s, in part because of the comparatively high cost of FC infrastructure components, which relegated FCP to high-end servers hosting mission-critical applications. Around 2000, FC adoption reached critical mass in the high-end server market. Simultaneously, performance improvements were being realized as companies began to view switched FC networks as the best practice instead of Fibre Channel Arbitrated Loop (FC-AL). In the years following, the adoption rate of switched FC increased dramatically. Consequently, FC prices began to drop and still are dropping as the FC market expands and competition increases. Furthermore, in response to competition from iSCSI, some FC HBA vendors have recently introduced "light" versions of their HBAs that provide less functionality at a lower cost than traditional FC HBAs. FCP is now being used by mid-range and high-end servers hosting a wide variety of business applications.
In the traditional FC-SAN design, each host and storage device is dual-attached to the network. (As previously noted, there are some exceptions to this guideline.) This is primarily motivated by a desire to achieve 99.999 percent availability. Conventional wisdom suggests that the network should be built with redundant switches that are not interconnected to achieve 99.999 percent availability. In other words, the network is actually two separate networks (commonly called path A and path B), and each end node (host or storage) is connected to both networks. Some companies take the same approach with their traditional IP/Ethernet networks, but most do not for reasons of cost. Because the traditional FC-SAN design doubles the cost of network implementation, many companies are actively seeking alternatives. Some companies are looking to iSCSI as the answer, and others are considering single path FC-SANs. Figures 3-12 and 3-13 illustrate typical dual path FC-SAN designs.
FC switches are market-classified as director class or fabric class. A director-class FC switch has no single point of failure in its architecture and provides 99.999 percent availability. Director-class FC switches also tend to have very high port density. By contrast, a fabric-class FC switch is similar to a traditional Ethernet switch in that it does not provide 99.999 percent availability. Fabric-class FC switches also tend to have limited port density. Some FC switch vendors employ completely different architectures in their director-class products versus their fabric-class products. This can result in functional disparity. In large-scale deployments, port density requirements often dictate the use of director-class FC switches. However, smaller environments can supplant the use of dual fabric-class FC switches with the use of a single director-class FC switch. This approach appeals to some companies because it fully protects the switch investment as the company grows, and it allows the company to take advantage of director-class functionality that might be missing from the fabric-class switches. However, availability can suffer if the director-class FC switch is physically damaged, or if a software bug in the switch's operating system causes an unplanned outage. Only dual path FC-SANs can protect against these risks.
A key difference between the FC and IP network models is support for routing protocols in the end nodes. Nearly all hosts attached to an IP network implement an IP routing protocol or static IP routing capability. If more than one router is attached to an Ethernet network, each host can decide which router to use when forwarding packets to non-local subnets. However, the forwarding decision is made at the network layer, not at the data-link layer. FC attached hosts do not implement a network layer protocol. Thus, an FC attached host merely forwards frames to the attached FC switch. This is equivalent to Ethernet frame processing in an IP attached host. Note that FC switches can perform load balancing, just as Ethernet switches and IP routers can. Chapter 10, "Routing and Switching Protocols," provides more detail about frame/packet forwarding mechanisms within networks. Chapter 11, "Load Balancing," provides more detail about load-balancing mechanisms within networks and hosts.
FCP Procedural Overview
When a host attached to an FC switch first comes online, it logs into the switch to exchange operating parameters and receive its FC address. Next, the host establishes an FC connection to the Fibre Channel Name Server (FCNS) and discovers FCP targets as discussed in Chapter 3, "An Overview of Network Operating Principles." The host then establishes an FC connection to each discovered FC device that contains a target. An FCP session is then established with each target. LUN discovery follows.
Each SCSI command is mapped to an FCP I/O operation. Each FCP I/O operation is identified by its Fully Qualified Exchange Identifier (FQXID), which is composed of the initiator's FC address, the target's FC address, an FC Exchange Identifier assigned by the initiator, and an FC Exchange Identifier assigned by the target. An FC Exchange Identifier is integral to frame tracking within the SCSI Interconnect. All frames comprising SCSI commands, data, and status are tracked in flight via the FC Sequence ID (SEQ_ID) and Sequence Count (SEQ_CNT) mechanisms. Each SEQ_ID value identifies a single sequence of related frames within the context of an Exchange Identifier. Each SEQ_CNT value identifies a single frame within the context of a SEQ_ID. SEQ_ID values do not have to increase contiguously from one Exchange to the next. This contrasts with the iSCSI model.