IP Storage Working Group Charles Monia INTERNET DRAFT Rod Mullendore Expires May 2002 Josh Tseng Nishan Systems Franco Travostino Victor Firoiu Nortel Networks David Robinson Sun Microsystems Wayland Jeong Troika Networks Rory Bolt Quantum/ATL Paul Rutherford ADIC Mark Edwards Eurologic November 2001 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 RFC2026 [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 obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/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 7 November 2001 Status of this Memo...................................................1 Comments..............................................................1 1. Abstract.....................................................5 2. About This Document..........................................5 2.1 Conventions used in this document............................5 2.2 Purpose of this document.....................................5 3. iFCP Introduction............................................5 3.1 Definitions..................................................6 4. Fibre Channel Communication Concepts.........................8 4.1 The Fibre Channel Network....................................8 4.2 Fabric Topologies............................................9 4.2.1 Switched Fibre Channel Fabrics.............................10 4.2.2 Mixed Fibre Channel Fabric.................................11 4.3 Fibre Channel Layers and Link Services......................12 4.3.1 Fabric-Supplied Link Services..............................13 4.4 Fibre Channel Nodes.........................................13 4.5 Fibre Channel Device Discovery..............................14 4.6 Fibre Channel Information Elements..........................14 4.7 Fibre Channel Frame Format..................................15 4.7.1 N_PORT Address Model.......................................15 4.8 Fibre Channel Transport Services............................16 4.9 Login Processes.............................................16 5. The iFCP Network Model......................................17 5.1 Fabric Topologies Supported by iFCP.........................19 5.2 iFCP Transport Services.....................................19 5.2.1 Fibre Channel Transport Services Supported by iFCP.........20 5.3 iFCP Device Discovery and Configuration Management..........20 5.4 The iFCP N_PORT Address Model...............................20 5.4.1 Operation in Address Transparent Mode......................22 5.4.2 Operation in Address Translation Mode......................24 5.4.3 Translation Table Maintenance..............................24 6. iFCP Protocol...............................................28 6.1 Overview....................................................28 6.1.1 iFCP Transport Services....................................28 6.1.2 iFCP Support for Link Services............................29 6.2 TCP Stream Transport of iFCP Frames.........................29 6.2.1 iFCP Session Model.........................................29 6.2.2 iFCP Session Management....................................30 6.2.3 Terminating an N_PORT Login Session........................34 6.3 IANA Considerations.........................................35 6.4 Encapsulation of Fibre Channel Frames.......................35 6.4.1 Encapsulation Header Format................................36 6.4.2 SOF and EOF Delimiter Fields...............................39 6.4.3 Frame Encapsulation........................................40 6.4.4 Frame De-encapsulation.....................................40 7. TCP Session Control Messages................................41 7.1 Connection Bind (CBIND).....................................43 7.2 Unbind Connection (UNBIND)..................................46 8. Fibre Channel Link Services.................................47 8.1 Special Link Service Messages...............................48 8.2 Link Services Requiring Payload Address Translation.........48 Monia et-al. Standards Track [Page 2] iFCP Revision 7 November 2001 8.3 Fibre Channel Link Services Processed by iFCP...............50 8.3.1 Abort Exchange (ABTX)......................................51 8.3.2 Discover Address (ADISC)...................................52 8.3.3 Discover Address Accept (ADISC ACC)........................53 8.3.4 FC Address Resolution Protocol Reply (FARP-REPLY)..........53 8.3.5 FC Address Resolution Protocol Request (FARP-REQ)..........54 8.3.6 Logout (LOGO)..............................................56 8.3.7 Port Login (PLOGI) and PLOGI ACC...........................56 8.3.8 Read Exchange Status Block (RES)...........................57 8.3.9 Read Exchange Status Block Accept..........................58 8.3.10 Read Link Error Status (RLS).............................59 8.3.11 Read Sequence Status Block (RSS).........................59 8.3.12 Reinstate Recovery Qualifier (RRQ).......................60 8.3.13 Request Sequence Initiative (RSI)........................61 8.3.14 Third Party Process Logout (TPRLO).......................61 8.3.15 Third Party Logout Accept (TPRLO ACC)....................64 8.4 FLOGI Service Parameters Supported by an iFCP Gateway.......64 9. iFCP Error Detection........................................66 9.1 Overview....................................................66 9.2 Stale Frame Prevention......................................66 9.2.1 Enforcing R_A_TOV Limits...................................67 10. Fabric Services Supported by an iFCP implementation.........69 10.1 F_PORT Server...............................................69 10.2 Fabric Controller...........................................69 10.3 Directory/Name Server.......................................69 10.4 iFCP Support for the FC Broadcast Service...................70 11. iFCP Security...............................................71 11.1 Overview....................................................71 11.2 iFCP Security Operating Requirements........................71 11.2.1 Context..................................................71 11.2.2 Security Threats.........................................71 11.2.3 Interoperability Requirements with Security Gateways.....72 11.2.4 Statically and Dynamically Assigned IP Addresses.........72 11.2.5 Authentication Requirements..............................72 11.2.6 Confidentiality Requirements.............................72 11.2.7 Rekeying Requirements....................................73 11.2.8 Usage Requirements.......................................73 11.2.9 iSNS Role................................................73 11.3 iFCP Security Design........................................73 11.3.1 Enabling Technologies....................................73 11.3.2 Use of IKE and IPsec.....................................75 11.3.3 Certificate-based authentication.........................76 11.4 iSNS and iFCP Security......................................77 11.5 Use of iSNS to Distribute Security Policy...................77 11.6 Minimal Security Policy for an iFCP gateway.................78 12. Quality of Service Considerations...........................78 12.1 Minimal requirements........................................78 12.2 High-assurance..............................................79 13. Author's Addresses..........................................80 A. iFCP Support for Fibre Channel Link Services................82 A.1 Basic Link Services.........................................82 A.2 Link Services Processed Transparently.......................82 Monia et-al. Standards Track [Page 3] iFCP Revision 7 November 2001 A.3 iFCP-Processed Link Services................................83 Full Copyright Statement.............................................86 Monia et-al. Standards Track [Page 4] iFCP Revision 7 November 2001 1. Abstract This document specifies an architecture and gateway-to-gateway protocol for the implementation of Fibre Channel fabric functionality on a network in which TCP/IP switching and routing elements replace Fibre Channel components. The protocol enables the attachment of existing Fibre Channel storage products to an IP network by supporting the fabric services required by such devices. 2. About This Document 2.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]. All frame formats are in big endian network byte order. 2.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 NCITS 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 protocol for mapping standards-compliant fibre Channel storage and adapter implementations to TCP/IP. This mapping includes sections of this document which describe the "iFCP Protocol" (see section 6). 3. 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. 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 through a process that allows normal Fibre Channel frame traffic to pass through the gateway directly, with provisions, where necessary, for Monia et-al. Standards Track [Page 5] iFCP Revision 7 November 2001 intercepting and emulating the fabric services required by a Fibre Channel device. 3.1 Definitions Terms needed to clarify the concepts presented in this document are presented here. Locally Attached Device - With respect to a gateway, a Fibre Channel device accessed through the Fibre Channel fabric to which the gateway is attached. Remotely Attached Device - With respect to a gateway, a Fibre Channel device accessed from the gateway by means of the iFCP protocol. 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. 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 logical fabric to which the gateway belongs. Gateway Region û The portion of the iFCP storage network accessed through an iFCP gateway. Fibre Channel devices in the region consist of all Fibre Channel devices locally attached to the gateway. Logical Fabric û The union of two or more gateway regions configured to interoperate together in address-transparent mode. Fibre Channel Device - An entity implementing the functionality accessed through an FC-4 application protocol. 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]. Fibre Channel Network - A native Fibre Channel fabric and all attached Fibre Channel nodes. Fabric - The components of a Fibre Channel network that provides the transport services defined in [FC-FS]. A fabric may be implemented in the IP framework by means of the architecture and protocols discussed in this document. Fabric Port - The interface through which an N_PORT accesses a Fibre Channel fabric. The type of fabric port depends on Monia et-al. Standards Track [Page 6] iFCP Revision 7 November 2001 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 application layer. This layer is functionally equivalent to the TCP/IP application layer. iFCP Portal - An IP-addressable entity representing the point at which a logical or physical iFCP device is attached to the IP 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 are dependant on the Fibre Channel fabric topology. As used in this document, the term applies equally to all variants. 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 I/Ds are assigned in accordance with the Fibre Channel rules for address assignment specified in [FC-FS]. N_PORT Alias -- The N_PORT address assigned by a gateway to represent a remote N_PORT accessed via the iFCP protocol. When routing frame traffic in address translation mode, the gateway automatically converts N_PORT aliases to N_PORT network addresses and vice versa. N_PORT Network Address - The address of an N_PORT in the IP fabric. This address consists of the IP address of the iFCP Portal and the N_PORT ID of the locally attached Fibre Channel device. F_PORT - The interface used by an N_PORT to access Fibre Channel switched fabric functionality. iFCP - The protocol discussed in this document. Logical iFCP Device - The abstraction representing a single Fibre Channel device as it appears on an iFCP network. iSNS - The IP protocol by which storage name services are implemented in an iFCP network. Fibre Channel Name services are provided by an iSNS name server as described in [ISNS]. Monia et-al. Standards Track [Page 7] iFCP Revision 7 November 2001 N_PORT Session - An association created when two N_PORTS have executed a PLOGI operation. It is comprised of the N_PORTs and TCP connection that carries traffic between them. iFCP Frame - A Fibre Channel frame encapsulated in accordance with the Common Encapsulation Specification [ENCAP] and this specification. Port Login (PLOGI) - The Fibre Channel Extended Link Service (ELS) that establishes an N_PORT login session through the exchange of identification and operation parameters between an originating N_PORT and a responding N_PORT. DOMAIN_ID û The value contained in the high-order byte of a 24-bit N_PORT Fibre Channel address. 4. 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 5. 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] -- Fibre Channel Fabric Loop Attachment, [FC-FLA] The reader will find an in-depth treatment of the technology in [Kembel]. 4.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 Monia et-al. Standards Track [Page 8] iFCP Revision 7 November 2001 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 interface within a fabric that provides Fibre Channel attachment for an N_PORT. The types of fabric port depend on the fabric topology and are discussed in section 4.2. d) The fabric infrastructure for carrying frame traffic between N_PORTs. e) Within a switched or mixed fabric (see section 4.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 The following sections describe Fibre Channel fabric topologies and give an overview of the Fibre Channel communications model. 4.2 Fabric Topologies The principal Fibre Channel fabric topologies consist of the following: a) Arbitrated Loop -- A series of N_PORTs connected together in daisy-chain fashion. Data transmission between N_PORTs requires arbitration for control of the loop in a manner similar to a token ring network. b) Switched Fabric -- A fabric consisting of switching elements, as described in section 4.2.1. Monia et-al. Standards Track [Page 9] iFCP Revision 7 November 2001 c) Mixed Fabric -- A fabric consisting of switches and "fabric- attached" loops. A description can be found in [FC-FLA]. Depending on the topology, the N_PORT and fabric port variants through which a Fibre Channel device is attached to the network may be one of the following: Fabric Topology Fabric Port Type N_PORT Variant --------------- ---------------- -------------- Loop L_PORT NL_PORT Switched F_PORT N_PORT Mixed FL_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. 4.2.1 Switched Fibre Channel Fabrics An example of a multi-switch Fibre Channel fabric is shown below. Monia et-al. Standards Track [Page 10] iFCP Revision 7 November 2001 +----------+ +----------+ | 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]. 4.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 11] iFCP Revision 7 November 2001 +----------+ +----------+ +---------+ | FC | | FC | | FC | | Device | | Device | | Device | |..........| |..........| |.........| | N_PORT |<........>| NL_PORT +---+ NL_PORT | +----+-----+ +-----+----+ +----+----+ | | 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. 4.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 FCP, the Fibre Channel SCSI protocol. Monia et-al. Standards Track [Page 12] iFCP Revision 7 November 2001 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. 4.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 well-known N_PORT fabric addresses. 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 an N_PORT request 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 4.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 4.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 is 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. 4.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 13] iFCP Revision 7 November 2001 a) A world-wide unique identifier for the node, b) A world-wide unique identifier for each N_PORT associated with the nodee, c) For each N_PORT attached to a fabric, a 24-bit fabric-unique address having the properties defined in section 4.7.1. The fabric address is the address to which frames are sent. Each world-wide unique identifier is a 64-bit binary quantity having the format defined in [FC-FS]. 4.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 world-wide 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]. 4.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 4.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 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 14] iFCP Revision 7 November 2001 4.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 highly simplified view of the frame. +-----------------------------+ | Start-of-frame Delimiter | +-----+-----------------------+<----+ | | Destination N_PORT | | | | Fabric Address (D_ID) | | | | (24-bits) | | +-----+-----------------------+ 24-byte | | Source N_PORT | Frame | | Fabric Address (S_ID) | Header | | (24 bits) | | +-----+-----------------------+ | | Control information for | | | frame type, Exchange | | | management, IU | | | segmentation and | | | re-assembly | | +-----------------------------+<----+ | | | Frame payload | | (0 û 2112 bytes) | | | | | | | +-----------------------------+ | CRC | +-----------------------------+ | 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 MAC addresses of originating and receiving N_PORTs. 4.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]: Bit 23 16 15 8 7 0 +-----------+------------+----------+ | Domain ID | Area ID | Port ID | +-----------+------------+----------+ Figure 5 -- Fibre Channel Address Format Monia et-al. Standards Track [Page 15] iFCP Revision 7 November 2001 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 I/D assigned by the principal switch. The value of the Domain I/D 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 I/D concatenated with switch- assigned area and port I/Ds. 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 I/Ds are supplied by the fabric when the FLOGI is executed. 4.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 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.Login Processes Monia et-al. Standards Track [Page 16] iFCP Revision 7 November 2001 The Login processes are the means whereby an N_PORT establishes 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 login (PLOGI) operation is preceded by a Name Server query to discover the Fibre Channel address of the remote device. A common query type involves use of the world-wide unique name of an N_PORT to obtain the 24-bit N_PORT Fibre Channel address to which the PLOGI request is sent. 5. The iFCP Network Model The purpose of the iFCP protocol is to enable the implementation of Fibre Channel mixed or switched fabric functionality on an IP network in which IP components and technology replace the Fibre Channel switching and routing infrastructure described in section 4.2. The following diagram shows a Fibre Channel fabric with attached devices. These are connected to the fabric through an N_PORT interface attached to a Fabric Port whose behavior is specified in [FC-FS]. In this case, the N_PORT and Fabric Port represent any of the variants described in section 4.2. Within the Fibre Channel device domain, fabric-addressable entities consist of other N_PORTs and devices internal to the fabric that perform the fabric services defined in [FC-GS3]. Monia et-al. Standards Track [Page 17] iFCP Revision 7 November 2001 Fibre Channel Network +--------+ +--------+ | FC | | FC | | Device | | Device | |........| |........| Fibre Channel | N_PORT |<......>| N_PORT | Device Domain +---+----+ +----+---+ ^ | | | +---+----+ +----+---+ | | Fabric | | Fabric | | | Port | | Port | | ==========+========+========+========+============== | Fabric & | | | Fabric Services | v | | Fibre Channel +--------------------------+ Fabric Domain Figure 6 -- A Fibre Channel Fabric Gateway Region Gateway Region +--------+ +--------+ +--------+ +--------+ | FC | | FC | | FC | | FC | | Device | | Device | Fibre | Device | | Device | Fibre |........| |........| Channel |........| |........| Channel | N_PORT | | N_PORT |<.........>| N_PORT | | N_PORT | Device +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain | | | | ^ +---+----+ +---+----+ +----+---+ +----+---+ | | Fabric | | Fabric | | Fabric | | Fabric | | | Port | | Port | | Port | | Port | | =+========+==+========+===========+========+==+========+========== | iFCP Layer |<--------->| iFCP Layer | | |....................| ^ |....................| | | iFCP Portal | | | iFCP Portal | v +--------+-----------+ | +----------+---------+ iFCP iFCP|Gateway Control iFCP|Gateway Fabric | Data | Domain | | | | |<------Encapsulated Frames------->| | +------------------+ | | | | | +------+ IP Network +--------+ | | +------------------+ Figure 7 -- An iFCP Fabric The above diagram shows animplementation of an equivalent iFCP fabric consisting of two iFCP gateways. Each controls a single gateway region. Fibre Channel devices in the region are those Monia et-al. Standards Track [Page 18] iFCP Revision 7 November 2001 directly connected to the iFCP fabric through fabric ports implemented as part of the gateway. An iFCP gateway contains one or more standards-compliant fibre channel ports and an iFCP Portal for attachment to the IP network. Looking into the fabric port, ,the gateway appears as a switch elementwithin a Fibre Channel fabric. Here, the gateway presents remote N_PORTs as fabric-attached devices. Conversely, on the IP network side, the gateway presents each locally connected N_PORT as a logical Fibre Channel device. 5.1 Fabric Topologies Supported by iFCP A property of this gateway architecture is that the fabric configuration and topology within the gateway region are opaque to the IP network and other gateway regions. That is, the topology in the gateway region, whether it is loop- or switch-based, is hidden from the IP network and from other gateway regions. As a result, support for specific FC fabric topologies becomes a gateway implementation issue. In such cases, the gateway incorporates whatever functionality is required to present locally attached N_PORTs as logical iFCP devices. Regarding fabric topologies, the examples in this specification show an N_PORT directly connected to a gateway fabric port, this is done to keep the illustrations simple and does not reflect any fundamental limitation in the fabric configuration that an implementation can support. 5.2 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 5.4. b) Execution of fabric-supplied link services addressed to one of the well-known Fibre Channel N_PORT addresses. c) 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. d) Establishment of an N_PORT login session in response to a PLOGI directed to a remote device. The following sections discuss the frame addressing mechanism and the way in which it is used to achieve communications transparency between N_PORTs. Monia et-al. Standards Track [Page 19] iFCP Revision 7 November 2001 5.2.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. 5.3 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]. iSNS is a client-server architecture that enables the following functions: a) Emulation of the services provided by the Fibre Channel name server described in section 4.3.1, including a mechanism for asynchronously notifying an N_PORT of changes in the fabric configuration, b) Definition and management of device discovery scopes, referred to as 'discovery domains', c) Grouping of iFCP gateways on the IP network into 'logical fabrics' for interoperation in address transparent mode as described in section 5.4.1.1. d) Storage and distribution of security policies as described in section 11.2.9. An iFCP gateway cannot operate without access to an iSNS server. 5.4 The iFCP N_PORT Address Model This section discusses the role of the N_PORT addressing model of section 4.7.1 in the routing of frames between locally and remotely attached N_PORTs. In the case of a remote N_PORT, where the frame traffic must traverse the IP network, the gateway must perform this routing transparently with respect to the locally attached N_PORT. To provide such transparency, the gateway maintains an association between the Fibre Channel address of a remote N_PORT, as seen by a locally attached device, and the corresponding address of the remote device on the IP network. 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 Monia et-al. Standards Track [Page 20] iFCP Revision 7 November 2001 switch, however, an iFCP gateway must also route frames to external devices attached to remote gateways on the IP network. In order to be transparent to FC devices, the gateway must route such frames using only the embedded 24-bit address. By exploiting its control of address allocation and access to frame traffic entering or leaving the gateway region, it is able to achieve the necessary transparency. The gateway may allocate N_PORT addresses in one of two ways: a) Address Translation Mode û A mode of address assignment in which the gateway allocates an N_PORT device address that is unique to the gateway region. The address of a remote device is represented in that gateway region by a gateway assigned N_PORT alias. b) Address Transparent Mode û A mode of address assignment in which the gateway allocates an N_PORT address that is unique across the set of gateway regions comprising a logical fabric. In address transparent mode, gateways within a logical 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 I/Ds from the address assignment authority as described in section 5.4.1.1. Consequently, within the scope of the logical 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. Support for address transparent mode is OPTIONAL. The mode of gateway operation is settable in an implementation- specific manner. The implementation MUST NOT allow the mode to be changed after the gateway begins processing fibre channel frame traffic. The choice of addressing mode involves the tradeoffs between scalability and transparency discussed below. The scalability constraints in address transparent mode are a consequence of the Fibre Channel address allocation policy described in section 4.7.1. As noted, a logical fabric using this address allocation scheme is limited to a combined total of 239 gateways and Fibre Channel switch elements. As the system expands, an IP fabric may consist of many switch elements distributed throughout the enterprise, each of which controls a small number of devices. In this case, the limitation in switch count may become a barrier to extending and fully integrating the storage network. Monia et-al. Standards Track [Page 21] iFCP Revision 7 November 2001 Address Translation mode avoids this limitation by decoupling N_PORT fabric addresses from the constraints of fabric-wide address space management. Consequently, a virtually unlimited number of iFCP gateways, Fibre Channel devices and switch elements may be internetworked. This mode of address allocation also simplifies management of an iFCP network by eliminating the need for a centralized N_PORT address assignment authority. A consequence of address translation mode is that the 24-bit N_PORT address is no longer unique across the set of Fibre Channel devices connected to the IP network. As a result, when processing frame traffic to or from remote N_PORTs, the gateway must intervene to translate the 24-bit N_PORT addresses between the sending and receiving gateway regions. These address operations involve: a) Translating the N_PORT I/Ds in the frame header and b) Translating N_PORT I/Ds carried in the payload of certain extended link service messages. The process of N_PORT I/D translation for the frame header is described in section 5.4.2. The processing of link service messages with frame addresses in the payload is described in section 8.1. The details of the address transparent and address translation operational modes are discussed in the following sections. 5.4.1 Operation in Address Transparent Mode In addition to the scalability limits discussed above, the following considerations and requirements apply to this mode of operation: a) There is increased dependency on the services of a central address assignment authority, such as [ISNS]. If connectivity with the server is lost, new DOMAIN_ID values cannot be automatically allocated as gateways and Fibre Channel switch elements are added to the logical fabric. As a result, new gateways and switch elements cannot be automatically added to the ip fabric. Of course, it is always possible to add and manage such additional components manually. b) Coordination of iSNS servers is required. Multiple iFCP gateways set up with independently-administered address servers must be completely torn down and slaved under a single iSNS name server before they can be configured into the same logical fabric. In contrast, operation in address translation mode requires only that the independent iSNS servers import client attributes from other iSNS servers before client gateways under different iSNS authorities can be made to interoperate. Monia et-al. Standards Track [Page 22] iFCP Revision 7 November 2001 c) iFCP gateways in address transparent mode will not interoperate with iFCP gateways that are not in transparent mode. d) 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 specification. As described in section 5.4.1.1, DOMAIN_ID values assigned to FC switches in attached fabrics must be issued by the iSNS server or manually assigned. e) When operating in address transparent Mode, no Fibre Channel address translation SHALL take place.. The process for establishing the TCP/IP context associated with an N_PORT login session in this mode is similar to that specified for address translation mode (section 5.4.2). 5.4.1.1 Transparent Mode Domain I/D Management As described above, each gateway and Fibre Channel switch in a logical fabric must have a unique domain I/D. In a gateway region containing Fibre Channel switch elements, each element obtains a domain I/D by querying the principal switch as described in [FC- SW2] -- in this case the iFCP gateway itself. The gateway in turn may obtain domain I/Ds on demand from a central address allocation authority, such as an iSNS name server or manually from a pre- assigned block of IDs. In that sense, the address authority (e.g., iSNS) assumes the role of master switch for the logical fabric. If iSNS is used for domain I/D allocation, the iSNS database contains: a) The definition for one or more logical fabrics, b) For each logical fabric, a world-wide unique name identifying each gateway in the logical fabric. A gateway in address transparent mode MUST reside in one and only one logical fabric. In its role as principle switch, an iFCP gateway in address transparent mode obtains domain I/Ds for use in the gateway region by issuing the appropriate iSNS query using its world-wide name. 5.4.1.2 Incompatibility with Address Translation Mode iFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRN bit set to one in the iFCP flags field of the encapsulation header (see section 6.4.1). The iFCP gateway SHALL immediately terminate all N_PORT login sessions with the iFCP gateway from which it receives such frames. Monia et-al. Standards Track [Page 23] iFCP Revision 7 November 2001 5.4.2 Operation in Address Translation Mode This section summarizes the process for managing the assignment of addresses within a gateway region, including the modification of FC frame addresses embedded in the frame header for frames sent and received from remotely attached N_PORTs. As described above, 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. When a remotely attached N_PORT is accessed, the gateway assigns a locally significant N_PORT alias. This alias is used in place of the N_PORT I/D assigned by the remote gateway. To perform address conversion and enable the appropriate routing, the gateway maintains a table mapping N_PORT aliases to the appropriate TCP/IP connection context and N_PORT ID of all remotely accessed N_PORTs. The means by which translation table entries are created and updated are described in section 5.4.3. 5.4.3 Translation Table Maintenance [Ed. Note: This section is under revision.] This section specifies the mechanisms for creating and maintaining the translation tables used by a gateway. For descriptive purposes, Figure 8 shows an example of how a translation table entry is formatted. +--------------------------------+ | IP Address of Remote Gateway | +--------------------------------+ | N_PORT I/D | +--------------------------------+ | N_PORT Alias | +--------------------------------+ | N_PORT World-wide Unique Name | +--------------------------------+ Figure 8 -- Address Translation Table Entry for Remote Device Each entry contains the following information: IP Address of Remote Gateway -- IP address of the gateway to which the remote device is attached. N_PORT I/D -- N_PORT address assigned to the remote device by the remote iFCP gateway. Monia et-al. Standards Track [Page 24] iFCP Revision 7 November 2001 N_PORT Alias -- N_PORT address assigned to the remote device by the 'local' iFCP gateway. N_PORT World-wide Unique Name -- 64-bit N_PORT world wide name as specified in [FC-FS]. In addition to the table itself, the iFCP gateway must have some way of performing rapid table lookups when translating addresses for frame traffic as described in section 5.4.3.2. An iFCP gateway SHALL have one and only one translation table entry for each remotely attached N_PORT it accesses. If an entry does not exist, one SHALL be built in response to one of the following transactions: a) A Fibre Channel Name Server request issued by a locally-attached N_PORTs as part of Fibre Channel device discovery (see section 4.5) or, b) An N_PORT PLOGI request received from the remote Fibre Channel device (see section 8.3.7). An iFCP gateway SHALL convert each Fibre Channel Name Server request to an iSNS server query. Information returned in response to the query includes the IP address, N_PORT ID and N_PORT world wide unique name for eachremote device included in the query response. After building the table entry containing this information for a specific N_PORT, the iFCP layer SHALL create and add the 24-bit N_PORT alias. This alias SHALL then be returned to the local N_PORT as the Fibre Channel address of the remotely attached device. If a PLOGI is received from a remotely attached device and no translation table entry exists for that device, an entry SHALL be created using the following information: a) The world-wide unique name of the N_PORT contained in the PLOGI payload, b) The IP address of the remote device obtained from the TCP connection context, c) The contents of the S_ID field in the PLOGI frame header. .. The N_PORT alias may then be assigned and used in address translation as specified in section 5.4.2. 5.4.3.1.1 Updating a Translation Table Entry [Ed. Note: This section is under revision.] Monia et-al. Standards Track [Page 25] iFCP Revision 7 November 2001 A translation table entry may become stale as the result of any event that invalidates or triggers a change in the fabric-assigned 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 I/D has changed will have no N_PORT login sessions. Consequently, frames directed to an N_PORT as the result of a stale translation table entry will be rejected or discarded by the receiving Fibre Channel device. Once the originating N_PORT learns of the reconfiguration, usually through the Fibre Channel state change notification mechanism, the normal name server lookup and PLOGI mechanisms needed to reestablish the N_PORT login session will automatically purge the translation table of such stale entries. 5.4.3.2 Frame Address Translation For outbound frames, the table of external N_PORT network addresses are referenced to map the Destination N_PORT alias and Source N_PORT ID to the TCP connection context and the N_PORT ID assigned by the remote gateway. The translation process for outbound frames is shown below. Monia et-al. Standards Track [Page 26] iFCP Revision 7 November 2001 Raw Fibre Channel Frame +--------+-----------------------------------+ +--------------+ | | Destination N_PORT Alias |--->| Lookup TCP | +--------+-----------------------------------+ | connection | | | Source N_PORT ID | | context | +--------------------------------------------+ | and N_PORT ID| | | +------+-------+ | Control information, | | TCP | Payload and FC CRC | | conn | | | context +--------------------------------------------+ | & | N_PORT | ID | After Address Translation and Encapsulation | +--------------------------------------------+ | | FC Encapsulation Header | | +--------------------------------------------+ | | SOF Delimiter Word | | +============================================+ | | | Destination N_PORT ID |<----------+ +--------+-----------------------------------+ | | Source N_PORT ID | +--------+-----------------------------------+ | | | Control information, Payload | | and FC CRC | +============================================+ | EOF Delimiter Word | +--------------------------------------------+ Figure 9 -- Outbound Frame Address Translation For inbound frames, a translation table lookup is performed to regenerate the N_PORT alias from the TCP connection context and N_PORT ID contained in the encapsulated FC frame. The translation process for inbound frames is shown below. Monia et-al. Standards Track [Page 27] iFCP Revision 7 November 2001 Network Format of Inbound Frame +--------------------------------------------+ TCP | FC Encapsulation Header | Connection +--------------------------------------------+ Context | SOF Delimiter Word | | +============================================+ V | | Destination N_PORT ID | +---+----+ +--------+-----------------------------------+ | Lookup | | | Source N_PORT ID |---->| Source | +--------+-----------------------------------+ | N_PORT | | | | Alias | | Control information, Payload | +----+---+ | and FC CRC | | Source +============================================+ | N_PORT | EOF Delimiter Word | | Alias +--------------------------------------------+ | | | Frame after Address Translation and De-encapsulation | +--------+-----------------------------------+ | | | Destination N_PORT ID | | +--------+-----------------------------------+ | | | Source N_PORT Alias |<---------+ +--------+-----------------------------------+ | | | Control information, Payload, | | and FC CRC | +--------------------------------------------+ Figure 10 -- Inbound Frame Address Translation 5.4.3.3 Incompatibility with Address Transparent Mode iFCP gateways in address translation mode SHALL NOT originate or accept frames that have the TRN bit set to one in the iFCP flags field of the encapsulation header. The iFCP gateway SHALL immediately abort all N_PORT login sessions with the iFCP gateway from which it receives such frames as described in section 6.2.3.2. 6. iFCP Protocol 6.1 Overview 6.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. 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. Monia et-al. Standards Track [Page 28] iFCP Revision 7 November 2001 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 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 FC2 extended link service messages as described in section 6.1.2 6.1.2 iFCP Support for Link Services iFCP must intervene in the processing of those Fibre Channel Extended Link Service (ELS) messages which 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 an ELS, 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 ELSs, iFCP interprets the frame, including any supplemental information, modifies the frame content, and forwards the resulting frame to the destination N_PORT for further processing. Section 8.1 describes the processing of these Extended Link Service messages in detail. 6.2 TCP Stream Transport of iFCP Frames 6.2.1 iFCP Session Model Monia et-al. Standards Track [Page 29] iFCP Revision 7 November 2001 An iFCP session consists of the pair of N_PORTs comprising the session endpoints joined by a single TCP/IP connection. An N_PORT is identified by its network address consisting of: a) The N_PORT I/D assigned by the gateway to which the N_PORT is locally attached and b) The IP address of the gateway's iFCP Portal. 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 7.1). When the iFCP layer detects a Port Login (PLOGI) message creating an iFCP session between a pair of N_PORTs, 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 PLOGI login session. 6.2.2 iFCP Session Management This section describes the protocols for establishing and terminating an N_PORT login session. 6.2.2.1 Creating an iFCP Session An iFCP session may be in one of the following states: a) OPEN -- The session state in which Fibre Channel frame images may be sent and received. b) 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 gateway SHALL initiate the creation of an iFCP session in response to a PLOGI ELS directed to a remote N_PORT from a locally attached N_PORT as described in the following steps. a) If no iFCP session exists, 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 Monia et-al. Standards Track [Page 30] iFCP Revision 7 November 2001 state or a new connection may be created and placed in the Unbound state. The network address of the remote gateway is obtained from the address translation table created as described in section 5.4.3 b) If a connection cannot be allocated or created due to limited resources, the gateway SHALL terminate the PLOGI with an LS_RJT response. The Reason Code field in the LS_RJT message shall be set to 0x09 (Unable to Perform Command Request) and the Reason Explanation SHALL be set to 0x29 (Insufficient Resources to Support Login). c) If an iFCP session in the OPEN state already exists to the remote N_PORT, the gateway SHALL forward the PLOGI ELS using the existing session. d) If the iFCP session does not exist, the gateway SHALL issue a CBIND session control message (see section 7.1) and place the session in the OPEN PENDING state. e) In the event that a CBIND response is returned with one of the following statuses, the PLOGI shall be terminated with an LS_RJT message. Depending on the CBIND failure status, the Reason Code and Reason Explanation SHALL be set to the following values specified in [FC-FS]. Monia et-al. Standards Track [Page 31] iFCP Revision 7 November 2001 CBIND Failure LS_RJT Reason LS_RJT Reason Code Status Code Explanation ------------- ------------- ------------------ Unspecified Unable to Perform No additional Reason (16) Command Request explanation (0x00) (0x09) No Such Device Unable to Perform Invalid N_PORT Name (17) Command Request (0x0D). (0x09) Lack of Unable to Perform Insufficient Resources (19) Command Request Resources to Support (0x09). Login (0x29). Incompatible Unable to Perform No additional address Command Request Explanation (0x00) translation mode (0x09) (20) Incorrect iFCP Unable to Perform No additional protocol version Command Request explanation (0x00) number (21) (0x09) f) A CBIND response with a CBIND STATUS of "N_PORT 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. The receiving gateway SHALL terminate this attempt, return the connection to the Unbound state and prepare to respond to an incoming CBIND request as described below. 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 Port Name in the incoming CBIND payload with the Destination Port Name. b) If the Source 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 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, 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. Monia et-al. Standards Track [Page 32] iFCP Revision 7 November 2001 6.2.2.2 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. 6.2.2.2.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 FC4 level. For that reason and the considerations described in [RFC1122], keep alive at the transport layer should not be implemented. 6.2.2.2.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 transmission delay of the Nagle algorithm may decrease I/O throughput. The Nagle algorithm should therefore not be used. Monia et-al. Standards Track [Page 33] iFCP Revision 7 November 2001 6.2.2.2.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. 6.2.2.2.4 Wrapped Sequence Protection (PAWS) TCP segments are identified with 32-bit sequence numbers. In networks with large bandwidth - delay products, it is therefore 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]. 6.2.3 Terminating an N_PORT Login Session An N_PORT login session SHALL be terminated or aborted in response to one of the following events: a) An LS_RJT response is returned to the gateway that issued the PLOGI ELS. The gateway SHALL forward the LS_RJT to the local N_PORT and complete the session as described in section 6.2.3.1. b) An ACC received from a remote device in response to a LOGO. The gateway SHALL forward the ACC to the local N_PORT and complete the session as described in section 6.2.3.1. c) For an FC frame received from the IP network, a gateway detects a CRC error in the encapsulation header. The gateway shall abort the session as described in section 6.2.3.2. d) The TCP connection associated with the login session fails for any reason. The gateway detecting the failed connection shall abort the session as described in section 6.2.3.2. The disposition of the associated TCP connection is described in sections 6.2.3.1 and 6.2.3.2 6.2.3.1 N_PORT Login Session Completion An N_PORT login session is completed in response to a rejected PLOGI request as described in section 6.2.3 or a successful LOGO ELS. The gateway receiving one of the above responses shall issue an Unbind session control ELS as described in section 7.2. Monia et-al. Standards Track [Page 34] iFCP Revision 7 November 2001 In response to the Unbind message, either gateway may choose to close the TCP connection or return it to a pool of unbound connections. 6.2.3.2 Aborting an N_PORT Login Session An N_PORT login session SHALL be aborted if the TCP connection is spontaneously terminated or whenever one of the following occurs: a) An encapsulation error is detected as described in section 6.4.3. b) The gateway receives an encapsulated frame from a gateway operating in an incompatible address translation mode as specified in section 5.4.3.3 or 5.4.1.2. In any event, the TCP connection SHOULD be terminated with a connection reset (RST). If the local N_PORT has logged in to the remote N_PORT, the gateway SHALL send a LOGO to the local N_PORT. 6.3 IANA Considerations The IANA-assigned port for TCP traffic (iFCP regular traffic) and UDP traffic (iFCP broadcast services only, see 10.4) is port number 3420. An iFCP Portal may initiate a connection using any TCP port number consistent with its implementation of the TCP/IP stack, provided each port number is unique. To prevent the receipt of stale data associated with a previous connection using a given port number, the provisions of [RFC1323], Appendix B SHOULD be observed. 6.4 Encapsulation of Fibre Channel Frames This section describes the iFCP encapsulation of Fibre Channel frames. The encapsulation is based on the common encapsulation format defined in [ENCAP]. The format of an encapsulated frame is shown below: +--------------------+ | Header | +--------------------+-----+ | SOF | f | +--------------------+ F r | | FC frame content | C a | +--------------------+ m | | EOF | e | +--------------------+-----+ Figure 11 -- Encapsulation Format Monia et-al. Standards Track [Page 35] iFCP Revision 7 November 2001 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. When operating in Address Translation mode, (see section 5.4.2) the iFCP gateway must recalculate the Fibre Channel CRC. 6.4.1 Encapsulation Header Format W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | +---------------+---------------+---------------+---------------+ 1| Reserved (must be zero) | +---------------+---------------+---------------+---------------+ 2| LS_COMMAND | iFCP Flags | SOF | EOF | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC | +---------------------------------------------------------------+ Common Encapsulation Fields: Monia et-al. Standards Track [Page 36] iFCP Revision 7 November 2001 Protocol# IANA-assigned protocol number identifying the protocol using the encapsulation. For iFCP the value is (/TBD/). Version Encapsulation version -Protocol# Ones complement of the protocol# -Version Ones complement of the version Flags Encapsulation flags (see 6.4.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 in SNTP format [RFC2030]. Time Stamp Fractional component of the time stamp [fraction] in SNTP format [RFC2030]. 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 9.2.1. iFCP-specific fields: Monia et-al. Standards Track [Page 37] iFCP Revision 7 November 2001 LS_COMMAND For an ELS ACC response processed by iFCP, the LS_COMMAND field SHALL contain bits 31 through 24 of the LS_COMMAND to which the ACC applies. Otherwise the LS_COMMAND field shall be set to zero. iFCP Flags iFCP-specific flags (see below) SOF Copy of the SOF delimiter encoding (see section 6.4.2) EOF Copy of the EOF delimiter encoding (see section 6.4.2) The iFCP flags word has the following format: |------------------------Bit----------------------------| | | | 23 22 21 20 19 18 17 16 | +------+------+------+------+------+------+------+------+ | Reserved | SES | TRN | SPC | +------+------+------+------+------+------+------+------+ Figure 12 -- iFCP Flags Word iFCP Flags: SES 1 = Session control frame (TRN and SPC MUST be 0) TRN 1 = Address transparent mode enabled 0 = Address translation mode enabled SPC 1 = Frame is part of an ELS requiring special processing by iFCP prior to forwarding to the destination N_PORT. 6.4.1.1 Common Encapsulation Flags The iFCP usage of the common encapsulation flags is shown below: Monia et-al. Standards Track [Page 38] iFCP Revision 7 November 2001 |------------------------Bit--------------------------| | | | 31 30 29 28 27 26 | +--------------------------------------------+--------+ | Reserved | CRCV | +--------------------------------------------+--------+ For iFCP, the CRC field MUST be valid and CRCV MUST be set to one. 6.4.2 SOF and EOF Delimiter Fields The format of the delimiter fields is shown below. W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+-------------------------------+ 0| SOF | SOF | -SOF | -SOF | +---------------+---------------+-------------------------------+ 1| | +----- FC frame content -----+ | | +---------------+---------------+-------------------------------+ n| EOF | EOF | -EOF | -EOF | +---------------+---------------+-------------------------------+ Figure 13 -- FC Frame Encapsulation Format SOF (bits 31-24 and bits 23-16 in word 0): iFCP uses the following subset of the SOF fields described in [ENCAP]. +-------+----------+ | FC | | | SOF | SOF Code | +-------+----------+ | SOFi2 | 0x2D | | SOFn2 | 0x35 | | SOFi3 | 0x2E | | SOFn3 | 0x36 | +-------+----------+ Table 2-- Translation of FC SOF Values to SOF Field Contents -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the ones complement of the value in the SOF fields. EOF (bits 31-24 and 23-16 in word n): iFCP uses the following subset of EOF fields specified in [ENCAP]. Monia et-al. Standards Track [Page 39] iFCP Revision 7 November 2001 +-------+----------+ | FC | | | EOF | EOF Code | +-------+----------+ | EOFn | 0x41 | | EOFt | 0x42 | +-------+----------+ Table 3 -- Translation of FC EOF Values to EOF Field Contents -EOF (bits 15-8 and 7-0 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. 6.4.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. Frames types submitted for encapsulation and forwarding on the IP network SHALL have one of the SOF delimiters in Table 2 and an EOF delimiter from Table 3. Other valid frame types MUST be processed internally by the gateway as specified in the appropriate Fibre Channel specification. Prior to submitting a frame for encapsulation, a gateway in address translation mode SHALL replace the D_ID address, and, if processing a special ELS requiring the inclusion of supplemental data, SHALL format the frame payload and add the supplemental information as specified in section 8.1. The gateway SHALL then calculate a new FC CRC on the reformatted frame. A gateway in address transparent mode 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 above. 6.4.4 Frame De-encapsulation 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 invalid, the gateway SHALL terminate the N_PORT login session as described in section 6.2.3.2. After validating the header CRC, the receiving gateway MAY verify the frame propagation delay as described in section 9.2.1. If the propagation delay is too long, the frame SHALL be discarded. Monia et-al. Standards Track [Page 40] iFCP Revision 7 November 2001 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 2 or an EOF code that is not in Table 3. The gateway shall then de-encapsulate the frame. If operating in address translation mode, the gateway shall: a) Check the FC CRC and discard the frame if the CRC is invalid. b) Replace the S_ID with the N_PORT alias of the frame originator c) If processing an augmented ELS, replace the ELS frame with a copy whose payload has been modified as specified in section 8.1. The de-encapsulated frame SHALL then be delivered 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. 7. TCP Session Control Messages TCP session control messages are used to create and manage an iFCP session as described in section 6.2.2. They are passed between peer iFCP Portals and are only processed within the iFCP layer. The message format is based on the extended link service message template shown below. Monia et-al. Standards Track [Page 41] iFCP Revision 7 November 2001 Word 3124 23<---------------Bits------------------------->0 +----------+------------------------------------------------+ 0| R_CTL | D_ID [0x00 00 00] | |[Req = 22]| [Destination of extended link Service request] | |[Rep = 23]| | +----------+------------------------------------------------+ 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 14 -- Format of Session Control Message The LS_COMMAND value for the response remains the same as that used for the request. The session control ELS frame is terminated with a Fibre Channel CRC. The encapsulation header for the link Service frame carrying a TCP ELS message SHALL be set as follows: Encapsulation Header Fields: Monia et-al. Standards Track [Page 42] iFCP Revision 7 November 2001 LS_COMMAND 0 iFCP Flags SES = 1 TRN = 0 INT = 0 SOF code SOFi3 encoding (0x2E) EOF code EOFt encoding (0x42) Time Stamp Integer 0,0 and Fraction fields The SOF and EOF delimiter words SHALL be set based on the SOF and EOF codes specified above. The following lists the session control messages and their corresponding LS_COMMAND values. Request LS_COMMAND Short Name iFCP Support ------- ---------- ---------- ----------- Connection Bind 0xE0 CBIND REQUIRED Unbind Connection 0xE4 UNBIND REQUIRED 7.1 Connection Bind (CBIND) As described in section 6.2.2.1, the CBIND message and response are used to bind an N_PORT login session to a specific TCP connection and establish an iFCP session. In the CBIND request message, the source and destination N_Ports are identified by the N_PORT network address (iFCP portal address and N_PORT ID). The following shows the format of the CBIND request. Monia et-al. Standards Track [Page 43] iFCP Revision 7 November 2001 +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Addr Mode | iFCP Ver | +------+-------------------------+-----------+----------+ | 2 | User Info | +------+------------+------------+-----------+----------+ | 3 | | +------+ SOURCE PORT NAME | | 4 | | +------+------------------------------------------------+ | 5 | | +------+ DESTINATION PORT NAME | | 6 | | +------+------------------------------------------------+ Addr Mode - The address translation mode of the originating gateway. 0 = Address Translation mode, 1 = Address Transparent mode. iFCP Ver - iFCP version number. SHALL be set to 1. USER INFO - Contains any data desired by the requester. This info MUST be echoed by the recipient in the CBIND response message. SOURCE PORT NAME - Contains the originating N_PORT's World Wide Port Name (WWPN). DESTINATION PORT NAME - Contains the destination N_PORT's World Wide Port Name (WWPN). The following shows the format of the CBIND response. Monia et-al. Standards Track [Page 44] iFCP Revision 7 November 2001 +------+------------+------------+-----------+----------+ | Word | Byte 0 | Byte 1 | Byte 2 | Byte 3 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0xE0 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Addr Mode | iFCP Ver | +------+-------------------------+-----------+----------+ | 2 | User Info | +------+------------+------------+-----------+----------+ | 3 | | +------+ SOURCE PORT NAME | | 4 | | +------+------------------------------------------------+ | 5 | | +------+ DESTINATION PORT NAME | | 6 | | +------+-------------------------+----------------------+ | 7 | Reserved | CBIND Status | +------+-------------------------+----------------------+ | 8 | Reserved | CONNECTION HANDLE | +------+-------------------------+----------------------+ Total Length = 32 Addr Mode - The address translation mode of the responding gateway. 0 = Address Translation mode, 1 = Address Transparent mode. iFCP Ver - iFCP version number of the responding gateway. SHALL be set to 1. USER INFO - Contains the same value received in the USER INFO field of the CBIND request message. DESTINATION PORT NAME - Contains the destination N_PORT's World Wide Port Name (WWPN). CBIND STATUS - Indicates success or failure of the CBIND request. CBIND values are shown below. Value Description ----- ----------- 0 Successful û No other status 1 û 15 Reserved 16 Failed û Unspecified Reason 17 Failed û No such device 18 Failed û N_PORT session already exists 19 Failed û Lack of resources 20 Failed - Incompatible address translation mode 21 Failed - Incorrect protocol version number Others Reserved Monia et-al. Standards Track [Page 45] iFCP Revision 7 November 2001 CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the iFCP Portal to identify the connection. CHANDLE is required when issuing the UNBIND request. 7.2 Unbind Connection (UNBIND) UNBIND is used to release a bound TCP connection and return it to the pool of unbound TCP connections. This message is transmitted in the connection that is to be unbound. 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 | +------+------------+------------+-----------+----------+ CONNECTION HANDLE (CHANDLE) - Contains the value assigned by the iFCP Portal to identify the connection The following shows the format of the UNBIND response 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 | +------+------------+------------+-----------+----------+ | 5 | Reserved | UNBIND Status | +------+------------+------------+-----------+----------+ Monia et-al. Standards Track [Page 46] iFCP Revision 7 November 2001 UNBIND STATUS - Indicates the success or failure of the UNBIND request. Value Description ----- ----------- 0 Successful û No other status 1 û 15 Reserved 16 Failed û Unspecified Reason 17 Failed û No such device 18 Failed û Connection ID Invalid Others Reserved CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the iFCP Portal to identify the unbound connection. 8. Fibre Channel Link Services Link services provide a set of Fibre Channel functions that allow a port to send control information or request another port to perform a specific control function. Each Link Service message (request and reply) is carried by a Fibre Channel sequence, and can be segmented into multiple frames. The iFCP Layer is responsible for transporting link service messages across the IP fabric. This includes mapping Link Service messages appropriately from the domain of the Fibre Channel transport to that of the IP network. This process may require special processing and the inclusion of supplemental data by the iFCP layer. Each link service or extended link service is processed according to one of the following rules: a) Transparent û The link service message and reply MUST be transported to the receiving N_PORT by the iFCP gateway without altering the message payload. The link service message and reply are not processed by the iFCP implementation. b) Special - Applies to an extended link service reply or request requiring iFCP intervention before forwarding to the destination N_PORT. Such ELSs may contain Fibre Channel addresses in the payload or may require other special processing.. c) Rejected û When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the iFCP implementation. The gateway SHALL respond to a rejected link service message by returning an LS_RJT response with a Reason Code of 0x0B (Command Not Supported) and a Reason Code Explanation of 0x0 (No Additional Explanation). Monia et-al. Standards Track [Page 47] iFCP Revision 7 November 2001 This section describes the processing for special link services, including the manner in which supplemental data is added to the ELS payload.. Appendix A enumerates all link services and the iFCP processing policy that applies to each. 8.1 Special Link Service Messages Special link service messages require the intervention of the iFCP layer before forwarding to the destination N_PORT. Such intervention is required in order to: a) Service any ELS that requires special handling, such as a PLOGI. b) In address translation mode only, service any ELS which has an N_PORT address in the payload. Such ELS messages are transmitted in a Fibre Channel frame having the following format: Word 31 24 23 0 +----------+------------------------------------------------+ 0| R_CTL | D_ID | | [22] | [Destination of extended link Service request] | +----------+------------------------------------------------+ 1| CS_CTL | S_ID | | | [Source of extended link service request] | +----------+------------------------------------------------+ 2| TYPE | F_CTL | +----------+------------------+-----------------------------+ 3| SEQ_ID | DF_CTL | SEQ_CNT | +----------+------------------+-----------------------------+ 4| OX_ID | RX_ID | +-----------------------------+-----------------------------+ 5| Parameter | | [ 00 00 00 00 ] | +-----------------------------------------------------------+ 6| LS_COMMAND | | [Extended Link Service Command Code] | +-----------------------------------------------------------+ 7| | .| Additional Service Request Parameters | .| ( if any ) | n| | +-----------------------------------------------------------+ Figure 15 -- Format of Extended Link Service Frame 8.2 Link Services Requiring Payload Address Translation Monia et-al. Standards Track [Page 48] iFCP Revision 7 November 2001 This section describes the handling for ELS frames containing N_PORT addresses in the ELS payload. Such addresses SHALL only be translated when the gateway is operating in address translation mode. When operating in address transparent mode, these addresses SHALL NOT be translated and such ELS messages SHALL NOT be sent as special frames unless other processing by the iFCP layer is required. Supplemental data includes information required by the receiving gateway to convert an N_PORT address in the payload to an N_PORT address in the receiving gatewayÆs address space. The following rules define the manner in which such supplemental data is packaged and referenced. For an N_PORT address field, the gateway originating the frame MUST set the value in the payload to identify the address translation type as follows: 0x00 00 01 û The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT alias of the frame originator. This translation type MUST be used when the address to be converted is that of the source N_PORT. 0x00 00 02 û The gateway receiving the frame from the IP network MUST replace the contents of the field with the N_PORT I/D of the destination N_PORT. This translation type MUST be used when the address to be converted is that of the destination N_PORT 0x00 00 03 û The gateway receiving the frame from the IP network MUST reference the specified supplemental data to set the field contents. The supplemental information is the 64-bit world wide identifier of the N_PORT as set forth in the Fibre Channel specification [FC-FS]. If not otherwise part of the ELS, this information MUST be appended in accordance with the applicable ELS description. Unless specified otherwise, this translation type SHALL NOT be used if the address to be converted corresponds to that of the frame originator or recipient. Since Fibre Channel addressing rules prohibit the assignment of fabric addresses with a domain I/D of 0, the above codes will never correspond to valid N_PORT fabric IDs. For translation type 3, the receiving gateway SHALL obtain the information needed to fill in the ELS field by converting the specified N_PORT world-wide identifier to a gateway IP address and N_PORT ID. This information MUST be obtained through a name server query. If the N_PORT is locally attached, the gateway MUST fill in the field with the N_PORT ID. If the N_PORT is remotely attached, Monia et-al. Standards Track [Page 49] iFCP Revision 7 November 2001 the gateway MUST assign and fill in the field with an N_PORT alias. If an N_PORT alias has already been assigned, it MUST be reused. In the event that the sending gateway cannot obtain the world wide identifier of an N_PORT, or a receiving gateway cannot obtain the IP address and N_PORT ID, the gateway detecting the error SHALL terminate the request with an LS_RJT message as described in [FCS]. The Reason Code SHALL be set to 0x07 (protocol error) and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier). Supplemental data is sent with the ELS request or ACC frames in one of the following ways: a) By appending the necessary data to the end of the ELS frame. b) By extending the sequence with additional frames. In the first case, a new frame SHALL be created whose length includes the supplemental data. The procedure for extending the ELS sequence with additional frames is dependent on the ELS type.. After applying the supplemental data, the receiving gateway SHALL forward the resulting ELS frames to the destination N_PORT with the supplemental information removed. When the ACC response requires iFCP intervention,, the receiving gateway MUST act as a proxy for the originator, retaining the state needed to process the response from the N_PORT to which the request was directed. 8.3 Fibre Channel Link Services Processed by iFCP The following Link Service Messages must receive special processing. . Each encapsulated Fibre Channel frame that is part of such an ELS MUST have the SPC bit set to one in the iFCP FLAGS field of the encapsulation header as specified in section 6.4.1. Supplemental data (if any) MUST be appended as described in the following section. Monia et-al. Standards Track [Page 50] iFCP Revision 7 November 2001 Link Service Message LS_COMMAND Mnemonic -------------------- ---------- -------- Abort Exchange 0x06 00 00 00 ABTX Discover Address 0x52 00 00 00 ADISC Discover Address Accept 0x02 00 00 00 ADISC ACC FC Address Resolution Protocol 0x55 00 00 00 FARP-REPLY Reply FC Address Resolution Protocol 0x54 00 00 00 FARP-REQ Request Logout 0x05 00 00 00 LOGO Port Login 0x30 00 00 00 PLOGI Read Exchange Concise 0x13 00 00 00 REC Read Exchange Concise Accept 0x02 00 00 00 REC ACC Read Exchange Status Block 0x08 00 00 00 RES Read Exchange Status Block 0x02 00 00 00 RES ACC Accept Read Link Error Status Block 0x0F 00 00 00 RLS Read Sequence Status Block 0x09 00 00 00 RSS Reinstate Recovery Qualifier 0x12 00 00 00 RRQ Request Sequence Initiative 0x0A 00 00 00 RSI Third Party Process Logout 0x24 00 00 00 TPRLO Third Party Process Logout 0x02 00 00 00 TPRLO ACC Accept The formats of each special ELS, including supplemental data where applicable, are shown in the following sections. Each ELS diagram shows the basic format, as specified in the applicable FC standard, followed by supplemental data as shown in the example below. +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | LS_COMMAND | +------+------------+------------+-----------+----------+ | 1 | | | . | | | . | ELS Payload | | | | | n | | +======+============+============+===========+==========+ | n+1 | | | . | Supplemental Data | | . | (if any) | | n+k | | +======+================================================+ ELS Diagram (single FC Frame Format) 8.3.1 Abort Exchange (ABTX) ELS Format: Monia et-al. Standards Track [Page 51] iFCP Revision 7 November 2001 +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x6 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | RRQ Status | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID of Tgt exchange | RX_ID of tgt exchange| +------+------------+------------+-----------+----------+ | 3-10 | Optional association header (32 bytes | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- section 8.2) ------------ ----------- Exchange Originator 1, 2 N/A S_ID Other Special Processing: None 8.3.2 Discover Address (ADISC) Format of ADISC ELS: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x52 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT I/D of ELS Originator | +======+============+============+===========+==========+ Monia et-al. Standards Track [Page 52] iFCP Revision 7 November 2001 Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- section 8.2) ------------ ------------- N_PORT I/D of ELS 1 N/A Originator Other Special Processing: The Hard Address of the ELS originator SHALL be set to 0. 8.3.3 Discover Address Accept (ADISC ACC) Format of ADISC ACC ELS: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x20 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Reserved | Hard address of ELS Originator | +------+------------+------------+-----------+----------+ | 2-3 | Port Name of Originator | +------+------------+------------+-----------+----------+ | 4-5 | Node Name of originator | +------+------------+------------+-----------+----------+ | 6 | Rsvd | N_PORT I/D of ELS Originator | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- section 8.2) ------------ ------------ N_PORT I/D of ELS 1 N/A Originator Other Special Processing: The Hard Address of the ELS originator SHALL be set to 0. 8.3.4 FC Address Resolution Protocol Reply (FARP-REPLY) The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see section 8.3.5) to perform the address resolution services Monia et-al. Standards Track [Page 53] iFCP Revision 7 November 2001 required by the FC-VI protocol [FC-VI] and the Fibre Channel mapping of IP and ARP specified in RFC 2625 [RFC2625]. Format of FARP-REPLY ELS: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x55 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Match Addr | Requesting N_PORT Identifier | | | Code Points| | +------+------------+------------+-----------+----------+ | 2 | Responder | Responding N_PORT Identifier | | | Action | | +------+------------+------------+-----------+----------+ | 3-4 | Requesting N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 5-6 | Requesting N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 7-8 | Responding N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 9-10 | Responding N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 11-14| Requesting N_PORT IP Address | +------+------------+------------+-----------+----------+ | 15-18| Responding N_PORT IP Address | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- section 8.2) ----------------- ------------- Requesting N_PORT 2 N/A Identifier Responding N_PORT 1 N/A identifier Other Special Processing: None. 8.3.5 FC Address Resolution Protocol Request (FARP-REQ) Monia et-al. Standards Track [Page 54] iFCP Revision 7 November 2001 The FARP-REQ ELS is used to in conjunction with the FC-VI protocol [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP and FC address resolution in an FC fabric. The FARP-REQ ELS is usually directed to the fabric broadcast server at well-known address 0xFF-FF-FF for retransmission to all attached N_PORTs. Section 10.4 describes the iFCP implementation of FC broadcast server functionality in an iFCP fabric. Format of FARP_REQ ELS: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x54 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Match Addr | Requesting N_PORT Identifier | | | Code Points| | +------+------------+------------+-----------+----------+ | 2 | Responder | Responding N_PORT Identifier | | | Action | | +------+------------+------------+-----------+----------+ | 3-4 | Requesting N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 5-6 | Requesting N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 7-8 | Responding N_PORT Port_Name | +------+------------+------------+-----------+----------+ | 9-10 | Responding N_PORT Node_Name | +------+------------+------------+-----------+----------+ | 11-14| Requesting N_PORT IP Address | +------+------------+------------+-----------+----------+ | 15-18| Responding N_PORT IP Address | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 3 only) ------------------- section 8.2) ----------------- ----------- Requesting N_PORT 3 Requesting N_PORT Identifier Port Name Responding N_PORT 3 Responding N_PORT Identifier Port Name Other Special Processing: None. Monia et-al. Standards Track [Page 55] iFCP Revision 7 November 2001 8.3.6 Logout (LOGO) ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x5 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | N_PORT I/D being logged out | +------+------------+------------+-----------+----------+ | 2-3 | Port name of the LOGO originator (8 bytes) | +======+============+============+===========+==========+ This ELS shall always be sent as an augmented ELS regardless of the translation mode in effect. Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) -------------- ----------- N_PORT I/D Being 1 N/A Logged Out Other Special Processing: See section 6.2.3.1. 8.3.7 Port Login (PLOGI) and PLOGI ACC PLOGI provides the mechanism for establishing a login session between two N_PORTs. In iFCP, a PLOGI request addressed to a remotely attached N_PORT may trigger the creation of an iFCP session, if one does not already exist. Otherwise, the PLOGI and ACC payloads MUST be passed transparently to the destination N_PORT. The PLOGI request and ACC response carry information identifying the originating N_PORT, including specification of its capabilities and limitations. If the destination N_PORT accepts the login request, it sends an accept (an ACC frame with PLOGI payload), specifying its capabilities and limitations. This exchange establishes the operating environment for the two N_PORTs. The following figure is duplicated from [FC-FS], and shows the PLOGI message format for both request and accept (ACC) response. A Monia et-al. Standards Track [Page 56] iFCP Revision 7 November 2001 port will reject a PLOGI request by transmitting an LS_RJT message, which contains no payload. Byte Offset +----------------------------------+ 0 | LS_COMMAND | 4 Bytes +----------------------------------+ 4 | COMMON SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 20 | PORT NAME | 8 Bytes +----------------------------------+ 28 | NODE NAME | 8 Bytes +----------------------------------+ 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 102 | VENDOR VERSION LEVEL | 16 Bytes +----------------------------------+ Total Length = 116 bytes Figure 16 -- Format of PLOGI Request and ACC Payloads Details on the above fields, including common and class-based service parameters, can be found in [FC-FS]. 8.3.8 Read Exchange Status Block (RES) ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x13 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association header (may be optionally reqÆd) | +======+============+============+===========+==========+ | 11-12| Port name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ Monia et-al. Standards Track [Page 57] iFCP Revision 7 November 2001 Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) ------------------ ----------- Exchange Originator 1, 2 or 3 Port Name of the S_ID Exchange Originator Other Special Processing: None. 8.3.9 Read Exchange Status Block Accept Format of ELS Accept Response: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Acc = 0x02 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 2 | Rsvd | Exchange Originator N_PORT ID | +------+------------+------------+-----------+----------+ | 3 | Rsvd | Exchange Responder N_PORT ID | +------+------------+------------+-----------+----------+ | 4 | Exchange Status Bits | +------+------------+------------+-----------+----------+ | 5 | Reserved | +------+------------+------------+-----------+----------+ | 6ûn | Service Parameters and Sequence Statuses | | | as described in [FCS] | +======+============+============+===========+==========+ |n+1- | Port name of the Exchange Originator (8 bytes) | |n+2 | | +======+============+============+===========+==========+ |n+3- | Port name of the Exchange Responder (8 bytes) | |n+4 | | +======+============+============+===========+==========+ Monia et-al. Standards Track [Page 58] iFCP Revision 7 November 2001 Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) ------------------ ----------- Exchange Originator 1, 2 or 3 Port Name of the N_PORT I/D Exchange Originator Exchange Responder 1, 2 or 3 Port Name of the N_0ORT I/D Exchange Responder When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. If the translation type for the Exchange Originator N_PORT I/D or the Exchange Responder N_PORT I/D is 1 or 2, the corresponding 8-byte port name SHALL be set to all zeros. Other Special Processing: None. 8.3.10 Read Link Error Status (RLS) ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x0F | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | N_PORT Identifier | +======+============+============+===========+==========+ | 2-3 | Port name of the N_PORT (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data (type Address Translation Type(see 3 only) ------------------- section 8.2) ------------------ ----------- N_PORT Identifier 1, 2 or 3 Port Name of the N_PORT Other Special Processing: None. 8.3.11 Read Sequence Status Block (RSS) ELS Format: Monia et-al. Standards Track [Page 59] iFCP Revision 7 November 2001 +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x09 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | SEQ_ID | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +======+============+============+===========+==========+ | 3-4 |Port name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) ------------------ ----------- Exchange Originator 1, 2 or 3 Port Name of the S_ID Exchange Originator Other Special Processing: None. 8.3.12 Reinstate Recovery Qualifier (RRQ) ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x12 | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association header (may be optionally reqÆd) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Monia et-al. Standards Track [Page 60] iFCP Revision 7 November 2001 Other Special Processing: None. 8.3.13 Request Sequence Initiative (RSI) ELS Format: +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | Cmd = 0x0A | 0x00 | 0x00 | 0x00 | +------+------------+------------+-----------+----------+ | 1 | Rsvd | Exchange Originator S_ID | +------+------------+------------+-----------+----------+ | 2 | OX_ID | RX_ID | +------+------------+------------+-----------+----------+ | 3-10 | Association header (may be optionally reqÆd) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 3 only) ------------------- section 8.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Other Special Processing: None. 8.3.14 Third Party Process Logout (TPRLO) TPRLO provides a mechanism for an N_PORT (third party) to remove one or more process login sessions that exist between the destination N_PORT and other N_PORTs specified in the command. This command includes one or more TPRLO LOGOUT PARAMETER PAGEs, each of which when combined with the destination N_PORT identifies a process login to be terminated by the command. Monia et-al. Standards Track [Page 61] iFCP Revision 7 November 2001 +--------+------------+--------------------+----------------------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15 - 0 | +--------+------------+--------------------+----------------------+ | 0 | Cmd = 0x24 | Page Length (0x10) | Payload Length | +--------+------------+--------------------+----------------------+ | 1 | TPRLO Logout Parameter Page 0 | +--------+--------------------------------------------------------+ | 5 | TPRLO Logout Parameter Page 1 | +--------+--------------------------------------------------------+ .... +--------+--------------------------------------------------------+ |(4*n)+1 | TPRLO Logout Parameter page n | +--------+--------------------------------------------------------+ Figure 17 -- Format of TPRLO ELS Each TPRLO parameter page contains parameters identifying one or more image pairs and may be associated with a single FC4 protocol type, common to all FC4 protocol types between the specified image pair, or global to all specified image pairs. The format of aTPRLO page requiring address translation is shown in Figure 18. Additional information on TPRLO can be found in [FC-FS]. +------+------------+------------+-----------+----------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15-8 | Bits 7-0 | +------+------------+------------+-----------+----------+ | 0 | TYPE Code | TYPE CODE | | | | or | EXTENSION | TPRLO Flags | | | Common SVC | | | | | Parameters | | | +------+------------+------------+-----------+----------+ | 1 | Third Party Process Associator | +------+------------+------------+-----------+----------+ | 2 | Responder Process Associator | +------+------------+------------+-----------+----------+ | 3 | Reserved | Third Party Originator N_PORT ID | +======+============+============+===========+==========+ | 4-5 | World Wide Name of Third Party Originator | | | N_PORT | +------+------------------------------------------------+ Figure 18 -- Format of an Augmented TPRLO Parameter Page The TPRLO flags that affect the processing of the supplementedELS are as follows: Bit 12: Global Process logout. When set to one, this bit indicates that all image pairs for all N_PORTs of the specified FC4 protocol shall be invalidated. When the value of this bit is one, only one logout parameter page is permitted in the TPRLO payload. Bit 13: Third party Originator N_PORT Validity. When set to one, this bit indicates that word 3, bits 23-00 (Third Monia et-al. Standards Track [Page 62] iFCP Revision 7 November 2001 Party Originator N_PORT ID) are meaningful. If bit 13 has a value of zero and bit 12 has a value of one in the TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS. Otherwise the originating gateway SHALL process the ELS as follows: a) The first word of the TPRLO payload SHALL NOT be modified. b) Each TPRLO parameter page shall be extended by two words as shown in Figure 18. c) If word 0, bit 13 (Third Party Originator N_PORT I/D validity) in the TPRLO flags field has a value of one, then the sender shall place the world-wide port name of the fibre channel device's N_PORT in the extension words. The N_PORT I/D SHALL be set to 3. Otherwise, the contents of the extension words and the Third Party Originator N_PORT ID SHALL be set to zero. d) The ELS originator SHALL set the SPC bit in the encapsulation header of each augmented frame comprising the ELS (see section 6.4.1). e) If the ELS contains a single TPRLO parameter page, the originator SHALL increase the frame length as necessary to include the extended parameter page. f) If the ELS to be augmented contains multiple TPRLO parameter pages, the FC frames created to contain the augmented ELS payload SHALL NOT exceed the maximum frame size that can be accepted by the destination N_PORT. Each Fibre Channel frame SHALL contain an integer number of extended TPRLO parameter pages. The maximum number of extended TPRLO parameter pages in a frame SHALL be limited to the number that can be held without exceeding the above upper limit. New frames resulting from the extension of the TPRLO pages to include the supplemental data shall be created by extending the SEQ_CNT in the Fibre Channel frame header. The SEQ_ID SHALL NOT be modified. The gateway receiving the augmented TPRLO ELS SHALL generate ELS frames to be sent to the destination N_PORT by copying word 0 of the ELS payload and processing each augmented parameter page as follows: a) If word 0, bit 13 has a value of one, create a parameter page by copying words 0 through 2 of the augmented parameter page. The Third Party Originator N_PORT I/D in word 3 shall be generated Monia et-al. Standards Track [Page 63] iFCP Revision 7 November 2001 by referencing the supplemental data as described in section 8.2. b) If word 0, bit 13 has a value of zero, create a parameter page by copying words 0 through 3 of the augmented parameter page. The size of each frame to be sent to the destination N_PORT MUST NOT exceed the maximum frame size that the destination N_PORT can accept. The sequence identifier in each frame header SHALL be copied from the augmented ELS and the sequence count shall be monotonically increasing. 8.3.15 Third Party Logout Accept (TPRLO ACC) The format of the TPRLO ACC frame is shown in Figure 19. +--------+------------+--------------------+----------------------+ | Word | Bits 31û24 | Bits 23û16 | Bits 15 - 0 | +--------+------------+--------------------+----------------------+ | 0 | Cmd = 0x2 | Page Length (0x10) | Payload Length | +--------+------------+--------------------+----------------------+ | 1 | TPRLO Logout Parameter Page 0 | +--------+--------------------------------------------------------+ | 5 | TPRLO Logout Parameter Page 1 | +--------+--------------------------------------------------------+ .... +--------+--------------------------------------------------------+ |(4*n)+1 | TPRLO Logout Parameter page n | +--------+--------------------------------------------------------+ Figure 19 -- Format of TPRLO ACC ELS The format of the parameter page and rules for parameter page augmentation are as specified in section 8.3.14. 8.4 FLOGI Service Parameters Supported by an iFCP Gateway The FLOGI ELS is issued by an N_PORT that wishes to access the fabric transport services. The format of the FLOGI request and FLOGI ACC payloads are identical to the PLOGI request and ACC payloads described in section 8.3.7. The figure in that section is duplicated below for convenience. Monia et-al. Standards Track [Page 64] iFCP Revision 7 November 2001 Byte Offset +----------------------------------+ 0 | LS_COMMAND | 4 Bytes +----------------------------------+ 4 | COMMON SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 20 | PORT NAME | 8 Bytes +----------------------------------+ 28 | NODE NAME | 8 Bytes +----------------------------------+ 36 | CLASS 1 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 52 | CLASS 2 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 68 | CLASS 3 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 86 | CLASS 4 SERVICE PARAMETERS | 16 Bytes +----------------------------------+ 102 | VENDOR VERSION LEVEL | 16 Bytes +----------------------------------+ Figure 20 -- FLOGI Request and ACC Payload Format A full description of each parameter is given in [FC-FS]. This section tabulates the protocol-dependant service parameters supported by a fabric port attached to an iFCP gateway. The service parameters carried in the payload of an FLOGI extended link service request MUST be set in accordance with Table 4. Monia et-al. Standards Track [Page 65] iFCP Revision 7 November 2001 +-----------------------------------------+---------------+ | | Fabric Login | | Service Parameter | Class | | +---+---+---+---+ | | 1 | 2 | 3 | 4 | +-----------------------------------------+---+---+---+---+ | Class Validity | n | M | M | n | +-----------------------------------------+---+---+---+---+ | Service Options | | +-----------------------------------------+---+---+---+---+ | Intermix Mode | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Stacked Connect-Requests | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Sequential Delivery | n | M | M | n | +-----------------------------------------+---+---+---+---+ | Dedicated Simplex | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Camp on | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Buffered Class 1 | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Priority | n | n | n | n | +-----------------------------------------+---+---+---+---+ | Initiator/Recipient Control | | +-----------------------------------------+---+---+---+---+ | Clock synchronization ELS capable | n | n | n | n | +-----------------------------------------+---+---+---+---+ Table 4 -- FLOGI Service Parameter Settings Notes: 1) "n" indicates a parameter or capability that is not supported by the iFCP protocol. 2) "M" indicates an applicable parameter that MUST be supported by an iFCP gateway. 9. iFCP Error Detection 9.1 Overview [FC-FS] defines error detection and recovery procedures. These Fibre Channel-defined mechanisms continue to be available in the iFCP environment. 9.2 Stale Frame Prevention Recovery from Fibre Channel protocol error conditions requires that frames associated with a failed or aborted Exchange drain from the fabric before Exchange resources can be safely reused. Monia et-al. Standards Track [Page 66] iFCP Revision 7 November 2001 Since a Fibre Channel fabric may not preserve frame order, there is no deterministic way to purge such frames. Instead, the fabric guarantees that frame the lifetime will not exceed a specific limit (R_A_TOV). R_A_TOV is defined in [FC-FS] as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". For example, a value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC4 ELS request must wait for the response to that request. The Fibre Channel default value for R_A_TOV is 10 seconds. The iFCP fabric MAY actively enforce limits on R_A_TOV as described in section 9.2.1. [Ed. Note: The criteria for enabling stale frame enforcement is /TBS/.] 9.2.1 Enforcing R_A_TOV Limits The R_A_TOV limit on frame lifetimes MAY be enforced by means of the time stamp in the encapsulation header (see section 6.4.1) as described in this section. The budget for R_A_TOV SHOULD include allowances for the propagation delay through the gateway regions of the sending and receiving N_PORTs plus the propagation delay through the IP network. This latter component is referred to in this specification as IP_TOV. If enforced by a gateway, IP_TOV should be set well below the value of R_A_TOV specified for the iFCP fabric and should be stored in the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV. The following paragraphs describe the requirements for synchronizing gateway time bases and the rules for measuring and enforcing propagation delay limits. The protocol for synchronizing a gateway time base is SNTP [RFC2030]. In order to insure that all gateways are time-aligned, a gateway SHOULD obtain the address of an SNTP-compatible time server via an iSNS query. If multiple time server addresses are returned by the query, the servers must be synchronized and the gateway may use any server in the list. Alternatively, the server may return a multicast group address in support of operation in Anycast mode. Implementation of Anycast mode is as specified in [RFC2030], including the precautions defined in that document. Multicast mode SHOULD NOT be used. An SNTP server may use any one of the time reference sources listed in [RFC2030]. The resolution of the time reference MUST be 125 milliseconds or better. Monia et-al. Standards Track [Page 67] iFCP Revision 7 November 2001 Stability of the SNTP server and gateway time bases should be 100 ppm or better. With regard to its time base, the gateway is in either the Synchronized or Unsynchronized state. When in the Unsynchronized state, the gateway SHALL: a) Set the time stamp field to 0,0 for all outgoing frames b) Ignore the time stamp field for all incoming frames. When in the synchronized state, the gateway SHALL a) Set the time stamp field for each outgoing frame in accordance with the gateway's internal time base b) Check the time stamp field of each incoming frame, following validation of the encapsulation header CRC as described in section 6.4.4. c) If the incoming frame has a time stamp of 0,0, the receiving gateway SHALL NOT test the frame to determine if it is stale. d) If the incoming frame has a non-zero time stamp, the receiving gateway SHALL compute the absolute value of the time in flight and SHALL compare it against the value of IP_TOV specified for the IP fabric. e) If the result in step (d) exceeds IP_TOV, the encapsulated frame shall be discarded. Otherwise, the frame shall be de- encapsulated as described in section 6.4.4. A gateway SHALL enter the Synchronized state upon receiving a successful response to an SNTP query. A gateway shall enter the Unsynchronized state: a) Upon power up and before successful completion of an SNTP query b) Whenever the gateway looses contact with the SNTP server such that the gateway's time base may no longer be in alignment with that of the SNTP server. The criterion for determining loss of contact is implementation specific. Following loss of contact, it is recommended that the gateway enter the Unsynchronized state when the estimated time base drift relative to the SNTP reference is greater than ten percent of the IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and IP_TOV equals 5 seconds, the maximum allowable loss of contact duration would be about 42 minutes.) Monia et-al. Standards Track [Page 68] iFCP Revision 7 November 2001 In response to loss of synchronization, a gateway enforcing R_A_TOV limits as described in this section should abort all N_PORT login sessions as described in section 6.2.3.2. 10. Fabric Services Supported by an iFCP implementation An iFCP gateway implementation MUST support the following fabric services: N_PORT ID Value Description Section --------------- ----------- ------- 0xFF-FF-FE F_PORT Server 10.1 0xFF-FF-FD Fabric Controller 10.2 0xFF-FF-FC Directory/Name Server 10.3 In addition, an iFCP gateway MAY support the FC broadcast server functionality described in section 10.4. 10.1 F_PORT Server The F_PORT server SHALL support the FLOGI ELS as described in section 8.4 as well as the following ELSs specified in [FC-FS]: a) Request for fabric service parameters (FDISC), b) Request for the link error status (RLS), c) Read Fabric Timeout Values (RTV). 10.2 Fabric Controller The Fabric Controller SHALL support the following ELSs as specified in [FC-FS]: a) State Change Notification (SCN), b) Registered State Change Notification (RSCN), c) State Change Registration (SCR). 10.3 Directory/Name Server The Directory/Name server provides a registration service allowing an N_PORT to record or query the database for information about other N_PORTs. The services are defined in [FC-GS3]. The queries Monia et-al. Standards Track [Page 69] iFCP Revision 7 November 2001 are issued as FC-4 transactions using the FC-CT command transport protocol specified in [FC-GS3]. In iFCP, name server requests are translated to the iSNS queries defined in [ISNS]. The definitions of name server objects are specified in [FC-GS3]. The name server SHALL support record and query operations for directory subtype 0x02 (Name Server) and 0x03 (IP Address Server) and MAY support the FC-4 specific services as defined in [FC-GS3]. 10.4 iFCP Support for the FC Broadcast Service In Fibre Channel, frames are broadcast by addressing them to the broadcast server at well-known address 0xFF-FF-FF. The broadcast server then replicates and delivers the frame to each attached N_PORT in all zones to which the originating device belongs. Only class 3 (datagram) service is supported. In an iFCP system, outgoing frames to be broadcast are directed to the gateway-resident broadcast server by locally attached N_PORTs. The broadcast server then redistributes such frames as follows: a) One copy is sent to each locally attached N_PORT in the same discovery domain as the originator. b) One copy is sent to the broadcast server in each remote gateway via a UDP datagram. The D_ID field is set to the well-known address of the FC broadcast server. The datagram encapsulation format is identical to the iFCP encapsulation format described in section 6.4. The UDP datagram SHALL be sent to the IANA- assigned port number at the specified IP address. The DF bit SHALL be set to 1 in the IP header to prohibit IP fragmentation (see [RFC791]). On receiving an iFCP broadcast datagram via UDP, the broadcast server SHALL: a) Validate the encapsulation header as described in section 6.4.3. If the header is invalid, the frame SHALL be discarded. b) Convert the S_ID N_PORT address in the frame to an N_PORT alias as described in section 5.4.2, if address translation mode is in effect. c) If the SPC bit is set in the iFCP flags field, perform any special processing required by the ELS, including translation of any addresses in the payload. d) Replicate and redistribute the frame to all locally attached N_PORTs in the discovery domain of the sender. Monia et-al. Standards Track [Page 70] iFCP Revision 7 November 2001 If no broadcast server is implemented, the receiving gateway SHALL discard an incoming broadcast frame from a remote gateway. Broadcast frames received from locally attached N_PORTs shall be processed as specified in[FC-GS3]. 11. iFCP Security 11.1 Overview iFCP relies upon the IPSec protocol suite to provide data confidentiality and authentication services and IKE as the key management protocol. Section 11.2 describes the security requirements arising from iFCPÆs operating environment while Section 11.3 describes the resulting design choices, their requirement levels, and how they apply to the iFCP protocol. 11.2 iFCP Security Operating Requirements 11.2.1 Context iFCP is a protocol designed for use by gateway devices deployed in enterprise data centers. Such environments typically have security gateways designed to provide network security through isolation from public networks. Furthermore, iFCP data may need to traverse security gateways in order to support SAN-to-SAN connectivity across public networks. 11.2.2 Security Threats Communicating iFCP gateways are vulnerable to attacks. Examples of attacks include attempts by an adversary to: a) Acquire confidential data and identities by snooping data packets. b) Modify packets containing iFCP data and control messages. c) Inject new packets into the iFCP session. d) Hijack the TCP connection carrying the iFCP session. e) Launch denial of service attacks against the iFCP gateway. f) Disrupt security negotiation process. g) Impersonate a legitimate security gateway. h) Compromise communication with the iSNS server. It is imperative to thwart these attacks, given that an iFCP gateway is the last line of defense for a whole Fibre Channel island, which may include several hosts and switches. To do so, the Monia et-al. Standards Track [Page 71] iFCP Revision 7 November 2001 iFCP protocol MUST define confidentiality, authentication, integrity, and replay protection on a per-datagram basis. It also MUST define a scalable approach to key management. Conformant implementations of the iFCP protocol MAY use such definitions. 11.2.3 Interoperability Requirements with Security Gateways Enterprise data center networks are considered mission-critical facilities that must be isolated and protected from all possible security threats. Such networks are usually protected by security gateways, which at a minimum provide a shield against denial of service attacks. The iFCP security architecture must be able to leverage the protective services of the existing security infrastructure, including firewall protection, NAT and NAPT services, and IPSec VPN services available on existing security gateways. 11.2.4 Statically and Dynamically Assigned IP Addresses As iFCP gateways and switches are deployed within enterprise networks, it is expected that, like most routers and switches, gateway IP addresses will be statically assigned. Consequently, IKE and IPSec features focused on supporting DHCP and other dynamic IP address assignment capabilities for mobile hosts are not strictly required. Since the iFCP protocol cannot rule out the use of dynamically assigned IP addresses however, the security definitions for the iFCP protocol shall not exhibit any vulnerability in the case of dynamically assigned IP addresses (e.g., via DHCP [RFC2131]). 11.2.5 Authentication Requirements iFCP is a peer-to-peer protocol. iFCP sessions may be initiated by either or both peer gateways. Consequently, bi-directional authentication of peer gateways MUST be provided. Fibre Channel, operating system and user identities are transparent to the iFCP protocol. IKE and IPSec authentication used to protect iFCP traffic shall be based upon the IP addresses of the communicating peer gateways. iFCP gateways shall use Discovery Domain information obtained from the iSNS server [ISNS] to determine whether the initiating Fibre Channel N_PORT should be allowed access to the target N_PORT. N_PORT identities used in the Port Login (PLOGI) process shall be considered authenticated provided the PLOGI request is received from the remote gateway over a secure, IPSec-protected connection. There is no requirement that the identities used in authentication be kept confidential. 11.2.6 Confidentiality Requirements Monia et-al. Standards Track [Page 72] iFCP Revision 7 November 2001 iFCP traffic may traverse insecure public networks, and therefore implementations MUST have per-packet encryption capabilities to provide confidentiality. 11.2.7 Rekeying Requirements Due to the high data transfer rates and the amount of data involved, an iFCP gateway implementation MUST support the capability to rekey each phase 2 security association in time intervals as often as every 25 seconds. The iFCP gateway MUST provide the capability for forward secrecy in the rekeying process. 11.2.8 Usage Requirements It must be possible for compliant iFCP implementations to administratively disable any and all security mechanisms. It must also be possible to apply different security requirements to individual N_PORT login session. Implementations may elect to expose such fine level of control through a management interface or through interaction with the iSNS. 11.2.9 iSNS Role iSNS [ISNS] is an invariant in all iFCP deployments. iFCP gateways use iSNS for discovery services, and MAY use security policies configured in the iSNS database as the basis for algorithm negotiation in IKE. The iSNS specification defines mechanisms to secure communication between an iFCP gateway and iSNS server(s). Additionally, such specification indicates how elements of security policy concerning individual iFCP sessions can be retrieved from iSNS server(s). 11.3 iFCP Security Design 11.3.1 Enabling Technologies Applicable technology from IPsec and IKE is defined in the following suite of specifications: [RFC2401] Security Architecture for the Internet Protocol [RFC2402] IP Authentication Header [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV [RFC2406] IP Encapsulating Security Payload [RFC2407] The Internet IP Security Domain of Interpretation for ISAKMP Monia et-al. Standards Track [Page 73] iFCP Revision 7 November 2001 [RFC2408] Internet Security Association and Key Management Protocol (ISAKMP) [RFC2409] The Internet Key Exchange (IKE) [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC [RFC2451] The ESP CBC-Mode Cipher Algorithms [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains The implementation of IPsec and IKE is required according the following guidelines. Support for the IP Encapsulating Security Payload (ESP) [RFC2406] is MANDATORY to implement. As stated in [RFC2406], the following authentication algorithms MUST be implemented: a) HMAC with SHA1 [RFC2404] b) NULL authentication The Advanced Encryption Standard [AES]in CBC MAC mode with Extended Cipher Block Chaining [XCBC] SHOULD be implemented. The following encryption algorithms MUST be implemented: a) NULL encryption [RFC2410] b) 3DES in CBC mode [RFC2451] AES counter mode encryption [AESCTR] SHOULD be implemented. Implementation of DES in CBC mode [RFC2405] is OPTIONAL. It is recommended that DES in CBC mode SHOULD NOT be used due to its inherent weakness. It is in fact well known that DES is crackable with modest computation resources, and so is inappropriate for use in any iFCP deployment scenario requiring levels of security. A conformant iFCP protocol implementation MUST implement IPsec ESP in tunnel mode [RFC2709], and MAY implement IPsec ESP in transport mode [RFC2406]. Regarding key management, iFCP implementations MUST support IKE [RFC2409] for peer authentication, negotiation of security associations, and key management, using the IPsec DOI. Manual keying MUST NOT be used since it does not provide the necessary keying support. According to [RFC2409], pre-shared secret key authentication is MANDATORY to implement, whereas certificate-based peer authentication using digital signatures MAY be implemented Monia et-al. Standards Track [Page 74] iFCP Revision 7 November 2001 (see section 11.3.3 regarding the use of certificates). [RFC2409] defines the following requirement levels for IKE Modes: Phase-1 Main Mode MUST be implemented Phase-1 Aggressive Mode SHOULD be implemented Phase-2 Quick Mode MUST be implemented Phase-2 Quick Mode with key exchange payload MUST be implemented. Phase-1 Main Mode SHOULD NOT be used in conjunction with pre-shared keys, due to Main ModeÆs vulnerability to men-in-the-middle- attackers when group pre-shared keys are used. iFCP therefore requires that Aggressive Mode MUST be implemented as a valid alternative to Main Mode. Peer authentication using the public key encryption methods outlined in sections 5.2 and 5.3 of [RFC2409] SHOULD NOT be used. In all Phase 1 Modes, iFCP MUST use IP addresses as identities. The Phase 2 Quick Mode exchanges used to negotiate protection for the TCP connections used by iFCP MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI [RFC2407] provides for several types of identification data. However, when used in conformant iFCP security implementations, each ID Payload MUST carry a single IP address and a single non-zero TCP port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and iFCP connections. 11.3.2 Use of IKE and IPsec Each IP address supporting iFCP communication shall be capable of establishing one or more Phase-1 IKE Security Associations (SA) to other IP addresses configured as peer iFCP gateways, using the IP address as the identity. Such a security association may be established at a gatewayÆs initialization time, or may be deferred until the first TCP connection with security requirements is established. Unlike Phase-1 SAs, a Phase-2 SA maps to an individual TCP connection. It protects the setup process of the underlying TCP connection and all its subsequent TCP traffic. TCP connections protected by the phase 2 SA are either in the unbound state, or are bound to a specific N_PORT login session. The creation of an IKE Phase-2 SA may be triggered by a policy rule supplied through a management interface, or by N_PORT properties registered with the iSNS server. Similarly, the use of Key Exchange payload in Quick Mode for perfect forward secrecy may be dictated through a management interface or by N_PORT properties registered with the Monia et-al. Standards Track [Page 75] iFCP Revision 7 November 2001 iSNS server. This specification allows multiple implementation strategies, in which the establishment of an IKE Phase-2 SA occurs at different times. Examples of implementation strategies include: a) The definition of a unique security policy for all TCP connections regardless of their bound or unbound state. Thus, an unbound TCP connection can be bound to an N_PORT login session without the need to incur a new IKE Phase-2 SA. b) Multiple security policies for unbound TCP connections and active N_PORT login sessions. In this case, an unbound TCP connection becomes bound to an N_PORT login session after establishing a new IKE Phase-2 SA matching the new security policy for that N_PORT session. c) The implementation does not support unbound connections. In this case, a new IKE Phase-2 SA and TCP connection must be started from scratch anytime a new N_PORT login session is created. If the implementation does use unbound TCP connections, then an IKE Phase-2 SA MUST protect each of such unbound connections. As expected, the successful establishment of a IKE Phase-2 SA results in the creation of two uni-directional IPsec SAs fully qualified by the tuple . Should a TCP connection be torn down (as opposed to joining a pool of unbound connections), the associated Phase-2 SA SHALL be terminated upon expiration of the TIME WAIT timeout value (according to [RFC793]). Upon receiving a Phase 1 delete message, an iFCP implementation SHALL tear down all the Phase 2 SAs spawned from that Phase 1 SA, followed by the Phase 1 SA itself. Upon receiving a Phase 2 delete message, iFCP implementations will behave according to the state of the TCP connection protected by the SA in question. If the TCP session was terminated (either via FINs or RSTs), then a Phase 2 delete message SHALL terminate the IPsec SAs and any state formerly associated with that Phase 2 SA. If, however, the TCP session is maintained, then a Phase 2 delete message shall trigger a new Quick Mode exchange. To minimize the use of SA resources while the TCP connection is idle, the creation of the security association may be deferred until data is sent over the connection. 11.3.3 Certificate-based authentication Conformant iFCP implementations MAY support certificate-based peer authentication using digital signatures. In this case, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the Monia et-al. Standards Track [Page 76] iFCP Revision 7 November 2001 pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures. [Wd. Note: Elements in this section are TBS.] 11.4 iSNS and iFCP Security iFCP is required to use iSNS for discovery and management services. Consequently, the security of the iSNS protocol has an impact on the security of iFCP gateways. In particular, the following threats exist: a) An attacker could alter iSNS protocol messages, so as to direct iFCP gateways to establish connections with rogue peer devices, or to weaken/eliminate IPSec protection for iFCP traffic. b) An attacker could masquerade as the real iSNS server using false iSNS heartbeat messages. This could cause iFCP gateways to use rogue iSNS servers. c) An attacker could gain knowledge about iFCP gateways by snooping iSNS protocol messages. Such information could aid an attacker in mounting a direct attack on iFCP gateways, such as a denial- of-service attack or outright physical theft. To address these threats, the following capabilities are required: a) Unicast iSNS protocol messages need to have both confidentiality and authentication support. b) Multicast iSNS protocol messages such as the iSNS heartbeat message need to have authentication support. There is no requirement that the communicating identities in iSNS protocol messages be kept confidential. Specifically, the identity and location of the iSNS server shall not be considered confidential. However, in order to protect against an attacker masquerading as the real iSNS server, the iSNS server MUST have the capability to allow client gateways to authenticate broadcast or multicast messages such as the iSNS heartbeat. The iSNS authentication block (which is identical in format to the SLP authentication block) may be used for this purpose. Note that the authentication block is used only for iSNS broadcast or multicast messages, and SHOULD NOT be used in unicast iSNS messages. For protecting unicast iSNS protocol messages, iSNS servers MUST support the ESP protocol in tunnel mode for iFCP client gateways. 11.5 Use of iSNS to Distribute Security Policy Monia et-al. Standards Track [Page 77] iFCP Revision 7 November 2001 Once communication between iFCP gateways and the iSNS server have been secured through use of IPSec, the iFCP gateways have the capability to discover the security settings that they need to use to protect iFCP traffic. This provides a potential scaling advantage over device-by-device configuration of individual security policies for each iFCP gateway. The iSNS server stores security settings for each iFCP gateway. These security settings include use or non-use of IPSec, IKE, Main Mode, Aggressive Mode, PFS, Pre-shared Key, and certificates. These settings can be retrieved by peer iFCP gateways, who can then take the appropriate action. For example, IKE may not be enabled for a particular iFCP gateway. If a peer gateway can learn of this in advance by consulting the iSNS server, it will not need to waste time and resources attempting to initiate an IKE session with that iFCP gateway. Additionally, the iSNS server can store policies that are used for ISAKMP phase 1 and phase 2 negotiations between iFCP gateways. The ISAKMP payload format includes a series of one or more proposals that the iFCP gateway will use when negotiating the appropriate IPSec policy to use to protect iFCP traffic. 11.6 Minimal Security Policy for an iFCP gateway An iFCP implementation MAY be able to administratively disable security mechanisms for individual N_PORT login sessions. This implies that IKE and IPsec security associations may not be established for one or more of such sessions. A configuration of this type may be accomplished through a management interface or through attributes set in the iSNS server. For most IP networks, it is inappropriate to assume physical security, administrative security, and correct configuration of the network and all attached nodes (a physically isolated network in a test lab may be an exception). Therefore, authentication SHOULD be used in order to provide a minimal assurance that connections have initially been opened with the intended counterpart. The minimal iFCP security policy thus only states that an iFCP gateway SHOULD authenticate its iSNS server(s) as described in [ISNS]. 12. Quality of Service Considerations 12.1 Minimal requirements Conforming iFCP protocol implementations SHALL correctly communicate gateway-to-gateway even across one or more intervening best-effort IP regions. The timings with which such gateway-to gateway communication is performed, however, will greatly depend upon BER, packet losses, latency, and jitter experienced throughout the best-effort IP regions. The higher these parameters, the higher will be the gap measured between iFCP observed behaviors and Monia et-al. Standards Track [Page 78] iFCP Revision 7 November 2001 baseline iFCP behaviors (i.e., as produced by two iFCP gateways directly connected to one another). 12.2 High-assurance It is expected that many iFCP deployments will benefit from a high degree of assurance on the behaviors of the intervening IP regions, with resulting high-assurance on the overall end-to-end path, as directly experienced by Fibre Channel applications. Such assurance on the IP behaviors stems from the intervening IP regions supporting standard Quality-of-Service (QoS) techniques, fully complementary to iFCP, such as: a) Congestion avoidance by over-provisioning of the network b) Integrated Services [RFC1633] QoS c) Differentiated Services [RFC2475] QoS d) Multi-Protocol Label Switching [RFC3031] One may load a MPLS forwarding equivalence class (FEC) with QoS class significance, in addition to other considerations such as protection and diversity for the given path. The complementarity and compatibility of MPLS with Differentiated Services is explored in [MPSLDS], wherein the PHB bits are copied to the EXP bits of the MPLS shim header1. In the most general definition, two iFCP gateways are separated by one or more independently managed IP regions, some of which implement some of the QoS solutions mentioned above. The IP regions with these QoS solutions are said to support Service Level Agreements (SLAs). Such agreements finalize requirements on network parameters such as bandwidth, loss, latency, jitter, burst length. The requirements may be expressed in absolute or relative terms, and apply to a unidirectional flow of packets. Depending on the QoS techniques available, the dynamic stipulation of a SLA may require the iFCP gateway to interact with network ancillary functions such admission control and bandwidth brokers (with RSVP or other signalling protocols that an IP region may accept). Due to the fact that Fibre Channel Class 2 and Class 3 do not currently support fractional bandwidth guarantees, and that iFCP is committed to supporting Fibre Channel semantics, it is impossible for an iFCP gateway to autonomously infer bandwidth requirements from streaming Fibre Channel traffic. Rather, the requirements on bandwidth or other network parameters need to be injected out-of- band into a iFCP gateway (or the node that will actually negotiate the SLA on the gateway's behalf) through mechanisms outside the scope of this specification (e.g., through a management interface into the iFCP gateway). Monia et-al. Standards Track [Page 79] iFCP Revision 7 November 2001 The administrator of a iFCP gateway MAY thus stipulate a Service Level Agreement with the local IP region for one, several, or all of an iFCP gateway's TCP sessions used by iFCP. Alternately, this responsibility may be delegated to a node downstream. Since one TCP connection is dedicated to each N_PORT login session , an individual N_PORT to N_PORT flow can enjoy a customized SLA. To render the best emulation of Fibre Channel possible over IP, it is anticipated that typical SLAs will specify a fixed amount of bandwidth, null losses, and, to a lesser degree of relevance, low latency, and low jitter. For example, an IP region using DiffServ QoS may support SLAs of this nature by applying EF DSCPs to the iFCP traffic. For the same SLA, another IP region might as well use a different DSCP or different QoS techniques alltogether. The way different QoS techniques are re-mapped at the edge of different intervening IP regions is beyond the scope of this specification. 13. Author's Addresses Charles Monia Franco Travostino Rod Mullendore Director, Content Josh Tseng Internetworking Lab, Nishan Systems Victor Firoiu 3850 North First Street San Jose, CA 95134 Nortel Networks Phone: 408-519-3986 3 Federal Street Email: Billerica, MA 01821 cmonia@nishansystems.com Phone: 978-288-7708 Email: travos@nortelnetworks.com Monia et-al. Standards Track [Page 80] iFCP Revision 7 November 2001 David Robinson Wayland Jeong Sun Microsystems Troika Networks Senior Staff Engineer Vice President, Hardware M/S UNWK16-301 Engineering 901 San Antonio Road 2829 Townsgate Road Suite Palo Alto, CA 94303-4900 200 Phone: 510-936-2337 Westlake Village, CA 91361 Email: Phone: 805-370-2614 David.Robinson@sun.com Email: wayland@troikanetworks.com Rory Bolt Paul Rutherford Quantum/ATL ADIC Director, System Design Vice President, Technology & 101 Innovation Drive Software Irvine, CA 92612 1143 Willows Road N.E. Phone: 949-856-7760 P.O. Box 97057 Email: rbolt@atlp.com Redmond, WA 98073-9757 Phone: 425-881-8004 Email: paul.rutherford@adic.com Mark Edwards Senior Systems Architect Eurologic Development, Ltd. 4th Floor, Howard House Queens Ave, UK. BS8 1SD Phone: +44 (0)117 930 9600 Email: medwards@eurologic.com Monia et-al. Standards Track [Page 81] iFCP Revision 7 November 2001 Appendix A A. iFCP Support for Fibre Channel Link Services For reference purposes, this appendix enumerates all the Fibre Channel link services and the manner in which each shall be processed by an iFCP implementation. The iFCP processing policies are defined in section 8. A.1 Basic Link Services The basic link services are shown in the following table. Basic Link Services Name Description iFCP Policy ---- ----------- ---------- ABTS Abort Sequence Transparent BA_ACC Basic Accept Transparent BA_RJT Basic Reject Transparent NOP No Operation Transparent PRMT Preempted Rejected (Applies to Class 1 only) RMC Remove Connection Rejected (Applies to Class 1 only) A.2 Link Services Processed Transparently The following link service requests and responses MUST be processed transparently as defined in section 8. ELSs Processed Transparently Name Description ---- ----------- ACC Accept ADVC Advise Credit CSR Clock Synchronization Request CSU Clock Synchronization Update ECHO Echo ESTC Estimate Credit ESTS Establish Streaming FACT Fabric Activate Alias_ID FAN Fabric Address Notification FDACT Fabric Deactivate Alias_ID FDISC Discover F_Port Service Parameters Monia et-al. Standards Track [Page 82] iFCP Revision 7 November 2001 FLOGI F_Port Login GAID Get Alias_ID LCLM Login Control List Management LINIT Loop Initialize LIRR Link Incident Record Registration LPC Loop Port Control LS_RJT Link Service Reject LSTS Loop Status NACT N_Port Activate Alias_ID NDACT N_Port Deactivate Alias_ID PDISC Discover N_Port Service Parameters PRLI Process Login PRLO Process Logout QoSR Quality of Service Request RCS Read Connection Status RLIR Registered Link Incident Report RNC Report Node Capability RNFT Report Node FC-4 Types RNID Request Node Identification Data RPL Read Port List RPS Read Port Status Block RPSC Report Port Speed Capabilities RSCN Registered State Change Notification RTV Read Timeout Value RVCS Read Virtual Circuit Status SBRP Set Bit-error Reporting Parameters SCL Scan Remote Loop SCN State Change Notification SCR State Change Registration TEST Test TPLS Test Process Login State A.3 iFCP-Processed Link Services The following extended link services are processed by the iFCP implementation as described in the referenced section listed in the table. Augmented Link Services Name Description Section ---- ----------- ------- ABTX Abort Exchange 8.3.1 ADISC Discover Address 8.3.2 Monia et-al. Standards Track [Page 83] iFCP Revision 7 November 2001 ADISC Discover Address Accept 8.3.3 ACC FARP- Fibre Channel Address 8.3.4 REPLY Resolution Protocol Reply FARP-REQ Fibre Channel Address 8.3.5 Resolution Protocol Request LOGO N_PORT Logout 8.3.6 PLOGI Port Login 8.3.7 RES Read Exchange Status Block 8.3.8 RES ACC Read Exchange Status Block 8.3.9 Accept RLS Read Link Error Status Block 8.3.10 RRQ Reinstate Recovery Qualifier 8.3.12 RSI Request Sequence Initiative 8.3.13 RSS Read Sequence Status Block 8.3.11 TPRLO Third Party Process Logout 8.3.14 TPRLO Third Party Process Logout 8.3.15 ACC Accept Monia et-al. Standards Track [Page 84] iFCP Revision 7 November 2001 Monia et-al. Standards Track [Page 85] iFCP Revision 7 November 2001 Full Copyright Statement "Copyright (C) The Internet Society, November 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Monia et-al. Standards Track [Page 86] iFCP Revision 7 November 2001 References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [FC-FS] dpANS X3.XXX-200X, "Fibre Channel Framing and Signaling Interface", Revision 1.2, NCITS Project 1331-D, February 2001 [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC- SW2)", revision 5.2, NCITS Project 1305-D, May 2001 [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC- GS3)", revision 7.01, NCITS Project 1356-D, November 2000 [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC- FLA)", revision 2.7, NCITS Project 1235-D, August 1997 [Kembel] Kembel, R., "Fibre Channel, A Comprehensive Introduction", Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0 Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0 [FC-AL2] dpANS X3.XXX-199X, "Fibre Channel Arbitrated Loop (FC-AL- 2)", revision 7.0, NCITS Project 1133D, April 1999 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September, 1981 [RFC1122] Braden, S., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989 [RFC896] Nagel, J., "Congestion Control in IP/TCP Networks", RFC 896, January 1984 [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High Performance", RFC 1323, May, 1992 [ENCAP] Weber, et-al., "FC Frame Encapsulation", draft-ietf-ips- fcencapsulation-01.txt, May 2001 [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol (SNTP)" Version 4, October 1996 Monia et-al. Standards Track [Page 87] iFCP Revision 7 November 2001 [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre Channel", June 1999 [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service", draft-ietf-ips-04.txt, July 2001 [RFC791] Postel, J., RFC 791, "The Internet Protocol", September 1981 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997 [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture for the Internet Protocol", November 1998 [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication Header", November 1998 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within ESP and AH", RFC 2404, November 1998 [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher Algorithm With Explicit IV" RFC 2405, November 1998 [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security Protocol", November 1998 [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of Interpretation for ISAKMP", November 1998 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., RFC 2408, "Internet Security Association and Key Management Protocol (ISAKMP)" November 1998 [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key Exchange (IKE)", November 1998 [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its use with IPSEC", RFC 2410, November 1998 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999 [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within ESP and AH", RFC 2404, November 1998 Monia et-al. Standards Track [Page 88] iFCP Revision 7 November 2001 [AES] FIPS Publication XXX, "Advanced Encyption Standard (AES)", Draft, 2001, Available from http://csrc.nist.gov/publications/drafts/dfips-AES.pdf [XCBC] Black, J., Rogaway, P., "A Suggestion for Handling Arbitrary Length Messages with the CBC MAC". Available from http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc- mac/xcbc-mac-spec.pdf [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and Its use with IPSEC", RFC 2410, November 1998 [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998 [AESCTR] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-Mode Encryption", 2001. Available from http://csrc.nist.gov/encryption/modes/proposedmodes/ctr/ctr- spec.pdf [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher Algorithm With Explicit IV" RFC 2405, November 1998 [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999 [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998 [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001 [MPSLDS] F. Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen, draft-ietf-mpls-diff-ext- 09.txt, To be issued [PART00] Partridge, C and J. Stone, "When The CRC and TCP Checksum Disagree", ACM SIGCOMM, September 2000 Monia et-al. Standards Track [Page 89] iFCP Revision 7 November 2001 [PADHYE00] Padhye, J, Firoiu, D, Kurose, J., "Modeling TCP Reno Performance: A Simple Model and its Empirical Validation" IEEE/ACM Transactions on Networking, April 2000 Monia et-al. Standards Track [Page 90]