IPS Working Group M. Rajagopal, R. Bhagwat, R. A. Helland, INTERNET-DRAFT LightSand Comm. E. Rodriguez, Lucent Tech. (Expires May, 2002) C. Carlson, QLogic Category: standards-track D. Fraser, Compaq D. Peterson, Cisco L. Lamers, SAN Valley V. Chau, G. Hecht, Gadzoox Networks S. Wilson, B. Snively, R. Weber, Brocade Comm. M. O'Donnell, A. Rijhsinghani, McDATA S. Rupanagunta, Aarohi Comm. V. Rangan, Rhapsody Networks J. Nelson, K. Hirata, Vixel M. Merhar, Pirus Networks N. Wanamaker, Akara Fibre Channel Over TCP/IP (FCIP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as Reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Fibre Channel Over TCP/IP (FCIP) describes mechanisms that allow the interconnection of islands of Fibre Channel storage area networks over IP-based networks to form a unified storage area network in a single Fibre Channel fabric. FCIP relies on IP-based network services to provide the connectivity between the storage area network islands over local area networks, metropolitan area networks, or wide area networks. Rajagopal, et al. Standards Track [Page 1] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Table Of Contents 1. Purpose, Motivation and Objectives . . . . . . . . . . . . . . . 3 2. Relationship to Fibre Channel Standards . . . . . . . . . . . . 4 2.1 Relevant Fibre Channel Standards . . . . . . . . . . . . . . . 4 2.2 This Specification and Fibre Channel Standards . . . . . . . . 5 3. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Summary . . . . . . . . . . . . . . . . . . . . . . . . 7 5. The FCIP Model . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1 FCIP Protocol Model . . . . . . . . . . . . . . . . . . . . . . 9 5.2 FCIP Link . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3 FC Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4 FCIP Entity . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.5 FCIP Link Endpoint (FCIP_LEP) . . . . . . . . . . . . . . . . 12 5.6 FCIP Data Engine (FCIP_DE) . . . . . . . . . . . . . . . . . . 13 5.6.1 FCIP Encapsulation of FC Frames . . . . . . . . . . . . . . 15 5.6.2 FCIP Data Engine Error Detection and Recover . . . . . . . . 18 5.6.2.1 TCP Assistance With Error Detection and Recovery . . . . . 18 5.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames . . . . 18 5.6.2.3 Synchronization Failures . . . . . . . . . . . . . . . . . 20 6. Checking FC Frame Transit Times in the IP Network . . . . . . . 20 7. The FCIP Short Frame . . . . . . . . . . . . . . . . . . . . . 21 8. TCP Connection Management . . . . . . . . . . . . . . . . . . . 24 8.1 TCP Connection Establishment . . . . . . . . . . . . . . . . . 24 8.1.1 Connection Establishment Model . . . . . . . . . . . . . . . 24 8.1.2 Connection Setup Following a Successful TCP Connect Request 25 8.1.3 Non-Dynamic Creation of New TCP Connections . . . . . . . . 26 8.1.4 Dynamic Creation of New TCP Connections . . . . . . . . . . 27 8.1.5 Processing Incoming TCP Connect Requests . . . . . . . . . . 28 8.2 Merging FCIP_LEPs . . . . . . . . . . . . . . . . . . . . . . 30 8.3 Closing TCP Connections . . . . . . . . . . . . . . . . . . . 30 8.4 TCP Connection Parameters . . . . . . . . . . . . . . . . . . 31 8.4.1 TCP Selective Acknowledgement Option . . . . . . . . . . . . 31 8.4.2 TCP Window Scale Option . . . . . . . . . . . . . . . . . . 31 8.4.3 Protection against sequence number wrap . . . . . . . . . . 31 8.4.4 TCP_NODELAY Option . . . . . . . . . . . . . . . . . . . . . 31 8.5 TCP Connection Considerations . . . . . . . . . . . . . . . . 31 8.6 Flow Control Mapping between TCP and FC . . . . . . . . . . . 32 9. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1 Threat Models . . . . . . . . . . . . . . . . . . . . . . . . 32 9.2 FC Fabric and IP Network Deployment Models . . . . . . . . . . 33 9.3 FCIP Security Components . . . . . . . . . . . . . . . . . . . 34 Rajagopal, et al. Standards Track [Page 2] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 9.3.1 IPSec ESP Authentication and Confidentiality . . . . . . . . 34 9.3.2 Key Management . . . . . . . . . . . . . . . . . . . . . . . 35 9.3.3 ESP Replay Protection and Rekeying issues . . . . . . . . . 36 9.4 Secure FCIP Link Operation . . . . . . . . . . . . . . . . . . 36 9.4.1 FCIP Link Initialization Steps . . . . . . . . . . . . . . . 36 9.4.2 TCP Connection Security Associations (SAs) . . . . . . . . . 37 9.4.3 Handling data integrity and confidentiality violations . . . 37 9.4.4 Handling SA parameter mismatches . . . . . . . . . . . . . . 37 10. Performance . . . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 Performance Considerations . . . . . . . . . . . . . . . . . 37 10.2 IP Quality of Service (QoS) Support . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 12. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 42 15. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 44 Annex A Example of synchronization recovery algorithm . . . . . . . . . 44 B Relationship between FCIP and IP over FC (IPFC) . . . . . . . . 49 C FC Frame Format . . . . . . . . . . . . . . . . . . . . . . . . 49 D FC Encapsulation Format . . . . . . . . . . . . . . . . . . . . 51 E FCIP Requirements on an FC Entity . . . . . . . . . . . . . . . 53 1. Purpose, Motivation and Objectives Fibre Channel (FC) is a gigabit speed networking technology primarily used to implement Storage Area Networks (SANs). See section 2 for information about how Fibre Channel is standardized and the relationship of this specification to Fibre Channel standards. This specification describes mechanisms that allow the interconnection of islands of Fibre Channel SANs over IP Networks to form a unified SAN in a single Fibre Channel fabric. The motivation behind defining these interconnection mechanisms is a desire to connect physically remote FC sites allowing remote disk access, tape backup, and live mirroring. Fibre Channel standards have chosen nominal distances between switch elements that are less than the distances available in an IP Network. Since Fibre Channel and IP Networking technologies are compatible, it is logical to turn to IP Networking for extending the allowable distances between Fibre Channel switch elements. The fundamental assumption made in this specification is that the Fibre Channel traffic is carried over the IP Network in such a manner that the Fibre Channel Fabric and all Fibre Channel devices on the Fabric are unaware of the presence of the IP Network. This Rajagopal, et al. Standards Track [Page 3] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 means that the FC datagrams must be delivered in such time as to comply with existing Fibre Channel specifications. The FC traffic may span LANs, MANs and WANs, so long as this fundamental assumption is adhered to. The objectives of this document are to: 1) specify the encapsulation and mapping of Fibre Channel (FC) frames employing FC Frame Encapsulation [25]. 2) apply the mechanism described in 1) to an FC Fabric using an IP network as an interconnect for two or more islands in an FC Fabric. 3) address any FC concerns arising from tunneling FC traffic over an IP-based network, including security, data integrity (loss), congestion, and performance. This will be accomplished by utilizing the existing IETF-specified suite of protocols. 4) be compatible with the referenced FC standards. While new work may be undertaken in T11 [7] to optimize and enhance FC Fabrics, this specification REQUIRES conformance only to the referenced FC standards. 5) be compatible with all applicable IETF standards so that the IP Network used to extend an FC Fabric can be used concurrently for other reasonable purposes. 2. Relationship to Fibre Channel Standards 2.1 Relevant Fibre Channel Standards FC is standardized under American National Standard for Information Systems of the National Committee for Information Technology Standards (ANSI-NCITS) in its T11 technical committee. T11 has specified a number of documents describing FC protocols, operations, and services. T11 documents of interest to readers of this specification include (but are not limited to): - FC-BB - Fibre Channel Backbone [3] - FC-BB-2 - Fibre Channel Backbone -2 [4] - FC-SW-2 - Fibre Channel Switch Fabric -2 [5] - FC-FS - Fibre Channel Framing and Signaling [6] FC-BB and FC-BB-2 describe the relationship between an FC Fabric and interconnect technologies not defined in by Fibre Channel standards (e.g., ATM and SONET). FC-BB-2 is the natural Fibre Channel home for describing relationships to TCP/IP and FCIP. Rajagopal, et al. Standards Track [Page 4] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 FC-SW-2 describes the switch components of an FC Fabric and FC-FS describes the FC Frame format and basic control features of Fibre Channel. Additional information regarding T11 activities is available on the committee's web site [7]. 2.2 This Specification and Fibre Channel Standards When considering the challenge of transporting FC Frames over an IP Network, it is logical to divide the standardization effort between TCP/IP requirements and Fibre Channel requirements. This specification covers the TCP/IP requirements for transporting FC Frames and the Fibre Channel documents described in section 2.1 cover the Fibre Channel requirements. This specification addresses only the requirements necessary to properly utilize an IP Network as a conduit for FC Frames. The result is a specification for an FCIP Entity (see section 5.4). A product that tunnels an FC Fabric through an IP Network MUST combine the FCIP Entity with an FC Entity (see section 5.3) using an implementation specific interface. The requirements placed on an FC Entity by this specification to achieve proper delivery of FC Frames are summarized in annex E. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [4]. No attempt is being made to define a specific API between an FCIP Entity and an FC Entity at this time because doing so risks compromising the performance and efficacy of the resulting products. Current experience in this area is simply insufficient to guide definition of the interface appropriately. The objectives and motivations of this specification are not impacted by the decision not to standardize a specific API between FCIP Entities and FC Entities because fully functional and compliant products can be built provided they contain both an FCIP Entity and an FC Entity. The only products that cannot be built are those that contain only one or the other. Rajagopal, et al. Standards Track [Page 5] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 3. Terminology Terms needed to clarify the concepts presented in FCIP are defined here. FC End Node - A FC device that uses the connection services provided by the FC Fabric. FC Entity - The Fibre Channel specific element that combines with an FCIP Entity to form an interface between an FC Fabric and an IP Network (see section 5.3). FC Fabric - An entity that interconnects various Nx_Ports (see [6]) attached to it, and is capable of routing FC Frames using only the destination ID information in a FC Frame header (see annex C). FC Frame - The basic unit of Fibre Channel data transfer (see annex C). FC Receiver Portal - The access point through which an FC Frame and time stamp enters an FCIP Data Engine from the FC Entity. FC Transmitter Portal - The access point through which a reconstituted FC Frame and time stamp leaves an FCIP Data Engine to the FC Entity. FCIP Data Engine (FCIP_DE) - The component of an FCIP Entity that handles FC Frame encapsulation, de-encapsulation, and transmission FCIP Frames through a single TCP Connection (see section 5.6). FCIP Entity - The principal FCIP interface point to the IP Network (see section 5.4). FCIP Frame - An FC Frame plus the FC Frame Encapsulation [25] header and encoded EOF that contains the FC Frame (see section 5.6.1). FCIP Link - One or more TCP Connections that connect one FCIP_LEP to another (see section 5.2). FCIP Link Endpoint (FCIP_LEP) - The component of an FCIP Entity that handles FC Frame encapsulation, de-encapsulation, and transmission through a single FCIP Link (see section 5.5). Encapsulated Frame Receiver Portal - The TCP access point through which an FCIP Frame is received from the IP Network by an FCIP Data Engine. Rajagopal, et al. Standards Track [Page 6] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Encapsulated Frame Transmitter Portal - The TCP access point through which an FCIP Frame is transmitted to the IP Network by an FCIP Data Engine. 4. Protocol Summary The FCIP protocol is summarized as follows: 1) The primary function of an FCIP Entity is forwarding FC Frames, employing FC Frame Encapsulation described in [25]. 2) Viewed from the IP Network perspective, FCIP Entities are peers and communicate using TCP/IP. Each FCIP Entity is a TCP endpoint in the IP-based network. 3) Viewed from the FC Fabric perspective, pairs of FCIP Entities, in combination with their associated FC Entities, serve as an FC Frame transmission component of the FC Fabric. The FC End Nodes are unaware of the existence of the FCIP Link. 4) FC Primitive Signals, Primitive Sequences, and Class 1 FC Frames are not transmitted across an FCIP Link because they cannot be encoded using FC Frame Encapsulation [25]. 5) The path (route) taken by an encapsulated FC Frame follows the normal routing procedures of the IP Network. 6) At any instant in time, an FCIP Entity SHALL NOT have more than one IP Address. 7) An FCIP Entity MAY contain multiple FCIP Link Endpoints, but each FCIP Link Endpoint (FCIP_LEP) communicates with exactly one other FCIP_LEP. 8) When multiple FCIP_LEPs with multiple FCIP_DEs are in use, selection of which FCIP_DE to use for encapsulating and transmitting a given FC Frame is outside the scope of this document. FCIP Entities do not actively participate in FC Frame routing. 9) The FCIP Control & Services function MAY use TCP/IP quality of service features (see section 10.2) to support Fibre Channel capabilities. 10) Each FCIP Entity is statically or dynamically configured with a list of IP addresses and port numbers corresponding to participating FCIP Entities. If dynamic discovery of participating FCIP Entities is supported, the function SHALL be Rajagopal, et al. Standards Track [Page 7] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 performed using the Service Location Protocol (SLPv2) [23]. It is outside the scope of this specification to describe any static configuration method for participating FCIP Entity discovery. Refer to section 8.1.4 for a detailed description of dynamic discovery of participating FCIP Entities using SLPv2. 11) FCIP Entities do not actively participate in the discovery of FC source and destination identifiers. Discovery of FC addresses (accessible via the FCIP Entity) is provided by techniques and protocols within the FC architecture as described in FC-FS [6] and FC-SW-2 [5]. 12) To support IP Network security (see section 9), FCIP Entities MUST: 1) implement cryptographically protected authentication and cryptographic data integrity keyed to the authentication process, and 2) implement data confidentiality security features. 13) On a given TCP Connection, this specification relies on TCP/IP to deliver a byte stream in the same order that it was sent. 14) This specification relies on both TCP and FC error recovery mechanisms to detect and recover from data loss and corruption within the IP Network. Rajagopal, et al. Standards Track [Page 8] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 5. The FCIP Model 5.1 FCIP Protocol Model The relationship between FCIP and other protocols is illustrated in figure 1. +------------------------+ FCIP Link +------------------------+ | FCIP |===========| FCIP | +--------+------+--------+ +--------+------+--------+ | FC-2 | | TCP | | TCP | | FC-2 | +--------+ +--------+ +--------+ +--------+ | FC-1 | | IP | | IP | | FC-1 | +--------+ +--------+ +--------+ +--------+ | FC-0 | | LINK | | LINK | | FC-0 | +--------+ +--------+ +--------+ +--------+ | | PHY | | PHY | | | +--------+ +--------+ | | | | | | | IP Network | | V +--------------------+ V to Fibre to Fibre Channel Channel Environment Environment Fig. 1 FCIP Protocol Stack Model Note that the objective of the FCIP Protocol is creation and maintenance of one or more FCIP Links. 5.2 FCIP Link The FCIP Link is the basic unit of service provided by the FCIP Protocol to an FC Fabric. As shown in figure 2, an FCIP Link connects two portions of an FC Fabric using an IP Network as a transport to form a single FC Fabric. /\/\/\/\/\/\ /\/\/\/\/\/\ /\/\/\/\/\/\ \ FC / \ IP / \ FC / / Fabric \=========/ Network \=========/ Fabric \ \/\/\/\/\/\/ \/\/\/\/\/\/ \/\/\/\/\/\/ | | |<--------- FCIP Link -------->| Fig. 2 FCIP Link Model At the points where the ends of the FCIP Link meet portions of the FC Fabric, an FCIP Entity (see section 5.4) combines with an FC Rajagopal, et al. Standards Track [Page 9] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Entity as described in section 5.3 to serve as the interface between FC and IP. An FCIP Link SHALL contain at least one TCP Connection and MAY contain more than one TCP Connection. The endpoints of a single TCP Connection are FCIP Data Engines (see section 5.6). The endpoints of a single FCIP Link are FCIP Link Endpoints (see section 5.5). 5.3 FC Entity A product that tunnels an FC Fabric through an IP Network MUST combine an FC Entity with an FCIP Entity (see section 5.4) to form a complete interface between the FC Fabric and IP Network as shown in figure 3. |<--------- FCIP Link -------->| | | +----------+ /\/\/\/\/\/\ +----------+ | FCIP | \ IP / | FCIP | | Entity |=========/ Network \=========| Entity | +----------+ \/\/\/\/\/\/ +----------+ | FC | | FC | | Entity | | Entity | +----------+ +----------+ | | /\/\/\/\/\/\ /\/\/\/\/\/\ \ FC / \ FC / / Fabric \ / Fabric \ \/\/\/\/\/\/ \/\/\/\/\/\/ Fig. 3 FC Entity and FCIP Entity Model In general, the combination of an FCIP Link and FC and FCIP Entities is intended to replace a Fibre Channel defined connection between Fibre Channel components. For example, this combination can be used to replace a hard-wire connection between two Fibre Channel switches. There are limitations on the generally intended usage of the combination shown in figure 3. As another example, the combination cannot be used to replace cable connections in a Fibre Channel Arbitrated Loop because loop primitive signals cannot be encapsulated for transmission over TCP. The interface between the FC and FCIP Entities is implementation specific. The minimum requirements placed on an FC Entity by this specification are listed in annex E. More information about FC Entities can be found in the Fibre Channel standards and an example of an FC Entity can be found in FC-BB-2 [4]. Rajagopal, et al. Standards Track [Page 10] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 5.4 FCIP Entity The model for an FCIP Entity is shown in figure 4. ....................................................... : FCIP Entity : : : : +-----------+ : : | FCIP | : : | Control & |------------------------------------+ : : | Services | | : : | Module | | : : +-----------+ | : : | +--------------------+ | : : | +-------+--------------------+|----+ | : : | |+-----+--------------------+|----+| | : : | ||+----| FCIP Link Endpoint |----+|| | : : | ||| +--------------------+ ||| | : :.............................................|||.....: | ||| ||| | | ||| ||| o<--+ | ||| unique TCP ||| | | | ||| connections-->||| | | | ||| ||| | | +----------+ /\/\/\/\/\/\ | | FC | \ IP / | | Entity | / Network \ | +----------+ \/\/\/\/\/\/ | | | /\/\/\/\/\/\ +------------------+ \ FC / +->IP Address & / Fabric \ +->Well Known Port \/\/\/\/\/\/ Fig. 4 FCIP Entity Model The FCIP Entity is the connection interface point for the IP Network and is the owner of the IP Address and Well Known Port used to form TCP Connections. An FC Fabric to IP Network interface product SHALL provide each FC Entity FCIP Entity pair contained in the product with a unique combination of FC Fabric Entity World Wide Identifier and FC/FCIP Entity Identifier values (see section 7). An FCIP Entity contains an FCIP Control & Services Module to provide the FC Entity with an interface to key IP Network features. The interfaces to the IP Network features is implementation specific, Rajagopal, et al. Standards Track [Page 11] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 however, to maintain interoperability, the TCP/IP mechanisms used are specified in this document as follows: - TCP Connections - see section 8 - Security - see section 9 - Performance - see section 10 - Dynamic Discovery - see section 8.1.4 The FCIP Link Endpoints in an FCIP Entity provide the FC Frame encapsulation and transmission features of FCIP. 5.5 FCIP Link Endpoint (FCIP_LEP) As shown in figure 5, the FCIP Link Endpoint contains one FCIP Data Engine for each TCP Connection in the FCIP Link. ................................................ : FCIP Link Endpoint : : +------------------+ : : +-------+------------------+|----+ : : |+-----+------------------+|----+| : : ||+----| FCIP Data Engine |----+|| : : ||| +------------------+ ||| : :..............................................: ||| ||| +----------+ /\/\/\/\/\/\ | FC | \ IP / | Entity | / Network \ +----------+ \/\/\/\/\/\/ | /\/\/\/\/\/\ \ FC / / Fabric \ \/\/\/\/\/\/ Fig. 5 FCIP Link Endpoint Model Each time a TCP Connection is formed with a new FCIP Entity FC Entity pair, the FCIP Entity SHALL create a new FCIP Link Endpoint containing one FCIP Data Engine. An FCIP_LEP is a transparent data translation point between an FC Entity and an IP Network. A pair of FCIP_LEPs communicating over one or more TCP Connections create an FCIP Link to join two islands of a FC Fabric, producing a single FC Fabric. The IP Network over which the two FCIP_LEPs communicate is not aware of the FC payloads that it is carrying. Likewise, the FC End Nodes Rajagopal, et al. Standards Track [Page 12] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 connected to the FC Fabric are unaware of the TCP/IP based transport employed in the structure of the FC Fabric. An FCIP_LEP uses normal TCP based flow control mechanisms for managing its internal resources and matching them with the advertised TCP Receiver Window Size (see section 8.6). An FCIP_LEP MAY communicate with its FC Entity counterpart to coordinate flow control. 5.6 FCIP Data Engine (FCIP_DE) The model for one of the multiple FCIP_DEs that MAY be present in an FCIP_LEP is shown in figure 6. +--------------------------------+ | | |-+ +------------------+ +-| C |p| | Encapsulation | |p| N F h -->|1|--->| Engine |--->|2|--> e i a |-+ +------------------+ +-| t b n | | I w r n |-+ +------------------+ +-| P o e e |p| | De-Encapsulation | |p| r l <--|4|<---| Engine |<---|3|<-- k |-+ +------------------+ +-| | | +--------------------------------+ Fig. 6 FCIP Data Engine Model Data enters and leaves the FCIP_DE through four portals (p1 - p4). The portals do not process or examine the data that passes through them. They are only the named access points where the FCIP_DE interfaces with external world. The names of the portals are as follows: p1) FC Receiver Portal - The interface through which an FC Frame and time stamp enters an FCIP_DE from the FC Entity. p2) Encapsulated Frame Transmitter Portal - The TCP interface through which an FCIP Frame is transmitted to the IP Network by an FCIP_DE. p3) Encapsulated Frame Receiver Portal - The TCP interface through which an FCIP Frame is received from the IP Network by an FCIP_DE. Rajagopal, et al. Standards Track [Page 13] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 p4) FC Transmitter Portal - The interface through which a reconstituted FC Frame and time stamp exits an FCIP_DE to the FC Entity. The work of the FCIP_DE is done by the Encapsulation and De- Encapsulation Engines. The Engines have two functions: 1) Encapsulating and de-encapsulating FC Frames using the encapsulation format described in FC Frame Encapsulation [25] and in section 5.6.1 of this document, and 2) Detecting some data transmission errors and performing minimal error recovery as described in section 5.6.2. Data flows through the FCIP_DE in the following seven steps: 1) An FC Frame and time stamp arrives at the FC Receiver Portal and is passed to the Encapsulation Engine. The FC Frame is assumed to have been processed by the FC Entity according to the applicable FC rules and is not validated by the FCIP_DE. If the FC Entity is in the Unsynchronized state with respect to a time base as described in the FC Frame Encapsulation [25] specification, the time stamp delivered with the FC Frame SHALL be zero. 2) In the Encapsulation Engine, the encapsulation format described in FC Frame Encapsulation [25] and in section 5.6.1 of this document SHALL be applied to prepare the FC Frame and associated time stamp for transmission over the IP Network. 3) The entire encapsulated FC Frame (a.k.a. the FCIP Frame) SHALL be passed to the Encapsulated Frame Transmitter Portal where it SHALL be inserted in the TCP byte stream. 4) Transmission of the FCIP Frame over the IP Network follows all the TCP rules of operation. This includes but is not limited to the in-order delivery of bytes in the stream, as specified by TCP [8]. 5) The FCIP Frame arrives at the partner FCIP Entity where it enters the FCIP_DE through the Encapsulated Frame Receiver Portal and is passed to the De-Encapsulation Engine for processing. Rajagopal, et al. Standards Track [Page 14] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 6) The De-Encapsulation Engine SHALL validate the incoming TCP byte stream as described in section 5.6.2 and SHALL de-encapsulate the FC Frame and associated time stamp according to the encapsulation format described in FC Frame Encapsulation [25] and in section 5.6.1 of this document. 7) In the absence of errors, the de-encapsulated FC Frame and time stamp SHALL be passed to the FC Transmitter Portal for delivery to the FC Entity. Every FC Frame that arrives at the FC Receiver Portal SHALL be transmitted on the IP Network as described in steps 1 through 4 above. In the absence of errors, data bytes arriving at the Encapsulated Frame Receiver Portal SHALL be de-encapsulated and forwarded to the FC Transmitter Portal as described in steps 5 through 7. 5.6.1 FCIP Encapsulation of FC Frames The FCIP encapsulation of FC Frames employs FC Frame Encapsulation [25]. The features from FC Frame Encapsulation that are unique to individual protocols SHALL be applied as follows for the FCIP encapsulation of FC Frames. The Protocol# field SHALL contain 1 in accordance with the IANA Considerations annex of FC Frame Encapsulation [25]. The Protocol Specific field SHALL have the format shown in figure 7. Note: the word numbers in figure 7 are relative to the complete FC Frame Encapsulation header, not to the Protocol Specific field. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------------------------------------------------------+ 1| replication of encapsulation word 0 | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | +---------------+---------------+---------------+---------------+ Fig. 7 FCIP Usage of FC Frame Encapsulation Protocol Specific field Word 1 of the Protocol Specific field SHALL contain an exact copy of word 0 in FC Frame Encapsulation [25]. Rajagopal, et al. Standards Track [Page 15] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 The pFlags (protocol specific flags) field provides information about the protocol specific usage of the FC Encapsulation Header. Figure 8 shows the defined pFlags bits. |----------------Bit--------------------| | | | 31 30 29 28 27 26 25 24 | +-----------------------------+----+----+ | Reserved | Ch | SF | +-----------------------------+----+----+ Fig. 8 pFlags Field Bits The SF (Short Frame) bit indicates whether the FCIP Frame is an encapsulated FC Frame or an FCIP Short Frame (see section 7). When the FCIP Frame contains an encapsulated FC Frame the SF bit SHALL be 0. When the FCIP Frame is an FCIP Short Frame the SF bit SHALL be 1. The FCIP Short Frame SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection and only one FCIP Short Frame SHALL be transmitted in each direction at that time. After that all FCIP Frames SHALL have the SF bit set to 0. The Ch (Changed) bit indicates whether an echoed Short Frame has been intentionally altered (see section 8.1.5). The Ch bit SHALL be 0 unless the Short Frame bit is 1. When the initial TCP Connection Short Frame is sent, the Ch bit SHALL be 0. If the recipient of a TCP connect request echoes the Short Frame without any changes, then the Ch bit SHALL continue to be 0. If the recipient of a TCP connect request alters the Short Frame before echoing it, then the Ch bit SHALL be changed to 1. Rajagopal, et al. Standards Track [Page 16] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Table 1 summarizes the usage of the pFlags SF and Ch bits. +----+----+------------+--------------------------------------+ | | | Originated | | | SF | Ch | or Echoed | Validitity/Description | +----+----+------------+--------------------------------------+ | 0 | 0 | n/a | Encapsulated FC Frame | +----+----+------------+--------------------------------------+ | 0 | 1 | n/a | Always Illegal | +----+----+------------+--------------------------------------+ | 1 | 0 | Originated | Originated Short Frame | +----+----+------------+--------------------------------------+ | 1 | 1 | Originated | Always Illegal | +----+----+------------+--------------------------------------+ | 1 | 0 | Echoed | Echoed Short Frame without changes | +----+----+------------+--------------------------------------+ | 1 | 1 | Echoed | Echoed Short Frame with changes | +----+----+------------+--------------------------------------+ | Note: Echoed Short Frames may contain changes resulting | | transmission errors, necessitating the comparison between | | sent and recieved Short Frame bytes by the Short Frame | | originator described in section 8.1.2. | +-------------------------------------------------------------+ pFlags SF and Ch bit usage summary The Reserved pFlags bits SHALL be 0. The Reserved field (bits 23-16 in word 2): SHALL contain 0. The -Reserved field (bits 7-0 in word 2): SHALL contain 255 (or 0xFF). The CRCV (CRC Valid) Flag SHALL be set to 0. The CRC field SHALL be set to 0. Rajagopal, et al. Standards Track [Page 17] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Table 2 shows the SOF and EOF code values that are legal in FCIP Frames. This list may be a subset of the SOF and EOF codes listed in the FC Frame Encapsulation [25]. +-------+----------+ +-------+----------+ | FC | | | FC | | | SOF | SOF Code | | EOF | EOF Code | +-------+----------+ +-------+----------+ | SOFf | 0x28 | | EOFn | 0x41 | | SOFi2 | 0x2D | | EOFt | 0x42 | | SOFn2 | 0x35 | | EOFni | 0x49 | | SOFi3 | 0x2E | | EOFa | 0x50 | | SOFn3 | 0x36 | +-------+----------+ +-------+----------+ Valid FCIP SOF and EOF codes 5.6.2 FCIP Data Engine Error Detection and Recover 5.6.2.1 TCP Assistance With Error Detection and Recovery TCP [8] requires in order delivery, generation of TCP checksums, and checking of TCP checksums. Thus, the byte stream passed from TCP to the FCIP_LEP will be in order and free of errors detectable by the TCP checksum. If TCP did not perform these functions, the FCIP_LEP would have to. 5.6.2.2 Errors in FCIP Headers and Discarding FCIP Frames Bytes delivered through the Encapsulated Frame Receiver Portal that are not correctly delimited as defined by the FC Frame Encapsulation [25] are considered to be in error. Further, some errors in the encapsulation will result in the FCIP_DE losing synchronization with the FCIP frames in the byte stream entering through the Encapsulated Frame Receiver Portal. The Frame Length field in the FC Frame Encapsulation header is used to determine where in the data stream the next FC Encapsulated Header is located. The following tests SHALL be performed to verify synchronization with the byte stream entering the Encapsulated Frame Receiver Portal, and synchronization SHALL be considered lost if any of the tests fail: 1) Length field validation -- 15 < Length < 545; 2) Comparison of Length field to its ones complement; and Rajagopal, et al. Standards Track [Page 18] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 3) A valid EOF is found in the word preceding the start of the next FCIP header as indicated by the Frame Length field, to be tested as follows: 1) Bits 24-31 and 16-23 contain identical legal EOF values (the list of legal EOF values is in the FC Frame Encapsulation [25]); and 2) Bits 8-15 and 0-7 contain the ones complement of the EOF value found in bits 24-31. If synchronization is lost, the frame SHALL NOT be forwarded on to the FC Entity and further recovery SHALL be handled as defined by section 5.6.2.3. In addition to the tests above, the validity and positioning of the following FCIP Frame information SHOULD be used to detect encapsulation errors that may or may not affect synchronization: a) Protocol # field and its ones complement (2 tests); b) Version field and its ones complement (2 tests); c) Replication of encapsulation word 0 in word 1 (1 test); d) Reserved field and its ones complement (2 tests); e) Flags field and its ones complement (2 tests); f) CRC field is equal to zero (1 test); g) SOF fields and ones complement fields (4 tests); h) Format and values of FC header (1 test); i) CRC of FC Frame (2 tests); j) FC Frame Encapsulation header information in the next FCIP Frame (1 test). At least 5 of the 18 tests listed above SHALL be performed. Failure of any of the above tests actually performed SHALL indicate an encapsulation error and the frame SHALL NOT be forwarded on to the FC Entity. Further, such errors SHOULD be considered carefully, since some may be synchronization errors. Whenever an FCIP_DE discards bytes delivered through the Encapsulated Frame Receiver Portal, it SHALL cause the FCIP Entity to notify the FC Entity of the condition and provide a suitable description of the reason bytes were discarded. The burden for recovering from discarded data falls on the FC Entity and other components of the FC Fabric and is outside the scope of this specification. Rajagopal, et al. Standards Track [Page 19] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 5.6.2.3 Synchronization Failures If an FCIP_DE determines that it cannot find the next FCIP Frame header in the byte stream entering through the Encapsulated Frame Receiver Portal, the FCIP_DE SHALL either: a) close the TCP Connection [8] [9]; b) recover synchronization by searching the bytes delivered by the Encapsulated Frame Receiver Portal for a valid FCIP Frame header having the correct properties, and discarding bytes delivered by the Encapsulated Frame Receiver Portal until a valid FCIP Frame header is found; or c) attempt to recover synchronization as described in b) and if synchronization cannot be recovered close the TCP Connection as described in a). If the FCIP_DE attempts to recover synchronization, the resynchronization algorithm used SHALL meet the following requirements: a) discard or identify with an EOFa (see annex section C.1) those FC Frames and fragments of FC Frames identified before synchronization has again been completely verified. The number of FC Frames not forwarded may vary based on the algorithm used; b) return to sending valid FC Frames only after synchronization has been verified; and c) close the TCP/IP connection if the algorithm ends without verifying successful synchronization. The probability of failing to synchronize successfully and the time necessary to determine whether or not synchronization was successful may vary with the algorithm used. An example algorithm meeting these requirements can be found in annex A. The burden for recovering from the discarding of FCIP Frames during the optional resynchronization process described in this section falls on the FC Entity and other components of the FC Fabric and is outside the scope of this specification. 6. Checking FC Frame Transit Times in the IP Network The FC Entity MUST implement setup and verification components of the frame transit time function described in the FC Frame Encapsulation [25] specification to detect FC Frames that have taken too long to transit the IP Network. The choice to place this Rajagopal, et al. Standards Track [Page 20] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 implementation requirement in the FC Entity is based on a desire to include the transit time through the FCIP Entities when computing the IP Network transit time experienced by the FC Frames. Each FC Frame that enters the FCIP_DE through the FC Receiver Portal SHALL be accompanied by a time stamp value that the FCIP_DE SHALL place in the Time Stamp [integer] and Time Stamp [fraction] fields of the encapsulation header of the FCIP Frame that contains the FC Frame. If no synchronized time stamp value is available to accompany the entering FC Frame a value of zero SHALL be supplied. Each FC Frame that exits the FCIP_DE through the FC Transmitter Portal SHALL be accompanied by the time stamp value taken from the FCIP Frame that encapsulated the FC Frame. The FC Entity SHALL use suitable internal clocks and either Fibre Channel services or an SNTP Version 4 server [12] to establish and maintain the required synchronized time value. The FC Entity SHALL verify that the FC Entity it is communicating with on an FCIP Link is using the same synchronized time source as it is, either Fibre Channel services or SNTP server. Note that since the FC Fabric is expected to have a single synchronized time value throughout, reliance on the Fibre Channel services means that only one synchronized time value is needed for all FCIP_DEs regardless of their connection characteristics. 7. The FCIP Short Frame Figure 9 shows the FCIP Short Frame format. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | (0x01) | (0x00) | (0xFE) | (0xFF) | +---------------+---------------+---------------+---------------+ (Continued) Fig. 9 FCIP Short Frame Format (part 1 of 2) Rajagopal, et al. Standards Track [Page 21] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| | | | (Concluded) | +-----------+-------------------+-----------+-------------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0x00) | (0x00-0F) | (0x3F) | (0x03-F0) | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +-------------------------------+-------------------------------+ 7| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ 8| | +----- Source FC Fabric Entity World Wide Name -----+ 9| | +---------------------------------------------------------------+ 10| Source FC/FCIP Entity Identifier | +---------------+---------------+-------------------------------+ 11| Connection | Reserved | Connection Usage Code | | Usage Flags | (0x00) | | +---------------+---------------+-------------------------------+ 12| | +----- Destination FC Fabric Entity World Wide Name -----+ 13| | +-------------------------------+-------------------------------+ 14| Reserved | -Reserved | | (0x00-00) | (0xFF-FF) | +-------------------------------+-------------------------------+ Fig. 9 FCIP Short Frame Format (part 2 of 2) The FCIP Short Frame SHALL only be sent as the first bytes transmitted in each direction on a newly formed TCP Connection and only one FCIP Short Frame SHALL be transmitted in each direction at that time. If an FCIP Short Frame that passes the FCIP Frame validity checks described in section 5.6.2.2 is received at any time other than as the first bytes delivered on a newly formed TCP Connection, the FCIP Rajagopal, et al. Standards Track [Page 22] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Short Frame SHALL not be delivered to the FC Transmitter Portal and its contents SHALL be ignored. The contents of the FCIP Short Frame SHALL be as described for encapsulated FC Frames, except for the fields described in this section. All FCIP Short Frames SHALL have the pFlags SF bit set to 1 (see section 5.6.1). The Source FC Fabric Entity World Wide Name field SHALL contain the Fibre Channel Name_Identifier [6] for the FC Fabric entity associated with the FC Entity FCIP Entity pair that generated the Short Frame. For example, if the FC Fabric entity is a FC Switch, the FC Fabric Entity World Wide Name field SHALL contain the Switch_Name [5] provided that name is world wide unique. The FC Fabric Entity World Wide Name SHALL be world wide unique. The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier for the FC Entity FCIP Entity pair that generated the Short Frame. The value is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field. The Source FC/FCIP Entity Identifier is statically assigned to represent the configuration relationship of the FC Entity FCIP Entity pair to the FC Fabric entity. Note: The combination of the Source FC Entity World Wide Name and Source FCIP Entity Identifier fields uniquely identifies every FC Entity FCIP Entity pair in the IP Network. An FCIP Entity that receives a TCP connect request SHALL expect to receive a Short Frame as the first incoming bytes on the new TCP Connection as described in section 8.1.5. The Connection Usage Flags field identifies the types of SOF values [25] to be carried on the connection as shown in figure 10. |------------------------------Bit------------------------------| | | | 31 30 29 28 27 26 25 24 | +---------------------------------------------------------------+ | SOFf | SOF?2 | SOF?3 | Reserved | +---------------------------------------------------------------+ Fig. 10 Connection Usage Flags Field Format If the SOFf bit is one, then FC Frames containing SOFf are intended to be carried on the connection. Rajagopal, et al. Standards Track [Page 23] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 If the SOF?2 bit is one, then FC Frames containing SOFi2 and SOFn2 are intended to be carried on the connection. If the SOF?3 bit is one, then FC Frames containing SOFi3 and SOFn3 are intended to be carried on the connection. All or none of the SOFf, SOF?2, and SOF?3 bits MAY be set to one. If all of the SOFf, SOF?2, and SOF?3 bits are zero, then the types of FC Frames intended to be carried on the connection has no specific relationship to SOF code. The FCIP Entity SHALL NOT enforce the SOF usage described by the Connection Usage Flags field and SHALL only use the contents of the field as described below. The Connection Usage Code field contains Fibre Channel defined information regarding the intended usage of the connection as specified in FC-BB-2 [4]. The FCIP Entity SHALL use the contents of the Connection Usage Flags and Connection Usage Code fields to locate appropriate QoS settings in the "shared" database of TCP Connection information (see section 8.1.1) and apply those settings to a newly formed connection. For each new incoming TCP connect request received, the FCIP Entity SHALL send the contents of the Source FC Fabric Entity World Wide Name, Source FC/FCIP Identifier, Connection Usage Flags and Connection Usage Code fields to the FC Entity along with the other new connection information (e.g., FCIP_LEP and FCIP_DE information). 8. TCP Connection Management 8.1 TCP Connection Establishment 8.1.1 Connection Establishment Model The description of the connection establishment process in section 8.1 is a model for the interactions between an FC Entity and an FCIP Entity during TCP Connection establishment. The model is written in terms of a "shared" database that the FCIP Entity consults to determine the properties of the TCP Connections to be formed combined with routine calls to the FC Entity when connections are successfully established. Whether the FC Entity contributes information to the "shared" database is not critical to this model. What is important is the fact that the FCIP Entity MAY consult the database at anytime to determine its actions relative to TCP Connection establishment. Rajagopal, et al. Standards Track [Page 24] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 It is important to remember that this description is only a model for the interactions between an FC Entity and an FCIP Entity. Any implementation that has the same effects on the FC Fabric and IP Network as those described in the model meets the requirements of this specification. For example, an implementation might replace the "shared" database with a routine interface between the FC and FCIP Entities. 8.1.2 Connection Setup Following a Successful TCP Connect Request Whether Non-Dynamic TCP Connection creation (see section 8.1.3) or Dynamic TCP Connection creation (see section 8.1.4) is used, the steps described in this section SHALL be followed to take the TCP Connection setup process to completion. After the TCP connect request has been accepted, the FCIP Entity SHALL send an FCIP Short Frame (see section 7) as the first bytes passing through Encapsulated Frame Transmitter Portal on the newly formed connection and retain a copy of those bytes for later comparisons. All fields in the FCIP Short Frame SHALL be filled in as described in section 7, particularly: - The Source FC Fabric Entity World Wide Name field SHALL contain the FC Fabric Entity World Wide Name for the FC Entity FCIP Entity pair that is originating the TCP connect request; - The Source FC/FCIP Entity Identifier field SHALL contain a unique identifier that is assigned by the FC Fabric entity whose world wide name appears in the Source FC Fabric Entity World Wide Name field; and - The Destination FC Fabric Entity World Wide Name field SHALL contain 0 or the expected FC Fabric Entity World Wide Name for the FC Entity FCIP Entity pair that is destination the TCP connect request. After the FCIP Short Frame bytes are sent through the Encapsulated Frame Transmitter Portal, the FCIP Entity SHALL wait for the FCIP Short Frame to be echoed as the first bytes received through Encapsulated Frame Receiver Portal on the newly formed connection. The FCIP Entity MAY apply a timeout of not less than 90 seconds to the waiting for the echoed FCIP Short Frame bytes and if the timeout expires the FCIP Entity SHALL close the TCP Connection. If the echoed FCIP Short Frame bytes do not exactly match the FCIP Short Frame bytes sent (words 7 through 13 inclusive), the FCIP Entity SHALL close the TCP Connection. Rajagopal, et al. Standards Track [Page 25] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 The remaining steps in this section SHALL be performed only if the echoed FCIP Short Frame bytes exactly match the FCIP Short Frame bytes sent (words 7 through 13 inclusive). If the IP Address and TCP Port to which the TCP Connection was made is not associated with any other FCIP_LEP, the FCIP Entity SHALL: 1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection, 2) Create a new FCIP_LEP for the new FCIP Link, 3) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and 4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Destination FC Fabric Entity World Wide Name, Connection Usage Flags and Connection Usage Code. If an existing FCIP_LEP is associated with the IP Address and TCP Port to which the TCP Connection was made, the FCIP Entity SHALL: 1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection, 2) Create a new FCIP_DE within the existing FCIP_LEP to service the new TCP Connection, and 3) Inform the FC Entity of the FCIP_LEP, Destination FC Fabric Entity World Wide Name, Connection Usage Flags, Connection Usage Code and new FCIP_DE. 8.1.3 Non-Dynamic Creation of New TCP Connections When an FCIP Entity discovers that a new TCP Connection needs to be established, it SHALL determine the IP Address to which the TCP Connection is to be made and establish all enabled IP security features for that IP Address as described in section 9. Then the FCIP Entity SHALL determine the following information about the new connection in addition to the IP Address: - The expected Destination FC Fabric Entity World Wide Name of the FC Entity FCIP Entity pair to which the TCP Connection is being made - TCP Connection Parameters (see section 8.4) - Quality of Service Information (see section 10) Rajagopal, et al. Standards Track [Page 26] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Based on this information, the FCIP Entity SHALL generate a TCP connect request [8] to the FCIP Well-Known Port at the specified IP Address. If the TCP connect request is rejected, the FCIP Entity SHALL act to limit unnecessary repetition of attempts to establish similar connections. If the TCP connect request is accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2 to complete the establishment of a new FCIP_DE. It is recommended that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted. 8.1.4 Dynamic Creation of New TCP Connections If dynamic discovery of participating FCIP Entities is supported the function SHALL be performed using the Service Location Protocol (SLPv2) [23] in the manner defined for FCIP usage [26]. Upon discovering that dynamic discovery is to be used, the FCIP Entity SHALL enable IP security features for the SLP discovery process as described in [26] and then: 1) Determine the one or more FCIP Discovery Domain(s) to be used in the dynamic discovery process; 2) Establish an SLPv2 Service Agent to advertise the availability of this FCIP Entity to peer FCIP Entities in the identified FCIP Discovery Domain(s); and 3) establish an SLPv2 User Agent to locate service advertisements for peer FCIP Entities in the identified FCIP Discovery Domain(s). For each peer FCIP Entity dynamically discovered through the SLPv2 User Agent, the FCIP Entity SHALL establish all enabled IP security features for the discovered IP Address as described in section 9 and then determine the following information about the new connection: - The expected Destination FC Fabric Entity World Wide Name of the FC Entity FCIP Entity pair to which the TCP Connection is being made - TCP Connection Parameters (see section 8.4) - Quality of Service Information (see section 10) Based on this information, the FCIP Entity SHALL generate a TCP connect request [8] to the FCIP Well-Known Port at the IP Address specified by the service advertisement. If the TCP connect request is rejected, act to limit unnecessary repetition of attempts to establish similar connections. If the TCP connect request is Rajagopal, et al. Standards Track [Page 27] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 accepted, the FCIP Entity SHALL follow the steps described in section 8.1.2 to complete the establishment of a new FCIP_DE. It is recommended that an FCIP Entity not initiate TCP connect requests to another FCIP Entity if incoming TCP connect requests from that FCIP Entity have already been accepted. 8.1.5 Processing Incoming TCP Connect Requests The FCIP Entity SHALL listen for new TCP Connection requests [8] on the FCIP Well-Known Port. An FCIP Entity MAY also accept and establish TCP Connections to a TCP port number other than the FCIP Well-Known Port, as configured by the network administrator. The FCIP Entity SHALL determine the following information about the requested connection: - Whether the requested connection is allowed - Whether IP security setup has been performed for the IP security features enabled on the connection (see section 9) If the requested connection is not allowed, the FCIP Entity SHALL terminate the TCP connect request [8]. If the requested connection is allowed, the FC Entity SHALL ensure that required IP security features are enabled and accept the TCP connect request. After the TCP connect request has been accepted, the FCIP Entity SHALL wait for the FCIP Short Frame sent by the originator of the TCP connect request as the first bytes received through the Encapsulated Frame Receiver Portal on the accepted connection. The FCIP Entity MAY apply a timeout of not less than 90 seconds to the waiting for the FCIP Short Frame bytes and if the timeout expires the FCIP Entity SHALL close the TCP Connection. Upon receipt of the FCIP Short Frame sent by the originator of the TCP connect request, the FCIP Entity SHALL inspect the contents of the following fields: - Destination FC Fabric Entity World Wide Name, - Connection Usage Flags, and - Connection Usage Code. If the Destination FC Fabric Entity World Wide Name contains 0, the FCIP Entity SHALL take one of the following two actions: 1) Leave the Destination FC Fabric Entity World Wide Name field and Ch bit both 0, or Rajagopal, et al. Standards Track [Page 28] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 2) Change the Destination FC Fabric Entity World Wide Name field to match FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request and change the Ch bit to 1. The choice between the above two actions depends on the anticipated usage of the FCIP Entity and is outside the scope of this specification. The FCIP Entity may consult the "shared" database when choosing between the above actions. If: a) the Destination FC Fabric Entity World Wide Name contains a non- zero value that does not match the FC Fabric Entity World Wide Name associated with the FCIP Entity that received the TCP connect request, or b) the contents of the Connection Usage Flags, and Connection Usage Code fields is not acceptable to the FCIP Entity that received the TCP connect request, then the FCIP Entity SHALL change the contents of the unacceptable fields to correct/acceptable values and set the Ch bit to 1. If the FCIP Entity makes any changes in the content of the FCIP Short Frame, it SHALL also set the Ch bit to 1. After the received FCIP Short Frame has been processed as described above, it SHALL be echoed to the originator of the TCP connect request as the first bytes passing through the Encapsulated Frame Transmitter Portal on the accepted connection. The remaining steps in this section SHALL be performed only if the FCIP Entity has changed the contents of the unacceptable fields to correct/acceptable values. If the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Short Frame do not match the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier associated with any other FCIP_LEP, the FCIP Entity SHALL: 1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields and "shared" database information (see section 8.1.1) as appropriate, 2) Create a new FCIP_LEP for the new FCIP Link, 3) Create a new FCIP_DE within the newly created FCIP_LEP to service the new TCP Connection, and Rajagopal, et al. Standards Track [Page 29] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 4) Inform the FC Entity of the new FCIP_LEP, FCIP_DE, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags and Connection Usage Code. If an existing FCIP_LEP is associated the Source FC Fabric Entity World Wide Name and Source FC/FCIP Entity Identifier field values in the FCIP Short Frame, the FCIP Entity SHALL: 1) Instantiate the appropriate Quality of Service (see section 10) conditions on the newly created TCP Connection, considering the Connection Usage Flags and Connection Usage Code fields and "shared" database information (see section 8.1.1) as appropriate, 2) Create a new FCIP_DE within the existing FCIP_LEP to service the new TCP Connection, and 3) Inform the FC Entity of the FCIP_LEP, Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier, Connection Usage Flags, Connection Usage Code and new FCIP_DE. Note that the originator of TCP connect requests uses IP Address and TCP Port to identify which TCP Connections belong to which FCIP_LEPs while the recipient of TCP connect requests uses the Source FC Fabric Entity World Wide Name, Source FC/FCIP Entity Identifier fields from the FCIP Short Frame to identify which TCP Connection belong to which FCIP_LEPs. For this reason, an FCIP Entity that both originates and receives TCP connect requests is unable to match the FCIP_LEPs associated with originated TCP connect requests to the FCIP_LEPs associated with received TCP connect requests. 8.2 Merging FCIP_LEPs Using information outside the scope of this specification, an FC Entity may be able to determine that two FCIP_LEPs belong to the same FCIP Link. The FCIP Entity SHALL provide to the FC Entity a mechanism that merges to name FCIP_LEPs to form a single FCIP_LEP. 8.3 Closing TCP Connections The FCIP Entity SHALL provide a mechanism by which the FC Entity is able to cause the closing of an existing TCP Connection at anytime. This allows the FC Entity to close TCP Connections that are producing too many errors, etc. Rajagopal, et al. Standards Track [Page 30] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 8.4 TCP Connection Parameters In order to provide efficient management of FCIP_LEP resources as well as FCIP Link resources, consideration of certain TCP connection parameters is RECOMMENDED. 8.4.1 TCP Selective Acknowledgement Option The Selective Acknowledgement option RFC 2883 [24] allows the receiver to acknowledge multiple lost packets in a single ACK, enabling faster recovery. An FCIP Entity MAY negotiate use of TCP SACK and use it for faster recovery from lost packets and holes in TCP sequence number space. 8.4.2 TCP Window Scale Option This option allows TCP window sizes larger than 16-bit limits to be advertised by the receiver. It is necessary to allow data in long fat networks to fill the available pipe. This also implies buffering on the TCP sender that matches the (bandwidth*delay) product of the TCP Connection. An FCIP_LEP uses locally available mechanisms to set a window size that matches the available local buffer resources and the desired throughput. 8.4.3 Protection against sequence number wrap It is RECOMMENDED that FCIP Entities implement protection against sequence number wrap. It is quite possible that within a single connection, TCP sequence numbers wrap within a timeout window. 8.4.4 TCP_NODELAY Option FCIP Entities SHALL set the TCP_NODELAY option to one. This will disable the Nagle Algorithm that is designed for usage in a telnet environment. 8.5 TCP Connection Considerations In idle mode, a TCP Connection "keep alive" option of TCP is normally used to keep a connection alive. However, this timeout is fairly large and may prevent early detection of loss of connectivity. In order to facilitate faster detection of loss of connectivity, FC Entities SHOULD implement some form of Fibre Channel connection failure detection. When an FCIP Entity discovers that a TCP connectivity has been lost, the FCIP Entity SHALL notify the FC Entity of the failure. Rajagopal, et al. Standards Track [Page 31] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 8.6 Flow Control Mapping between TCP and FC The FCIP Entity and FC Entity are connected to the IP Network and FC Fabric, respectively, and they need to follow the flow control mechanisms of both TCP and FC, which work independent of each other. This section provides guidelines as to how the FCIP Entity can map TCP flow control to status notifications to the FC Entity. There are two scenarios when the flow control management becomes crucial: 1) When there is line speed mismatch between the FC and IP interfaces. Even though it is RECOMMENDED that both the FC and IP interfaces to the FC Entity and FCIP Entity, respectively, be of comparable speeds, it is possible to carry FC traffic over an IP Network that has a different line speed and bit error rate. 2) When the FC Fabric or IP Network encounters congestion. Even when both the FC Fabric or IP network are of comparable speeds, during the course of operation the FC Fabric or the IP Network could encounter congestion due to transient conditions. The FC Entity uses Fibre Channel mechanisms for flow control at the FC Receiver Portal based on information supplied by the FCIP Entity regarding flow constraints at the Encapsulated Frame Transmitter Portal. The FCIP Entity uses TCP mechanisms for flow control at the Encapsulated Frame Receiver Portal portal based on information supplied by the FC Entity regarding flow constraints at the FC Transmitter Portal. Coordination of these flow control mechanisms one of which is credit based and the other of which is window based depends on painstaking design that is outside the scope of this specification. 9. Security 9.1 Threat Models Using a general purpose, wide-area network such as an IP Network as a substitute for physical cabling introduces some security problems not normally encountered in Fibre Channel Fabrics. FC interconnect cabling typically is protected physically from outside access. Public IP Networks allow hostile parties to impact the security of the transport infrastructure. Rajagopal, et al. Standards Track [Page 32] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 The general effect is that the security of the entire FC Fabric is only as good as the security of the entire IP Network through which it tunnels. The following broad classes of attacks are possible: 1) Unauthorized Fibre Channel elements can gain access to resources through normal Fibre Channel Fabric and processes. Although this is a valid threat, securing the Fibre Channel Fabrics is outside the scope of this document. Securing the IP Network is the issue considered in this specification. 2) Unauthorized agents can monitor and manipulate Fibre Channel traffic flowing over physical media used by the IP Network and under control of the agent. 3) TCP Connections may be hijacked and used to instantiate an invalid FCIP Link between two peer FCIP Entities. 4) Valid and invalid FCIP Encapsulated frames may be injected on the TCP Connections. 5) The payload of an FCIP Encapsulated frame may be altered or transformed in such a way that it preserves the TCP Checksum transform while altering content. 6) Unauthorized agents can masquerade as a valid FCIP Entities and disturb proper operation of the Fibre Channel Fabric. 7) Denial of Service attacks can be mounted by injecting TCP Connection requests and other resource exhaustion operations. The existing IPSec Security Architecture and protocol suite [13] offers protection from these threats. An FCIP Entity MUST implement portions of the IPSec protocol suite as described in this section. 9.2 FC Fabric and IP Network Deployment Models In the context of enabling a secure FCIP tunnel between FC SANs, the following characteristics of the IP Network deployment are useful to note. 1) The FCIP Entities share a peer-to-peer relationship. Therefore, the administration of security policies applies to all FCIP Entities in an equal manner. This varies from a true Client- Server relationship, where there is an inherent difference in how security policies are administered. Rajagopal, et al. Standards Track [Page 33] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 2) Policy administration as well as security deployment and configuration are constrained to the set of FCIP Entities, thereby posing less of a requirement on a scalable mechanism. For example, the validation of credentials can be relaxed to the point where deploying a set of pre-shared keys is a viable technique. 3) TCP Connections and the IP Network are terminated at the FCIP Entity. The granularity of security implementation is at the level of the FCIP tunnel endpoint (or FCIP Entity), unlike other applications where there is a user-level termination of TCP Connections. User-level objects are not controllable by or visible to FCIP Entities. All user-level security related to FCIP is the responsibility of the Fibre Channel standards [7] and outside the scope of this specification. 9.3 FCIP Security Components FCIP Security compliant implementations MUST implement IPSec Protocol Suite based cryptographic authentication and data integrity [13], as well as confidentiality using algorithms and transforms as described in this section. Also, FCIP implementations MUST meet the secure key management requirements of IPSec protocol suite. 9.3.1 IPSec ESP Authentication and Confidentiality FCIP Entities MUST implement IPSec ESP [15] in Tunnel Mode for providing Data Integrity and Confidentiality. FCIP Entities MAY implement IPSec ESP in Transport Mode, if deployment considerations require use of Transport Mode. If Confidentiality is not enabled but Data Integrity is enabled, ESP with NULL Encryption [17] MUST be used. IPSec ESP for message authentication computes a cryptographic hash over the payload that is protected. While IPSec ESP mandates compliant implementations to support certain algorithms for deriving this hash, FCIP implementations: - MUST implement HMAC with SHA-1 [14] - SHOULD implement AES in CBC MAC mode with XCBC extensions [draft- pending] For ESP Confidentiality, FCIP Entities: - MUST implement 3DES in CBC mode - SHOULD implement AES in CTR mode [27] - MUST implement NULL Encryption [17] Rajagopal, et al. Standards Track [Page 34] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 When AES is used, the key size SHALL be at least 128-bits and the block size SHALL be at least 128-bits. CTR mode SHALL conform to the Segmented Integer Counter Mode of operation as described in [draft pending] (a possible source for the pending draft is [28]). 9.3.2 Key Management FCIP Entities MUST use the IKE protocol [16] to establish and maintain a Security Association (SA) for use by the two peers. Manual keying for establishing SA is not permitted since it does not provide the necessary elements for rekeying (see section 9.3.3). IKE Phase 1 establishes a secure, MAC-authenticated channel for communications for use by IKE Phase 2. FCIP Entities MUST support "Main Mode" operation in Phase 1 and MAY support "Aggressive Mode" if identity protection is not required. FCIP Entities negotiate parameters for SA during IKE Phase 2 only using "Quick Mode". For FCIP Entities engaged in IKE "Quick Mode", there is no requirement for PFS (Perfect Forward Secrecy). FCIP Entities engaged in IKE "Quick Mode" are not required to transmit a Key Exchange (KE) payload. For a given pair of FCIP Entities, the same IKE Phase 1 negotiation can be used for all Phase 2 negotiations; i.e., all TCP Connections that are bundled into the single FCIP Link can share the same Phase 1 results. Repeated rekeying using "Quick Mode" on the same shared secret will over time, reduce the cryptographic properties of that secret. To overcome this, Phase 1 MAY be invoked periodically to create a new set of IKE shared secrets and related security parameters. IKE Phase 1 establishment requires key distribution, and FCIP Entities: - MUST support pre-shared IKE keys - MAY support public key encryption - MAY support signature based authentication When pre-shared keys are used, FCIP Entities SHALL provide a secure administrative interface for entering these keys. Such mechanisms are outside the scope of this document. Support for IKE Oakley Groups is not required. For the purposes of establishing a secure FCIP Link, the two participating FCIP Entities consult a Security Policy Database Rajagopal, et al. Standards Track [Page 35] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 (SPD). FCIP Entities MUST maintain at least one SPD entry for each FCIP_LEP with which they establish secured TCP Connections, using the Switch WWN of the peer FCIP_LEP as its identifier. This WWN is transmitted as part of the IKE payload, so that multiple connections between the same FCIP_LEP share the same Phase 1 negotiation. At the end of successful IKE negotiations both FCIP Entities store the SA parameters in their SA database (SAD). The SAD contains the set of active SA entries, each entry containing Sequence Counter Overflow, Sequence Number Counter, Anti-replay Window and the Lifetime of the SA. FCIP Entities SHALL employ a default SA Lifetime of one hour and a default Anti-replay window of 32 sequence numbers. When a TCP Connection is established between two FCIP_DEs, an SA is created for that connection and is identified in the form of a Security Parameter Index (SPI). Each direction of flow on the TCP Connection is associated with a different SA and each FCIP_DE MUST maintain the SPI for its outgoing FCIP Encapsulated Frames. 9.3.3 ESP Replay Protection and Rekeying issues FCIP Entities MUST implement Replay Protection against ESP Sequence Number wrap, as described in [16]. In addition, based on the number of bits in the cipher block size, the validity of the key becomes compromised. In both cases, the SA needs to be reestablished. FCIP Entities MUST use the results of IKE Phase 1 negotiation for initiating an IKE Phase 2 "Quick Mode" exchange and establish new SAs. To enable smooth transition of SAs, it is RECOMMENDED that both FCIP Entities refresh the SPI when sequence number counter reaches 2^31 (i.e., half the sequence number space). It also is RECOMMENDED that the receiver operate with multiple SPIs for the same TCP Connection for a period of 2^31 sequence number packets before aging out an SPI. When multiple SPIs are active the sending side SHALL use the most recently created SPI. 9.4 Secure FCIP Link Operation 9.4.1 FCIP Link Initialization Steps When an FCIP Link is initialized, before any FCIP TCP Connections are established, the local SPD is consulted to determine if IKE Phase 1 has been completed with the FCIP_LEP in the peer FCIP Entity, as identified by the WWN. Rajagopal, et al. Standards Track [Page 36] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 If Phase 1 is already completed, IKE Phase 2 proceeds. Otherwise, IKE Phase 1 MUST be completed before IKE Phase 2 can start. Both IKE Phase 1 and Phase 2 transactions use UDP Port 500. If IKE Phase 1 fails, the FCIP Link initialization terminates. Otherwise, the FCIP Link initialization moves to TCP Connection Initialization. 9.4.2 TCP Connection Security Associations (SAs) For a TCP Connection establishment, IKE Phase 2 is employed, resulting in an SA, identified by an SPI. All IP datagrams of the TCP Connection MUST carry an ESP header with a valid SPI and Sequence Number to be accepted as valid by the receiving peer. An implementation is free to perform several IKE Phase 2 negotiations and cache them in its local SPIs, although entries in such a cache can be flushed per current SA Lifetime settings. When a TCP Connection is terminated, the SA associated with it MUST be removed from the local SAD. 9.4.3 Handling data integrity and confidentiality violations Upon datagram reception, when the ESP packet fails an integrity check, the receiver MUST drop the datagram, which will trigger TCP retransmission. If many such datagrams are dropped, a receiving FCIP Entity MAY close the connection. An implementation MAY audit such events as a diagnostic aid. Confidentiality checks MUST be performed if Confidentiality is enabled. 9.4.4 Handling SA parameter mismatches When SA parameters do not match, the TCP Connection may reach a point where no traffic moves, or there are excessive TCP retransmissions. In such a case, either side MAY close the TCP Connection or MAY choose to reestablish another set of SA parameters. 10. Performance 10.1 Performance Considerations Traditionally, the links between FC Fabric components have been characterized by low latency and high throughput. The purpose of FCIP is to replace some of these links with an IP Network, where low latency and high throughput are not as certain. It follows that FCIP Rajagopal, et al. Standards Track [Page 37] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Entities and their counterpart FC Entities probably will be interested in optimal use of the IP Network. Many options exist for ensuring high throughput and low latency appropriate for the distances involved in an IP Network. For example, a private IP Network might be constructed for the sole use of FCIP Entities. The options that are within the scope of this specification are discussed here. One option for increasing the probability that FCIP data streams will experience low latency and high throughput is the IP QoS techniques discussed in section 10.2. This option can have value when applied to a single TCP Connection. Depending on the sophistication of the FC Entity, further value may be obtained by having multiple TCP Connections with differing QoS characteristics. There are many reasons why an FC Entity might request creation of multiple TCP Connections within an FCIP_LEP. These reasons include a desire to provide differentiated service for different TCP data connections between FCIP_LEPs or a preference to separately queue different streams of traffic not having a common in-order delivery requirement. At the time a new TCP Connection is created, the FC Entity SHALL specify to the FCIP Entity the QoS characteristics (including but not limited to IP per-hop-behavior) to be used for the lifetime of that connection. This MAY be achieved by having: a) only one set of QoS characteristics for all TCP Connections; b) a default set of QoS characteristics that the FCIP Entity applies in the absence of differing instructions from the FC Entity; or c) a sophisticated mechanism for exchanging QoS requirements information between the FC Entity and FCIP Entity each time a new TCP Connection is created. Once established, the QoS characteristics of a TCP Connection SHALL NOT be changed, since this specification provides no mechanism for the FC Entity to control such changes. The mechanism for providing different QoS characteristics in FCIP is the establishment of a different TCP Connections and associated FCIP_DEs. When FCIP is used with a network with a large (bandwidth*delay) product, it is RECOMMENDED that FCIP_LEPs use the TCP mechanisms (window scaling and wrapped sequence protection) for Long Fat Networks (LFNs) as defined in RFC 1323 [10]. Rajagopal, et al. Standards Track [Page 38] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 10.2 IP Quality of Service (QoS) Support Many methods of providing QoS have been devised or proposed. These include (but are not limited to) the following: - Multi-Protocol Label Switching (MPLS) - Differentiated Services Architecture (diffserv) -- RFC 2474 [19], RFC 2475 [20], RFC 2597 [21], and RFC 2598 [22] -- and other forms of per-hop-behavior (PHB) - Integrated Services, RFC 1633 [11] - IEEE 802.1p The purpose of this specification is not to specify any particular form of IP QoS but rather to specify only those issues that must be addressed in order to maximize interoperability between FCIP equipment that has been manufactured by different vendors. It is RECOMMENDED that some form of preferential QoS be used for FCIP traffic to minimize latency and drop precedence. No particular form of QoS is recommended. If a PHB IP QoS is implemented, it is RECOMMENDED that it interoperate with diffserv (see RFC 2474 [19], RFC 2475 [20], RFC 2597 [21], and RFC 2598 [22]). If diffserv/PHB QoS is NOT implemented, the DSCP field for all IP packets SHALL be set to '000000'. 11. References The references in this section were current as of the time this specification was approved. This specification is intended to operate with newer version of the referenced documents and looking for newer reference documents is recommended. [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Fibre Channel Backbone (FC-BB), ANSI NCITS.342:200x, March 5, 2001 (http://www.t11.org/t11/docreg.nsf/ldl/fc-bb). [4] Fibre Channel Backbone -2 (FC-BB-2), T11 Project 1466-D, (http:// www.t11.org/t11/docreg.nsf/ldl/fc-bb-2). Rajagopal, et al. Standards Track [Page 39] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 [5] Fibre Channel Switch Fabric -2 (FC-SW-2), ANSI NCITS.355:200x, May 23, 2001 (http://www.t11.org/t11/docreg.nsf/ldl/fc-sw-2). [6] Fibre Channel Framing and Signaling (FC-FS), T11 Project 1331-D, Rev 1.2, February 16, 2001 (http://www.t11.org/t11/docreg.nsf/ ldl/fc-fs). [7] http://www.t11.org [8] "Transmission Control Protocol", RFC 793, Sept. 1981. [9] Braden, R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989 [10] Jacobson, V., Braden, R. and Borman, D., "TCP Extensions for High Performance", RFC 1323, May 1992. [11] R. Braden, et. al., ISI, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994 [12] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 2030, October 1996. [13] Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, Nov. 1998. [14] Krawczyk, H., Bellare, M., and Canetti, R., "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [15] Kent, S. and Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2406, Nov. 1998. [16] Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [17] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, Nov. 1998 [18] Thayer, R., Glenn, R., and Doraswamy, N., "IP Security Document Roadmap", RFC 2411, Nov. 1998. [19] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and Ipv6 Headers", RFC 2474, December 1998. [20] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., Weiss, W., "An Architecture for Differentiated Services", RFC 2475, Dec. 1998. Rajagopal, et al. Standards Track [Page 40] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 [21] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "An Assured Forwarding PHB", RFC 2597, June 1999. [22] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB Group", RFC 2598, June 1999. [23] E.Guttman, C. Perkins, J. Veizades, M. Day. Service Location Protocol, version 2, RFC 2608, July, 1999. [24] Floyd, et al, "SACK Extension", RFC 2883, July 2000. [25] Weber, Rajagopal, Travostino, Chau, O'Donnell, Monia Merhar, "FC Frame Encapsulation", draft-ietf-ips-fcencapsulation-__.txt (RFC reference and date to be added during standards action). [26] Peterson, "Finding FCIP Entities Using SLP", draft-ietf-ips- fcip-slp-___.txt (RFC reference and date to be added during standards action). [27] Lipmaa, H., Rogaway, P., and Wagner, D., "Comments to NIST Concerning AES Modes of Operation: CTR-Mode Encryption", NIST Workshop on AES Modes of Operation, http://csrc.nist.gov/ encryption/modes/proposedmodes/ctr/ctr-spec.pdf [28] McGrew, D., "Segmented Integer Counter Mode: Specification and Rationale", NIST Workshop on AES Modes of Operation, http:// www.mindspring.com/~dmcgrew/sic-mode.pdf 12. Bibliography The following references may prove informative to readers unfamiliar with Fibre Channel. Kembel, R., "The Fibre Channel Consultant: A Comprehensive Introduction", Northwest Learning Associates, 1998 13. Acknowledgments Funding for the RFC Editor function is currently provided by the Internet Society. Rajagopal, et al. Standards Track [Page 41] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 14. Authors' Addresses Murali Rajagopal Raj Bhagwat LightSand Communications, Inc. LightSand Communications, Inc. 24411 Ridge Route Dr. 24411 Ridge Route Dr. Suite 135 Suite 135 Laguna Hills, CA 92653 Laguna Hills, CA 92653 USA USA Phone: +1 949 837 1733 x101 Phone: +1 949 837 1733 x104 Email: muralir@lightsand.com Email: rajb@lightsand.com R. Andy Helland Elizabeth G. Rodriguez LightSand Communications, Inc. Lucent Technologies 375 Los Coches Street 1202 Richardson Drive, Suite 104 Milpitas, CA 95035 Richardson, TX 75080 USA USA Phone: +1 408 404 3119 Phone: +1 972 231 0672 Fax: +1 408 941 2166 Fax: +1 972 644 5857 Email: andyh@lightsand.com Email: egrodriguez@lucent.com Sriram Rupanagunta Neil Wanamaker Aarohi Communications Akara 3200 Montelena Drive 10624 Icarus Court San Jose, CA 95135 Austin, TX 78726 USA USA Phone: +1 408 966 8309 Phone: +1 512 257 7633 Email: sriramr@aarohi-inc.com Fax: +1 512 257 7877 Email: nwanamaker@akara.com Steve Wilson Bob Snively Brocade Comm. Systems, Inc. Brocade Comm. Systems, Inc. 1745 Technology Drive 1745 Technology Drive San Jose, CA. 95110 San Jose, CA 95110 USA USA Phone: +1 408 487 8128 Phone: +1 408 487 8135 Fax: +1 408 487 8101 Email: rsnively@brocade.com email: swilson@brocade.com Ralph Weber ENDL Texas, representing Brocade Suite 102 PMB 178 18484 Preston Road Dallas, TX 75252 USA Phone: +1 214 912 1373 Email: roweber@acm.org Rajagopal, et al. Standards Track [Page 42] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 David Peterson Donald R. Fraser Cisco Systems - SRBU Compaq Computer Corporation 6450 Wedgwood Road 301 Rockrimmon Blvd., Bldg. 5 Maple Grove, MN 55311 Colorado Springs, CO 80919 USA USA Phone: +1 763 398 1007 Phone: +1 719 548 3272 Cell: +1 612 802 3299 Email: don.fraser@compaq.com Email: dap@cisco.com Vi Chau Gaby Hecht Gadzoox Networks, Inc. Gadzoox Network, Inc. 16241 Laguna Canyon Road 16241 Laguna Canyon Road Suite 100 Suite 100 Irvine, CA 92618 Irvine, CA 92618 USA USA Phone: +1 949 789 4639 Phone: +1 949 789 4642 Fax: +1 949 453 1271 Fax: +1 949 453 1271 Email: vchau@gadzoox.com Email: ghecht@Gadzoox.com Ken Hirata Jim Nelson Vixel Corporation Vixel Corporation 15245 Alton Parkway, Suite 100 15245 Alton Parkway, Suite 100 Irvine, CA 92618 Irvine, CA 92618 USA USA Phone: +1 949 788 6368 Phone: +1 949 450 6159 Fax: +1 949 753 9500 Fax: +1 949 753 9500 Email: ken.hirata@vixel.com Email: Jim.Nelson@vixel.com Michael E. O'Donnell Anil Rijhsinghani McDATA Corporation McDATA Corporation 310 Interlocken Parkway 5 Brickyard lane Broomfield, Co. 80021 Westboro, MA 01581 USA USA Phone: +1 303 460 4142 Phone: +1 508 870 6593 Fax: +1 303 465 4996 Email: Email: modonnell@mcdata.com anil.rijhsinghani@mcdata.com Milan J. Merhar Craig W. Carlson 43 Nagog Park QLogic Corporation Pirus Networks 6321 Bury Drive Acton, MA 01720 Eden Prairie, MN 55346 USA USA Phone: +1 978 206 9124 Phone: +1 952 932 4064 Email: Milan@pirus.com Email: craig.carlson@qlogic.com Rajagopal, et al. Standards Track [Page 43] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Venkat Rangan Larwrence J. Lamers Rhapsody Networks Inc. SAN Valley 3450 W. Warren Ave. 4611 Park Norton Place Fremont, CA 94538 San Jose, CA 95136-2523 USA USA Phone: +1 510 743 3018 Phone: +1 408 626 1285 Fax: +1 510 687 0136 Email: ljlamers@ieee.org Email: venkat@rhapsodynetworks.com 15. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANNEX A - Example of synchronization recovery algorithm The contents of this annex are informative. Synchronization may be recovered as specified in section 5.6.2.3. An example of an algorithm for searching the bytes delivered to the Encapsulated Frame Receiver Portal for a valid FCIP Frame header is provided in this annex. This resynchronization uses the principle that a valid FCIP data stream must contain at least one valid header every 2176 bytes (the Rajagopal, et al. Standards Track [Page 44] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 maximum length of an encapsulated FC Frame). Although other data patterns containing apparently valid headers may be contained in the stream, the FC CRC or FCIP Frame validity of the data patterns contained in the data stream will always be either interrupted by or resynchronized with the valid FCIP Frame headers. Consider the case shown in figure 11. A series of short FCIP Frames, perhaps from a trace, are embedded in larger FCIP Frames, say as a result of a trace file being transferred from one disk to another. The headers for the short FCIP Frames are denoted SFH and the long FCIP Frame headers are marked as LFH. +-+--+-+----+-+----+-+----+-+-+-+---+-+--- |L| |S| |S| |S| |S| |L| |S| |F| |F| |F| |F| |F| |F| |F|... |H| |H| |H| |H| |H| |H| |H| +-+--+-+----+-+----+-+----+-+-+-+---+-+--- | | |<---------2176 bytes-------->| Fig. 11 Example of resynchronization data stream A resynchronization attempt that starts just to the right of an LFH will find several SFH FCIP Frames before discovering that they do not represent the transmitted stream of FCIP Frames. Within 2176 bytes plus or minus, however, the resynchronization attempt will encounter an SFH whose length does not match up with the next SFH because the LFH will fall in the middle of the short FCIP Frame pushing the next header farther out in the byte stream. Note that the resynchronization algorithm cannot forward any prospective FC Frames to the FC Transmitter Portal because until synchronization is completely established there is no certainty that anything that looked like an FCIP Frame really was one. For example, an SFH might fortuitously contain a length that points exactly to the beginning of an LFH. The LFH would identify the correct beginning of a transmitted FCIP Frame, but that in no way guarantees that the SFH was also a correct FCIP Frame header. There exist some data streams that cannot be resynchronized by this algorithm. If such a data stream is encountered, the algorithm causes the TCP Connection to be closed. The resynchronization assumes that security and authentication procedures outside the FCIP Entity are protecting the valid data stream from being replaced by an intruding data stream containing valid FCIP data. Rajagopal, et al. Standards Track [Page 45] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 The following steps are one example of how an FCIP_DE might resynchronize with the data stream entering the Encapsulated Frame Receiver Portal. 1) Search for candidate and strong headers: The data stream entering the Encapsulated Frame Receiver Portal is searched for 12 bytes in a row containing the required values for: a) Protocol field, b) Version field, c) ones complement of the Protocol field, d) ones complement of the Version field, e) replication of encapsulation word 0 in word 1, and f) Reserved field and its ones complement. If such a 12-byte grouping is found, the FCIP_DE assumes that it has identified bytes 0-2 of a candidate FCIP encapsulation header. All bytes up to and including the candidate header byte are discarded. If no candidate header has been found after searching a specified number of bytes greater than some multiple of 2176 (the maximum length of an FCIP Frame), resynchronization has failed and the TCP/IP connection is closed. Word 3 of the candidate header contains the Frame Length and Flags fields and their ones complements. If the fields are consistent with their ones complements, the candidate header is considered a strong candidate header. The Frame Length field is used to determine where in byte stream the next strong candidate header should be and processing continues at step 2). 2) Use multiple strong candidate headers to locate a verified candidate header: The Frame Length in one strong candidate header is used to skip incoming bytes until the expected location of the next strong candidate header is reached. Then the tests described in step 1) are applied to see if another strong candidate header has successfully been located. All bytes skipped and all bytes in all strong candidate headers processed are discarded. Strong candidate headers continue to be verified in this way for at least 4352 bytes (twice the maximum length of an FCIP Frame). Rajagopal, et al. Standards Track [Page 46] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 If at anytime a verification test fails, processing restarts at step 1 and a retry counter is incremented. If the retry counter exceeds 3 retries, resynchronization has failed and the TCP Connection is closed. After strong candidate headers haves been verified for at least 4352 bytes, the next header identified is a verified candidate header and processing continues at step 3). Note: If a strong candidate header was part of the data content of an FCIP Frame, the FCIP Frame defined by that or a subsequent strong candidate header will eventually cross an actual header in the byte stream. As a result it will either identify the actual header as a strong candidate header or it will lose synchronization again because of the extra 28 bytes in the length, returning to step 1 as described above. 3) Use multiple strong candidate headers to locate a verified candidate header: Incoming bytes are skipped and discarded until the next verified candidate header is reached. Each verified candidate header is tested against the full collection of tests listed in section 5.6.2.2 as would normally be the case. Verified candidate headers continue to be located and tested in this way for a minimum of 4352 bytes (twice the maximum length of an FCIP Frame). If all verified candidate headers encountered are valid, the last verified candidate header is a valid header. At this point the FCIP_DE stops discarding bytes and begins normal FCIP de-encapsulation begins, including for the first time since synchronization was lost, delivery of FC frames through the FC Transmitter Portal according to normal FCIP rules. If any verified candidate headers are invalid but meet all the requirements of a strong candidate header, increment the retry counter and return to step 2). If any verified candidate headers are invalid and fail to meet the tests for a strong candidate header, increment the retry counter and return to step 1. If the retry counter exceeds 4 retries, resynchronization has failed and the TCP/IP connection is closed. A flowchart for this algorithm can be found in figure 12. Rajagopal, et al. Standards Track [Page 47] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Synchronization is lost | _____________v_______________ | | | Search for candidate header | +----------->| | | | Found Not Found | | | (Strong candidate) | | |_____________________________| | | | | | + --------->close TCP/IP | _______v_____________________ Connection | | | | | Enough strong candidate | | +---->| headers identified? | | | | | | | | No Yes | | | | (Verified candidate) | | | |_____________________________| |___________________| | ^ | | | | | | | _______________________v_____ | | | | | | | Enough verified candidate | | | | headers validated? | | | | | | | | No Yes | | | | (Resynchronized) | | | |_____________________________| | | | | | | ______v__________ | Resume | | | | + ---> Normal | | | Synchronization | De-encapsulation | | | Lost? | | | | | | | | No Yes | | | |_________________| | | | | | |________| | |___________________________| Fig. 12 Flow diagram of simple synchronization example Rajagopal, et al. Standards Track [Page 48] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 ANNEX B - Relationship between FCIP and IP over FC (IPFC) The contents of this annex are informative. IPFC (RFC 2625) describes the encapsulation of IP packets in FC Frames. It is intended to facilitate IP communication over an FC network. FCIP describes the encapsulation of FC Frames in TCP segments which in turn are encapsulated inside IP packets for transporting over an IP network. It gives no consideration to the type of FC Frame that is being encapsulated. Therefore, the FC Frame may actually contain an IP packet as described in the IP over FC specification (RFC 2625). In such a case, the data packet would have: - Data Link Header - IP Header - TCP Header - FCIP Header - FC Header - IP Header Note: The two IP headers would not be identical to each other. One would have information pertaining to the final destination while the other would have information pertaining to the FCIP Entity. The two documents focus on different objectives. As mentioned above, implementation of FCIP will lead to IP encapsulation within IP. While perhaps inefficient, this should not lead to issues with IP communication. One caveat: if a Fibre Channel device is encapsulating IP packets in an FC Frame (e.g. an IPFC device), and that device is communicating with a device running IP over a non-FC medium, a second IPFC device may need to act as a gateway between the two networks. This scenario is not specifically addressed by FCIP. There is nothing in either of the specifications to prevent a single device from implementing both FCIP and IP-over-FC (IPFC), but this is implementation specific, and is beyond the scope of this document. ANNEX C - FC Frame Format The contents of this annex are informative. All FC Frames have a standard format (see FC-FS [6]) much like LAN's 802.x protocols. However, the exact size of each FC Frame varies depending on the size of the variable fields. The size of the variable field ranges from 0 to 2112-bytes as shown in the FC Frame Rajagopal, et al. Standards Track [Page 49] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Format in figure 13 resulting in the minimum size FC Frame of 36 bytes and the maximum size FC Frame of 2176 bytes. Valid FC Frame lengths are always a multiple of four bytes. +------+--------+-----------+----//-------+------+------+ | SOF |Frame |Optional | Frame | CRC | EOF | | (4B) |Header |Header | Payload | (4B) | (4B) | | |(24B) |<----------------------->| | | | | | Data Field = (0-2112B) | | | +------+--------+-----------+----//-------+------+------+ Fig. 13 FC Frame Format C.1 SOF and EOF Delimiters On an FC link, Start-of-Frame (SOF) and End-Of-Frame (EOF) are called Ordered Sets and are sent as special words constructed from the 8B/10B comma character (K28.5) followed by three additional 8B/ 10B data characters making them uniquely identifiable in the data stream. On an FC link the SOF delimiter serves to identify the beginning of an FC Frame and prepares the receiver for FC Frame reception. The SOF contains information about the FC Frame's Class of Service, position within a sequence, and in some cases, connection status. The EOF delimiter identifies the end of the FC Frame and the final FC Frame of a sequence. In addition, it serves to force the running disparity to negative. The EOF is used to end the connection in connection-oriented classes of service. A special EOF delimiter called EOFa (End Of Frame - Abort) is used to terminate a partial FC Frame resulting from a malfunction in a link facility during transmission. Since an FCIP Entity functions like a transmission link with respect to the rest of the FC Fabric, FCIP_DEs may use EOFa in their error recovery procedures. It is therefore important to preserve the information conveyed by the delimiters across the IP-based network, so that the receiving FCIP Entity can correctly reconstruct the FC Frame in its original SOF and EOF format before forwarding it to its ultimate FC destination on the FC link. When an FC Frame is encapsulated and sent over a byte-oriented interface, the SOF and EOF delimiters are represented as sequences of four consecutive bytes, which carry the equivalent Class of Service and FC Frame termination information as the FC ordered sets. The representation of SOF and EOF in an encapsulation FC Frame is Rajagopal, et al. Standards Track [Page 50] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 described in FC Frame Encapsulation [25]. C.2 Frame Header The FC Frame Header is transparent to the FCIP Entity. The FC Frame Header is 24 bytes long and has several fields that are associated with the identification and control of the payload. Current FC Standards allow up to 3 Optional Header fields [6]: - Network_Header (16-bytes) - Association_Header (32-bytes) - Device_Header (up to 64-bytes). C.3 Frame Payload The FC Frame Payload is transparent to the FCIP Entity. An FC application level payload is called an Information Unit at the FC-4 Level. This is mapped into the FC Frame Payload of the FC Frame. A large Information Unit is segmented using a structure consisting of FC Sequences. Typically, a Sequence consists of more than one FC Frame. FCIP does not maintain any state information regarding the relationship of FC Frames within a FC Sequence. C.4 CRC The FC CRC is 4 bytes long and uses the same 32-bit polynomial used in FDDI and is specified in ANSI X3.139 Fiber Distributed Data Interface. This CRC value is calculated over the entire FC header and the FC payload; it does not include the SOF and EOF delimiters. Note: When FC Frames are encapsulated into FCIP Frames, the FC Frame CRC is untouched by the FCIP Entity. ANNEX D - FC Encapsulation Format This annex contains a reproduction of the FC Encapsulation Format [25] as it applies to FCIP Frames. The information in this annex was correct as of the time this specification was approved. The information in this annex is informative only. If there are any differences between the information here and the FC Encapsulation Format specification [25], the FC Encapsulation Format specification takes precedence. If there are any differences between the information here and the contents of section 5.6.1, then the contents of section 5.6.1 take precedence. Rajagopal, et al. Standards Track [Page 51] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 Figure 14 applies the requirements stated in section 5.6.1 and in the FC Encapsulation Frame format resulting in a summary of the FCIP frame format. Where FCIP requires specific values, those values are shown in hexadecimal in parentheses. Detailed requirements for the FCIP usage of the FC Encapsulation Format are in section 5.6.1. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 1| Protocol# | Version | -Protocol# | -Version | | (0x01) | (0x01) | (0xFE) | (0xFE) | +---------------+---------------+---------------+---------------+ 2| pFlags | Reserved | -pFlags | -Reserved | | | (0x00) | | (0xFF) | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | | (0x00) | | (0x3F) | | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC (Reserved in FCIP) | | (0x00-00-00-00) | +---------------+---------------+---------------+---------------+ 7| SOF | SOF | -SOF | -SOF | +---------------+---------------+---------------+---------------+ 8| | +----- FC frame content (see annex C) -----+ | | +---------------+---------------+---------------+---------------+ n| EOF | EOF | -EOF | -EOF | +---------------+---------------+---------------+---------------+ Fig. 14 FCIP Frame Format The names of fields are generally descriptive on their contents and the FC Encapsulation Format specification [25] is referenced for details. Field names preceded by a minus sign are one's complement values of the named field. Rajagopal, et al. Standards Track [Page 52] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 ANNEX E - FCIP Requirements on an FC Entity The contents of this annex are informative for FCIP but might be considered normative on FC-BB-2. The capabilities that FCIP requires of an FC Entity include: 1) The FC Entity must deliver FC Frames to the correct FCIP Data Engine (in the correct FCIP Link Endpoint). 2) Each FC Frame delivered to an FCIP_DE must be accompanied by a time value synchronized with the clock maintained by the FC Entity at the other end of the FCIP Link (see section 6). If a synchronized time value is not available, a value of zero must accompany the FC Frame. 3) When FC Frames exit FCIP Data Engine(s) via the FC Transmitter Portal(s), the FC Entity should forward them to the FC Fabric. However, before forwarding a FC Frame the FC Entity must compute the end-to-end transit time for the FC Frame using the time value supplied by the FCIP_DE (taken from the FCIP header) and a synchronized time value (see section 6). If the end-to-end transit time exceeds the requirements of the FC Fabric, the FC Entity is responsible for discarding the FC Frame. 4) The only delivery ordering guarantee provided by FCIP is correctly ordered delivery of FC Frames between a pair of FCIP Data Engines. FCIP expects the FC Entity to implement all other FC Frame delivery ordering requirements. 5) The FC Entity may participate in determining allowed TCP Connections, TCP connection parameters, quality of service usage, and security usage by modifying interactions with the FCIP Entity that are modelled as a "shared" database in section 8.1.1. 6) The FC Entity may require the FCIP Entity to merge to FCIP_LEPs. 7) The FC Entity may require the FCIP Entity to perform TCP close requests. 8) The FC Entity may recover from connection failures. 9) The FC Entity must recover from events that the FCIP Entity cannot handle, such as: a) loss of synchronization with FCIP Frame headers from the Encapsulated Frame Receiver Portal requiring resetting the TCP Connection; Rajagopal, et al. Standards Track [Page 53] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 b) recovering from FCIP Frames that are discarded as a result of synchronization problems (see section 5.6.2.2 and section 5.6.2.3); c) additional examples, TBD 10) The FC Entity must work cooperatively with the FCIP Entity to manage flow control problems in either the IP Network or FC Fabric. 11) The FC Entity may test for failed TCP Connections. 12) TBD support for monitoring Note that the Fibre Channel standards must be consulted for a complete understanding of the requirements placed on an FC Entity. The following table shows the explicit interactions between the FCIP Entity and the FC Entity. +-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | 5.6 | FC Frame ready | | Provide FC | | FCIP Data | for IP transfer | | Frame and | | Engine | | | time stamp at | | | | | FC Receiver | | | | | Portal | +-------------+-----------------+-----------------+-----------------+ | 5.6 | FCIP Frame | Provide FC | | | FCIP Data | received from | Frame and | | | Engine | IP Network | time stamp at | | | | | FC Transmitter | | | | | Portal | | +-------------+-----------------+-----------------+-----------------+ | 5.6.2.2 | FCIP_DE | Inform FC | | | Errors | discards bytes | Entity that | | | in FCIP | delivered | bytes have been | | | Headers and | through | discarded with | | | Discarding | Encapsulated | reason code | | | FCIP Frames | Frame Receiver | | | | | Portal | | | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------------------------------------------------------------+ Rajagopal, et al. Standards Track [Page 54] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 +-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | continued | +-------------+-----------------+-----------------+-----------------+ | 8.1.3 | New TCP | Inform FC | | | Non-Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on "shared" | FCIP_LEP and | | | Connections | database | new FCIP_DE | | | | information | along with | | | | | Destination FC | | | | | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags and | | | | | Connection | | | | | Usage Code | | +-------------+-----------------+-----------------+-----------------+ | 8.1.4 | New TCP | Inform FC | | | Dynamic | Connection | Entity of | | | Creation of | created based | new or existing | | | a New TCP | on SLP service | FCIP_LEP and | | | Connections | advertisement | new FCIP_DE | | | | and "shared" | along with | | | | database | Destination FC | | | | information | Fabric Entity | | | | | WWN, Connection | | | | | Usage Flags and | | | | | Connection | | | | | Usage Code | | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ | continued | +-------------------------------------------------------------------+ Rajagopal, et al. Standards Track [Page 55] Internet-Draft Fibre Channel Over TCP/IP (FCIP) November, 2001 +-------------+-----------------+-----------------------------------+ | | | Information/Parameter Passed and | | | | Direction | | Reference | +-----------------+-----------------+ | Section | Condition | FCIP Entity---> | <---FC Entity | +-------------+-----------------+-----------------+-----------------+ | concluded | +-------------+-----------------+-----------------+-----------------+ | 8.1.5 | New TCP | Inform FC | | | Processing | Connection | Entity of | | | Incoming | created based | new or existing | | | TCP Connect | on incoming TCP | FCIP_LEP and | | | Requests | Connect request | new FCIP_DE | | | | and "shared" | along with | | | | database | Source FC | | | | information | Fabric Entity | | | | | WWN, Source | | | | | FC/FCIP Entity | | | | | Identifier, | | | | | Connection | | | | | Usage Flags | | | | | and Connection | | | | | Usage Code | | +-------------+-----------------+-----------------+-----------------+ | 8.2 | FC Entity | | Identifiers | | Merging | determines that | | for the two | | FCIP_LEPs | two FCIP_LEPs | | FCIP_LEPs to | | | are part of a | | be merged | | | common FCIP | | | | | Link | | | +-------------+-----------------+-----------------+-----------------+ | 8.3 | FC Entity | | Identification | | Closing TCP | determines | | of the FCIP_DE | | Connections | that a TCP | | whose TCP | | | Connection | | Connection | | | needs to be | | needs to be | | | closed | | closed | +-------------+-----------------+-----------------+-----------------+ | WWN = World Wide Name | +-------------------------------------------------------------------+ Rajagopal, et al. Standards Track [Page 56]