iFCP - A Protocol for Internet Fibre Channel Networking August 2002 IP Storage Working Group Charles Monia INTERNET DRAFT Rod Mullendore Expires February 2003 Document: draft-ietf-ips-ifcp-13.txt Nishan Systems Category: Standards Track Franco Travostino Nortel Networks Wayland Jeong Troika Networks Mark Edwards Eurologic August 2002 iFCP - A Protocol for Internet Fibre Channel Storage Networking Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [RFC2026]. 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 made obsolete 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/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the author(s). Monia, et al. Standards Track [Page 1] iFCP Revision 13 August 2002 Status of this Memo...................................................1 Comments..............................................................1 Abstract..............................................................5 Acknowledgements......................................................5 1. About This Document..........................................6 1.1 Conventions used in this document............................6 1.1.1 Data Structures Internal to an Implementation................6 1.2 Purpose of this document.....................................6 2. iFCP Introduction............................................6 2.1 Definitions..................................................7 3. Fibre Channel Communication Concepts.........................9 3.1 The Fibre Channel Network...................................10 3.2 Fibre Channel Network Topologies............................11 3.2.1 Switched Fibre Channel Fabrics..............................11 3.2.2 Mixed Fibre Channel Fabric..................................12 3.3 Fibre Channel Layers and Link Services......................13 3.3.1 Fabric-Supplied Link Services...............................14 3.4 Fibre Channel Nodes.........................................14 3.5 Fibre Channel Device Discovery..............................15 3.6 Fibre Channel Information Elements..........................15 3.7 Fibre Channel Frame Format..................................16 3.7.1 N_PORT Address Model........................................16 3.8 Fibre Channel Transport Services............................17 3.9 Login Processes.............................................18 4. The iFCP Network Model......................................18 4.1 iFCP Transport Services.....................................21 4.1.1 Fibre Channel Transport Services Supported by iFCP..........21 4.2 iFCP Device Discovery and Configuration Management..........21 4.3 iFCP Fabric Properties......................................21 4.3.1 Address Transparency........................................22 4.3.2 Configuration Scalability...................................22 4.3.3 Fault Tolerance.............................................23 4.4 The iFCP N_PORT Address Model...............................23 4.5 Operation in Address Transparent Mode.......................25 4.5.1 Transparent Mode Domain ID Management.......................25 4.5.2 Incompatibility with Address Translation Mode...............26 4.6 Operation in Address Translation Mode.......................26 4.6.1 Inbound Frame Address Translation...........................27 4.6.2 Incompatibility with Address Transparent Mode...............28 5. iFCP Protocol...............................................28 5.1 Overview....................................................28 5.1.1 iFCP Transport Services.....................................28 5.1.2 iFCP Support for Link Services..............................29 5.2 TCP Stream Transport of iFCP Frames.........................30 5.2.1 iFCP Session Model..........................................30 5.2.2 iFCP Session Management.....................................30 5.2.3 Terminating iFCP Sessions...................................37 5.3 Fibre Channel Frame Encapsulation...........................39 5.3.1 Encapsulation Header Format.................................39 5.3.2 SOF and EOF Delimiter Fields................................43 5.3.3 Frame Encapsulation.........................................44 5.3.4 Frame De-encapsulation......................................44 Monia et-al. Standards Track [Page 2] iFCP Revision 13 August 2002 6. TCP Session Control Messages................................45 6.1 Connection Bind (CBIND).....................................47 6.2 Unbind Connection (UNBIND)..................................50 6.3 LTEST -- Test Connection Liveness...........................52 7. Fibre Channel Link Services.................................53 7.1 Special Link Service Messages...............................54 7.2 Link Services Requiring Payload Address Translation.........56 7.3 Fibre Channel Link Services Processed by iFCP...............58 7.3.1 Special Extended Link Services..............................60 7.3.2 Special FC-4 Link Services..................................75 7.4 FLOGI Service Parameters Supported by an iFCP Gateway.......77 8. iFCP Error Detection........................................79 8.1 Overview....................................................79 8.2 Stale Frame Prevention......................................79 8.2.1 Enforcing R_A_TOV Limits....................................80 9. Fabric Services Supported by an iFCP implementation.........81 9.1 F_PORT Server...............................................82 9.2 Fabric Controller...........................................82 9.3 Directory/Name Server.......................................82 9.4 Broadcast Server............................................83 9.4.1 Establishing the Broadcast Configuration....................83 9.4.2 Broadcast Session Management................................84 9.4.3 Standby Global Broadcast Server.............................85 10. iFCP Security...............................................85 10.1 Overview....................................................85 10.2 iFCP Security Threats and Scope.............................85 10.2.1 Context.....................................................85 10.2.2 Security Threats............................................85 10.2.3 Interoperability with Security Gateways.....................86 10.2.4 Authentication..............................................86 10.2.5 Confidentiality.............................................86 10.2.6 Rekeying....................................................86 10.2.7 Authorization...............................................87 10.2.8 Policy control..............................................87 10.2.9 iSNS Role...................................................87 10.3 iFCP Security Design........................................87 10.3.1 Enabling Technologies.......................................87 10.3.2 Use of IKE and IPsec........................................89 10.3.3 Signatures and Certificate-based Authentication.............91 10.4 iSNS and iFCP Security......................................92 10.5 Use of iSNS to Distribute Security Policy...................92 10.6 Minimal Security Policy for an iFCP gateway.................92 11. Quality of Service Considerations...........................92 11.1 Minimal requirements........................................92 11.2 High-assurance..............................................93 12. IANA Considerations.........................................94 13. Author's Addresses..........................................94 14. Normative References........................................95 15. Non-Normative References....................................96 A. iFCP Support for Fibre Channel Link Services................99 A.1 Basic Link Services.........................................99 A.2 Pass-Through Link Services..................................99 Monia et-al. Standards Track [Page 3] iFCP Revision 13 August 2002 A.3 Special Link Services......................................100 B. Supporting the Fibre Channel Loop Topology.................102 B.1 Remote Control of a Public Loop............................102 Full Copyright Statement............................................103 Notice of Intellectual Property Rights..............................103 Monia et-al. Standards Track [Page 4] iFCP Revision 13 August 2002 Abstract This document specifies an architecture and gateway-to-gateway protocol for the implementation of fibre channel fabric functionality over an IP network. This functionality is provided through TCP protocols for fibre channel frame transport and the distributed fabric services specified by the fibre channel standards. The architecture enables internetworking of fibre channel devices through gateway-accessed regions having the fault isolation properties of autonomous systems and the scalability of the IP network. Acknowledgements The authors are indebted to those who contributed material or who took the time to carefully review and critique this specification including David Black (EMC), Rory Bolt (Quantum/ATL), Victor Firoiu (Nortel), Robert Peglar (XIOtech), David Robinson (Sun), Elizabeth Rodriguez, Joshua Tseng (Nishan), Naoke Watanabe (HDS) and members of the IPS working group. For review of the iFCP security policy, the authors are further indebted to the authors of the IPS security draft [SECIPS], which include Bernard Aboba (Microsoft), Ofer Biran (IBM), Uri Elzer (Broadcom), Charles Kunziger (IBM), Venkat Rangan (Rhapsody Networks), Julian Satran (IBM), Joseph Tardo (Broadcom), and Jesse Walker (Intel). Monia et-al. Standards Track [Page 5] iFCP Revision 13 August 2002 1. About This Document 1.1 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 [RFC2119]. Unless specified otherwise, numeric quantities are given as decimal values. All diagrams that portray bit and byte ordering, including the depiction of structures defined by fibre channel standards, adhere to the IETF conventions where bit 0 is the most significant bit and the first addressable byte is in the upper left hand corner. This IETF convention differs from that used for INCITS T11 fibre channel standards, in which bit 0 is the least significant bit. 1.1.1 Data Structures Internal to an Implementation To facilitate the specification of required behavior, this document may define and refer to internal data structures within an iFCP implementation. Such structures are intended for explanatory purposes only and need not be instantiated within an implementation as described in this specification. 1.2 Purpose of this document This is a standards-track document, which specifies a protocol for the implementation of fibre channel transport services on a TCP/IP network. Some portions of this document contain material from standards controlled by INCITS T10 and T11. This material is included here for informational purposes only. The authoritative information is given in the appropriate NCITS standards document. The authoritative portions of this document specify the mapping of standards-compliant fibre channel protocol implementations to TCP/IP. This mapping includes sections of this document which describe the "iFCP Protocol" (see section 5). 2. iFCP Introduction iFCP is a gateway-to-gateway protocol, which provides fibre channel fabric services to fibre channel devices over a TCP/IP network. iFCP uses TCP to provide congestion control, error detection and recovery. iFCP's primary objective is to allow interconnection and networking of existing fibre channel devices at wire speeds over an IP network. Monia et-al. Standards Track [Page 6] iFCP Revision 13 August 2002 The protocol and method of frame address translation described in this document permit the attachment of fibre channel storage devices to an IP-based fabric by means of transparent gateways. The protocol achieves this transparency by allowing normal fibre channel frame traffic to pass through the gateway directly, with provisions, where necessary, for intercepting and emulating the fabric services required by a fibre channel device. 2.1 Definitions Terms needed to describe the concepts presented in this document are presented here. Address-translation mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses for locally attached devices are local to the iFCP gateway region in which the devices reside. Address-transparent mode -- A mode of gateway operation in which the scope of N_PORT fabric addresses for all fibre channel devices are unique to the bounded iFCP fabric to which the gateway belongs. Bounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate together in address-transparent mode. DOMAIN_ID -- The value contained in the high-order byte of a 24-bit N_PORT fibre channel address. F_PORT -- The interface used by an N_PORT to access fibre channel switched fabric functionality. Fabric -- From [FC-FS]: "The entity which interconnects N_PORTs attached to it and is capable of routing frames by using only the address information in the fibre channel frame." Fabric Port -- The interface through which an N_PORT accesses a fibre channel fabric. The type of fabric port depends on the fibre channel fabric topology. In this specification, all fabric port interfaces are considered to be functionally equivalent. FC-2 -- The fibre channel transport services layer described in [FC-FS]. FC-4 -- The fibre channel mapping of an upper layer protocol, such as [FCP-2], the fibre channel to SCSI mapping. Fibre Channel Device -- An entity implementing the functionality Monia et-al. Standards Track [Page 7] iFCP Revision 13 August 2002 accessed through an FC-4 application protocol. Fibre Channel Network -- A native fibre channel fabric and all attached fibre channel nodes. Fibre Channel Node -- A collection of one or more N_PORTs controlled by a level above the FC-2 layer. A node is attached to a fibre channel fabric by means of the N_PORT interface described in [FC-FS]. Gateway Region -- The portion of an iFCP fabric accessed through an iFCP gateway by a remotely attached N_PORT. Fibre channel devices in the region consist of all those locally attached to the gateway. iFCP -- The protocol discussed in this document. iFCP Frame -- A fibre channel frame encapsulated in accordance with the FC Frame Encapsulation Specification [ENCAP] and this specification. iFCP Portal -- An entity representing the point at which a logical or physical iFCP device is attached to the IP network. The network address of the iFCP portal consists of the IP address and TCP port number to which a request is sent when creating the TCP connection for an iFCP session (see section 5.2.1). iFCP Session -- An association comprised of a pair of N_PORTs and a TCP connection that carries traffic between them. An iFCP session may be created as the result of a PLOGI fibre channel login operation. iSNS -- The server functionality and IP protocol that provide storage name services in an iFCP network. Fibre channel name services are implemented by an iSNS name server as described in [ISNS]. Locally Attached Device -- With respect to a gateway, a fibre channel device accessed through the fibre channel fabric to which the gateway is attached. Logical iFCP Device -- The abstraction representing a single fibre channel device as it appears on an iFCP network. N_PORT -- An iFCP or fibre channel entity representing the interface to fibre channel device functionality. This interface implements the fibre channel N_PORT semantics specified in [FC-FS]. Fibre channel defines several variants of this interface that depend on the fibre channel fabric topology. As used in this document, the term Monia et-al. Standards Track [Page 8] iFCP Revision 13 August 2002 applies equally to all variants. N_PORT Alias -- The N_PORT address assigned by a gateway to represent a remote N_PORT accessed via the iFCP protocol. N_PORT fabric address -- The address of an N_PORT within the fibre channel fabric. N_PORT ID -- The address of a locally attached N_PORT within a gateway region. N_PORT IDs are assigned in accordance with the fibre channel rules for address assignment specified in [FC-FS]. N_PORT Network Address -- The address of an N_PORT in the iFCP fabric. This address consists of the IP address and TCP port number of the iFCP Portal and the N_PORT ID of the locally attached fibre channel device. Port Login (PLOGI) -- The fibre channel Extended Link Service (ELS) that establishes an iFCP session through the exchange of identification and operation parameters between an originating N_PORT and a responding N_PORT. Remotely Attached Device -- With respect to a gateway, a fibre channel device accessed from the gateway by means of the iFCP protocol. Unbounded iFCP Fabric -- The union of two or more gateway regions configured to interoperate together in address-translation mode. 3. Fibre Channel Communication Concepts Fibre channel is a frame-based, serial technology designed for peer-to-peer communication between devices at gigabit speeds and with low overhead and latency. This section contains a discussion of the fibre channel concepts that form the basis for the iFCP network architecture and protocol described in this document. Readers familiar with this material may skip to section 4. Material presented in this section is drawn from the following T11 specifications: -- The Fibre Channel Framing and Signaling Interface, [FC-FS] -- Fibre Channel Switch Fabric -2, [FC-SW2] -- Fibre Channel Generic Services, [FC-GS3] Monia et-al. Standards Track [Page 9] iFCP Revision 13 August 2002 -- Fibre Channel Fabric Loop Attachment, [FC-FLA] The reader will find an in-depth treatment of the technology in [KEMCMP] and [KEMALP]. 3.1 The Fibre Channel Network The fundamental entity in fibre channel is the fibre channel network. Unlike a layered network architecture, a fibre channel network is largely specified by functional elements and the interfaces between them. As shown in Figure 1, these consist, in part, of the following: a) N_PORTs -- The end points for fibre channel traffic. In the FC standards, N_PORT interfaces have several variants, depending on the topology of the fabric to which they are attached. As used in this specification, the term applies to any one of the variants. b) FC Devices -- The fibre channel devices to which the N_PORTs provide access. c) Fabric Ports -- The interfaces within a fibre channel network that provide attachment for an N_PORT. The types of fabric port depend on the fabric topology and are discussed in section 3.2. d) The network infrastructure for carrying frame traffic between N_PORTs. e) Within a switched or mixed fabric (see section 3.2), a set of auxiliary servers, including a name server for device discovery and network address resolution. The types of service depend on the network topology. +--------+ +--------+ +--------+ +--------+ | FC | | FC | | FC | | FC | | Device | | Device |<-------->| Device | | Device | |........| |........| |........| |........| | N_PORT | | N_PORT | | N_PORT | | N_PORT | +---+----+ +----+---+ +----+---+ +----+---+ | | | | +---+----+ +----+---+ +----+---+ +----+---+ | Fabric | | Fabric | | Fabric | | Fabric | | Port | | Port | | Port | | Port | +========+===+========+==========+========+==+========+ | Fabric | | & | | Fabric Services | +-----------------------------------------------------+ Figure 1 -- A Fibre Channel Network Monia et-al. Standards Track [Page 10] iFCP Revision 13 August 2002 The following sections describe fibre channel network topologies and give an overview of the fibre channel communications model. 3.2 Fibre Channel Network Topologies The principal fibre channel network topologies consist of the following: a) Arbitrated Loop -- A series of N_PORTs connected together in daisy-chain fashion. In [FC-FS], loop-connected N_PORTs are referred to as NL_PORTs. Data transmission between NL_PORTs requires arbitration for control of the loop in a manner similar to a token ring network. b) Switched Fabric -- A network consisting of switching elements, as described in section 3.2.1. c) Mixed Fabric -- A network consisting of switches and "fabric- attached" loops. A description can be found in [FC-FLA]. A loop-attached N_PORT (NL_PORT), is connected to the loop through an L_PORT and accesses the fabric by way of an FL_PORT. Depending on the topology, the N_PORT and its means of network attachment may be one of the following: FC Network Network Interface N_PORT Variant Topology ----------------- -------------- --------------- Loop L_PORT NL_PORT Switched F_PORT N_PORT Mixed FL_PORT via L_PORT NL_PORT F_PORT N_PORT The differences in each N_PORT variant and its corresponding fabric port are confined to the interactions between them. To an external N_PORT, all fabric ports are transparent and all remote N_PORTs are functionally identical. 3.2.1 Switched Fibre Channel Fabrics An example of a multi-switch fibre channel fabric is shown in Figure 2. Monia et-al. Standards Track [Page 11] iFCP Revision 13 August 2002 +----------+ +----------+ | FC | | FC | | Device | | Device | |..........| |..........| | N_PORT |<........>| N_PORT | +----+-----+ +-----+----+ | | +----+-----+ +-----+----+ | F_PORT | | F_PORT | ==========+==========+==========+==========+============== | FC | | FC | | Switch | | Switch | +----------+ +----------+ Fibre Channel |Inter- | |Inter- | Fabric |Switch | |Switch | |Interface | |Interface | +-----+----+ +-----+----+ | | | | +-----+----+----------+-----+----+ |Inter- | |Inter- | |Switch | |Switch | |Interface | |Interface | +----------+ +----------+ | FC Switch | | | +--------------------------------+ Figure 2 -- Multi-Switch Fibre Channel Fabric The interface between switch elements is either proprietary or the standards-compliant E_PORT interface described by the FC-SW2 specification, [FC-SW2]. 3.2.2 Mixed Fibre Channel Fabric A mixed fabric contains one or more arbitrated loops connected to a switched fabric as shown in Figure 3. Monia et-al. Standards Track [Page 12] iFCP Revision 13 August 2002 +----------+ +----------+ +---------+ | FC | | FC | | FC | | Device | | Device | | Device | |..........| FC |..........| |.........| | N_PORT |<........>| NL_PORT +---+ NL_PORT | +----+-----+ Traffic +-----+----+ +----+----+ | | FC Loop | +----+-----+ +-----+----+ | | F_PORT | | FL_PORT +--------+ | | | | ==========+==========+==========+==========+============== | FC | | FC | | Switch | | Switch | +----------+ +----------+ |Inter- | |Inter- | |Switch | |Switch | |Interface | |Interface | +-----+----+ +-----+----+ | | | | +-----+----+----------+-----+----+ |Inter- | |Inter- | |Switch | |Switch | |Interface | |Interface | +----------+ +----------+ | FC Switch | | | +--------------------------------+ Figure 3 -- Mixed Fibre Channel Fabric As noted previously, the protocol for communications between peer N_PORTs is independent of the fabric topology, N_PORT variant and type of fabric port to which an N_PORT is attached. 3.3 Fibre Channel Layers and Link Services Fibre channel consists of the following layers: FC-0 -- The interface to the physical media, FC-1 -- The encoding and decoding of data and out-of-band physical link control information for transmission over the physical media, FC-2 -- The transfer of frames, sequences and Exchanges comprising protocol information units. FC-3 -- Common Services, FC-4 -- Application protocols such as the fibre channel protocol for SCSI (FCP). Monia et-al. Standards Track [Page 13] iFCP Revision 13 August 2002 In addition to the layers defined above, fibre channel defines a set of auxiliary operations, some of which are implemented within the transport layer fabric, called link services. These are required to manage the fibre channel environment, establish communications with other devices, retrieve error information, perform error recovery and other similar services. Some link services are executed by the N_PORT. Others are implemented internally within the fabric. These internal services are described in the next section. 3.3.1 Fabric-Supplied Link Services Servers internal to a switched fabric handle certain classes of Link Service requests and service-specific commands. The servers appear as N_PORTs located at the 'well-known' N_PORT fabric addresses specified in [FC-FS]. Service requests use the standard fibre channel mechanisms for N_PORT-to-N_PORT communications. All switched fabrics must provide the following services: Fabric F_PORT server -- Services N_PORT requests to access the fabric for communications. Fabric Controller -- Provides state change information to inform other FC devices when an N_PORT exits or enters the fabric (see section 3.5). Directory/Name Server - Allows N_PORTs to register information in a database, retrieve information about other N_PORTs and discover other devices as described in section 3.5. A switched fabric may also implement the following optional services: Broadcast Address/Server -- Transmits single-frame, class 3 sequences to all N_PORTs. Time Server -- Intended for the management of fabric-wide expiration timers or elapsed time values and not intended for precise time synchronization. Management Server - Collects and reports management information, such as link usage, error statistics, link quality and similar items. Quality of Service Facilitator - Performs fabric-wide bandwidth and latency management. 3.4 Fibre Channel Nodes A fibre channel node has one or more fabric-attached N_PORTs. The node and its N_PORTs have the following associated identifiers: Monia et-al. Standards Track [Page 14] iFCP Revision 13 August 2002 a) A worldwide unique identifier for the node, b) A worldwide unique identifier for each N_PORT associated with the node, c) For each N_PORT attached to a fabric, a 24-bit fabric-unique address having the properties defined in section 3.7.1. The fabric address is the address to which frames are sent. Each worldwide unique identifier is a 64-bit binary quantity having the format defined in [FC-FS]. 3.5 Fibre Channel Device Discovery In a switched or mixed fabric, fibre channel devices and changes in the device configuration may be discovered by means of services provided by the fibre channel Name Server and Fabric Controller. The Name Server provides registration and query services that allow a fibre channel device to register its presence on the fabric and discover the existence of other devices. For example, one type of query obtains the fabric address of an N_PORT from its 64-bit worldwide unique name. The full set of supported fibre channel name server queries is specified in [FC-GS3]. The Fabric Controller complements the static discovery capabilities provided by the Name Server through a service that dynamically alerts a fibre channel device whenever an N_PORT is added or removed from the configuration. A fibre channel device receives these notifications by subscribing to the service as specified in [FC-FS]. 3.6 Fibre Channel Information Elements The fundamental element of information in fibre channel is the frame. A frame consists of a fixed header and up to 2112 bytes of payload having the structure described in section 3.7. The maximum frame size that may be transmitted between a pair of fibre channel devices is negotiable up to the payload limit, based on the size of the frame buffers in each fibre channel device and the path maximum transmission unit (MTU) supported by the fabric. Operations involving the transfer of information between N_PORT pairs are performed through 'Exchanges'. In an Exchange, information is transferred in one or more ordered series of frames referred to as Sequences. Within this framework, an upper layer protocol is defined in terms of transactions carried by Exchanges. Each transaction, in turn, consists of protocol information units, each of which is carried by an individual Sequence within an Exchange. Monia et-al. Standards Track [Page 15] iFCP Revision 13 August 2002 3.7 Fibre Channel Frame Format A fibre channel frame consists of a header, payload and 32-bit CRC bracketed by SOF and EOF delimiters. The header contains the control information necessary to route frames between N_PORTs and manage Exchanges and Sequences. The following diagram gives a schematic view of the frame. Bit 0 31 +-----------------------------+ Word 0 | Start-of-frame Delimiter | +-----+-----------------------+<----+ | | Destination N_PORT | | 1 | | Fabric Address (D_ID) | | | | (24 bits) | | +-----+-----------------------+ 24-byte | | Source N_PORT | Frame 2 | | Fabric Address (S_ID) | Header | | (24 bits) | | +-----+-----------------------+ | 3 | Control information for | | . | frame type, Exchange | | . | management, IU | | . | segmentation and | | 6 | re-assembly | | +-----------------------------+<----+ 7 | | . | Frame payload | . | (0 - 2112 bytes) | . | | . | | . | | +-----------------------------+ . | CRC | +-----------------------------+ n | End-of-Frame Delimiter | +-----------------------------+ Figure 4 -- Fibre Channel Frame Format The source and destination N_PORT fabric addresses embedded in the S_ID and D_ID fields represent the physical addresses of originating and receiving N_PORTs respectively. 3.7.1 N_PORT Address Model N_PORT fabric addresses are 24-bit values having the following format defined by the fibre channel specification [FC-FS]: Monia et-al. Standards Track [Page 16] iFCP Revision 13 August 2002 Bit 0 7 8 15 16 23 +-----------+------------+----------+ | Domain ID | Area ID | Port ID | +-----------+------------+----------+ Figure 5 -- Fibre Channel Address Format A fibre channel device acquires an address when it logs into the fabric. Such addresses are volatile and subject to change based on modifications in the fabric configuration. In a fibre channel fabric, each switch element has a unique Domain ID assigned by the principal switch. The value of the Domain ID ranges from 1 to 239 (0xEF). Each switch element, in turn, administers a block of addresses divided into area and port IDs. An N_PORT connected to a F_PORT receives a unique fabric address consisting of the switchÆs Domain ID concatenated with switch- assigned area and port IDs. A loop-attached NL_PORT (see Figure 3) obtains the Port ID component of its address during the loop initialization process described in [FC-AL2]. The area and domain IDs are supplied by the fabric when the fabric login (FLOGI) is executed. 3.8 Fibre Channel Transport Services N_PORTs communicate by means of the following classes of service specified in the fibre channel standard ([FC-FS]): Class 1 - A dedicated physical circuit connecting two N_PORTs. Class 2 - A frame-multiplexed connection with end-to-end flow control and delivery confirmation. Class 3 - A frame-multiplexed connection with no provisions for end-to-end flow control or delivery confirmation. Class 4 -- A connection-oriented service, based on a virtual circuit model, providing confirmed delivery with bandwidth and latency guarantees. Class 6 -- A reliable multicast service derived from class 1. Class 2 and class 3 are the predominant services supported by deployed fibre channel storage and clustering systems. Class 3 service is similar to UDP or IP datagram service. Fibre channel storage devices using this class of service rely on the ULP implementation to detect and recover from transient device and transport errors. For class 2 and class 3 service, the fibre channel fabric is not required to provide in-order delivery of frames unless explicitly Monia et-al. Standards Track [Page 17] iFCP Revision 13 August 2002 requested by the frame originator (and supported by the fabric). If ordered delivery is not in effect, it is the responsibility of the frame recipient to reconstruct the order in which frames were sent based on information in the frame header. 3.9 Login Processes The Login processes are FC-2 operations that allow an N_PORT to establish the operating environment necessary to communicate with the fabric, other N_PORTs and ULP implementations accessed via the N_PORT. Three login operations are supported: a) Fabric Login (FLOGI) -- An operation whereby the N_PORT registers its presence on the fabric, obtains fabric parameters such as classes of service supported, and receives its N_PORT address, b) Port Login (PLOGI) -- An operation by which an N_PORT establishes communication with another N_PORT. c) Process Login (PRLOGI) -- An operation which establishes the process-to-process communications associated with a specific FC-4 ULP -- such as FCP-2, the fibre channel SCSI mapping. Since N_PORT addresses are volatile, an N_PORT originating a login (PLOGI) operation executes a Name Server query to discover the fibre channel address of the remote device. A common query type involves use of the worldwide unique name of an N_PORT to obtain the 24-bit N_PORT fibre channel address to which the PLOGI request is sent. 4. The iFCP Network Model The iFCP protocol enables the implementation of fibre channel fabric functionality on an IP network in which IP components and technology replace the fibre channel switching and routing infrastructure described in section 3.2. The example of Figure 6 shows a fibre channel network with attached devices. Each device accesses the network through an N_PORT connected to an interface whose behavior is specified in [FC-FS] or [FC-AL2]. In this case, the N_PORT represents any of the variants described in section 3.2. The interface to the fabric may be an L_PORT, F_PORT or FL_PORT. Within the fibre channel device domain, addressable entities consist of other N_PORTs and fibre channel devices internal to the network that perform the fabric services defined in [FC-GS3]. Monia et-al. Standards Track [Page 18] iFCP Revision 13 August 2002 Fibre Channel Network +--------+ +--------+ | FC | | FC | | Device | | Device | |........| FC |........| Fibre Channel | N_PORT |<......>| N_PORT | Device Domain +---+----+ Traffic+----+---+ ^ | | | +---+----+ +----+---+ | | Fabric | | Fabric | | | Port | | Port | | ==========+========+========+========+============== | FC Network & | | | Fabric Services | v | | Fibre Channel +--------------------------+ Network Domain Figure 6 -- A Fibre Channel Network Gateway Region Gateway Region +--------+ +--------+ +--------+ +--------+ | FC | | FC | | FC | | FC | | Device | | Device | | Device | | Device | Fibre |........| |........| FC |........| |........| Channel | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain | | | | ^ +---+----+ +---+----+ +----+---+ +----+---+ | | F_PORT | | F_PORT | | F_PORT | | F_PORT | | =+========+==+========+===========+========+==+========+========== | iFCP Layer |<--------->| iFCP Layer | | |....................| ^ |....................| | | iFCP Portal | | | iFCP Portal | v +--------+-----------+ | +----------+---------+ IP iFCP|Gateway Control iFCP|Gateway Network | Data | | | | | |<------Encapsulated Frames------->| | +------------------+ | | | | | +------+ IP Network +--------+ | | +------------------+ Figure 7 -- An iFCP Fabric Example One example of an equivalent iFCP fabric is shown in Figure 7. The fabric consists of two gateway regions, each accessed by a single iFCP gateway. Monia et-al. Standards Track [Page 19] iFCP Revision 13 August 2002 Each gateway contains two standards-compliant F_PORTs and an iFCP Portal for attachment to the IP network. Fibre channel devices in the region are those locally connected to the iFCP fabric through the gateway fabric ports. Looking into the fabric port, the gateway appears as a fibre channel switch element. At this interface, remote N_PORTs are presented as fabric-attached devices. Conversely, on the IP network side, the gateway presents each locally connected N_PORT as a logical fibre channel device. Extrapolating to the general case, each gateway region behaves like an autonomous system whose configuration is invisible to the IP network and other gateway regions. Consequently, in addition to the F_PORT shown in the example, a gateway implementation may transparently support the following fibre channel interfaces: Inter-Switch Link -- A fibre channel switch-to-switch interface used to access a region containing fibre channel switch elements. An implementation may support the E_PORT defined by [FC-SW2] or one of the proprietary interfaces provided by various fibre channel switch vendors. In this case, the gateway acts as a border switch connecting the gateway region to the IP network. FL_PORT -- An interface that provides fabric access for loop- attached fibre channel devices as specified in [FC-FLA]. L_PORT -- An interface through which a gateway may emulate the fibre channel loop environment specified in [FC-AL2]. As discussed in appendix B, the gateway presents remotely accessed N_PORTS as loop-attached devices. The manner in which these interfaces are provided by a gateway is implementation-specific and therefore beyond the scope of this document. Although each region is connected to the IP network through one gateway, a region may incorporate multiple gateways for added performance and fault tolerance. To do so: a) The gateways MUST coordinate the assignment of N_PORT IDs and aliases such that each N_PORT has one and only one address and b) All iFCP traffic between a given remote and local N_PORT pair MUST flow through the same iFCP session (see section 5.2.1). However, iFCP sessions to a given remotely attached N_PORT need not traverse the same gateway. Coordinating address assignments and managing the flow of traffic is implementation-specific and outside the scope of this specification. Monia et-al. Standards Track [Page 20] iFCP Revision 13 August 2002 4.1 iFCP Transport Services N_PORT to N_PORT communications that traverse a TCP/IP network require the intervention of the iFCP layer within the gateway. This consists of the following operations: a) Execution of the frame addressing and mapping functions described in section 4.4. b) Encapsulation of fibre channel frames for injection into the TCP/IP network and de-encapsulation of fibre channel frames received from the TCP/IP network. c) Establishment of an iFCP session in response to a PLOGI directed to a remote device. Section 4.4 discusses the iFCP frame addressing mechanism and the way in which it is used to achieve communications transparency between N_PORTs. 4.1.1 Fibre Channel Transport Services Supported by iFCP An iFCP fabric supports Class 2 and Class 3 fibre channel transport services as specified in [FC-FS]. An iFCP fabric does not support class 4, class 6 or the Class 1 (dedicated connection) service. An N_PORT discovers the classes of transport services supported by the fabric during fabric login. 4.2 iFCP Device Discovery and Configuration Management An iFCP implementation performs device discovery and iFCP fabric management through the Internet Storage Name Service defined in [ISNS]. Access to an iSNS server is required to perform the following functions: a) Emulate the services provided by the fibre channel name server described in section 3.3.1, including a mechanism for asynchronously notifying an N_PORT of changes in the iFCP fabric configuration, b) Aggregate gateways into iFCP fabrics for interoperation, c) Segment an iFCP fabric into fibre channel zones through the definition and management of device discovery scopes, referred to as 'discovery domains', d) Store and distribute security policies as described in section 10.2.9. e) Implementation of the fibre channel broadcast mechanism. 4.3 iFCP Fabric Properties Monia et-al. Standards Track [Page 21] iFCP Revision 13 August 2002 A collection of iFCP gateways may be configured for interoperation as either a bounded or unbounded iFCP fabric. Gateways in a bounded iFCP fabric operate in address transparent mode as described in section 4.5. In this mode, the scope of a fibre channel N_PORT address is fabric-wide and is derived from domain IDs issued by the iSNS server from a common pool. As discussed in section 4.3.2, the maximum number of domain IDs allowed by fibre channel limits the configuration of a bounded iFCP fabric. Gateways in an unbounded iFCP fabric operate in address translation mode as described in section 4.6. In this mode, the scope of an N_PORT address is local to a gateway region. For fibre channel traffic between regions, the translation of frame-embedded N_PORT addresses is performed by the gateway. As discussed below, the number of switch elements and gateways in an unbounded iFCP fabric may exceed the limits of a conventional fibre channel fabric. All iFCP gateways MUST support unbounded iFCP fabrics. Support for bounded iFCP fabrics is OPTIONAL. The decision to support bounded iFCP fabrics in a gateway implementation depends on the address transparency, configuration scalability, and fault tolerance considerations given in the following sections. 4.3.1 Address Transparency Although iFCP gateways in an unbounded fabric will convert N_PORT addresses in the frame header and payload of standard link service messages, a gateway cannot convert such addresses in the payload of vendor- or user-specific fibre channel frame traffic. Consequently, while both bounded and unbounded iFCP fabrics support standards-compliant FC-4 protocol implementations and link services used by mainstream fibre channel applications, a bounded iFCP fabric may also support vendor- or user-specific protocol and link service implementations that carry N_PORT IDs in the frame payload. 4.3.2 Configuration Scalability The scalability limits of a bounded fabric configuration are a consequence of the fibre channel address allocation policy discussed in section 3.7.1. As noted, a bounded iFCP fabric using this address allocation scheme is limited to a combined total of 239 gateways and fibre channel switch elements. As the system expands, the network may grow to include many switch elements and gateways, each of which controls a small number of devices. In this case, the limitation in switch and gateway count may become a barrier to extending and fully integrating the storage network. Monia et-al. Standards Track [Page 22] iFCP Revision 13 August 2002 Since N_PORT fibre channel addresses in an unbounded iFCP fabric are not fabric-wide, the limits imposed by fibre channel address allocation only apply within the gateway region. Across regions, the number of iFCP gateways, fibre channel devices and switch elements that may be internetworked are not constrained by these limits. In exchange for improved scalability, however, implementations must consider the incremental overhead of address conversion as well as the address transparency issues discussed in section 4.3.1. 4.3.3 Fault Tolerance In a bounded iFCP fabric, address reassignment caused by a fault or reconfiguration, such as the addition of a new gateway region, may cascade to other regions, causing fabric-wide disruption as new N_PORT addresses are assigned. Furthermore, before a new gateway can be merged into the fabric, its iSNS server must be slaved to the iSNS server in the bounded fabric to centralize the issuance of domain IDs. In an unbounded iFCP fabric coordinating the iSNS databases requires only that the iSNS servers exchange client attributes with one another. A bounded iFCP fabric also has an increased dependency on the availability of the iSNS server, which must act as the central address assignment authority. If connectivity with the server is lost, new DOMAIN_ID values cannot be automatically allocated as gateways and fibre channel switch elements are added. 4.4 The iFCP N_PORT Address Model This section discusses iFCP extensions to the fibre channel addressing model of section 3.7.1, which are required for the transparent routing of frames between locally and remotely attached N_PORTs. In the iFCP protocol an N_PORT is represented by the following addresses: a) A 24-bit N_PORT ID. The fibre channel N_PORT address of a locally attached device. Depending on the gateway addressing mode, the scope is either local to a region or a bounded iFCP fabric. In either mode, communications between N_PORTs in the same gateway region use the N_PORT ID. b) A 24-bit N_PORT alias. The fibre channel N_PORT address assigned by each gateway operating in address translation mode to identify a remotely attached N_PORT. Frame traffic is intercepted by an iFCP gateway and directed to a remotely attached N_PORT by means of the N_PORT alias. The address assigned by each gateway is unique within the scope of the gateway region. Monia et-al. Standards Track [Page 23] iFCP Revision 13 August 2002 c) An N_PORT network address. A tuple consisting of the gateway IP address, TCP port number and N_PORT ID. The N_PORT network address identifies the source and destination N_PORTs for fibre channel traffic on the IP network. To provide transparent communications between a remote and local N_PORT, a gateway MUST maintain an iFCP session descriptor (see section 5.2.2.2) reflecting the association between the fibre channel address representing the remote N_PORT and the remote device's N_PORT network address. To establish this association the iFCP gateway assigns and manages fibre channel N_PORT fabric addresses as described in the following paragraphs. In an iFCP fabric, the iFCP gateway performs the address assignment and frame routing functions of an FC switch element. Unlike an FC switch, however, an iFCP gateway must also direct frames to external devices attached to remote gateways on the IP network. In order to be transparent to FC devices, the gateway must deliver such frames using only the 24-bit destination address in the frame header. By exploiting its control of address allocation and access to frame traffic entering or leaving the gateway region, the gateway is able to achieve the necessary transparency. N_PORT addresses within a gateway region may be allocated in one of two ways: a) Address Translation Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique to the gateway region. The address of a remote device is represented in that gateway region by its gateway-assigned N_PORT alias. b) Address Transparent Mode - A mode of N_PORT address assignment in which the scope of an N_PORT fibre channel address is unique across the set of gateway regions comprising a bounded iFCP fabric. In address transparent mode, gateways within a bounded fabric cooperate in the assignment of addresses to locally attached N_PORTs. Each gateway in control of a region is responsible for obtaining and distributing unique domain IDs from the address assignment authority as described in section 4.5.1. Consequently, within the scope of a bounded fabric, the address of each N_PORT is unique. For that reason, gateway-assigned aliases are not required to represent remote N_PORTs. All iFCP implementations MUST support operation in address translation mode. Implementation of address transparent mode is OPTIONAL but, of course, must be provided if bounded iFCP fabric configurations are to be supported. Monia et-al. Standards Track [Page 24] iFCP Revision 13 August 2002 The mode of gateway operation is settable in an implementation- specific manner. The implementation MUST NOT: a) Allow the mode to be changed after the gateway begins processing fibre channel frame traffic b) Permit operation in more than one mode at a time or c) Establish an iFCP session with a gateway that is not in the same mode. 4.5 Operation in Address Transparent Mode The following considerations and requirements apply to this mode of operation: a) iFCP gateways in address transparent mode will not interoperate with iFCP gateways that are not in address transparent mode. b) When interoperating with locally attached fibre channel switch elements, each iFCP gateway MUST assume control of DOMAIN_ID assignments in accordance with the appropriate fibre channel standard or vendor-specific protocol specification. As described in section 4.5.1, DOMAIN_ID values assigned to FC switches internal to the gateway region must be issued by the iSNS server. c) When operating in address transparent Mode, fibre channel address translation SHALL NOT take place. When operating in address transparent mode, however, the gateway MUST establish and maintain the context of each iFCP session in accordance with section 5.2.2. 4.5.1 Transparent Mode Domain ID Management As described in section 4.5, each gateway and fibre channel switch in a bounded iFCP fabric has a unique domain ID. In a gateway region containing fibre channel switch elements, each element obtains a domain ID by querying the principal switch as described in [FC-SW2] -- in this case the iFCP gateway itself. The gateway in turn obtains domain IDs on demand from the iSNS name server acting as the central address allocation authority. In effect, the iSNS server assumes the role of principal switch for the bounded fabric. In that case, the iSNS database contains: a) The definition for one or more bounded iFCP fabrics, b) For each bounded fabric, a worldwide unique name identifying each gateway in the fabric. A gateway in address transparent mode MUST reside in one and only one bounded fabric. Monia et-al. Standards Track [Page 25] iFCP Revision 13 August 2002 As the Principal Switch within the gateway region, an iFCP gateway in address transparent mode SHALL obtain domain IDs for use in the gateway region by issuing the appropriate iSNS query using its worldwide name. 4.5.2 Incompatibility with Address Translation Mode Except for the session control frames specified in section 6, iFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRP bit set to one in the iFCP flags field of the encapsulation header (see section 5.3.1). The iFCP gateway SHALL immediately terminate all iFCP sessions with the iFCP gateway from which it receives such frames. 4.6 Operation in Address Translation Mode This section describes the process for managing the assignment of addresses within a gateway region that is part of an unbounded iFCP fabric, including the modification of FC frame addresses embedded in the frame header for frames sent and received from remotely attached N_PORTs. As described in section 4.4, the scope of N_PORT addresses in this mode is local to the gateway region. A principal switch within the gateway region, possibly the iFCP gateway itself, oversees the assignment of such addresses in accordance with the rules specified in [FC-FS] and [FC-FLA]. The assignment of N_PORT addresses to locally attached devices is controlled by the switch element to which the device is connected. The assignment of N_PORT addresses for remotely attached devices is controlled by the gateway through which the remote device is accessed. In this case, the gateway MUST assign a locally significant N_PORT alias to be used in place of the N_PORT ID assigned by the remote gateway. The N_PORT alias is assigned during device discovery as described in section 5.2.2.1. To perform address conversion and enable the appropriate routing, the gateway MUST establish an iFCP session and generate the information required to map each N_PORT alias to the appropriate TCP/IP connection context and N_PORT ID of the remotely accessed N_PORT. The means by which these mappings are created and updated are specified in section 5.2.2.2. As described in that section, the required mapping information is represented by the iFCP session descriptor reproduced in Figure 8. Monia et-al. Standards Track [Page 26] iFCP Revision 13 August 2002 +-----------------------+ |TCP Connection Context | +-----------------------+ | Local N_PORT ID | +-----------------------+ | Remote N_PORT ID | +-----------------------+ | Remote N_PORT Alias | +-----------------------+ Figure 8 -- iFCP Session Descriptor (from section 5.2.2.2) Except for frames comprising special link service messages (see section 7.2), outbound frames are encapsulated and sent without modification. Address translation is deferred until receipt from the IP network as specified in section 4.6.1. 4.6.1 Inbound Frame Address Translation For inbound frames received from the IP network, the receiving gateway SHALL reference the session descriptor to fill in the D_ID field with the destination N_PORT ID and the S_ID field with the N_PORT alias it assigned. The translation process for inbound frames is shown in Figure 9. Monia et-al. Standards Track [Page 27] iFCP Revision 13 August 2002 Network Format of Inbound Frame +--------------------------------------------+ iFCP | FC Encapsulation Header | Session +--------------------------------------------+ Descriptor | SOF Delimiter Word | | +========+===================================+ V | | D_ID Field | +--------+-----+ +--------+-----------------------------------+ | Lookup source| | | S_ID Field | | N_PORT Alias | +--------+-----------------------------------+ | and | | Control Information, Payload | | destination | | and FC CRC | | N_PORT ID | | | +--------+-----+ | | | | | | +============================================+ | | EOF Delimiter Word | | +--------------------------------------------+ | | | Frame after Address Translation and De-encapsulation | +--------+-----------------------------------+ | | | Destination N_PORT ID |<-------------+ +--------+-----------------------------------+ | | | Source N_PORT Alias |<-------------+ +--------+-----------------------------------+ | | | Control information, Payload, | | and FC CRC | +--------------------------------------------+ Figure 9 -- Inbound Frame Address Translation The receiving gateway SHALL consider the contents of the S_ID and D_ID fields to be undefined when received. After replacing these fields, the gateway MUST recalculate the FC CRC. 4.6.2 Incompatibility with Address Transparent Mode iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRP bit set to one in the iFCP flags field of the encapsulation header. The iFCP gateway SHALL immediately abort all iFCP sessions with the iFCP gateway from which it receives such frames as described in section 5.2.3. 5. iFCP Protocol 5.1 Overview 5.1.1 iFCP Transport Services The main function of the iFCP protocol layer is to transport fibre channel frame images between locally and remotely attached N_PORTs. Monia et-al. Standards Track [Page 28] iFCP Revision 13 August 2002 When transporting frames to a remote N_PORT, the iFCP layer encapsulates and routes the fibre channel frames comprising each fibre channel Information Unit via a predetermined TCP connection for transport across the IP network. When receiving fibre channel frame images from the IP network, the iFCP layer de-encapsulates and delivers each frame to the appropriate N_PORT. The iFCP layer processes the following types of traffic: a) FC-4 frame images associated with a fibre channel application protocol. b) FC-2 frames comprising fibre channel link service requests and responses c) Fibre channel broadcast frames d) iFCP control messages required to setup, manage or terminate an iFCP session. For FC-4 N_PORT traffic and most FC-2 messages the iFCP layer never interprets the contents of the frame payload. iFCP does interpret and process iFCP control messages and certain link service messages as described in section 5.1.2 5.1.2 iFCP Support for Link Services iFCP must intervene in the processing of those fibre channel link service messages that contain N_PORT addresses in the message payload or require other special handling, such as an N_PORT login request (PLOGI). In the former case, an iFCP gateway operating in address translation mode MUST supplement the payload with additional information that enables the receiving gateway to convert such embedded N_PORT addresses to its frame of reference. For out-bound fibre channel frames comprising such a link service, the iFCP layer creates the supplemental information based on frame content, modifies the frame payload, then transmits the resulting fibre channel frame with supplemental data through the appropriate TCP connection. For incoming iFCP frames containing supplemented fibre channel link service frames, iFCP must interpret the frame, including any supplemental information, modify the frame content, and forward the resulting frame to the destination N_PORT for further processing. Monia et-al. Standards Track [Page 29] iFCP Revision 13 August 2002 Section 7.1 describes the processing of these link service messages in detail. 5.2 TCP Stream Transport of iFCP Frames 5.2.1 iFCP Session Model An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. No more than one iFCP session SHALL exist between a given pair of N_PORTs. An N_PORT is identified by its network address consisting of: a) The N_PORT ID assigned by the gateway to which the N_PORT is locally attached and b) The iFCP Portal address, consisting of its IP address and TCP port number. Since only one iFCP session may exist between a pair of N_PORTs, the iFCP session is uniquely identified by the network addresses of the session end points. TCP connections that may be used for iFCP sessions between pairs of iFCP portals are either "bound" or "unbound". An unbound connection is a TCP connection that is not actively supporting an iFCP session. A gateway implementation MAY establish a pool of unbound connections to reduce the session setup time. Such pre- existing TCP connections between iFCP Portals remain unbound and uncommitted until allocated to an iFCP session through a CBIND message (see section 6.1). When the iFCP layer creates an iFCP session, it may select an existing unbound TCP connection or establish a new TCP connection and send the CBIND message down that TCP connection. This allocates the TCP connection to that iFCP session. 5.2.2 iFCP Session Management This section describes the protocols and data structures required to establish and terminate an iFCP session. 5.2.2.1 The Remote N_PORT Descriptor In order to establish an iFCP session, an iFCP gateway MUST maintain information allowing it to locate a remotely attached N_PORT. For explanatory purposes, such information is assumed to reside in a descriptor having the format shown in Figure 10. Monia et-al. Standards Track [Page 30] iFCP Revision 13 August 2002 +--------------------------------+ | N_PORT Worldwide Unique Name | +--------------------------------+ | iFCP Portal Address | +--------------------------------+ | N_PORT ID of Remote N_PORT | +--------------------------------+ | N_PORT Alias | +--------------------------------+ Figure 10 -- Remote N_PORT Descriptor Each descriptor aggregates the following information about a remotely attached N_PORT: N_PORT Worldwide Unique Name -- 64-bit N_PORT world wide name as specified in [FC-FS]. A Remote N_PORT descriptor is uniquely identified by this parameter. iFCP Portal Address -- The IP address and TCP port number referenced when requesting creation of the TCP connection associated with an iFCP session. N_PORT ID -- N_PORT fibre channel address assigned to the remote device by the remote iFCP gateway. N_PORT Alias -- N_PORT fibre channel address assigned to the remote device by the 'local' iFCP gateway when operating in address translation mode. An iFCP gateway SHALL have one and only one descriptor for each remote N_PORT it accesses. If a descriptor does not exist, one SHALL be created using the information returned by an iSNS name server query. Such queries may be result from: a) A fibre channel Name Server request originated by a locally attached N_PORT (see sections 3.5 and 9.3), or b) A CBIND request received from a remote fibre channel device (see section 5.2.2.2). When creating a descriptor in response to an incoming CBIND request, the iFCP gateway SHALL perform an iSNS name server query using the worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME field within the CBIND payload. The descriptor SHALL be filled in using the query results. After creating the descriptor, a gateway operating in address translation mode SHALL create and add the 24-bit N_PORT alias. 5.2.2.1.1 Updating a Remote N_PORT Descriptor Monia et-al. Standards Track [Page 31] iFCP Revision 13 August 2002 A Remote N_PORT descriptor SHALL only be updated as the result of an iSNS query to obtain information for the specified worldwide port name or from information returned by an iSNS state change notification. Following such an update, a new N_PORT alias SHALL NOT be assigned. Before such an update, the contents of a descriptor may have become stale as the result of an event that invalidated or triggered a change in the N_PORT network address of the remote device, such as a fabric reconfiguration or the device's removal or replacement. A collateral effect of such an event is that a fibre channel device that has been added or whose N_PORT ID has changed will have no active N_PORT logins. Consequently, FC-4 traffic directed to such an N_PORT as the result of a stale descriptor will be rejected or discarded. Once the originating N_PORT learns of the reconfiguration, usually through the name server state change notification mechanism, information returned in the notification or the subsequent name server lookup needed to reestablish the iFCP session will automatically purge such stale data from the gateway. 5.2.2.1.2 Deleting a Remote N_PORT Descriptor Deleting a remote N_PORT descriptor is equivalent to freeing up the corresponding N_PORT alias for reuse, consequently the descriptor MUST NOT be deleted while there are any iFCP sessions that reference the remote N_PORT. Descriptors eligible for deletion should be removed based on a last in, first out policy. 5.2.2.2 Creating an iFCP Session An iFCP session may be in one of the following states: OPEN -- The session state in which fibre channel frame images may be sent and received. OPEN PENDING -- The session state after a gateway has issued a CBIND request but no response has yet been received. No fibre channel frames may be sent. The session may be initiated in response to a PLOGI ELS (see section 7.3.1.7) or for any other implementation-specific reason. The gateway SHALL create the iFCP session as follows: a) Locate the remote N_PORT descriptor corresponding to the session end point. If creating the session in order to forward a fibre channel frame, the session endpoint may be obtained by Monia et-al. Standards Track [Page 32] iFCP Revision 13 August 2002 referencing the remote N_PORT alias contained in the frame header D_ID field. If no descriptor exists, an iFCP session SHALL NOT be created. b) Allocate a TCP connection to the gateway to which the remote N_PORT is locally attached. An implementation may use an existing connection in the Unbound state or a new connection may be created and placed in the Unbound state. When creating a connection, the IP address and TCP Port number SHALL be obtained by referencing the remote N_PORT descriptor as specified in section 5.2.2.1. c) If the TCP connection cannot be allocated or cannot be created due to limited resources the gateway SHALL terminate session creation. d) If the TCP connection is aborted for any reason before the iFCP session enters the OPEN state, the gateway SHALL respond in accordance with section 5.2.3 and MAY terminate the attempt to create a session or MAY try again to establish the TCP connection. e) The gateway SHALL then issue a CBIND session control message (see section 6.1) and place the session in the OPEN PENDING state. f) If a CBIND response is returned with a status other than "Success" or "iFCP session already exists", the session SHALL be terminated and the TCP connection returned to the Unbound state. g) A CBIND STATUS of "iFCP session already exists" indicates that the remote gateway has concurrently initiated a CBIND request to create an iFCP session between the same pair of N_PORTs. A gateway receiving such a response SHALL terminate this attempt and process the incoming CBIND request in accordance with section 5.2.2.3. h) In response to a CBIND STATUS of "Success", the gateway SHALL place the session in the OPEN state. Once the session is placed in the OPEN state, an iFCP session descriptor SHALL be created containing the information shown in Figure 11: Monia et-al. Standards Track [Page 33] iFCP Revision 13 August 2002 +-----------------------+ |TCP Connection Context | +-----------------------+ | Local N_PORT ID | +-----------------------+ | Remote N_PORT ID | +-----------------------+ | Remote N_PORT Alias | +-----------------------+ Figure 11 -- iFCP Session Descriptor TCP Connection Context -- Information required to identify the TCP connection associated with the iFCP session. Local N_PORT ID -- N_PORT ID of the locally attached fibre channel device. Remote N_PORT ID -- N_PORT ID assigned to the remote device by the remote gateway. Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the local gateway when operating in address translation mode. If in this mode, the gateway SHALL copy this parameter from the Remote N_PORT descriptor. Otherwise, it is not filled in. 5.2.2.3 Responding to a CBIND Request The gateway receiving a CBIND request SHALL respond as follows: a) If the receiver has a duplicate iFCP session in the OPEN PENDING state, then the receiving gateway SHALL compare the Source N_PORT Name in the incoming CBIND payload with the Destination N_PORT Name. b) If the Source N_PORT Name is greater, the receiver SHALL issue a CBIND response of "Success" and SHALL place the session in the OPEN state. c) If the Source N_PORT Name is less, the receiver shall issue a CBIND RESPONSE of Failed - N_PORT session already exists. The state of the receiver-initiated iFCP session SHALL BE unchanged. d) If there is no duplicate iFCP session in the OPEN PENDING state, the receiving gateway SHALL issue a CBIND response. If a status of Success is returned, the receiving gateway SHALL create the iFCP session and place it in the OPEN state. An iFCP session descriptor SHALL be created as described in section 5.2.2.2. e) If a remote N_PORT descriptor does not exist, one SHALL be created and filled in as described in section 5.2.2.1. 5.2.2.4 Monitoring iFCP Connectivity Monia et-al. Standards Track [Page 34] iFCP Revision 13 August 2002 During extended periods of inactivity, an iFCP session may be terminated due to a hardware failure within the gateway or through loss of TCP/IP connectivity. The latter may occur when the session traverses a stateful intermediate device, such as a NA(P)T box or firewall, that detects and purges connections it believes are unused. To test session liveness, expedite the detection of connectivity failures, and avoid spontaneous connection termination, an iFCP gateway may maintain a low level of session activity and monitor the session by requesting that the remote gateway periodically transmit the LTEST message described in section 6.3. All iFCP gateways SHALL support liveness testing as described in this specification. A gateway requests the LTEST heartbeat by specifying a non-zero value for the LIVENESS TEST INTERVAL in the CBIND request or response message as described in section 6.1. If both gateways wish to monitor liveness, each must set the LIVENESS TEST INTERVAL in the CBIND request or response. Upon receiving such a request, the gateway providing the heartbeat SHALL transmit LTEST messages at the specified interval. The first message SHALL be sent as soon as the iFCP session enters the OPEN state. LTEST messages SHALL NOT be sent when the iFCP session is not in the OPEN state. An iFCP session SHALL be terminated as described in section 5.2.3 if: a) The contents of the LTEST message are incorrect, or b) An LTEST message is not received within twice the specified interval or the iFCP session has been quiescent for longer than twice the specified interval. The gateway to receive the LTEST message SHALL measure the interval for the first expected LTEST message from when the session is placed in the OPEN state. Thereafter, the interval SHALL be measured relative to the last LTEST message received. To maximize liveness test coverage, LTEST messages SHOULD flow through all the gateway components used to enter and retrieve fibre channel frames from the IP network, including the mechanisms for encapsulating and de-encapsulating fibre channel frames. In addition to monitoring a session, information in the LTEST message encapsulation header may also be used to compute an estimate of network propagation delay as described in section 8.2.1. However, the propagation delay limit SHALL NOT be enforced for LTEST traffic. Monia et-al. Standards Track [Page 35] iFCP Revision 13 August 2002 5.2.2.5 Use of TCP Features and Settings This section describes ground rules for the use of TCP features in an iFCP session. The core TCP protocol is defined in [RFC793]. TCP implementation requirements and guidelines are specified in [RFC1122]. +-----------+------------+--------------+------------+------------+ | Feature | Applicable | RFC | Peer-wise | Requirement| | | RFCs | Status | agreement | Level | | | | | required? | | +===========+============+==============+============+============+ | Keep Alive| [RFC1122] | None | No | Should not | | |(discussion)| | | use | +-----------+------------+--------------+------------+------------+ | Tiny | [RFC896] | Standard | No | Should not | | Segment | | | | use | | Avoidance | | | | | | (Nagle) | | | | | +-----------+------------+--------------+------------+------------+ | Window | [RFC1323] | Proposed | No | Should use | | Scale | | Standard | | | +-----------+------------+--------------+------------+------------+ | Wrapped | [RFC1323] | Proposed | No | SHOULD use | | Sequence | | Standard | | | | Protection| | | | | | (PAWS) | | | | | +-----------+------------+--------------+------------+------------+ Table 1 -- Usage of Optional TCP Features The following sections describe these options in greater detail. 5.2.2.5.1 Keep Alive Keep Alive speeds the detection and cleanup of dysfunctional TCP connections by sending traffic when a connection would otherwise be idle. The issues are discussed in [RFC1122]. In order to test the device more comprehensively, fibre channel applications, such as storage, may implement an equivalent keep alive function at the FC-4 level. Alternatively, periodic liveness test messages may be issued as described in section 5.2.2.4. Because of these more comprehensive end-to-end mechanisms and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented. 5.2.2.5.2 'Tiny' Segment Avoidance (Nagle) The Nagle algorithm described in [RFC896] is designed to avoid the overhead of small segments by delaying transmission in order to agglomerate transfer requests into a large segment. In iFCP, such small transfers often contain I/O requests. Hence, the Monia et-al. Standards Track [Page 36] iFCP Revision 13 August 2002 transmission delay of the Nagle algorithm may decrease I/O throughput. Therefore, the Nagle algorithm should not be used. 5.2.2.5.3 Window Scale Window scaling, as specified in [RFC1323], allows full utilization of links with large bandwidth - delay products and should be supported by an iFCP implementation. 5.2.2.5.4 Wrapped Sequence Protection (PAWS) TCP segments are identified with 32-bit sequence numbers. In networks with large bandwidth - delay products, it is possible for more than one TCP segment with the same sequence number to be in flight. In iFCP, receipt of such a sequence out of order may cause out-of-order frame delivery or data corruption. Consequently, this feature SHOULD be supported as described in [RFC1323]. 5.2.3 Terminating iFCP Sessions iFCP sessions SHALL be terminated in response to one of the events in Table 2: Monia et-al. Standards Track [Page 37] iFCP Revision 13 August 2002 +-------------------------------------------+---------------------+ | Event | iFCP Sessions | | | to Terminate | +===========================================+=====================+ | PLOGI terminated with LS_RJT response | Peer N_PORT | +-------------------------------------------+---------------------+ | State change notification indicating | All iFCP Sessions | | N_PORT removal or reconfiguration. | from the | | | reconfigured N_PORT | +-------------------------------------------+---------------------+ | LOGO ACC response from peer N_PORT | Peer N_PORT | +-------------------------------------------+---------------------+ | ACC response to LOGO ELS sent to F_PORT | All iFCP sessions | | server (D_ID = 0xFF-FF-FE) (fabric | from the originating| | logout) | N_PORT | +-------------------------------------------+---------------------+ | Implicit N_PORT LOGO as defined in | All iFCP sessions | | [FC-FS] | from the N_PORT | | | logged out | +-------------------------------------------+---------------------+ | LTEST Message Error (see section 5.2.2.4) | Peer N_PORT | +-------------------------------------------+---------------------+ | Non fatal encapsulation error as | Peer N_PORT | | specified in section 5.3.3 | | +-------------------------------------------+---------------------+ | Failure of the TCP connection associated | Peer N_PORT | | with the iFCP session | | +-------------------------------------------+---------------------+ | Receipt of an UNBIND session control | Peer N_PORT | | message | | +-------------------------------------------+---------------------+ | Gateway enters the Unsynchronized state | All iFCP sessions | | (see section 8.2.1) | | +-------------------------------------------+---------------------+ | Gateway detects incorrect address mode | All iFCP sessions | | to peer gateway(see section 4.6.2) | with peer gateway | +-------------------------------------------+---------------------+ Table 2-- Session Termination Events If a session is being terminated due to an incorrect address mode with the peer gateway, the TCP connection SHALL be aborted by means of a connection reset (RST) without performing an UNBIND. Otherwise, if the TCP connection is still open following the event, the gateway SHALL shut down the connection as follows: a) Stop sending fibre channel frames over the TCP connection. b) Discard all incoming traffic, except for an UNBIND session control message. c) If an UNBIND message is received at any time, return a response in accordance with section 6.2. Monia et-al. Standards Track [Page 38] iFCP Revision 13 August 2002 d) If session termination was not triggered by an UNBIND message, issue the UNBIND session control message as described in section 6.2. e) If the UNBIND message completes with a status of Success, the TCP connection MAY remain open at the discretion of either gateway and may be kept in a pool of unbound connections in order to speed the creation of a new iFCP session. If the UNBIND fails for any reason, the TCP connection MUST be terminated. In this case, the connection SHOULD be aborted with a connection reset (RST). For each terminated session, the session descriptor SHALL be deleted. If a session was terminated by an event other than an implicit LOGO or a LOGO ACC response, the gateway shall issue a LOGO to the locally attached N_PORT on behalf of the remote N_PORT. To recover resources, either gateway may spontaneously close an unbound TCP connection at any time. If a gateway terminates a connection with a TCP close operation, the peer gateway MUST respond by executing a TCP close. 5.3 Fibre Channel Frame Encapsulation This section describes the iFCP encapsulation of fibre channel frames. The encapsulation complies with the common encapsulation format defined in [ENCAP], portions of which are included here for convenience. The format of an encapsulated frame is shown below: +--------------------+ | Header | +--------------------+-----+ | SOF | f | +--------------------+ F r | | FC frame content | C a | +--------------------+ m | | EOF | e | +--------------------+-----+ Figure 12 -- Encapsulation Format The encapsulation consists of a 7-word header, an SOF delimiter word, the FC frame (including the fibre channel CRC), and an EOF delimiter word. The header and delimiter formats are described in the following sections. 5.3.1 Encapsulation Header Format Monia et-al. Standards Track [Page 39] iFCP Revision 13 August 2002 W|------------------------------Bit------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3| d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | +---------------+---------------+---------------+---------------+ 1| Reserved (must be zero) | +---------------+---------------+---------------+---------------+ 2| LS_COMMAND_ACC| iFCP Flags | SOF | EOF | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC | +---------------------------------------------------------------+ Figure 13 --- Encapsulation Header Format Common Encapsulation Fields: Monia et-al. Standards Track [Page 40] iFCP Revision 13 August 2002 Protocol# IANA-assigned protocol number identifying the protocol using the encapsulation. For iFCP, the value assigned by [ENCAP] is 2. Version Encapsulation version as specified in [ENCAP] -Protocol# Ones complement of the protocol# -Version Ones complement of the version Flags Encapsulation flags (see 5.3.1.1) Frame Length Contains the length of the entire FC Encapsulated frame including the FC Encapsulation Header and the FC frame (including SOF and EOF words) in units of 32-bit words. -Flags Ones-complement of the Flags field. -Frame Length Ones-complement of the Frame Length field. Time Stamp [integer] Integer component of the frame time stamp as specified in [ENCAP]. Time Stamp Fractional component of the time stamp [fraction] as specified in [ENCAP]. CRC Header CRC. MUST be valid for iFCP. The time stamp fields are used to enforce the limit on the lifetime of a fibre channel frame as described in section 8.2.1. iFCP-specific fields: Monia et-al. Standards Track [Page 41] iFCP Revision 13 August 2002 LS_COMMAND_ACC For a special link service ACC response to be processed by iFCP, the LS_COMMAND_ACC field SHALL contain a copy of bits 0 through 7 of the LS_COMMAND to which the ACC applies. Otherwise the LS_COMMAND_ACC field SHALL be set to zero. iFCP Flags iFCP-specific flags (see below) SOF Copy of the SOF delimiter encoding (see section 5.3.2) EOF Copy of the EOF delimiter encoding (see section 5.3.2) The iFCP flags word has the following format: |------------------------Bit----------------------------| | | | 8 9 10 11 12 13 14 15 | +------+------+------+------+------+------+------+------+ | Reserved | SES | TRP | SPC | +------+------+------+------+------+------+------+------+ Figure 14 -- iFCP Flags Word iFCP Flags: SES 1 = Session control frame (TRP and SPC MUST be 0) TRP 1 = Address transparent mode enabled 0 = Address translation mode enabled SPC 1 = Frame is part of a link service message requiring special processing by iFCP prior to forwarding to the destination N_PORT. 5.3.1.1 Common Encapsulation Flags The iFCP usage of the common encapsulation flags defined in [ENCAP] is shown in Figure 15: Monia et-al. Standards Track [Page 42] iFCP Revision 13 August 2002 |------------------------Bit--------------------------| | | | 0 1 2 3 4 5 | +--------------------------------------------+--------+ | Reserved | CRCV | +--------------------------------------------+--------+ Figure 15 -- iFCP Common Encapsulation Flags For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 5.3.2 SOF and EOF Delimiter Fields The format of the delimiter fields is shown below. W|------------------------------Bit------------------------------| o| | r| 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3| d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+---------------+---------------+ 0| SOF | SOF | -SOF | -SOF | +---------------+---------------+---------------+---------------+ 1| | +----- FC frame content -----+ | | +---------------+---------------+---------------+---------------+ n| EOF | EOF | -EOF | -EOF | +---------------+---------------+---------------+---------------+ Figure 16 -- FC Frame Encapsulation Format SOF (bits 0-7 and bits 8-15 in word 0): iFCP uses the following subset of the SOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 3. The authoritative encodings should be obtained from [ENCAP]. +-------+----------+ | FC | | | SOF | SOF Code | +-------+----------+ | SOFi2 | 0x2D | | SOFn2 | 0x35 | | SOFi3 | 0x2E | | SOFn3 | 0x36 | +-------+----------+ Table 3-- Translation of FC SOF Values to SOF Field Contents -SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the ones complement of the value in the SOF fields. EOF (bits 0-7 and 8-15 in word n): iFCP uses the following subset of EOF fields specified in [ENCAP]. For convenience, these are reproduced in Table 4. The authoritative encodings should be obtained from [ENCAP]. Monia et-al. Standards Track [Page 43] iFCP Revision 13 August 2002 +-------+----------+ | FC | | | EOF | EOF Code | +-------+----------+ | EOFn | 0x41 | | EOFt | 0x42 | +-------+----------+ Table 4 -- Translation of FC EOF Values to EOF Field Contents -EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the one's complement of the value in the EOF fields. iFCP implementations SHALL place a copy of the SOF and EOF delimiter codes in the appropriate header fields. 5.3.3 Frame Encapsulation A fibre channel Frame to be encapsulated MUST first be validated as described in [FC-FS]. Any frames received from a locally attached fibre channel device that do not pass the validity tests in [FC-FS] SHALL be discarded by the gateway. If the frame is a PLOGI ELS, the creation of an iFCP session as described in section 7.3.1.7 may precede encapsulation. Once the session has been created, frame encapsulation SHALL proceed as follows. The S_ID and D_ID fields in the frame header SHALL be referenced to lookup the iFCP session descriptor (see section 5.2.2.2). If no iFCP session descriptor exists, the frame SHALL be discarded. Frame types submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 3 and an EOF delimiter from Table 4. Other valid frame types MUST be processed internally by the gateway as specified in the appropriate fibre channel specification. If operating in address translation mode and processing a special link service message requiring the inclusion of supplemental data, the gateway SHALL format the frame payload and add the supplemental information specified in section 7.1. The gateway SHALL then calculate a new FC CRC on the reformatted frame. Otherwise, the frame contents SHALL NOT be modified and the gateway MAY encapsulate and transmit the frame image without recalculating the FC CRC. The frame originator MUST then create and fill in the header and the SOF and EOF delimiter words as specified in sections 5.3.1 and 5.3.2. 5.3.4 Frame De-encapsulation Monia et-al. Standards Track [Page 44] iFCP Revision 13 August 2002 The receiving gateway SHALL perform de-encapsulation as follows: Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the header CRC is valid, the receiving gateway SHALL check the iFCP flags field. If one of the error conditions in Table 5 is detected, the gateway SHALL handle the error as specified in section 5.2.3. +------------------------------+-------------------------+ | Condition | Error Type | +==============================+=========================+ | Header CRC Invalid | Encapsulation error | +------------------------------+-------------------------+ | SES = 1, TRP or SPC not 0 | Encapsulation error | +------------------------------+-------------------------+ | SES = 0, TRP set incorrectly | Incorrect address mode | +------------------------------+-------------------------+ Table 5 -- Encapsulation Header Errors The receiving gateway SHALL then verify the frame propagation delay as described in section 8.2.1. If the propagation delay is too long, the frame SHALL be discarded. Otherwise, the gateway SHALL check the SOF and EOF in the encapsulation header. A frame SHALL be discarded if it has an SOF code that is not in Table 3 or an EOF code that is not in Table 4. The gateway SHALL then de-encapsulate the frame as follows: a) Check the FC CRC and discard the frame if the CRC is invalid. b) If operating in address translation mode, replace the S_ID field with the N_PORT alias of the frame originator and the D_ID with the N_PORT ID of the frame recipient. Both parameters SHALL be obtained from the iFCP session descriptor. c) If processing a special link service message, replace the frame with a copy whose payload has been modified as specified in section 7.1. The de-encapsulated frame SHALL then be forwarded to the N_PORT specified in the D_ID field. If the frame contents have been modified by the receiving gateway, a new FC CRC SHALL be calculated. 6. TCP Session Control Messages TCP session control messages are used to create and manage an iFCP session as described in section 5.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer. The message format is based on the fibre channel extended link service message template shown below. Monia et-al. Standards Track [Page 45] iFCP Revision 13 August 2002 Word 0<--Bits-->7 8<---------------Bits------------------------>31 +------------+------------------------------------------------+ 0| R_CTL | D_ID [0x00 00 00] | |[Req = 0x22]| [Destination of extended link Service request] | |[Rep = 0x23]| | +------------+------------------------------------------------+ 1| CS_CTL | S_ID [0x00 00 00] | | [0x0] | [Source of extended link service request] | +------------+------------------------------------------------+ 2|TYPE [0x1] | F_CTL [0] | +------------+------------------+-----------------------------+ 3|SEQ_ID | DF_CTL [0x00] | SEQ_CNT [0x00] | |[0x0] | | | +------------+------------------+-----------------------------+ 4| OX_ID [0x0000] | RX_ID_[0x0000] | +-------------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-------------------------------------------------------------+ 6| LS_COMMAND | | [Session Control Command Code] | +-------------------------------------------------------------+ 7| | .| Additional Session Control Parameters | .| ( if any ) | n| | +=============================================================+ n| Fibre Channel CRC | +| | 1+=============================================================+ Figure 17 -- Format of Session Control Message The LS_COMMAND value for the response remains the same as that used for the request. The session control frame is terminated with a fibre channel CRC. The frame SHALL be encapsulated and de-encapsulated according to the rules specified in section 5.3. The encapsulation header for the link Service frame carrying a session control message SHALL be set as follows: Encapsulation Header Fields: Monia et-al. Standards Track [Page 46] iFCP Revision 13 August 2002 LS_COMMAND_ACC 0 iFCP Flags SES = 1 TRP = 0 INT = 0 SOF code SOFi3 encoding (0x2E) EOF code EOFt encoding (0x42) The encapsulation time stamp words SHALL be set as described for each message type. The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above. Table 6 lists the values assigned to byte 0 of the LS_COMMAND field for iFCP session control messages. +--------------+-------------------------+----------+-------------+ | LS_COMMAND | Function | Mnemonic | iFCP | | field, byte 0| | | Support | +--------------+-------------------------+----------+-------------+ | 0xE0 | Connection Bind | CBIND | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0xE4 | Unbind Connection | UNBIND | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0xE5 | Test Connection Liveness| LTEST | REQUIRED | +--------------+-------------------------+----------+-------------+ | 0x01-0x7F | Vendor-specific | | | +--------------+-------------------------+----------+-------------+ | 0x00 | Reserved -- Unassignable| | | +--------------+-------------------------+----------+-------------+ | All other | Reserved | | | | values | | | | +--------------+-------------------------+----------+-------------+ Table 6 -- Session Control LS_COMMAND Field, Byte 0 Values 6.1 Connection Bind (CBIND) As described in section 5.2.2.2, the CBIND message and response are used to bind an N_PORT login to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_PORTs are identified by their worldwide port names. The time stamp words in the encapsulation header SHALL be set to zero in the request and response message frames. The following shows the format of the CBIND request. Monia et-al. Standards Track [Page 47] iFCP Revision 13 August 2002 +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | | | (Seconds) | | | +------+-------------------------+-----------+----------+ | 2 | USER INFO | +------+------------+------------+-----------+----------+ | 3 | | +------+ SOURCE N_PORT NAME | | 4 | | +------+------------------------------------------------+ | 5 | | +------+ DESTINATION N_PORT NAME | | 6 | | +------+------------------------------------------------+ Addr Mode: The addressing mode of the originating gateway. 0 = Address Translation mode, 1 = Address Transparent mode. iFCP Ver: iFCP version number. SHALL be set to 1. LIVENESS TEST If non-zero, requests that the receiving INTERVAL: gateway transmit an LTEST message at the specified interval in seconds. If set to zero, LTEST messages SHALL NOT be sent. USER INFO: Contains any data desired by the requestor. This information MUST be echoed by the recipient in the CBIND response message. SOURCE N_PORT NAME: The Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway originating the CBIND request. DESTINATION N_PORT The Worldwide Port Name (WWPN) of the NAME: N_PORT locally attached to the gateway receiving the CBIND request. The following shows the format of the CBIND response. Monia et-al. Standards Track [Page 48] iFCP Revision 13 August 2002 +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver | | | (Seconds) | | | +------+-------------------------+-----------+----------+ | 2 | USER INFO | +------+------------+------------+-----------+----------+ | 3 | | +------+ SOURCE N_PORT NAME | | 4 | | +------+------------------------------------------------+ | 5 | | +------+ DESTINATION N_PORT NAME | | 6 | | +------+-------------------------+----------------------+ | 7 | Reserved | CBIND Status | +------+-------------------------+----------------------+ | 8 | Reserved | CONNECTION HANDLE | +------+-------------------------+----------------------+ Total Length = 36 Monia et-al. Standards Track [Page 49] iFCP Revision 13 August 2002 Addr Mode: The address translation mode of the responding gateway. 0 = Address Translation mode, 1 = Address Transparent mode. iFCP Ver: iFCP version number. Shall be set to 1. LIVENESS TEST If non-zero, requests that the gateway INTERVAL: receiving the CBIND RESPONSE transmit an LTEST message at the specified interval in seconds. If zero, LTEST messages SHALL NOT be sent. USER INFO: Echoes the value received in the USER INFO field of the CBIND request message. SOURCE N_PORT NAME: Contains the Worldwide Port Name (WWPN) of the N_PORT locally attached to the gateway issuing the CBIND request. DESTINATION N_PORT Contains the Worldwide Port Name (WWPN) of NAME: the N_PORT locally attached to the gateway issuing the CBIND response. CBIND STATUS: Indicates success or failure of the CBIND request. CBIND values are shown below. CONNECTION HANDLE: Contains a value assigned by the gateway to identify the connection. The connection handle is required when issuing the UNBIND request. CBIND Status Description ------------ ----------- 0 Success 1 - 15 Reserved 16 Failed - Unspecified Reason 17 Failed - No such device 18 Failed - iFCP session already exists 19 Failed - Lack of resources 20 Failed - Incompatible address translation mode 21 Failed - Incorrect protocol version number 22 Failed - Gateway not Synchronized (see section 8.2) Others Reserved 6.2 Unbind Connection (UNBIND) Monia et-al. Standards Track [Page 50] iFCP Revision 13 August 2002 UNBIND is used to terminate an iFCP session and disassociate the TCP connection as described in section 5.2.3. The UNBIND message is transmitted over the connection that is to be unbound. The time stamp words in the encapsulation header shall be set to zero in the request and response message frames. The following is the format of the UNBIND request message. +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE4 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | USER INFO | +------+------------+------------+-----------+----------+ | 2 | Reserved | CONNECTION HANDLE | +------+------------+------------+----------------------+ | 3 | Reserved | +------+------------+------------+-----------+----------+ | 4 | Reserved | +------+------------+------------+-----------+----------+ USER INFO Contains any data desired by the requestor. This information MUST be echoed by the recipient in the UNBIND response message. CONNECTION HANDLE: Contains the gateway-assigned value from the CBIND request. The following shows the format of the UNBIND response message. +------+------------+------------+-----------+----