IP Storage Working Group Rod Mullendore INTERNET DRAFT Charles Monia Josh Tseng Expires May 2001 Nishan Systems Category: Informational November 2000 mFCP - Metro FCP protocol for IP Networking Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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). 1. Abstract This document describes the mFCP protocol, which transports the Fibre Channel Protocol for SCSI (FCP) over metro- and local-scale IP networks that demonstrate comparable latency, reliability, and performance levels to that of a Fibre Channel network. Most existing storage devices use the FCP protocol for data transport and error recovery. mFCP leverages these existing mechanisms to facilitate high-performance interconnection of Fibre Channel-based storage devices over private IP networks. All FCP mechanisms are transported natively over IP between Fibre Channel and SCSI storage 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 [1]. 2.2 Purpose of this document This document is an informational draft. Some portions of this document contain material from T10 and T11 Committee standards documents. The repeated information is included here for informational purposes, and the authoritative reference for standards material is the appropriate T10 or T11 standard. 3. mFCP Introduction The mFCP protocol provides Fibre Channel fabric services to FCP- based Fibre Channel devices using a high-performance, reliable IP Mullendore, Tseng, Monia Informational 1 mFCP November 2000 network. mFCP uses the UDP transport protocol to facilitate high performance, and assumes that reliability and flow control will be handled by the physical infrastructure. mFCP's primary objective is to allow interconnection and networking of existing Fibre Channel devices over an IP network. mFCP achieves this objective by leveraging FCP mechanisms already in use in storage products, and statelessly mapping these to UDP/IP. Existing FCP-based Fibre Channel products can now use mFCP to internetwork over an IP-based network. mFCP achieves high performance by forwarding FCP information units directly between FCP end nodes without the delays introduced by conventional storage routers. 3.1 Definitions Terms needed to clarify the concepts presented in this document are presented here. Fibre Channel Network _ A fabric and all attached fibre channel devices. Fabric _ The part of a fibre channel network which provides the transport services defined in the FC-FS specification. A fabric may be implemented in the IP framework by means of the architecture and protocols discussed in this document. FC-2 _ The Fibre Channel transport services layer described in the FC-FS specification. FCP Portal - An IP-addressable entity representing the point at which a logical or physical FCP device is attached to the IP network. N_PORT _ An mFCP or Fibre Channel entity representing the interface to Fibre Channel device functionality. This interface implements the Fibre Channel N_PORT semantics specified in the FC-FS standard [FC-FS]. N_PORT Fabric Address - The address of an N_PORT within the Fibre Channel fabric. N_PORT Network Address - The address of an N_PORT in the IP fabric. This address consists of the IP address of the FCP Portal and the N_PORT ID of the directly-attached Fibre Channel device. mFCP _ The protocol discussed in this document. Logical FCP Device - An abstraction representing a Fibre Channel device as it appears on an IP network. Mullendore, Tseng, Monia Informational 2 mFCP November 2000 Physical mFCP Device - A device in which all Fibre Channel and mFCP protocol functionality is contained within the physical device. iSNS _ The protocol by which storage name services are implemented. Resolution of fibre channel network object names is provided by an iSNS name server. mFCP Frame - The frame inserted into a UDP datagram which contains the Fibre Channel frame, mFCP header, and trailing mFCP checksum. 3.2 The mFCP Network Model The following diagram shows a Fibre Channel fabric with attached devices. These are connected to the fabric through N_PORT and F_PORT interfaces, whose behavior is specified in [FGS]. 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 [FGS]. In this case, the N_PORT Fibre Channel addresses are 24-bit quantities that are unique within the scope of the FC fabric. N_PORTs that perform fabric services are assigned well-known addresses starting at the top end of the 24-bit Fibre Channel address space. Fibre Channel Network +--------+ +--------+ | FC | | FC | | Device | | Device | |........| |........| Fibre Channel | N_PORT |<------>| N_PORT | Device Domain +---+----+ +----+---+ ^ | | | +---+----+ +----+---+ | | F_PORT | | F_PORT | | ==========+========+========+========+============== | Fabric & | | | Fabric Services | v | | Fibre Channel +--------------------------+ Fabric Domain Mullendore, Tseng, Monia Informational 3 mFCP November 2000 An mFCP Network with mFCP Gateways Fibre Channel Devices Fibre Channel Devices +--------+--+--------+ +--------+--+--------+ | FC | | FC | | FC | | FC | | Device | | Device | Fibre | Device | | Device | Fibre |........| |........| Channel |........| |........| Channel | N_PORT | | N_PORT |<--------->| N_PORT | | N_PORT | Device +---+----+ +---+----+ Traffic +----+---+ +----+---+ Domain | | | | ^ +---+----+ +---+----+ +----+---+ +----+---+ | | F_PORT | | F_PORT | | F_PORT | | F_PORT | | =+========+==+====================+========+==+========+========== | mFCP Layer |<--------->| mFCP Layer | | |....................| ^ |....................| | | FCP Portal | | | FCP Portal | v +--------+-----------+ | +----------+---------+ IP Fabric | Control | | Data | | | | | |<------Encapsulated Frames------->| | +------------------+ | | | | | +------+ IP Network +--------+ | | +------------------+ The above diagram shows the equivalent mFCP fabric implementation. Here, Fibre Channel devices are connected to the fabric through F_PORTs implemented as part of the edge switch or gateway. At the N_PORT interface, the network appears as a Fibre Channel fabric. N_PORT to N_PORT communications that traverse a TCP/IP network require the intervention of the mFCP layer. This is done through the following operations on Fibre Channel frames: a) For outbound frames, translate Fibre Channel fabric addresses imbedded in FC frames to N_PORT Network Addresses. b) For inbound frames, translate N_PORT Network Addresses to Fibre Channel fabric addresses. c) Generate control traffic in response to certain link service requests or fabric control operations as described in section 7.1. d) Encapsulate fibre channel frames for injection into the TCP/IP network and de-encapsulate fibre channel frames received from the TCP/IP network. e) Direct de-encapsulated, FC frames to the appropriate N_PORT. After address translation on outbound FC frames, the emulation process generates two streams of encapsulated FC frame traffic: Mullendore, Tseng, Monia Informational 4 mFCP November 2000 a) FC frames to be passed between N_PORTs unchanged, except for the address field modifications described below. b) Augmented FC frames generated in response to N_PORT Link Service requests. These frames are passed between the mFCP layers. For N_PORT link service requests, mFCP may modify the payload to perform these operations in an IP fabric. Control traffic is also generated in order to perform certain peer- to-peer operations among mFCP nodes. 3.3 Native mFCP Devices The following diagram shows an IP fabric with a mFCP device directly attached. mFCP Network with native mFCP Device mFCP Device Fibre Channel Devices +------------+ +--------+ +--------+ |Native mFCP | | FC | | FC | | Device | | Device | | Device | Fibre |............| Fibre Channel |........| |........| Channel | N_PORT |<------------->| N_PORT | | N_PORT | Device |............| Traffic +----+---+ +----+---+ Domain | | | | ^ | Native | +----+---+ +----+---+ | | mFCP | | F_PORT | | F_PORT | | | Layer | Control ==+========+==+========+=========== | |<------------->| mFCP Layer | | |............| Traffic |....................| | | FC Portal | | FC Portal | v +-----+------+ +----------+---------+ IP Fabric | Translated Frames | |<---- with IP Encapsulation----->| | +--------------------+ | | | | | +----+ IP Network +-------+ | | +--------------------+ For a native mFCP device, the major difference is that, unlike a gateway, the N_PORT layer is aware of the underlying IP environment. Hence mFCP address translation is not required, as the device makes direct use of IP addresses. 3.4 Frame Translation and IP Encapsulation As mentioned above, an mFCP gateway is responsible for the mapping between N_PORT Fibre Channel addresses and N_PORT addresses in the IP fabric. Mullendore, Tseng, Monia Informational 5 mFCP November 2000 In the IP fabric, the address of a N_PORT has two components: the IP address of the FC portal to which the Fibre Channel device is attached and an N_PORT ID that is unique within the scope of the FC portal. When an FC frame is in transit, the IP components of the source and destination FC portals are in the IP header. The source and destination N_PORT IDs are stored in the corresponding N_PORT address fields that are part of the FC frame. The mFCP gateway is responsible for assigning Fibre Channel Port IDs to directly attached N_PORTs. For external N_PORTs, the mFCP gateway is also responsible for assigning an internal key used to look up the N_PORT network address for the external device. To perform this function, the gateway maintains a table of IP addresses and N_PORT IDs of all external N_PORTs to which the directly-attached devices have an established port login session. The gateway builds the store of external port addresses in the IP domain by intercepting name service requests issued by directly attached N_PORTs and redirecting them to the iSNS name server. The name server returns the IP address and N_PORT ID pair. After saving these in the store of external addresses, the mFCP layer then creates a 24-bit key that is returned to the directly-attached N_PORT as the Fibre Channel address of the external device. For outbound frames, the external N_Port ID table is referenced to translate an N_PORT address key to an IP address_N_Port ID pair. The translation process for outbound frames is shown below. The names in parentheses are the field names specified in FC-FS. Mullendore, Tseng, Monia Informational 6 mFCP November 2000 Raw Fibre Channel Frame +--------+-----------------------------------+ +--------------+ | | Destination N_PORT Address Key |---->| | | | (D_ID) | | IP fabric | +--------+-----------------------------------+ | address | | | Source N_PORT ID (S_ID) | | Lookup | +--------+-----------------------------------+ +--------------+ | | | Dest | Control information | | Address | and Payload | | & +--------------------------------------------+ | N_PORT | ID | Frame After Address Translation and IP Encapsulation | +--------------------------------------------+ | | IP Header | | | | | | IP Destination Address<-------------------------+ | IP Source Address | | +--------------------------------------------+ | | Transport Header (UDP or TCP) | | +--------------------------------------------+ | | mFCP Encapsulation Header | | +========+===================================+ <-----+ | | | Destination N_PORT ID (D_ID) |<------|----+ +--------+-----------------------------------+ | | | Source N_PORT ID (S_ID) | | +--------+-----------------------------------+ FC Frame | | | | Control information | | | and Payload | | +--------------------------------------------+ <-----+ For inbound frames, the store regenerates the internal address key from the source IP address and N_PORT number contained in the encapsulated FC frame. The translation process for inbound frames is shown below. Mullendore, Tseng, Monia Informational 7 mFCP November 2000 Network Format of Inbound Frame +--------------------------------------------+ | IP Header | | | +---------+ | IP Source Address------------------|------>| Address | | IP Destination Address | | Key | +--------------------------------------------+ | Lookup | | mFCP Encapsulation Header | | | +========+===================================+ | | | | Destination N_PORT ID (D_ID) | | | +--------+-----------------------------------+ | | | | Source N_PORT ID (S_ID) |------>| | +--------+-----------------------------------+ +-----+---+ | | |Address | Control information | | Key | and Payload | | +--------------------------------------------+ | | | | Frame after Address Translation and De-encapsulation | +--------+-----------------------------------+ | | | Destination N_PORT ID (D_ID) | | +--------+-----------------------------------+ | | | Source N_PORT Key (S_ID) |<------------+ +--------+-----------------------------------+ | | | Control information | | and Payload | +--------------------------------------------+ 3.5 mFCP Layered Services The following diagram shows the functional layers for host devices that support FCP. As shown, mFCP provides a set of layered services that transparently provide the transport services required by FCP devices. Using the mFCP framework, an existing FCP implementation will execute with no modifications required. The mFCP protocol layer consists of the data transport services and mFCP-specific Link Services. This layer provides transport services specific to Fibre Channel devices as specified in [FC-PH], [FC-PH-2], and [FC-PH-3]. This is illustrated in the following diagram, which shows the functional layers of a host implementation. The IP Fabric provides the transport services for FCP, and is a direct replacement for the transport services provided by a Fibre Channel fabric. Meanwhile, the components in the Fibre Channel Device Domain remain unchanged. Mullendore, Tseng, Monia Informational 8 mFCP November 2000 +---------------------------------------+ - - - - - - - | Storage & Backup Applications | +---------------------------------------+ | Operating System | Application +--------------------+ | Layer | SCSI | | +--------------------+ | - - - - - - - | FCP | | FC-4 Layer +------------+-------+------------------+ - - - - - - - | | Link Services | | +--------------------------+ FC-2 Layer ^ | | | | N_PORT - F_PORT Interface | Fibre Channel | | Device Domain <=============================================================> | | IP Fabric | mFCP Data Transport Service | | | | v | +---------------+ | |mFCP Specific | mFCP Layer | |Link Services | +-----------------------+---------------+ - - - - - - | | | UDP | Transport | | Layer +---------------------------------------+ - - - - - - | | | IP | Network | | Layer +---------------------------------------+ - - - - - - | | | Physical Transport | Link Layer | | +---------------------------------------+ - - - - - - In the figure shown above, each layer leverages the services of the layer below it. 3.5.1 Application Layer This includes the operating system, Storage and Backup applications, and the SCSI driver. This layer interfaces with FCP and Link Services in the FC-2 and FC-4 layers. 3.5.2 FC-4 Layer (FCP) FCP is the Fibre Channel FC-4 layer application protocol used to communicate with devices implementing the SCSI-3 command set and architectural model. Basically, FCP divides each SCSI I/O operation into a series of information units to be transfered between the initiator and target. Mullendore, Tseng, Monia Informational 9 mFCP November 2000 3.5.3 FC-2 Layer The FC-2 Layer provides the facilities for Link Services and transfer of Fibre Channel information units as described below. 3.5.3.1 Link Service Messages Fibre Channel defines a series of link services defined in Fibre Channel Physical and Signaling Interface specification (FC-PH, FC- PH-2, FC-PH-3). These Link Service Messages provide a set of defined functions that allow a Fibre Channel port to send control information, or to request another port to perform a specific function. Some Link Service messages reference services provided internally within the Fibre Channel fabric. 3.5.3.2 N_PORT Interface This is an interface which provides access to Fibre Channel device functionality. The N_PORT interface is responsible for segmentation and reassembly of information units from Fibre Channel frames. 3.5.3.3 F_PORT Interface This is the interface through which the N_PORT accesses the Fibre Channel fabric. 3.5.4 mFCP Layer The mFCP layer provides two essential services for FCP-based storage products: a) Transport of Fibre Channel frames and Link Service messages between N_PORTs. b) Augmentation of some Link Service messages with additional data needed in the mFCP environment. The mFCP layer maps Fibre Channel frames to UDP datagrams for transport. 4. mFCP Protocol 4.1 Overview 4.1.1 mFCP Transport Services The mFCP transport services map the fibre channel frames comprising each FCP IU and Link Service message to UDP datagrams for transport across an IP network. When receiving in-band FCP-based storage data from the network, the mFCP layer transports, and delivers each Mullendore, Tseng, Monia Informational 10 mFCP November 2000 resulting frame to the appropriate N_PORT. The mFCP layer never interprets the frame contents. For incoming mFCP frames with control data, mFCP interprets the augmented information in the mFCP header, modifies the frame content accordingly, and may forward the resulting frame to the N_PORT for further processing. For out-bound Fibre Channel frames that require control data, mFCP inserts the augmented data in the mFCP header based on frame content, modifies the frame content, then transmits the resulting encapsulated Fibre Channel frame and augmented mFCP header in a UDP datagram. 4.1.2 mFCP Support for Link Services (mFCP-LS) Some Link Service messages reference constructs which are specific to the Fibre Channel fabric environment, but are irrelevant in the context of an IP fabric. When mFCP encounters such messages, it will augment the information in the payload by adding additional information in the mFCP header. The receiving mFCP layer will reference the augmented information in order to reconstruct the original Link Service message. The reconstructed frames are then forwarded to the N_PORT for further processing. Section 7.1 describes augmented Link Services. 4.2 Mandatory FC-2 Functionality [To be specified] 4.3 FC-2 Functionality Not Supported [To be specified] 4.5 Optional FC-2 Functionality [To be specified] 5. mFCP Encapsulation of FCP and Link Services Messages This section describes the formatting of mFCP frames. mFCP encapsulates two types of payload--the frames comprising FCP Information Units and Link Service Messages. The mFCP encapsulation format is shown below. The mFCP header encapsulates the mFCP payload containing the Fibre Channel frame. The length of the mFCP frame depends on the size of the encapsulated Fibre Channel frame and the amount of augmentation data in the mFCP header. Each Fibre Channel frame, in turn, is comprised of a header and payload whose format is specified in the appropriate Fibre Channel standards [FC-PH]. Mullendore, Tseng, Monia Informational 11 mFCP November 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ - - - - - - - - - - - 0 | mFCP Header | N Bytes ^ +----------------------------------+ - - - - - - - - | | | ^ mFCP 8 / Fibre Channel Header / 24 Bytes | Frame | (described in section 5.1) | | | +----------------------------------+ Fibre | 32 | | Channel | / Fibre Channel Payload / L Bytes Frame | | | | | +----------------------------------+ | | 4 | mFCP Checksum (if present) | | | +----------------------------------+ - - - - - - - - - - - Total Length = 28 + N + L 5.1 mFCP Header The mFCP header for UDP is shown below. |3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1|1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0| |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| +-------+-------+---------------+-------------------------------+ | CLASS | VERS | HEADER MARKER | mFCP FLAGS | +-------+-------+---------------+-------------------------------+ | mFCP HEADER LENGTH | RESERVED | +-------------------------------+-------------------------------+ | mFCP AUGMENTATION DATA (if present) | +---------------------------------------------------------------+ CLASS - This 4-bit field indicates the class of service. Only the values 2 and 3 are allowed and are equivalent to the class of service for Fibre Channel. VERS - This 4-bit field indicates the mFCP protocol version. The version number shall be 1. mFCP FLAGS - This 16-bit field contains status flags that indicate various parameters for the data frame. Bit Field mFCP Flag Description --------- --------- ----------- 15 SEQUENCE END Indicates if frame terminates a sequence. For Class 3 sequences, the FCP Portal sets this bit on the last frame of the sequence. In Class 2 sequences, this bit is set by the recipient on the ACK frame that terminates the sequence. 1=Last frame of sequence, 0=not Mullendore, Tseng, Monia Informational 12 mFCP November 2000 14 SEQUENCE START Indicates if frame is the first frame of a sequence. 1=First frame of sequence, 0=not 13-2 RESERVED 1 AUGMENTATION Indicates the mFCP Augmentation Data PRESENT field is present in the mFCP header. 1=Present, 0=not 0 COMPLIANCE This bit must be enabled. mFCP HEADER LENGTH - A 2-byte Header Length field giving the length in bytes of the mFCP HEADER, including the mFCP AUGMENTATION DATA field (if present). HEADER MARKER shall be 0xC3 when the mFCP CRC Checksum is present, and 0x00 when it is not. Other values for the HEADER MARKER are reserved, and can indicate other types of checksums. 5.2 Fibre Channel Frame Header The Fibre Channel frame header defined in FC-PH is used when transporting FCP and Link Service frames in an IP fabric. Use of the Fibre Channel frame header simplifies the connection of Fibre Channel devices to a mFCP storage network. In mFCP, the only modification to the basic Fibre Channel frame header is that the contents of D_ID and S_ID fields are replaced with Destination and Source N_PORT IDs as described in section 3.4. The figure below shows the format of the header used for both FCP and Link Service frames. The contents of D_ID and S_ID fields have been replaced by the Destination and Source N_PORT Port IDs. 3 3 3 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 |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| +---------------+-----------------------------------------------+ | R_CTL | Destination N_PORT ID | +---------------+-----------------------------------------------+ | CS_CTL | Source N_PORT ID | +---------------+-----------------------------------------------+ | Type | F_CTL | +---------------+---------------+-------------------------------+ | SEQ_ID | DF_CTL | SEQ_CNT | +---------------+---------------+-------------------------------+ | OX_ID | RX_ID | +-------------------------------+-------------------------------+ | PARAMETER | +---------------------------------------------------------------+ Mullendore, Tseng, Monia Informational 13 mFCP November 2000 Other than Source and Destination N_PORT ID, descriptions of each of the above fields can be found in [FC-PH]. 5.2.1 Destination N_PORT ID The contents of this 24-bit field is stored in the Fibre Channel D_ID field. When combined with the destination IP address, the Destination N_PORT ID specifies the unique N_PORT network address of the receiving device for the Fibre Channel frame. 5.2.2 Source N_PORT ID The contents of this 24-bit field is stored in the Fibre Channel S_ID field. When combined with the source IP address, the Source N_PORT ID specifies the unique N_PORT network address of the originating device for the Fibre Channel frame. 6. UDP Encapsulation of mFCP Frames 6.1 Background UDP provides a simplified transport for mFCP data, allowing for optimal performance. UDP is stateless and has no error detection or flow control mechanism. UDP can be used only when the reliability and performance of the underlying network is adequate. 6.2 UDP Encapsulation mFCP Information Units are encapsulated into one more more UDP datagrams as shown below. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | UDP Header | 8 Bytes +----------------------------------+ 8 | mFCP Header | 4 Bytes +----------------------------------+ | | 12 / Fibre Channel Header / 24 Bytes | (described in section 5) | +----------------------------------+ 36 | | / Fibre Channel Payload / L Bytes | | +----------------------------------+ L + 36 | mFCP CHECKSUM (if present) | 4 Bytes +----------------------------------+ L + 40 | TRAILER CHECKSUM | 2 Bytes +----------------------------------+ Total Length = 42 + L Mullendore, Tseng, Monia Informational 14 mFCP November 2000 6.3 UDP Port Number An FCP Portal may use any UDP port consistent with the implementation of the IP stack. The destination FCP Portal saves the originating port number and uses the saved port number in all subsequent mFCP communications. The destination FCP Portal processes mFCP datagrams received on Port Number [TBD], a registered port number assigned by the IANA. 6.4 mFCP Checksum This field contains a CRC calculated over the data contained in the frame from the mFCP Header to the Payload (inclusive). The mFCP CRC algorithm is the same used for the Frame Check Sequence (FCS) of IEEE 802.3 Ethernet frames. The HEADER MARKER in the mFCP Header indicates the presence of the mFCP CRC Checksum or some other type of checksum. If the HEADER MARKER field is 0, then the mFCP Checksum field is present. 6.5 Trailer Checksum The UDP checksum can be any arbitrary non-zero value. The Trailer Checksum is calculated using the UDP checksum and UDP payload, and will be the value which will make the arbitrary UDP checksum correct. 7. Link Services The link services provide a set of functions that allow a port to send control information or request another port to perform a specific function. Each Link Service message (response and reply) is carried by a Fibre Channel sequence, and can be segmented into multiple frames.The mFCP 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 involve manipulation of field values as the Link Service message travels to and from the IP and Fibre Channel fabrics. It may also involve inclusion of additional "out-of-band" data through use of the AUGMENTATION DATA field in the mFCP header in order to make the Link Service message significant in the IP fabric. [Editor's Note: The method for processing multi-frame Link Service messages will be detailed in a subsequent draft] 7.1 Augmented Link Service Messages The following Link Service Messages must be augmented with additional "out-of-band" information carried in the mFCP header. Mullendore, Tseng, Monia Informational 15 mFCP November 2000 When the mFCP header encapsulates one of these Link Service messages in the mFCP payload, the AUGMENTATION PRESENT bit must be enabled in the mFCP FLAGS field, and the mFCP HEADER LENGTH must be adjusted appropriately to account for the additional augmentation data in the mFCP header. In addition, many ACC responses to the following Link Service messages must also have control data information carried in the encapsulating mFCP header. Link Service Message LS_COMMAND Short Name -------------------- ---------- ---------- Port Login 0x03000000 PLOGI Read Exchange Status Block 0x08000000 RES Read Sequence Status Block 0x09000000 RSS Request Sequence Initiative 0x0A000000 RSI Reinstate Recovery Qualifier 0x12000000 RRQ Read Exchange Concise 0x13000000 REC Third Party Process Logout 0x24 TPRLO Discover Address 0x52000000 ADISC The above Link Service messages use N_PORT fabric addresses in their message format, and must have the corresponding World Wide Port name (WWPN) carried in the AUGMENTATION DATA field of the iFCP header. The N_PORT fabric address field shall then be cleared while the Link Service message is carried in the mFCP frame. Upon receipt of the mFCP frame, the mFCP layer shall use the WWPN data in the mFCP header to replace the original N_PORT fabric address with the appropriate value. The following sections describe the contents and format of the mFCP AUGMENTATION DATA field in the mFCP header. Note that if appropriate, the augmentation may also apply to the corresponding ACC or LS_RJT reply. 7.1.1 Port Login (PLOGI) PLOGI provides the mechanism for establishing a login session between two N_PORTs. The PLOGI request carries information identifying the originating N_PORT, including specification of its capabilities and limitations. If the destination N_PORT accepts the login request, it sends a 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-PH, and shows the PLOGI message format for both request and accept (ACC) response. A port will reject a PLOGI request by transmitting an LS_RJT message, which contains no payload. Mullendore, Tseng, Monia Informational 16 mFCP November 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 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 = 118 Details on the above fields, including common and class-based service parameters, can be found in [FC-PH]. The above PLOGI message is transported by the mFCP layer without modification. However, additional accompanying information must be carried in the encapsulating mFCP header. The mFCP AUGMENTED DATA field in the mFCP header shall contain the following information: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | DEVICE TYPE | 4 Bytes +----------------------------------+ Total Length = 4 DEVICE TYPE - This field contains a value indicating the type of device. The allowed values are shown in the following table. A Parallel SCSI type is assumed to be attached by a SCSI-mFCP Router, while a Fibre Channel device is assumed to be attached by an mFCP Edge Switch. DEVICE TYPE Bit Field Device Type Values --------- ------------------ 7:4 RESERVED 3 iSCSI DEVICE 2 mFCP DEVICE 1 FIBRE CHANNEL DEVICE Mullendore, Tseng, Monia Informational 17 mFCP November 2000 0 PARALLEL SCSI DEVICE 7.1.2 Third Party Process Logout (TPRLO) TPRLO provides a mechanism for an N_PORT (third party) to remove one or more login sessions that exists 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 SCSI login session which shall be terminated by the command. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND | 1 Byte +----------------------------------+ 1 | PAGE LENGTH (0x10) | 1 Byte +----------------------------------+ 2 | PAYLOAD LENGTH (0x14) | 2 Bytes +----------------------------------+ 4 | TPRLO LOGOUT PARAMETER PAGE 1 | 2-4 Bytes +----------------------------------+ | . . . . | M Bytes +----------------------------------+ | TPRLO LOGOUT PARAMETER PAGE N | 2-4 Bytes +----------------------------------+ Total Length = Variable Each TPRLO LOGOUT PARAMETER PAGE identifies a remote N_PORT which when combined with the destination N_PORT identifies a SCSI session to be terminated. The TPRLO LOGOUT PARAMETER PAGE is of the following format: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | TYPE CODE | 1 Byte +----------------------------------+ 1 | TYPE CODE EXTENSION | 1 Byte +----------------------------------+ 2 | TPRLO FLAGS | 2 Bytes +----------------------------------+ 4 | ORIG PROCESS ASSOC (if present) | 4 Bytes +----------------------------------+ 8 | RESP PROCESS ASSOC (if present) | 4 Bytes +----------------------------------+ 12 | RESERVED | 1 Byte +----------------------------------+ 13 | THIRD PARTY ORIGINATOR N_PORT ID | 3 Bytes +----------------------------------+ Total Length = 16 Bytes Mullendore, Tseng, Monia Informational 18 mFCP November 2000 When the mFCP header contains a TPRLO message (including the ACC response), the mFCP AUGMENTED DATA field will contain the PORT_NAME(s) (WWPN) identifying the N_PORT described by the equivalent TPRLO LOGOUT PARAMETER PAGE(s). If more than one TPRLO LOGOUT PARAMETER PAGE is contained in the Link Service message, equivalent additional PORT_NAME shall also be carried in the mFCP AUGMENTED DATA field. PORT_NAMEs shall be listed in the same order as the equivalent TPRLO LOGOUT PARAMETER PAGEs in the original Link Service message. The following diagram describes the PORT_NAME entries in the mFCP AUGMENTATION DATA field in the mFCP header: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | 3rd PARTY ORIG PORT NAME 1 | 8 Bytes +----------------------------------+ 8 |3rd PTY ORIG PORT NAME 2 (if pres)| 8 Bytes +----------------------------------+ 16 | . . . . | +----------------------------------+ Additionally, the THIRD PARTY ORIGINATOR N_PORT ID field in each TPRLO LOGOUT PARAMETER PAGE shall be cleared when it is carried by the mFCP header. This applies to both the original Link Service message and the ACC response. When the mFCP layer receives a TPRLO message with AUGMENTATION DATA in the mFCP header, it shall use the latter to replace the THIRD PARTY ORIGINATOR N_PORT ID in the original Link Service message, before forwarding it on to the upper Fibre Channel layers. Additional information on TPRLO can be found in [FC-PH-2]. 7.1.3 Reinstate Recovery Qualifier (RRQ) RRQ is a request to release resources previously made unavailable as a result of an ABTS or ABTX. The following shows the format of an RRQ request message. Mullendore, Tseng, Monia Informational 19 mFCP November 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND | 4 Bytes +----------------------------------+ 4 | RESERVED | 1 Bytes +----------------------------------+ 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes +----------------------------------+ 8 | RRQ OX_ID | 2 Bytes +----------------------------------+ 10 | RRQ RX_ID | 2 Bytes +----------------------------------+ Total Length = 12 Upon transmitting the RRQ Link Service message to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. Furthermore, the mFCP layer shall add the EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. The EXCHANGE ORIGINATOR is a 4-byte field set to 0x00000001 to indicate that the RRQ originator is also the originator of the exchange for which the Recovery Qualifier is being reinstated. This field is set to 0x00000000 to indicate that the RRQ recipient is the originator of the exchange for which the Recovery Qualifier is being reinstated. RRQ OX_ID - The OX_ID of the exchange for which the Recovery Qualifier is being reinstated. RRQ RX_ID - The RX_ID of the exchange for which the Recovery Qualifier is being reinstated. Upon receipt of the RRQ Link Service message from the IP network, the iFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace the EXCHANGE ORIGINATOR S_ID field before forwarding the message on to the upper Fibre Channel layers. The ACC reply contains only the LS_COMMAND field as the payload, and does not require additional augmentation data. An LS_RJT reply may be sent in lieu of ACC, to indicate that the RRQ was rejected. 7.1.4 Read Exchange Concise (REC) REC is a request for information on an exchange. The following shows the format of an REC request. Mullendore, Tseng, Monia Informational 20 mFCP November 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND | 4 Bytes +----------------------------------+ 4 | RESERVED | 1 Bytes +----------------------------------+ 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes +----------------------------------+ 8 | REC OX_ID | 2 Bytes +----------------------------------+ 10 | REC RX_ID | 2 Bytes +----------------------------------+ Total Length = 12 Upon transmitting the REC Link Service message to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. Furthermore, the mFCP layer shall add the EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. The EXCHANGE ORIGINATOR is a 4-byte field set to 0x00000001 to indicate that the REC originator is also the originator of the exchange for which status is being requested. This field is set to 0x00000000 to indicate that the REC recipient is the originator of the exchange for which status is being requested. REC OX_ID - The OX_ID of the exchange for which information is being requested. REC RX_ID - The RX_ID of the exchange for which information is being requested. RX_ID may be 0xFFFF, indicating RX_ID is unassigned. Upon receipt of the REC Link Service message from the IP network, the iFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace the EXCHANGE ORIGINATOR S_ID field before forwarding the message on to the upper Fibre Channel layers. The following shows the format of the ACC payload in response to REC. Mullendore, Tseng, Monia Informational 21 mFCP November 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND (0x02000000) | 4 Bytes +----------------------------------+ 4 | REC OX_ID | 2 Bytes +----------------------------------+ 6 | REC RX_ID | 2 Bytes +----------------------------------+ 8 | RESERVED | 1 Byte +----------------------------------+ 9 | EXCHANGE ORIGINATOR N_PORT ID | 3 Bytes +----------------------------------+ 12 | RESERVED | 1 Byte +----------------------------------+ 12 | EXCHANGE RESPONDER N_PORT ID | 3 Bytes +----------------------------------+ 16 | DATA TRANSFER COUNT | 4 Bytes +----------------------------------+ 20 | E_STAT | 4 Bytes +----------------------------------+ Total Length = 24 Upon transmitting the ACC response to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR N_PORT ID and EXCHANGE RESPONDER N_PORT ID fields when encapsulating the ACC message into mFCP. Furthermore, the mFCP AUGMENTED DATA field in the encapsulating mFCP header shall contain the EXCHANGE RESPONDER field, which is identical to the EXCHANGE ORIGINATOR value used to augment the original REC request message. REC OX_ID - The OX_ID of the exchange for which information is being returned. It should be identical to the REC OX_ID field in the REC request. REC RX_ID - The RX_ID of the exchange for which information is being returned. This field should also be identical to the REC RX_ID field in the REC request. When receiving the ACC response message from the IP network, the mFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and EXCHANGE RESPONDER (in the mFCP header) to replace the EXCHANGE ORIGINATOR N_PORT ID and EXCHANGE RESPONDER N_PORT ID fields before passing the Link Service message on to the upper Fibre Channel layers. DATA TRANSFER COUNT - The number of bytes received by an N_PORT for a write command, or the number of bytes for a read command. E_STAT (Exchange Status) - Of the bits defined in this field, two are particularly significant to mFCP: Mullendore, Tseng, Monia Informational 22 mFCP November 2000 Bit Field Description Significance --------- ----------- ------------ 30 SEQUENCE INITIATIVE 0 = Other port holds sequence init 1 = This port holds sequence init 29 Completion 0 = Open 1 = Closed An LS_RJT reply may be sent in lieu of ACC, to indicate that the REC was rejected. 7.1.5 Discover Address (ADISC) ADSC allows devices to exchange name (Port and Node) information. This allows verification of Port and Node addresses. The following shows the format of the ADISC request message. The ACC response is identical except the command code is replaced with the ACC code (0x02000000), and the PORT_NAME and NODE_NAME fields are those of the responder. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND | 4 Bytes +----------------------------------+ 4 | RESERVED | 1 Byte +----------------------------------+ 5 | HARD ADDRESS | 3 Bytes +----------------------------------+ 8 | ORIGINATOR/RESPONDER PORT NAME | 8 Bytes +----------------------------------+ 16 | ORIGINATOR/RESPONDER NODE NAME | 8 Bytes +----------------------------------+ 24 | RESERVED | 1 Byte +----------------------------------+ 25 | ORIGINATOR N_PORT ID | 3 Bytes +----------------------------------+ Total Length = 28 The HARD ADDRESS field has no meaning for mFCP. The field may contain non-zero values in the request message, but shall be zeroed in the ADISC response. Upon transmission to the IP network, the ORIGINATOR N_PORT ID shall be zeroed in both the request and ACC response messages. Upon receipt of the request or ACC response from the IP network, the mFCP layer shall use the ORIGINATOR/RESPONDER PORT_NAME and NODE_NAME to replace the ORIGINATOR N_PORT ID with the appropriate value, before forwarding the message on to upper Fibre Channel layers. Mullendore, Tseng, Monia Informational 23 mFCP November 2000 The following parameters are used for the ADISC request message. ORIGINATOR PORT NAME - This field contains the World Wide Port Name (WWPN) of the mFCP port from which the ADSC request is being originated. ORIGINATOR NODE NAME - This field contains the WWPN of the mFCP node from which the ADSC request is being originated. 7.1.6 Request Exchange Status (RES) RES requests the status of a specific exchange. The RES request is sent in a new exchange. The following shows the RES message format. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND (0x08000000) | 4 Bytes +----------------------------------+ 4 | RESERVED | 1 Byte +----------------------------------+ 7 | EXCHANGE ORIGINATOR S_ID | 3 Bytes +----------------------------------+ 8 | RES OX_ID | 2 Bytes +----------------------------------+ 10 | RES RX_ID | 2 Bytes +----------------------------------+ Total Length = 12 Upon transmitting the RES Link Service message to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. Furthermore, the mFCP layer shall add the EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. The EXCHANGE ORIGINATOR is a 4-byte field. When 0x00000001, itindicates that the RES requester is the originator of the exchange for which status is being requested. When 0x00000000, indicates that the RES recipient is the originator of the exchange for which status is being requested. RES OX_ID - Specifies the OX_ID of the exchange for which status is being requested. RES_RX_ID - Specifies the RX_ID of the exchange for which status is being requested. If the RES recipient does not have an Exchange Status Block for the specified exchange, it shall respond with an LS_RJT message with a reason code of "UNABLE TO PERFORM COMMAND REQUEST". Mullendore, Tseng, Monia Informational 24 mFCP November 2000 Upon receipt of the RES Link Service message from the IP network, the iFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace the EXCHANGE ORIGINATOR S_ID field before forwarding the message on to the upper Fibre Channel layers. The payload for the ACC response is a variable-length block of information called the EXCHANGE STATUS BLOCK. The Exchange Status Block (ESB) is used throughout an exchange to track the exchange's progress and identify which ports holds sequence initiative. The ESB has the following format shown below. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | ESB OX_ID | 1 Byte +----------------------------------+ 2 | ESB RX_ID | 2 Bytes +----------------------------------+ 4 | RESERVED | 1 Byte +----------------------------------+ 5 | ORIGINATOR N_PORT ID | 3 Bytes +----------------------------------+ 4 | RESERVED | 1 Byte +----------------------------------+ 5 | RESPONDER N_PORT ID | 3 Bytes +----------------------------------+ 6 | E_STAT | 4 Bytes +----------------------------------+ | RESERVED | 4 Bytes +----------------------------------+ 8 | SERVICE PARAMETERS | 112 Bytes +----------------------------------+ 88 | OLDEST SHORT SSB | 8 Bytes +----------------------------------+ 96 | INTERMEDIATE SHORT SSB | X*8 Bytes +----------------------------------+ 96 + X*8 | NEWEST SHORT SSB | 8 Bytes +----------------------------------+ Total Length = 104 + X*8 ESB OX_ID - The OX_ID for the exchange status saved in the ESB. ESB RX_ID - The RX_ID for the exchange status saved in the ESB. Upon transmitting the ACC reply to the IP network, the mFCP layer shall clear the ORIGINATOR N_PORT_ID and RESPONDER N_PORT ID fields. Furthermore, the mFCP layer shall add a 4-byte EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. When the EXCHANGE ORIGINATOR field is 0x00000001, this indicates that the port sending the RES message (or receiving the ACC reply) is the originator of the exchange whose status is saved in the ESB. Mullendore, Tseng, Monia Informational 25 mFCP November 2000 When the EXCHANGE ORIGINATOR is 0x00000000, this indicates that the port receiving the RES message (or sending the ACC reply) is the originator of the exchange whose status is saved in the ESB. Upon receipt of the ACC reply from the IP network, the iFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace the ORIGINATOR and RESPONDER N_PORT ID fields before forwarding the message on to the upper Fibre Channel layers. More information on RES and the Exchange Status Block (ESB) can be found in [FC-PH]. 7.1.7 Request Sequence Initiative (RSI) RSI allows a sequence recipient to request sequence initiative be passed for an open exchange. The RSI recipient responds in the following manner if the RSI request identifies an open exchange. The following shows the format of the RSI request message. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND (0x12000000) | 4 Bytes +----------------------------------+ 4 | RESERVED | 1 Byte +----------------------------------+ 7 | EXCHANGE ORIGINATOR S_ID | 3 Bytes +----------------------------------+ 8 | RSI OX_ID | 2 Bytes +----------------------------------+ 10 | RSI RX_ID | 2 Bytes +----------------------------------+ Total Length = 12 Upon transmitting the RSI Link Service message to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. Furthermore, the mFCP layer shall add a 4-byte EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. The EXCHANGE ORIGINATOR field, when 0x00000001, indicates that the RSI requester is the originator of the exchange for which initiative is being requested. When EXCHANGE ORIGINATOR is set to 0x00000000, this indicates the RSI recipient is the originator of the exchange for which initiative is being requested. RSI OX_ID - Specifies the OX_ID of the exchange for which sequence initiative is being requested. RSI RX_ID - Specifies the RX_ID of the exchange for which sequence initiative is being requested. Mullendore, Tseng, Monia Informational 26 mFCP November 2000 Upon receipt of the RSI message from the IP network, the iFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header) and the EXCHANGE ORIGINATOR value (in the iFCP header) to replace the EXCHANGE ORIGINATOR S_ID field before forwarding the message on to the upper Fibre Channel layers. An ACC response is sent after the sequence initiative has been transferred, or if it already has been transferred. The ACC response only has the 4-byte LS_COMMAND field as the payload. An LS_RJT response may be sent if the RSI parameters do not specify an open exchange (invalid OX_ID/RX_ID combination). 7.1.8 Read Sequence Status (RSS) RSS requests the status of a specific sequence in an exchange. The following shows the format of the RSS request. Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | LS_COMMAND (0x09000000) | 4 Bytes +----------------------------------+ 4 | SEQ_ID | 1 Byte +----------------------------------+ 5 | EXCHANGE ORIGINATOR S_ID | 3 Bytes +----------------------------------+ 8 | RSS OX_ID | 2 Bytes +----------------------------------+ 10 | RSS RX_ID | 2 Bytes +----------------------------------+ Total Length = 12 Upon transmitting the RSS Link Service message to the IP network, the mFCP layer shall clear the EXCHANGE ORIGINATOR S_ID field. Furthermore, the mFCP layer shall add a 4-byte EXCHANGE ORIGINATOR to the mFCP AUGMENTED DATA field in the mFCP header. The EXCHANGE ORIGINATOR field, when 0x00000001, indicates that the RSS requester is the originator of the exchange for which sequence status is being requested. When EXCHANGE ORIGINATOR is set to 0x00000000, this indicates the RSS recipient is the originator of the exchange for which sequence status is being requested. SEQ_ID - Specifies the SEQ_ID of the sequence for which status is being requested. RSS OX_ID - Specifies the OX_ID of the exchange for which sequence status is being requested. RSS RX_ID - Specifies the RX_ID of the exchange for which sequence status is being requested. Mullendore, Tseng, Monia Informational 27 mFCP November 2000 Upon receipt of the RSS message from the IP network, the mFCP layer shall use the N_PORT fabric addresses (in the Fibre Channel header), and the EXCHANGE ORIGINATOR value (in the mFCP header) to replace the EXCHANGE ORIGINATOR S_ID field before forwarding the message on to the upper Fibre Channel layers. The ACC response payload for an RSS request consists of a single 16-byte field, the Sequence Status Block (SSB), shown below. If the RSS recipient does not have a Sequence Status Block, it shall respond with an LS_RJT with a reason code of "UNABLE TO PERFORM COMMAND REQUEST". More information on the Sequence Status Block can be found in [FC-PH]. 8 Error Detection and Recovery Procedures for mFCP 8.1 Overview [FCP-2], [FC-PH], and [FC-PH-2] define error detection and recovery procedures. These Fibre Channel-defined mechanisms continue to be available in the mFCP environment. 8.2 Timer Definitions 8.2.1 Error_Detect_Timeout (E_D_TOV) E_D_TOV is "a reasonable timeout value for detection of a response to a time event". The default value specified by FC-PH of 10 seconds will be also used as the mFCP default value. E_D_TOV is the maximum time allowed between the transmission of consecutive data frames within a sequence. For Class 2 service, E_D_TOV specifies the maximum time interval between transmission of a frame, and receipt of the ACK for that frame. [The policy for setting E_D_TOV for an IP fabric is TBS] 8.2.2 Resource Allocation Timeout (R_A_TOV) R_A_TOV is defined in FC-PH-2 as "the maximum transit time within a fabric to guarantee that a lost frame will never emerge from the fabric". A value of 2 x R_A_TOV is the minimum time that the originator of an ELS request or FC-4 ELS request shall wait for the response to that request. [The policy for setting R_A_TOV for an IP fabric is TBS] 8.2.3 Resource Recovery Timer (RR_TOV) [The content of this section is TBD] 9. Security Mullendore, Tseng, Monia Informational 28 mFCP November 2000 9.1 Overview As with any other IP-based network, an mFCP storage network has security issues which must be addressed with the appropriate security policies and enforcement resources. There are various levels of security paradigms which when applied appropriately to an mFCP network can provide sufficient levels of security, including data integrity, authentication, and privacy, depending on user needs. 9.2 Physical Security Most existing SCSI and Fibre Channel interconnections are deployed in private, physically isolated environments where hostile entities are not provided access to the SCSI and Fibre Channel interconnects. This is the most basic security mechanism, and may be a sufficient model in some cases for an mFCP network. 9.3 Controlling Access A second level of security is the use of zoning. Zoning specifies which devices are allowed to communicate, and is similar in concept to VLAN (Virtual Local Area Network) technology. Zoning information is maintained in a Name Server. 9.4 Authentication and Encryption Where additional levels of data integrity and privacy are required for mFCP, existing IPSec specifications can be applied to mFCP. Because IPSec is a layer-3 technology and has no knowledge of TCP, UDP, or higher-level protocols such as mFCP and FCP, it can be applied transparently to mFCP. The following IETF documents describe the operational framework and automatic keying mechanisms for IPSec. RFC2401 Security Architecture for the Internet Protocol RFC2402 IP Authentication Header RFC2406 IP Encapsulating Security Payload RFC2407 The Internet IP Security Domain of Interpretation for ISAKMP RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC2409 The Internet Key Exchange (IKE) 9.5 Storage Firewalls Firewalls are a common and proven methodology for securing access to IP-based networks, and they can be appropriate for use in IP- based storage networks as well. A firewall is a choke point through which all transit traffic must transit in order to pass between two separate networks. Mullendore, Tseng, Monia Informational 29 mFCP November 2000 Access to storage resources can be secured by setting up a single gateway through which all outside non-secured traffic must pass through in order to access resources in the storage network. Such a firewall can be a proxy host operating at the session or application layer, requiring authentication before allowing traffic to pass. It can also be a stateful inspection gateway which understands the mFCP protocol, and can passively inspect and discover security threats as they transit the gateway. A third option is to use a standard router access control list to filter authorized traffic based upon static parameters such as IP addresses and TCP port numbers. 10. Glossary 10.1 Definitions address identifier - An address value used to identify source (S_ID) or destination (D_ID) of a frame. application client - An object that is the source of SCSI commands. application client buffer offset - Offset in bytes from the start or base address of the application client's data buffer to the location for the transfer of the first byte of a data delivery service request. base address - The address of the lowest address byte to be transferred to or from an application client buffer. command - A request describing a unit of work to be performed by a device server. command descriptor block - A structure used to communicate a command from an application client to a device server. device server - An object within the logical unit which executes SCSI tasks and enforces the rules for task management. FCP I/O operation - An unlinked SCSI command, a series of linked SCSI commands, or a task management function. FCP_Port - An N_Port or NL_Port that supports the SCSI Fibre Channel Protocol. fully qualified exchange identifier - A token used to uniquely identify a FCP I/O operation. information unit - An organized collection of data specified by the FCP to be transferred as a single sequence by the Fibre Channel serice interface. Mullendore, Tseng, Monia Informational 30 mFCP November 2000 initiator - A SCSI device containing application clients that originate device service requests and task management functions to be processed by a target SCSI device. logical unit - A target resident entity that implements a device model and executes SCSI commands sent by an application client. logical unit identifier - Identifier used by an initiator to reference the logical unit. logical unit number - An encoded 64-bit identifier for a logical unit. NL_Port - An N_Port that contains arbitrated loop functions associated with the Fibre Channel Arbitrated Loop topology. N_Port - A hardware entity that supports FC-PH. It may act as an originator, a responder, or both. Originator - The logical function associated with an N_Port responsible for originating an Exchange. Originator Exchange Identifier (OX_ID) - An identifier assigned by an Originator to identify an Exchange and meaningful only to the Originator. Port Login (PLOGI) - The Fibre Channel Extended Link Service (ELS) that exchanges identification and operation parameters between an originating N_Port and a responding N_Port. recovery abort - FC-PH protocol that recovers FCP_Port resources by terminating the Exchange and FCP I/O Operation. request byte count - Number of bytes to be moved by a data delivery service request. Responder - The logical function in an N_Port responsible for supporting the Exchange initiated by the Originator in another N_Port. Responder Exchange Identifier (RX_ID) - An identifier assigned by a Responder to identify an exchange, and meaningful only to the Responder. Source_Identifier - The address identifier used to indicate the source port of the transmitted frame. SCSI device - A device that originates or services SCSI commands. tag - The initiator-specified component of the task identifier. Mullendore, Tseng, Monia Informational 31 mFCP November 2000 target - A SCSI device that receives SCSI commands and directs such commands to one or more logical units for execution. target identifier - Address of up to 64 bits by which a target is identified. task - An object within the logical unit representing the work associated with a command or group of linked commands. task attribute - The queuing specification for a task (SIMPLE, ORDERED, HEAD OF QUEUE, ACA). task identifier - The information uniquely identifying a task task management function - A peer-to-peer confirmed service provided by a task manager that can be invoked by an application client to affect the execution of one or more tasks. 10.2 Abbreviations and Acronyms ABTS Abort Sequence ACA Automatic Contingent Allegiance AH Authentication Header AL_PA Arbitrated Loop Physical Address API Application Program Interface BLS Basic Link Service CDB Command Data Block CRC Cyclic Redundancy Checksum CRN Command Reference Number DHCP Dynamic Host Configuration Protocol DOI Domain of Interpretation HBA Host Bus Adapter ELS Extended Link Service EOF End of Frame EPDC Enable Precise Delivery Checking ESP Encapsulating Security Payload FC Fibre Channel FC-AL Fibre Channel Arbitrated Loop FC-FLA Fibre Channel Fabric Loop Attachment FCP Fibre Channel Protocol for SCSI FCP/IP FCP over IP FIP FCP over Internet Protocol Architecture HBA Host Bus Adapter IANA Internet Assigned Numbers Authority ICMP Internet Control Message Protocol IEEE The Institute of Electrical and Electronic Engineers IKE Internet Key Exchange I/O Input/Output IP Interet Protocol ISAKMP Internet Security Association and Key Management Protocol IU Information Unit Mullendore, Tseng, Monia Informational 32 mFCP November 2000 JBOD Just a Bunch of Disks LAN Local Area Network LSb Least Significant Bit LSB Least Significant Byte LUN Logical Unit Number MAN Metropolitan Area Network MPLS Multi-Protocol Label Switching MSb Most Significant Bit MSB Most Significant Byte MTU Maximum Transmission Unit NAA Network Address Authority NOP No Operation OUI Organizationally Unique Identifier OX_ID Originator Exchange ID RDMA Remote Direct Memory Access RX_ID Responder Exchange ID RAID Redundant Arrays of Inexpensive Disks SAM SCSI Architecture Model SAM-2 SCSI Architecture Model - 2 SAN Storage Area Network SCSI Small Computer Systems Interface SDB Stream Data Block SNS Storage Name Server SOF Start of Frame TBD To Be Determined TCP Transport Control Protocol UDP User Datagram Protocol ULA Universal LAN MAC Address ULP Upper Level Protocol (or Upper Layer Protocol) VPN Virtual Private Network WAN Wide Area Network WWN World Wide Name WWNN World Wide Node Name WWPN World Wide Port Name 11. References 11.1 Relevant SCSI (T10) Specifications The following documents are available from: Global Engineering, 15 Inverness Way East, Englewood, CO 80112-5704. Telephone (800) 854-7179 or (303) 792-2181, Fax: (303) 792-2192 SCSI-3 Architecture Model (SAM), ANSI X3.270-1996 SCSI Architecture Model-2 (SAM-2), Project 1157-D, revision 11 SCSI Primary Commands (SPC), ANSI X3.301-1997 SCSI Primary Commands-2 (SPC-2), Project 1236-D, revision 16 Fibre Channel Protocol for SCSI (FCP), ANSI X3.269-1996 Mullendore, Tseng, Monia Informational 33 mFCP November 2000 Fibre Channel Protocol for SCSI, Second Revision (FCP-2), Project 1144D, revision 04 11.2 Relevant Fibre Channel (T11) Specifications The following documents are available from: Global Engineering, 15 Inverness Way East, Englewood, CO 80112-5704. Telephone (800) 854-7179 or (303) 792-2181, Fax: (303) 792-2192 Fibre Channel Physical and Signaling Interface (FC-PH) Rev 4.3, ANSI X3.230:1994 Fibre Channel Physical and Signaling Interface (FC-PH-2) Rev 7.4, ANSI X3.297:1997 Fibre Channel Physical and Signaling Interface (FC-PH-3) Rev 9.4, ANSI X3.303:1998 Fibre Channel Generic Requirements (FC-FG) Rev 3.5, ANSI X3.289:1996 Fibre Channel Generic Services (FC-GS-2) Rev 5.2, ANSI NCITS 288 Fibre Channel Arbitrated Loop (FC-AL) Rev 4.5, ANSI X3.272:1996 Fibre Channel Arbitrated Loop (FC-AL-2) Rev 7.0, NCITS 332:1999 Fibre Channel Private Loop SCSI Direct Attachment (FC-PLDA), NCITS TR-19:1998 Fibre Channel Fabric Loop Attachment (FC-FLA), NCITS TR-20:1998 Fibre Channel Tape and Tape Medium Changers (FC-TAPE), NCITS TR- 24:1999 11.3 Relevant RFC Documents RFC768 User Datagram Protocol RFC791 Internet Protocol, DARPA Internet Program Protocol Specification RFC1146 TCP Alternate Checksum Options RFC2401 Security Architecture for Internet Protocol RFC2402 IP Authentication Header RFC2406 Encapsulating Security Protocol (ESP) RFC2407 The Internet IP Security Domain for ISAKMP Mullendore, Tseng, Monia Informational 34 mFCP November 2000 RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC2409 The Internet Key Exchange (IKE) RFC2460 Internet Protocol, Version 6 (IPv6) Specification 11.4 Other Reference Documents Fibre Channel, Gigabit Communications and I/O for Computer Networks, Alan F. Beener, McGraw-Hill, ISBN 0-07-005669-2 The Fibre Channel Consultant, A Comprehensive Introduction, Robert W. Kembel, Northwest Learning Associates, ISBN 0-931836-82-6 The Fibre Channel Consultant, Arbitrated Loop, Rober W. Kembel, Connectivity Solutions, a division of Northwest Learning Associates, ISBN 0-931836-84-0 12. Author's Addresses Charles Monia Rod Mullendore Josh Tseng Nishan Systems 3850 North First Street San Jose, CA 95134 Phone: 408-519-3986 Email: cmonia@nishansystems.com Mullendore, Tseng, Monia Informational 35 mFCP November 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 Mullendore, Tseng, Monia Informational 36