IP Storage Working Group Rod Mullendore INTERNET DRAFT Charles Monia Josh Tseng Expires November, 2001 Nishan Systems Category: Informational May 2001 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 made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the author(s). Mullendore, Tseng, Monia Informational 1 mFCP -- Version 1 May 2001 mFCP - Metro FCP protocol for IP Networking.....................1 Status of this Memo.............................................1 Comments........................................................1 1. Abstract...................................................3 2. About This Document........................................3 2.1 Conventions Used in this Document........................3 2.2 Purpose of this document.................................3 3. mFCP Introduction..........................................3 3.1 Definitions..............................................4 3.2 The mFCP Network Model...................................5 3.3 Native mFCP Devices......................................6 3.4 Gateway Region Properties................................7 3.5 mFCP Services............................................7 3.6 The N_PORT Addressing Model..............................8 3.6.1 Operation in Address Transparent Mode.................11 3.6.2 Operation in Address Translation Mode.................12 4. mFCP Protocol.............................................15 4.1 Overview................................................15 4.2 mFCP Congestion Control.................................16 4.3 UDP Encapsulation of Fibre Channel Frames...............16 4.3.1 Encapsulation Header Format...........................16 4.3.2 Common Encapsulation Flags............................19 4.3.3 SOF and EOF Delimiter Fields..........................20 4.3.4 Frame Encapsulation and De-encapsulation..............21 4.4 Link Services...........................................22 4.4.1 Augmented Link Service Messages.......................23 4.4.2 Augmented Link Services Requiring Payload Address Translation....................................................24 4.4.3 Augmented Link Services...............................26 4.5 Error Detection and Recovery Procedures for mFCP........40 4.5.1 Timer Definitions and Stale Frame Detection...........40 5. Fabric Services Supported by an mFCP implementation.......42 5.1 mFCP Support for the FC Broadcast Service...............43 6. Security..................................................44 6.1 Overview................................................44 6.2 Physical Security.......................................44 6.3 Controlling Access......................................44 6.4 Authentication and Encryption...........................44 6.5 Storage Firewalls.......................................45 7. References................................................45 7.1 Relevant RFC Documents..................................45 8. Author's Addresses........................................46 A. mFCP Support for Fibre Channel Link Services..............47 A.1 Basic Link Services.....................................47 A.2 Link Services Processed Transparently...................47 A.3 Augmented Link Services.................................48 Full Copyright Statement.......................................50 Mullendore, Tseng, Monia Informational 2 mFCP -- Version 1 May 2001 1. Abstract This document describes mFCP, a UDP-based [UDP] implementation of the iFCP Fibre Channel Protocol [iFCP] over metro- and local-scale IP networks. These networks are provisioned to have latency, reliability, and performance levels comparable to that of a Fibre Channel network. Storage devices use the Fibre Channel SCSI mapping in [FCP] for data transport and error recovery. mFCP leverages these existing mechanisms to facilitate high-performance interconnection of Fibre Channel- based storage devices over suitably provisioned IP networks. As in the case of iFCP, fibre channel frames may be transported natively over such a network without Fibre Channel switching and routing elements. Congestion control provisions for mFCP will be specified in the next release of this document. 2. About This Document 2.1 Conventions Used in this Document The key 0words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 mFCP is a mapping of the iFCP protocol to UDP. The UDP mapping facilitates high performance through a lightweight mechanism for the encapsulation and transport of fibre channel frame images over an IP network. mFCP achieves high performance by forwarding Fibre Channel frames directly between Fibre Channel end nodes without the protocol translation overhead of conventional storage bridging approaches. mFCP assumes that the IP network's physical infrastructure is provisioned to provide reliability equivalent to that of a comparable fibre channel fabric. Mullendore, Tseng, Monia Informational 3 mFCP -- Version 1 May 2001 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 Fibre Channel specifications [FC PH]. FCP Portal - An IP-addressable entity representing the point at which a logical or physical fibre channel device is attached to the IP network. Gateway Region û The portion of the storage network accessed through an mFCP gateway. Devices in the region consist of all fibre channel devices directly attached to the gateway. 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 fibre channel standard [FC PH]. 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 locally- attached Fibre Channel device. mFCP û The protocol discussed in this document. Logical mFCP Device - An abstraction representing a Fibre Channel device as it appears on an IP network. 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 Mullendore, Tseng, Monia Informational 4 mFCP -- Version 1 May 2001 object names is provided by an iSNS name server [iSNS]. mFCP Frame - The encapsulated FC frame inserted into a UDP datagram. 3.2 The mFCP Network Model The mFCP network model is based on the iFCP network model described in [iFCP] and summarized here. 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 [FC PH]. 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 PH]. 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. +--------+ +--------+ | FC | | FC | | Device | | Device | |........| |........| Fibre Channel | N_PORT |<------>| N_PORT | Device Domain +---+----+ +----+---+ ^ | | | +---+----+ +----+---+ | | F_PORT | | F_PORT | | ==========+========+========+========+============== | Fabric & | | | Fabric Services | v | | Fibre Channel +--------------------------+ Fabric Domain Figure 1 -- A Fibre Channel Fabric Mullendore, Tseng, Monia Informational 5 mFCP -- Version 1 May 2001 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 | Control | Fabric | Traffic | | | | | |<-----Encapsulated Frames------->| | +------------------+ | | | | | +------+ IP Network +-------+ | | +------------------+ Figure 2 -- An mFCP Fabric 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 an mFCP edge switch or gateway. Each gateway controls a single gateway region. At the N_PORT interface, the network appears as a Fibre Channel fabric. 3.3 Native mFCP Devices Figure 3 shows an IP fabric with a mFCP device directly attached. Mullendore, Tseng, Monia Informational 6 mFCP -- Version 1 May 2001 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 +-------+ | | +--------------------+ Figure 3 -- mFCP Network with native mFCP Device For a native mFCP device, the major difference is that, unlike a gateway, the N_PORT layer is aware of the underlying IP environment. 3.4 Gateway Region Properties The fabric configuration and topology within the gateway region are opaque to the IP network. That is, the topology in the fibre channel domain within the regions, whether it is loop- or switch-based, is hidden from the IP network and from other gateways. Consequently, support for such FC fabric topologies becomes a gateway implementation option. In such cases, the gateway incorporates whatever functionality is required to distill and present locally attached N_PORTs (or NL_PORTs) as logical iFCP devices. The mFCP fabric shown in Figure 2, for example, contains two gateway regions. Each consists of Fibre Channel devices directly connected to the mFCP fabric through F_PORTs implemented as part of the edge switch or gateway. An alternative implementation might consist of two NL_PORTs connected by means of a fabric attached loop. To an external gateway, both topologies would look the same. 3.5 mFCP Services Mullendore, Tseng, Monia Informational 7 mFCP -- Version 1 May 2001 N_PORT to N_PORT communications that traverse an IP network require the intervention of the mFCP layer. This consists of the following operations: a) Transparent conversion of a fibre channel frame to a UDP datagram by means of the frame addressing, mapping and encapsulation functions described in section 3.6. b) Execution of fabric-supplied link services addressed to one of the well-known Fibre Channel N_PORT addresses. c) De-encapsulation of Fibre Channel frames received from the IP network as UDP datagrams. d) Establishment of an N_PORT login session in response to a PLOGI directed to a remote device. The following sections discuss the process for the transparent movement of frames between N_PORTs attached to an mFCP fabric. 3.6 The N_PORT Addressing Model This section discusses the role of the N_PORT addressing model 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 mFCP gateway assigns and manages fibre channel N_PORT fabric addresses as described in the following sections. As shown in Figure 4, the fibre channel address of an N_PORT device is a 24-bit value having the format defined by the fibre channel specification [FC PH]. Bit 23 16 15 8 7 0 +-----------+------------+----------+ | Domain ID | Area ID | Port ID | +-----------+------------+----------+ Figure 4 -- Fibre Channel Address Format Such addresses are volatile and subject to change based on modifications in the fabric configuration. Mullendore, Tseng, Monia Informational 8 mFCP -- Version 1 May 2001 In a fibre channel fabric, each switch element has a unique Domain I/D assigned by a master switch. The value of the Domain I/D ranges from 1 to 239 (0xEF). Each switch in turn controls a 65K block of addresses divided into area and port IDs. N_PORTs logging into the fabric receive a unique fabric address consisting of the switchÆs Domain I/D concatenated with switch- assigned area and port I/Ds. These N_PORT addresses are carried in the fibre channel frame as shown in the following diagram. Bit 31 24 23 0 +--------+-----------------------------------+ Word 0 | | Destination N_PORT Address (D_ID) | +--------+-----------------------------------+ Word 1 | | Source N_PORT Address (S_ID) | +--------+-----------------------------------+ . | | . | Control information | . | and Payload | Word 527 +--------------------------------------------+ (Max) Figure 5 -- Fibre Channel Address Fields within a Frame The D_ID and S_ID fields represent the fabric addresses of the source and destination N_PORTs respectively. In an mFCP storage fabric, the gateway replaces the FC switch element as the device responsible for N_PORT address assignment and frame routing. Unlike an FC switch, however, an mFCP gateway must route frames between N_PORTs within the gateway region or to external devices attached to remote gateways on the IP network. In order to be FC-compatible, 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 device addresses in one of two ways: a) Address Transparent Mode û A mode of address assignment in which several gateways collaborate to form a ælogical fabricÆ. 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 3.6.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. Mullendore, Tseng, Monia Informational 9 mFCP -- Version 1 May 2001 b) Address Translation Mode û A mode of address assignment in which the scope of all N_PORT device addresses, including remote devices, is local to each gateway region. The address of a remote device is represented by a gateway assigned N_PORT alias. All mFCP implementations MUST support operation in address translation mode. Support for address transparent mode is optional. The choice of addressing mode involves tradeoffs between scalability, and transparency. The scalability constraints are a consequence of the Fibre Channel address allocation policy previously described. As noted, an IP 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. 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 mFCP gateways, Fibre Channel devices and switch elements may be internetworked. This mode of address allocation also simplifies management of the IP storage fabric configuration by eliminating the need for a centralized address-assignment authority. A consequence of address translation mode is that the 24-bit N_PORT address is no longer unique across the storage 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 gateways. 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 the extended link service messages described in section 4.4.3. The process of N_PORT I/D translation for the frame header is described in section 3.6.2. The processing for link services with frame addresses in the payload is described in section 4.4.1. The details of the address transparent and address translation operational modes are discussed in the following sections. Mullendore, Tseng, Monia Informational 10 mFCP -- Version 1 May 2001 3.6.1 Operation in Address Transparent Mode The use of address transparent mode is an alternative where address transparency is desired. In addition to the scalability limits discussed above, the following considerations and requirements pertain 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 mFCP 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 clients under different iSNS authorities can be made to interoperate. c) mFCP gateways in transparent mode will not interoperate with gateways that are not in transparent mode. d) When interoperating with locally attached Fibre Channel fabrics, the mFCP gateway MUST assume control of DOMAIN_ID assignments in accordance with the appropriate Fibre Channel standard or specification. As described in section 3.6.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, and no link service Messages shall be augmented with additional information by the mFCP layer. The process for establishing the IP context associated with an N_PORT login session in this mode is similar to that specified for address translation mode (section 3.6.2). 3.6.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 Mullendore, Tseng, Monia Informational 11 mFCP -- Version 1 May 2001 region containing fibre channel switch elements, each element obtains a domain I/D by querying a master switch element as described in [FC SW] -- in this case the mFCP 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. 3.6.1.2 Incompatibility with Address Translation Mode mFCP gateways in address transparent mode SHALL NOT originate or accept frames that do not have the TRN bit set to one in the mFCP flags field of the encapsulation header (see section 4.3.1). An mFCP gateway operating in this mode SHALL discard any frames received with the TRN bit set to 0. 3.6.2 Operation in Address Translation Mode This section summarizes the process for modifying FC frame addresses embedded in the frame header. As described above, the mFCP gateway is responsible for assigning Fibre Channel N_PORT addresses to locally and remotely attached N_PORTs. For remotely attached N_PORTs, the gateway assigns an N_PORT alias used in place of the N_PORT address assigned by the remote gateway. To perform this function and enable the appropriate routing, the gateway builds and maintains a table that maps N_PORT aliases to the appropriate IP address and N_PORT ID of all external N_PORTs. The gateway opportunistically builds the store of N_PORT network addresses for remotely attached devices in the IP fabric by: a) Intercepting name service requests issued by locally- attached N_PORTs as described below or, b) Intercepting incoming N_PORT login requests from external Fibre Channel devices and outgoing N_PORT login requests directed to remote N_PORTs. Such requests are used to establish the N_PORT login session. In response to name server requests, the iSNS server returns the IP address and N_PORT ID pair of the remote device. After saving these values, the mFCP layer creates the 24-bit N_PORT alias that is returned to the local N_PORT as the Fibre Channel address of the external device. 3.6.2.1 Translation Table Maintenance Mullendore, Tseng, Monia Informational 12 mFCP -- Version 1 May 2001 The contents of the gatewayÆs address translation tables are updated opportunistically, in response to the name service queries and PLOGI requests described previously. There is no need to invalidate entries in response to changes in the fabric configuration, since any potentially stale entries caused by such events are self-correcting as described below. Once a fabric has achieved steady-state operation, any event that causes a change in the fibre channel address of a device also causes the device to terminate all N_PORT sessions. In the process of resuming operation, the status of the device, including its new address, is reflected in the name serverÆs database. The new state of the device is advertised using the appropriate state change notifications. These, in turn, trigger the series of port login operations described below. For inbound PLOGI requests, the mFCP gateway simply updates the translation table, generates the N_PORT alias and forwards the request to the local N_PORT for processing as described above. For outbound requests, a fabric-attached fibre channel device usually precedes the PLOGI with a name server query to obtain the deviceÆs new N_PORT address. At this point, the mFCP gateway intercepts such a request, performs the necessary iSNS query, creates the translation table entry and returns the assigned N_PORT alias to the requester. After issuing the PLOGI, the N_PORT verifies that it has logged in with the expected device by checking the device name returned in the PLOGI response. An N_PORT that attempts to execute a PLOGI without first querying the name server is still required to confirm the device name as described above. 3.6.2.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 a TCP connection identifier and the N_PORT ID assigned by the remote gateway. The translation process for outbound frames is shown below. Mullendore, Tseng, Monia Informational 13 mFCP -- Version 1 May 2001 Raw Fibre Channel Frame +--------+-----------------------------------+ +--------------+ | | Destination N_PORT Alias |--->| Lookup IP | +--------+-----------------------------------+ | address | | | Source N_PORT ID | | and N_PORT ID| +--------+-----------------------------------+ +------+-------+ | | | IP | Control information | | Address | and Payload | | & +--------------------------------------------+ | N_PORT | ID | After Address Translation and IP Encapsulation | +--------------------------------------------+ IP | | IP Header |<----------+ +--------------------------------------------+ Address | | UDP Header | | +============================================+ | | Encapsulation Header | | +--------------------------------------------+ | | SOF Delimiter | | +--------+-----------------------------------+ | | | Destination N_PORT ID |<----------+ +--------+-----------------------------------+ N_PORT I/D | | Source N_PORT ID | +--------+-----------------------------------+ | | | Control information | | and Payload | +--------------------------------------------+ | Fibre Channel CRC | +--------------------------------------------+ } EOF Delimiter | +--------------------------------------------+ Figure 6 -- Outbound Frame Address Translation For inbound frames, the store is accessed to obtain the N_PORT alias from the IP address-NPORT I/D pair contained in the encapsulated FC frame. The translation process for inbound frames is shown below. Mullendore, Tseng, Monia Informational 14 mFCP -- Version 1 May 2001 Network Format of Inbound Frame +--------------------------------------------+ IP +-------+ | IP Header |------->| | +--------------------------------------------+ Address| | | UDP Header | | Lookup| +============================================+ | N_PORT| | Encapsulation Header | | Alias | +--------------------------------------------+ | | | SOF Delimiter | | | +--------+-----------------------------------+ | | | | Destination N_PORT ID | +--->| | +--------+-----------------------------------+ | +-------+ | | Source N_PORT ID |---+ | +--------+-----------------------------------+ | | | | | Control information | | | and Payload | | +--------------------------------------------+ | | Fibre Channel CRC | | +--------------------------------------------+ | } EOF Delimiter | | +--------------------------------------------+ | | | | Frame after Address Translation and De-encapsulation | +--------+-----------------------------------+ | | | Destination N_PORT ID | | +--------+-----------------------------------+ | | | Source N_PORT Alias |<-----------+ +--------+-----------------------------------+ | | | Control information | | and Payload | +--------------------------------------------+ Figure 7 -- Inbound Frame Address Translation 3.6.2.3 Incompatibility with Address Transparent Mode mFCP gateways in address translation mode shall not originate or accept frames that have the TRN bit set to one in the mFCP flags field of the encapsulation header. The mFCP gateway SHALL discard such frames. 4. mFCP Protocol 4.1 Overview 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 Mullendore, Tseng, Monia Informational 15 mFCP -- Version 1 May 2001 an encapsulated Fibre Channel frame from the network, the mFCP layer de-encapsulates the frame and delivers the frame image to the appropriate N_PORT. Except for the extended link services and fabric services described in section 4.4, the mFCP layer never interprets the frame contents. For incoming mFCP frames representing augmented extended link services, mFCP interprets the augmented information, modifies the frame content accordingly, and forwards the resulting frame to the N_PORT for further processing. For out-bound Fibre Channel frames that require control data, mFCP inserts the supplementary data (if any), modifies the frame content, then transmits the resulting encapsulated Fibre Channel frame in a UDP datagram. 4.2 mFCP Congestion Control /TBS/ [Editor's Note: This section will be based on an IETF- sanctioned congestion control mechanism]. 4.3 UDP Encapsulation of Fibre Channel Frames The UDP encapsulation of fibre channel frames is shown below. Each fibre channel frame SHALL be encapsulated in one UDP datagram. The encapsulated FC frame format is identical to the iFCP encapsulation specified in [iFCP]. +--------------------+<---------+ | IP Header | | +--------------------+ | | UDP Header | D| +----->+====================+ a| | |Encapsulation Header| t| | +--------------------+<----+ U a| Encapsulated| SOF | f | D g| FC Frame +--------------------+ F r | P r| | | FC frame content | C a | a| | +--------------------+ m | m| | | EOF | e | | +----->+--------------------+<----+----+ Figure 8 -- UDP Encapsulation Format The maximum frame size is determined for each N_PORT login session and is the lesser of (a) the smallest maximum frame size supported by either N_PORT or (b) the MTU along the path connecting the N_PORT pair. 4.3.1 Encapsulation Header Format Mullendore, Tseng, Monia Informational 16 mFCP -- Version 1 May 2001 W|------------------------------Bit------------------------------| o| | r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 | d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0| +---------------+---------------+---------------+---------------+ 0| Protocol# | Version | -Protocol# | -Version | +---------------+---------------+---------------+---------------+ 1| Reserved (must be zero) | +---------------+---------------+---------------+---------------+ 2| LS_COMMAND | mFCP Flags | SOF | EOF | +-----------+---+---------------+-----------+---+---------------+ 3| Flags | Frame Length | -Flags | -Frame Length | +-----------+-------------------+-----------+-------------------+ 4| Time Stamp [integer] | +---------------------------------------------------------------+ 5| Time Stamp [fraction] | +---------------------------------------------------------------+ 6| CRC | +---------------------------------------------------------------+ Figure 9 -- Encapsulation Header Common Encapsulation Fields: Mullendore, Tseng, Monia Informational 17 mFCP -- Version 1 May 2001 Protocol# IANA-assigned protocol number identifying the protocol using the encapsulation. For mFCP the value is (/TBD/). Version Encapsulation version -Protocol# Ones complement of the protocol# -Version Ones complement of the version Flags Encapsulation flags (see 4.3.2) 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 [SNTP]. Time Stamp Fractional component of the time stamp [fraction] in SNTP format [SNTP]. CRC Header CRC. MUST be valid for mFCP. The time stamp fields are used to enforce the limit on the lifetime of a fibre channel frame as described in section 4.5.1.3. mFCP-specific fields: Mullendore, Tseng, Monia Informational 18 mFCP -- Version 1 May 2001 LS_COMMAND For an augmented ELS ACC response, 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. mFCP Flags mFCP-specific flags (see below) SOF Copy of the SOF delimiter encoding (see section 4.3.3) EOF Copy of the EOF delimiter encoding (see section 4.3.3) The mFCP flags word has the following format: |------------------------Bit----------------------------| | | | 23 22 21 20 19 18 17 16 | +------+------+------+------+------+------+------+------+ | CPL | Reserved | SES | TRN | AUG | +------+------+------+------+------+------+------+------+ Figure 10 -- mFCP Encapsulation Flags Word mFCP Flags: CPL Compliance level: 1 = Encapsulation complies with draft standard or RFC of mFCP or the encapsulation specification 0 = Encapsulation complies with standards track version of mFCP or the encapsulation specification SES 1 = Session control frame (TRN and AUG MUST be 0) TRN 1 = Address transparent mode enabled 0 = Address translation mode enabled AUG 1 = Augmented frame. 4.3.2 Common Encapsulation Flags Mullendore, Tseng, Monia Informational 19 mFCP -- Version 1 May 2001 The mFCP usage of the common encapsulation flags is shown below: |------------------------Bit--------------------------| | | | 31 30 29 28 27 26 | +--------------------------------------------+--------+ | Reserved | CRCV | +--------------------------------------------+--------+ Figure 11 -- Common Encapsulation Flags For mFCP, the CRC field MUST be valid and CRCV MUST be set to one. 4.3.3 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 | +---------------+---------------+-------------------------------+ FC Frame Encapsulation Format SOF (bits 31-24 and bits 23-16 in word 0): The SOF fields contain the encoded SOF value selected from the table below. +-------+----------+ | FC | | | SOF | SOF Code | +-------+----------+ | SOFf | 0x28 | | SOFi2 | 0x2D | | SOFn2 | 0x35 | | SOFi3 | 0x2E | | SOFn3 | 0x36 | +-------+----------+ Table 1 -- Translation of FC SOF values to SOF field contents Mullendore, Tseng, Monia Informational 20 mFCP -- Version 1 May 2001 -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): The EOF fields contain the encoded EOF value selected from the table below. +-------+----------+ | FC | | | EOF | EOF Code | +-------+----------+ | EOFn | 0x41 | | EOFt | 0x42 | | EOFni | 0x49 | | EOFa | 0x50 | +-------+----------+ Table 2 -- 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. mFCP implementations shall place a copy of the SOF and EOF delimiter codes in the appropriate header fields. 4.3.4 Frame Encapsulation and De-encapsulation When encapsulating a frame, the frame originator MUST fill in the header and the SOF and EOF delimiter words as specified above. The receiving gateway SHALL perform de-encapsulation as follows: Upon receiving the encapsulated frame, the gateway SHALL check the header CRC. If the CRC is invalid, the mFCP gateway SHALL discard the frame. If the CRC is valid, any additional header validity checks are optional. If a header check is unsuccessful, the frame SHALL be discarded. After header validation, the receiving gateway MAY generate the FC frame delimiters by: a) Using the EOF and SOF codes in the encapsulation header or b) By referencing the SOF and EOF delimiter words. If the EOF and SOF delimiter words are used, the gateway must validate the delimiter contents by verifying that the code is legal and that the delimiter contents conform to the formats Mullendore, Tseng, Monia Informational 21 mFCP -- Version 1 May 2001 shown above. If an invalid delimiter is detected, the gateway SHALL discard the frame. If the EOF and SOF in the header are used, the gateway MAY ignore the contents of the delimiter words. The gateway SHOULD verify that the SOF and EOF codes in the header are legal. If an illegal code is detected, the gateway SHALL discard the frame. After validating the encapsulation, the receiving gateway MAY verify the frame propagation delay as described in section 4.5.1.3. 4.4 Link Services 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 (request 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 also may also require the inclusion of supplemental data by the mFCP 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 mFCP gateway without altering the message payload. The link service request and reply are not processed by the mFCP implementation. b) Augmented - Applies to an extended link service request or reply containing fibre channel addresses in the payload or requiring other special processing by the mFCP implementation. The processing for augmented link services is described in this section. c) Rejected û When issued by a locally attached N_PORT, the specified link service request MUST be rejected by the mFCP implementation. The gateway SHALL respond to a rejected link service message by returning an LS_RJT response with a Mullendore, Tseng, Monia Informational 22 mFCP -- Version 1 May 2001 Reason Code of 0x0B (Command Not Supported) and a Reason Code Explanation of 0x0 (No Additional Explanation). This section describes the processing for augmented link services, including the manner in which supplemental data is transmitted over the IP network. Appendix A enumerates all link services and the mFCP processing policy that applies to each. 4.4.1 Augmented Link Service Messages Augmentation applies to extended link service requests that require the intervention of the mFCP layer. 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: Mullendore, Tseng, Monia Informational 23 mFCP -- Version 1 May 2001 Word 31<-bit>24 23<------------------Bit---------------------->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| | +-----------------------------------------------------------+ Format of ELS Frame 4.4.2 Augmented Link Services Requiring Payload Address Translation 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 augmented frames unless other special processing 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 00 û The gateway receiving the frame from the IP network MUST reference the augmentation data to set the Mullendore, Tseng, Monia Informational 24 mFCP -- Version 1 May 2001 field contents as described below. The augmentation information is the 64-bit world wide identifier of the N_PORT as set forth in the fibre channel specification [FC PH]. If not otherwise part of the ELS, this information MUST be appended as described below. This translation type SHALL NOT be used when the address to be converted corresponds to that of the frame originator or recipient. 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 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 0, 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, 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. If 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 [FC PH]. The Reason Code SHALL be set to 0x07 (protocol error) and the Reason Explanation SHALL be set to 0x1F (Invalid N_PORT identifier). [EditorÆs note: Such errors, when detected by the receiving gateway, may be indicative of a serious problem requiring a more drastic response. Therefore, this section should be regarded as tentative.] 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. Mullendore, Tseng, Monia Informational 25 mFCP -- Version 1 May 2001 b) By extending the sequence through the addition of 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 /TBS/. After applying the supplemental data, the receiving gateway SHALL forward the resulting ELS to the destination N_PORT with the supplemental information removed. When the ACC response must be augmented, 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. 4.4.3 Augmented Link Services The following Link Service Messages must receive special processing or be supplemented with additional control data. When the mFCP header encapsulates one of these Extended Link Service messages in the mFCP payload, the AUG bit must be set to one in the mFCP FLAGS field as specified in section 4.3.1 and the supplemental data (if any) must be appended as described in the following section. An ELS ACC frame that is augmented must be similarly formatted. 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 The formats of each augmented ELS, including supplemental data where applicable, are shown in the following sections. Each ELS diagram shows the basic format, as specified in the Mullendore, Tseng, Monia Informational 26 mFCP -- Version 1 May 2001 applicable FC standard, followed by supplemental data as shown 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 | | +======+================================================+ Figure 12 -- ELS with Supplemental Data (Single Frame Format) 4.4.3.1 Abort Exchange (ABTX) ELS Format: +------+------------+------------+-----------+----------+ | 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 0 only) ------------------- section 4.4.2) ------------ ----------- Exchange Originator 1, 2 N/A S_ID Other Special Processing: None Mullendore, Tseng, Monia Informational 27 mFCP -- Version 1 May 2001 4.4.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 | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type (see (type 0 only) ------------------- section 4.4.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. 4.4.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 | +======+============+============+===========+==========+ Mullendore, Tseng, Monia Informational 28 mFCP -- Version 1 May 2001 Fields Requiring Translation Supplemental Data Address Translation Type (see (type 0 only) ------------------- section 4.4.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. 4.4.3.4 FC Address Resolution Protocol Reply (FARP-REPLY) The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS (see section 4.4.3.5) to perform the address resolution services required by the FC-VI protocol [FC VI]. 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 0 only) section 4.4.2) Mullendore, Tseng, Monia Informational 29 mFCP -- Version 1 May 2001 ------------------- ------------- ----------------- Requesting N_PORT 2 N/A Identifier Responding N_PORT 1 N/A identifier Other Special Processing: None. 4.4.3.5 FC Address Resolution Protocol Request (FARP-REQ) The FARP-REQ ELS is used to in conjunction with the FC-VI protocol [FC VI] 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 5.1 describes the mFCP implementation of FC broadcast server functionality in an mFCP 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 | +======+============+============+===========+==========+ Mullendore, Tseng, Monia Informational 30 mFCP -- Version 1 May 2001 Fields Requiring Translation Supplemental Data Address Translation Type (see (type 0 only) ------------------- section 4.4.2) ----------------- ----------- Requesting N_PORT 0 Requesting N_PORT Identifier Port Name Responding N_PORT 1 N/A Identifier Other Special Processing: None. 4.4.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 0 only) ------------------- section 4.4.2) -------------- ----------- N_PORT I/D Being 0, 1 or 2 Port Name of LOGO Logged Out Originator Other Special Processing: None. 4.4.3.7 Port Login (PLOGI) PLOGI provides the mechanism for establishing a login session between two N_PORTs. The PLOGI request carries information Mullendore, Tseng, Monia Informational 31 mFCP -- Version 1 May 2001 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-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. 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 Details on the above fields, including common and class-based service parameters, can be found in [FC PH]. The above PLOGI message MUST BE transported by the mFCP layer without modification. [EditorÆs note: The service parameter details that apply to an mFCP environment are /TBS/.] 4.4.3.8 Read Exchange Concise ELS Format: Mullendore, Tseng, Monia Informational 32 mFCP -- Version 1 May 2001 +------+------------+------------+-----------+----------+ | 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-4 |Port name of the exchange originator (8 bytes) | | | (present only for translation type 0) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 0, 1 or 2 Port Name of the S_ID Exchange Originator Other Special Processing: None. 4.4.3.9 Read Exchange Concise Accept Format of ACC Response: Mullendore, Tseng, Monia Informational 33 mFCP -- Version 1 May 2001 +------+------------+------------+-----------+----------+ | 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 | Data Transfer Count | +------+------------+------------+-----------+----------+ | 5 | Exchange Status | +======+============+============+===========+==========+ | 6-7 |Port name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ | 8-9 |Port name of the Exchange Responder (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 0, 1 or 2 Port Name of the N_PORT I/D Exchange Originator Exchange Responder 0, 1 or 2 Port Name of the N_PORT I/D Exchange Responder When supplemental data is required, the ELS shall be always be extended by 4 words as shown above. Unused words in the extended fields SHALL be set to 0. Other Special Processing: None. 4.4.3.10 Read Exchange Status Block (RES) ELS Format: Mullendore, Tseng, Monia Informational 34 mFCP -- Version 1 May 2001 +------+------------+------------+-----------+----------+ | 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-18| Port name of the Exchange Originator (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 0, 1 or 2 Port Name of the S_ID Exchange Originator Other Special Processing: None. 4.4.3.11 Read Exchange Status Block Accept Format of ELS Accept Response: Mullendore, Tseng, Monia Informational 35 mFCP -- Version 1 May 2001 +------+------------+------------+-----------+----------+ | 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+8 | | +======+============+============+===========+==========+ |n+9- | Port name of the Exchange Responder (8 bytes) | |n+16 | | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data Address Translation Type(see (type 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 0, 1 or 2 Port Name of the N_PORT I/D Exchange Originator Exchange Responder 0, 1 or 2 Port Name of the N_PORT I/D Exchange Responder When supplemental data is required, the ELS SHALL be extended by 4 words as shown above. Unused words in the extended fields SHALL be set to 0. Other Special Processing: None. 4.4.3.12 Read Link Error Status (RLS) ELS Format: Mullendore, Tseng, Monia Informational 36 mFCP -- Version 1 May 2001 +------+------------+------------+-----------+----------+ | 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-9 | Port name of the N_PORT (8 bytes) | +======+============+============+===========+==========+ Fields Requiring Translation Supplemental Data (type Address Translation Type(see 0 only) ------------------- section 4.4.2) ------------------ ----------- N_PORT Identifier 0, 1 or 2 Port Name of the N_PORT Other Special Processing: None. 4.4.3.13 Read Sequence Status Block (RSS) ELS Format: +------+------------+------------+-----------+----------+ | 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 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 0, 1 or 2 Port Name of the S_ID Exchange Originator Other Special Processing: Mullendore, Tseng, Monia Informational 37 mFCP -- Version 1 May 2001 None. 4.4.3.14 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 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Other Special Processing: None. 4.4.3.15 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) | +======+============+============+===========+==========+ Mullendore, Tseng, Monia Informational 38 mFCP -- Version 1 May 2001 Fields Requiring Translation Supplemental Data Address Translation Type(see (type 0 only) ------------------- section 4.4.2) ------------------ ----------- Exchange Originator 1 or 2 N/A S_ID Other Special Processing: None. 4.4.3.16 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 Offset +----------------------------------+ 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: Mullendore, Tseng, Monia Informational 39 mFCP -- Version 1 May 2001 Byte Offset +----------------------------------+ 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 +----------------------------------+ When a TPRLO message or TPRLO ACC response is sent, mFCP supplemental 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, the corresponding PORT_NAME shall also be included. PORT_NAMEs shall be listed in the same order as the equivalent TPRLO LOGOUT PARAMETER PAGEs in the original Link Service message. [The format for passing TPRLO supplemental data is /TBS/] Additionally, the THIRD PARTY ORIGINATOR N_PORT ID field in each TPRLO LOGOUT PARAMETER PAGE shall be cleared when it is sent by the originating gateway. This applies to both the original Link Service message and the ACC response. When the mFCP layer receives a TPRLO message, 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]. 4.5 Error Detection and Recovery Procedures for mFCP [FCP] and [FC PH] define error detection and recovery procedures. These Fibre Channel-defined mechanisms continue to be available in the mFCP environment. 4.5.1 Timer Definitions and Stale Frame Detection 4.5.1.1 Error_Detect_Timeout (E_D_TOV) Mullendore, Tseng, Monia Informational 40 mFCP -- Version 1 May 2001 E_D_TOV is "a reasonable timeout value for detection of a response to a timed event". The default value specified by [FC FS]of 2 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. E_D_TOV MAY be specified individually for each gateway. If a gateway-specific value is not set, the gateway SHALL obtain the value from the iSNS name server. 4.5.1.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 fibre channel default value for R_A_TOV is 10 seconds. R_A_TOV MAY be specified individually for each gateway. If a gateway-specific value is not set, the gateway SHALL obtain the value from the iSNS name server. The mFCP fabric MAY actively enforce limits on R_A_TOV as described in section 4.5.1.3. 4.5.1.3 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 4.3.1) as described in this section. If enforced by a gateway, the propagation delay time limit (MAX_PROP_DELAY) SHOULD be set well below the value of R_A_TOV specified for the mFCP fabric and SHOULD be stored in the iSNS server. A rule of thumb is to set MAX_PROP_DELAY 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. In order to insure that all gateways are time-aligned, a gateway SHOULD obtain the address of an SNTP server via an iSNS query. If multiple SNTP 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 [RFC Mullendore, Tseng, Monia Informational 41 mFCP -- Version 1 May 2001 2030], 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 [RFC 2030]. The resolution of the time reference MUST be 125 milliseconds or better. With regard to the 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. 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 time in flight and compare it against the value of MAX_PROP_DELAY specified for the IP fabric. e) If the result in step (d) exceeds MAX_PROP_DELAY, the frame shall be discarded. Otherwise, the frame shall be accepted. 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. If synchronization is lost, the gateway MAY choose to abort all N_PORT login sessions with all remote gateways. 5. Fabric Services Supported by an mFCP implementation An mFCP gateway implementation MUST support the following fabric services: Mullendore, Tseng, Monia Informational 42 mFCP -- Version 1 May 2001 N_PORT ID Value Description Section --------------- ----------- ------- 0xFF FF FE F_PORT Server /TBS/ 0xFF FF FD Fabric Controller /TBS/ 0xFF FF FC Directory/Name Server /TBS/ In addition, an mFCP gateway MAY support the FC broadcast server functionality described in section 5.1. 5.1 mFCP 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 mFCP/iSNS system, the broadcast functionality MAY be implemented within each gateway by an mFCP broadcast server. The broadcast server has an N_PORT I/D of 0xff ff ff. Outgoing frames to be broadcast are directed to the 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 zone 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 broadcast server. The datagram encapsulation format is identical to the mFCP encapsulation format described in section 4.3. On receiving an mFCP broadcast datagram, the broadcast server SHALL: a) Validate the header as described in section 4.3.4. 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 3.6.2, if address translation mode is in effect. c) If the AUG bit is set in the mFCP flags field, perform any special processing required by the ELS, including translation of any addresses in the payload. Mullendore, Tseng, Monia Informational 43 mFCP -- Version 1 May 2001 d) Replicate and redistribute the frame to all locally attached N_PORTs in the discovery domain of the sender. If no broadcast server is implemented, the receiving gateway SHALL discard an incoming broadcast frame from a remote gateway. Frames received from locally attached N_PORTs shall be processed as specified in [FC SW]. 6. Security 6.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. 6.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. 6.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. 6.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 Mullendore, Tseng, Monia Informational 44 mFCP -- Version 1 May 2001 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) 6.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. 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. 7. References 7.1 Relevant RFC Documents RFC768 User Datagram Protocol RFC791 Internet Protocol, DARPA Internet Program Protocol Specification RFC2401 Security Architecture for Internet Protocol RFC2402 IP Authentication Header RFC2406 Encapsulating Security Protocol (ESP) RFC2407 The Internet IP Security Domain for ISAKMP RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) RFC2409 The Internet Key Exchange (IKE) RFC2460 Internet Protocol, Version 6 (IPv6) Specification Mullendore, Tseng, Monia Informational 45 mFCP -- Version 1 May 2001 8. 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 46 mFCP -- Version 1 May 2001 Appendix A A. mFCP 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 mFCP implementation. The mFCP processing policies are defined in section 4.4. A.1 Basic Link Services The basic link services are shown in the following table. Basic Link Services Name Description mFCP 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 4.4. 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 Mullendore, Tseng, Monia Informational 47 mFCP -- Version 1 May 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 RTIN Request Topology Information 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 Augmented Link Services The following extended link services are augmented with additional data and processed by the mFCP implementation as described in the referenced section listed in the table. Augmented Link Services Name Description Section ---- ----------- ------- ABTX Abort Exchange 4.4.3.1 ADISC Discover Address 4.4.3.2 Mullendore, Tseng, Monia Informational 48 mFCP -- Version 1 May 2001 ADISC Discover Address Accept 4.4.3.3 ACC FARP- Fibre Channel Address 4.4.3.4 REPLY Resolution Protocol Reply FARP-REQ Fibre Channel Address 4.4.3.5 Resolution Protocol Request LOGO N_PORT Logout 4.4.3.6 PLOGI Port Login 4.4.3.7 REC Read Exchange Concise 4.4.3.8 REC ACC Read Exchange Concise Accept 4.4.3.9 RES Read Exchange Status Block 4.4.3.10 RES ACC Read Exchange Status Block 4.4.3.11 Accept RLS Read Link Error Status Block 4.4.3.12 RRQ Reinstate Recovery Qualifier 4.4.3.14 RSI Request Sequence Initiative 4.4.3.15 RSS Read Sequence Status Block 4.4.3.13 TPRLO Third Party Process Logout 4.4.3.16 Mullendore, Tseng, Monia Informational 49 mFCP -- Version 1 May 2001 Full Copyright Statement "Copyright (C) The Internet Society, May 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." [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [UDP] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, August 1980. [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre Channel Storage Networking", STD, May 2001. [FCP] NCITS 350 DRAFT, "Information technology -SCSI Fibre Channel Protocol - 2 (FCP-2)", National Committee for Information Technology Standards 06-Apr-2001 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Mullendore, Tseng, Monia Informational 50 mFCP -- Version 1 May 2001 [FC PH] The following documents comprise the FC-PH standards set: ANSI/NCITS X3.230-1994, "Information Technology - Fibre Channel Physical and Signaling Interface (FC-PH)", National Committee for Information Technology Standards, 01-Jan-1994 ANSI/NCITS X3.297-1997, "Fiber Channel 2nd Generation (FC-PH 2)", (formerly FC-EP),National Committee for Information Technology Standards, 01-Jan-1997 ANSI/NCITS X3.303-1998, "Third Generation Fibre Channel Physical and Signaling Interface (FC-PH-3)", National Committee for Information Technology Standards, 01-Jan-1998 [iSNS] Tseng, J, et al, "iSNS Internet Storage Name Service", STD, May 2001. [FC SW] ANSI/NCITS 321-1998 "Fibre Channel - Switched Fabric and Switched Control Requirements (FC-SW)", (Formerly FC- XS), 01-Jan-1998. [FC VI] T11 "dpANS - Fibre Channel - Virtual Interface Architecture Mapping", Revision 1.61, T11/00-092v2. [FC FS] T11 Draft Standard, "Fibre Channel Framing and Signaling", Revision 1.2, T11/00-340v3, Feb 16, 2001. [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", October 1996. Mullendore, Tseng, Monia Informational 51