[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-monia-ips-ifcp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 RFC 4172

     IP Storage Working Group                                  Charles Monia
     INTERNET DRAFT                                           Rod Mullendore
     Expires April 2002                                           Josh Tseng
     <draft-ietf-ips-ifcp-06.txt>                             Nishan Systems
     
                                                           Franco Travostino
                                                               Victor Firoiu
                                                             Nortel Networks
     
                                                              David Robinson
                                                            Sun Microsystems
     
                                                               Wayland Jeong
                                                             Troika Networks
     
                                                                   Rory Bolt
                                                                 Quantum/ATL
     
                                                             Paul Rutherford
                                                                        ADIC
     
                                                                Mark Edwards
                                                                   Eurologic
     
                                                                October 2001
     
     
        iFCP - A Protocol for Internet Fibre Channel Storage Networking
     
     Status of this Memo
     
         This document is an Internet-Draft and is in full conformance with
         all provisions of Section 10 of RFC2026 [RFC2026].
     
         Internet-Drafts are working documents of the Internet Engineering
         Task Force (IETF), its areas, and its working groups. Note that
         other groups may also distribute working documents as Internet-
         Drafts. Internet-Drafts are draft documents valid for a maximum of
         six months and may be updated, replaced, or obsoleted by other
         documents at any time. It is inappropriate to use Internet-Drafts
         as reference material or to cite them other than as "work in
         progress."
     
         The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt
     
         The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.
     
     Comments
     
         Comments should be sent to the ips mailing list (ips@ece.cmu.edu)
         or to the author(s).
     
     Monia, et al.              Standards Track                   [Page 1]


     iFCP Revision 6                                      October 2001
     
     
     Status of this Memo...................................................1
     Comments..............................................................1
     1.      Abstract.....................................................8
     2.      About This Document..........................................8
     2.1     Conventions used in this document............................8
     2.2     Purpose of this document.....................................8
     3.      iFCP Introduction............................................8
     3.1     Definitions..................................................9
     4.      Fibre Channel Communication Concepts........................11
     4.1     The Fibre Channel Network...................................11
     4.2     Fabric Topologies...........................................12
     4.2.1    Switched Fibre Channel Fabrics.............................13
     4.2.2    Mixed Fibre Channel Fabric.................................14
     4.3     Fibre Channel Layers and Link Services......................15
     4.3.1    Fabric-Supplied Link Services..............................16
     4.4     Fibre Channel Devices.......................................16
     4.5     Fibre Channel Device Discovery..............................17
     4.6     Fibre Channel Information Elements..........................17
     4.7     Fibre Channel Frame Format..................................18
     4.7.1    N_PORT Address Model.......................................18
     4.8     Fibre Channel Transport Services............................19
     4.9     Login Processes.............................................19
     5.      The iFCP Network Model......................................20
     5.1     Fabric Topologies Supported by iFCP.........................21
     5.2     iFCP Transport Services.....................................22
     5.2.1    Fibre Channel Transport Services Supported by iFCP.........22
     5.3     The iFCP N_PORT Address Model...............................22
     5.3.1    Operation in Address Transparent Mode......................24
     5.3.2    Operation in Address Translation Mode......................25
     6.      iFCP Protocol...............................................29
     6.1     Overview....................................................29
     6.1.1    iFCP Transport Services....................................29
     6.1.2    iFCP Support for  Link Services............................30
     6.2     TCP Stream Transport of iFCP Frames.........................30
     6.2.1    iFCP Session Model.........................................30
     6.2.2    iFCP Session Management....................................31
     6.2.3    Terminating an N_PORT Login Session........................36
     6.3     IANA Considerations.........................................37
     6.4     Encapsulation of Fibre Channel Frames.......................37
     6.4.1    Encapsulation Header Format................................38
     6.4.2    SOF and EOF Delimiter Fields...............................41
     6.4.3    Frame Encapsulation........................................42
     6.4.4    Frame De-encapsulation.....................................42
     7.      Fibre Channel Link Services.................................43
     7.1     Augmented Link Service Messages.............................44
     7.2     Augmented Link Services Requiring Payload Address Translation44
     7.3     Augmented Link Services.....................................46
     7.3.1    Abort Exchange (ABTX)......................................47
     7.3.2    Discover Address (ADISC)...................................48
     7.3.3    Discover Address Accept (ADISC ACC)........................49
     7.3.4    FC Address Resolution Protocol Reply (FARP-REPLY)..........49
     7.3.5    FC Address Resolution Protocol Request (FARP-REQ)..........50
     
     Monia et-al.               Standards Track                   [Page 2]


     iFCP Revision 6                                      October 2001
     
     
     7.3.6    Logout (LOGO)..............................................51
     7.3.7    Port Login (PLOGI).........................................52
     7.3.8    Read Exchange Concise......................................53
     7.3.9    Read Exchange Concise Accept...............................54
     7.3.10     Read Exchange Status Block (RES).........................55
     7.3.11     Read Exchange Status Block Accept........................55
     7.3.12     Read Link Error Status (RLS).............................56
     7.3.13     Read Sequence Status Block (RSS).........................57
     7.3.14     Reinstate Recovery Qualifier (RRQ).......................58
     7.3.15     Request Sequence Initiative (RSI)........................58
     7.3.16     Third Party Process Logout (TPRLO).......................59
     7.3.17     Third Party Logout Accept (TPRLO ACC)....................61
     7.4     FLOGI Service Parameters Supported by an iFCP Gateway.......62
     8.      TCP Session Control Messages................................63
     8.1     Connection Bind (CBIND).....................................65
     8.2     Unbind Connection (UNBIND)..................................68
     9.      iFCP Error Detection........................................69
     9.1     Overview....................................................69
     9.2     Stale Frame Prevention......................................69
     9.2.1    Enforcing R_A_TOV Limits...................................69
     10.     Fabric Services Supported by an iFCP implementation.........71
     10.1    F_PORT Server...............................................71
     10.2    Fabric Controller...........................................72
     10.3    Directory/Name Server.......................................72
     10.4    iFCP Support for the FC Broadcast Service...................72
     11.     iFCP Security...............................................73
     11.1    Overview....................................................73
     11.2    iFCP Security Operating Requirements........................73
     11.2.1     Context..................................................73
     11.2.2     Security Threats.........................................74
     11.2.3     Performance Requirments..................................74
     11.2.4     Interoperability Requirements with Security Gateways.....74
     11.2.5     Statically and Dynamically Assigned IP Addresses.........74
     11.2.6     Authentication Requirements..............................75
     11.2.7     Confidentiality Requirements.............................75
     11.2.8     Rekeying Requirements....................................75
     11.2.9     Resource Requirements....................................75
     11.2.10    Usage Requirments........................................76
     11.2.11    iSNS Requirements........................................76
     11.3    iFCP Security Design........................................76
     11.3.1     Enabling Technologies....................................76
     11.3.2     Use of IKE and IPsec.....................................78
     11.3.3     Minimal Security Policy..................................79
     11.3.4     Certificates.............................................79
     12.     Quality of Service Considerations...........................79
     12.1    Minimal requirements........................................80
     12.2    High-assurance..............................................80
     13.     Author's Addresses..........................................81
     A.      iFCP Support for Fibre Channel Link Services................83
     A.1     Basic Link Services.........................................83
     A.2     Link Services Processed Transparently.......................83
     A.3     Augmented Link Services.....................................84
     
     Monia et-al.               Standards Track                   [Page 3]


     iFCP Revision 6                                      October 2001
     
     
     B.      Performance of The iFCP Session Model.......................87
     B.1     Relationship of Throughput to Packet Losses.................87
     B.2     Background..................................................88
     Full Copyright Statement.............................................90
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                   [Page 4]


     iFCP Revision 6                                      October 2001
     
     
     
     
     1.       Abstract
     
         This document specifies an architecture and gateway-to-gateway
         protocol for the implementation of Fibre Channel fabric
         functionality on a network in which TCP/IP switching and routing
         elements replace Fibre Channel components. The protocol enables the
         attachment of existing Fibre Channel storage products to an IP
         network by supporting the fabric services required by such devices.
     
     2.       About This Document
     
     2.1      Conventions used in this document
     
         The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
         "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
         this document are to be interpreted as described in RFC-2119
         [RFC2119].
     
         All frame formats are in big endian network byte order.
     
     2.2      Purpose of this document
     
         This is a standards-track document, which specifies a protocol for
         the implementation of Fibre Channel transport services on a TCP/IP
         network.  Some portions of this document contain material from
         standards controlled by NCITS T10 and T11. This material is
         included here for informational purposes only. The authoritative
         information is given in the appropriate NCITS standards document.
     
         The authoritative portions of this document specify the protocol
         for mapping standards-compliant fibre Channel storage and adapter
         implementations to TCP/IP.  This mapping includes sections of this
         document which describe the "iFCP Protocol" (see section 6).
     
     3.       iFCP Introduction
     
         iFCP is a gateway-to-gateway protocol, which provides Fibre Channel
         fabric services to Fibre Channel devices over a TCP/IP network.
         iFCP uses TCP to provide congestion control, error detection and
         recovery. iFCP's primary objective is to allow interconnection and
         networking of existing Fibre Channel devices at wire speeds over an
         IP network.
     
         The protocol and method of frame address translation described in
         this document permit the attachment of Fibre Channel storage
         devices to an IP-based fabric by means of transparent gateways.
     
         The protocol achieves this transparency through a process that
         allows normal Fibre Channel frame traffic to pass through the
         gateway directly, with provisions, where necessary, for
     
     Monia et-al.               Standards Track                   [Page 5]


     iFCP Revision 6                                      October 2001
     
     
         intercepting and emulating the fabric services required by a Fibre
         Channel device.
     
     3.1      Definitions
     
         Terms needed to clarify the concepts presented in this document are
         presented here.
     
         Locally Attached Device - With respect to a gateway, a Fibre
                 Channel device accessed through the Fibre Channel fabric to
                 which the gateway is attached.
     
         Remotely Attached Device - With respect to a gateway, a Fibre
                 Channel device accessed from the gateway by means of the
                 iFCP protocol.
     
         Address-translation mode û A mode of gateway operation in which the
                 scope of N_PORT fabric addresses for locally attached
                 devices are local to the iFCP gateway.
     
         Address-transparent mode û A mode of gateway operation in which the
                 scope of N_PORT fabric addresses for all Fibre Channel
                 devices are unique to the logical fabric to which the
                 gateway belongs.
     
         Gateway Region û The portion of the iFCP storage network accessed
                 through an iFCP gateway. Fibre Channel devices in the
                 region consist of all Fibre Channel devices locally
                 attached to the gateway.
     
         Logical Fabric û The union of two or more gateway regions
                 configured to interoperate together in address-transparent
                 mode.
     
         Fibre Channel Device - A device attached to a Fibre Channel fabric
                 by means of the N_PORT interface described in [FC-FS].
     
         Fibre Channel Network - A native Fibre Channel fabric and all
                 attached Fibre Channel devices.
     
         Fabric - The components of a Fibre Channel network that provides
                 the transport services defined in [FC-FS]. A fabric may be
                 implemented in the IP framework by means of the
                 architecture and protocols discussed in this document.
     
         Fabric Port -  The interface through which an N_PORT accesses a
                 Fibre Channel fabric.  The type of fabric port depends on
                 the Fibre Channel fabric topology. In this specification,
                 all fabric port interfaces are considered to be
                 functionally equivalent.
     
     
     
     Monia et-al.               Standards Track                   [Page 6]


     iFCP Revision 6                                      October 2001
     
     
         FC-2 - The Fibre Channel transport services layer described in [FC-
                 FS].
     
         iFCP Portal - An IP-addressable entity representing the point at
                 which a logical or physical iFCP device is attached to the
                 IP network.
     
         N_PORT - An iFCP or Fibre Channel entity representing the interface
                 to Fibre Channel device functionality. This interface
                 implements the Fibre Channel N_PORT semantics specified in
                 [FC-FS].  Fibre Channel defines several variants of this
                 interface that are dependant on the Fibre Channel fabric
                 topology.  As used in this document, the term applies
                 equally to all variants.
     
         N_PORT fabric address - The address of an N_PORT within the Fibre
                 Channel fabric.
     
         N_PORT ID -- The address of a locally attached N_PORT within a
                 gateway region.  N_PORT I/Ds are assigned in accordance
                 with the Fibre Channel rules for address assignment
                 specified in [FC-FS].
     
         N_PORT Alias --  The N_PORT address assigned by a gateway to
                 represent a remote N_PORT accessed via the iFCP network.
                 When routing frame traffic in address translation mode, the
                 gateway automatically converts N_PORT aliases to N_PORT
                 network addresses and vice versa.
     
         N_PORT Network Address - The address of an N_PORT in the IP fabric.
                 This address consists of the IP address of the iFCP Portal
                 and the N_PORT ID of the locally attached Fibre Channel
                 device.
     
         F_PORT - The interface used by an N_PORT to access Fibre Channel
                 switched fabric functionality.
     
         iFCP - The protocol discussed in this document.
     
         Logical iFCP Device - The abstraction representing a single Fibre
                 Channel device as it appears on an iFCP network.
     
         iSNS - The IP protocol by which storage name services are
                 implemented in an iFCP network. Fibre Channel Name services
                 are provided by an iSNS name server as described in [ISNS].
     
         N_PORT Session - An association created when two N_PORTS have
                 executed a PLOGI operation.  It is comprised of the N_PORTs
                 and TCP connection that carries traffic between them.
     
     
     
     
     Monia et-al.               Standards Track                   [Page 7]


     iFCP Revision 6                                      October 2001
     
     
         iFCP Frame - A Fibre Channel frame encapsulated in accordance with
                 the Common Encapsulation Specification [ENCAP] and this
                 specification.
     
         Port Login (PLOGI) - The Fibre Channel Extended Link Service (ELS)
                 that establishes an N_PORT login session through the
                 exchange of identification and operation parameters between
                 an originating N_PORT and a responding N_PORT.
     
         DOMAIN_ID û The value contained in the high-order byte of a 24-bit
                 N_PORT Fibre Channel address.
     
     4.       Fibre Channel Communication Concepts
     
         Fibre Channel is a frame-based, serial technology designed for
         peer-to-peer communication between devices at gigabit speeds and
         with low overhead and latency.
     
         This section contains a discussion of the Fibre Channel concepts
         that form the basis for the iFCP network architecture and protocol
         described in this document. Readers familiar with this material may
         skip to section 5.
     
         Material presented in this section is drawn from the following T11
         specifications:
     
         -- The Fibre Channel Framing and Signaling Interface, [FC-FS]
     
         -- Fibre Channel Switch Fabric -2, [FC-SW2]
     
         -- Fibre Channel Generic Services, [FC-GS3]
     
         -- Fibre Channel Fabric Loop Attachment, [FC-FLA]
     
         The reader will find an in-depth treatment of the technology in
         [Kembel].
     
     4.1      The Fibre Channel Network
     
         The fundamental entity in Fibre Channel is the Fibre Channel
         network. Unlike  a layered network architecture,  a Fibre Channel
         network is largely specified by functional elements and the
         interfaces between them. As shown in Figure 1, these consist, in
         part, of the following:
     
        a) N_PORTs -- The end points for Fibre Channel traffic. In the FC
           standards,  N_PORT interfaces have several variants, depending on
           the topology of the fabric to which they are attached.  As used
           in this specification, the term applies to any one of the
           variants.
     
     
     
     Monia et-al.               Standards Track                   [Page 8]


     iFCP Revision 6                                      October 2001
     
     
        b) FC Devices û The Fibre Channel devices to which the N_PORTs
           provide access.
     
        c) Fabric Ports -û The interface within a fabric that provides Fibre
           Channel attachment for an N_PORT.  The types of fabric port
           depend on the fabric topology and are discussed in section 4.2.
     
        d) The fabric infrastructure for carrying frame traffic between
           N_PORTs.
     
        e) Within a switched or mixed fabric (see section 4.2), a set of
           auxiliary servers, including a name server for device discovery
           and network address resolution.  The types of service depend on
           the network topology.
     
       +--------+   +--------+          +--------+  +--------+
       |  FC    |   |  FC    |          |  FC    |  |  FC    |
       | Device |   | Device |<-------->| Device |  | Device |
       |........|   |........|          |........|  |........|
       | N_PORT |   | N_PORT |          | N_PORT |  | N_PORT |
       +---+----+   +----+---+          +----+---+  +----+---+
           |             |                   |           |
       +---+----+   +----+---+          +----+---+  +----+---+
       | Fabric |   | Fabric |          | Fabric |  | Fabric |
       | Port   |   | Port   |          | Port   |  | Port   |
       +========+===+========+==========+========+==+========+
       |                        Fabric                       |
       |                          &                          |
       |                     Fabric Services                 |
       +-----------------------------------------------------+
                         Figure 1 -- A Fibre Channel Network
     
         The following sections describe Fibre Channel fabric topologies and
         give an overview of the Fibre Channel communications model.
     
     4.2      Fabric Topologies
     
         The principal Fibre Channel fabric topologies consist of the
         following:
     
         a)  Arbitrated Loop -- A series of N_PORTs connected together in
             daisy-chain fashion.  Data transmission between N_PORTs
             requires arbitration for control of the loop in a manner
             similar to a token ring network.
     
         b)  Switched Fabric --  A fabric consisting of switching elements,
             as described in section 4.2.1.
     
         c)  Mixed Fabric -- A fabric consisting of switches and "fabric-
             attached" loops.  A description can be found in [FC-FLA].
     
     
     
     Monia et-al.               Standards Track                   [Page 9]


     iFCP Revision 6                                      October 2001
     
     
         Depending on the topology, the N_PORT and fabric port variants
         through which a Fibre Channel device is attached to the network may
         be one of the following:
     
              Fabric Topology  Fabric Port Type    N_PORT Variant
              ---------------  ----------------    --------------
     
              Loop             L_PORT              NL_PORT
     
              Switched         F_PORT              N_PORT
     
              Mixed            FL_PORT             NL_PORT
     
                               F_PORT              N_PORT
     
     
     
         The differences in each N_PORT variant and its corresponding fabric
         port are confined to the interactions between them.  To an external
         N_PORT, all fabric ports are transparent and all remote N_PORTs are
         functionally identical.
     
     4.2.1   Switched Fibre Channel Fabrics
     
         An example of a multi-switch Fibre Channel fabric is shown below.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 10]


     iFCP Revision 6                                      October 2001
     
     
                 +----------+          +----------+
                 |    FC    |          |  FC      |
                 |   Device |          | Device   |
                 |..........|          |..........|
                 |   N_PORT |<........>| N_PORT   |
                 +----+-----+          +-----+----+
                      |                      |
                 +----+-----+          +-----+----+
                 | F_PORT   |          | F_PORT   |
       ==========+==========+==========+==========+==============
                 |  FC      |          | FC       |
                 |  Switch  |          | Switch   |
                 +----------+          +----------+ Fibre Channel
                 |Inter-    |          |Inter-    |   Fabric
                 |Switch    |          |Switch    |
                 |Interface |          |Interface |
                 +-----+----+          +-----+----+
                       |                     |
                       |                     |
                 +-----+----+----------+-----+----+
                 |Inter-    |          |Inter-    |
                 |Switch    |          |Switch    |
                 |Interface |          |Interface |
                 +----------+          +----------+
                 |            FC Switch           |
                 |                                |
                 +--------------------------------+
                    Figure 2 -- Multi-Switch Fibre Channel Fabric
     
         The interface between switch elements is either proprietary or the
         standards-compliant E_PORT interface described by the FC-SW2
         specification, [FC-SW2].
     
     4.2.2   Mixed Fibre Channel Fabric
     
         A mixed fabric contains one or more arbitrated loops connected to a
         switched fabric as shown in Figure 3.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 11]


     iFCP Revision 6                                      October 2001
     
     
                 +----------+          +----------+   +---------+
                 |    FC    |          |  FC      |   |  FC     |
                 |   Device |          | Device   |   | Device  |
                 |..........|          |..........|   |.........|
                 |   N_PORT |<........>| NL_PORT  +---+ NL_PORT |
                 +----+-----+          +-----+----+   +----+----+
                      |                      |   FC Loop   |
                 +----+-----+          +-----+----+        |
                 | F_PORT   |          | FL_PORT  +--------+
                 |          |          |          |
       ==========+==========+==========+==========+==============
                 |  FC      |          | FC       |
                 |  Switch  |          | Switch   |
                 +----------+          +----------+
                 |Inter-    |          |Inter-    |
                 |Switch    |          |Switch    |
                 |Interface |          |Interface |
                 +-----+----+          +-----+----+
                       |                     |
                       |                     |
                 +-----+----+----------+-----+----+
                 |Inter-    |          |Inter-    |
                 |Switch    |          |Switch    |
                 |Interface |          |Interface |
                 +----------+          +----------+
                 |            FC Switch           |
                 |                                |
                 +--------------------------------+
                        Figure 3 -- Mixed Fibre Channel Fabric
     
         As noted previously, the protocol for communications between peer
         N_PORTs is independent of the fabric topology, N_PORT variant and
         type of fabric port to which an N_PORT is attached.
     
     4.3      Fibre Channel Layers and Link Services
     
         Fibre channel consists of the following layers:
     
         FC0 -- The interface to the physical media,
     
         FC1 û- The encoding and decoding of data and out-of-band physical
         link control information for transmission over the physical media,
     
         FC2 û- The transfer of frames, sequences and Exchanges comprising
         protocol information units.
     
         FC3 û- Common Services,
     
         FC4 û- Application protocols, such as FCP, the Fibre Channel SCSI
         protocol.
     
     
     
     Monia et-al.               Standards Track                  [Page 12]


     iFCP Revision 6                                      October 2001
     
     
         In addition to the layers defined above, Fibre Channel defines a
         set of auxiliary operations, some of which are implemented within
         the transport layer fabric, called link services. These are
         required to manage the Fibre Channel environment, establish
         communications with other devices, retrieve error information,
         perform error recovery and other similar services. Some link
         services are executed by the N_PORT. Others are implemented
         internally within the fabric.  These internal services are
         described in the next section.
     
     4.3.1   Fabric-Supplied Link Services
     
         Servers internal to a switched fabric handle certain classes of
         Link Service requests.  The servers appear as N_PORTs located at
         well-known N_PORT fabric addresses. Service requests use the
         standard Fibre Channel mechanisms for N_PORT-to-N_PORT
         communications.
     
         All switched fabrics must provide the following services:
     
            Fabric F_PORT server û Services an N_PORT request to access the
            fabric for communications.
     
            Fabric Controller -- Provides state change information to inform
            other FC devices when an N_PORT exits or enters the fabric (see
            section 4.5).
     
            Directory/Name Server û Allows N_PORTs to register information
            in a database, retrieve information about other N_PORTs and
            discover other devices as described in section 4.5.
     
         A switched fabric may also implement the following optional
         services:
     
            Broadcast Address/Server û- Transmits single-frame, class 3
            sequences to all N_PORTs.
     
            Time Server û- Intended for the management of fabric-wide
            expiration timers or elapsed time values and is not intended for
            precise time synchronization.
     
            Management Server û Collects and reports management information,
            such as link usage, error statistics, link quality and similar
            items.
     
            Quality of Service Facilitator û Performs fabric-wide bandwidth
            and latency management.
     
     4.4      Fibre Channel Devices
     
         A Fibre Channel device has one or more fabric-attached N_PORTs. The
         device and its N_PORTs have the following associated identifiers:
     
     Monia et-al.               Standards Track                  [Page 13]


     iFCP Revision 6                                      October 2001
     
     
        a) A world-wide unique identifier for the device,
     
        b) A world-wide unique identifier for each N_PORT attached to the
           device,
     
        c) For each N_PORT attached to a fabric, a 24-bit fabric-unique
           address having the properties defined in section 4.7.1.  The
           fabric address is the address to which frames are sent.
     
         Each world-wide unique identifier is a 64-bit binary quantity
         having the format defined in [FC-FS].
     
     4.5      Fibre Channel Device Discovery
     
         In a switched or mixed fabric, fibre channel devices and changes in
         the device configuration may be discovered by means of services
         provided by the Fibre Channel Name Server and Fabric Controller.
     
         The Name Server provides registration and query services that allow
         a Fibre Channel device to register its presence on the fabric and
         discover the existence of other devices.  For example, one type of
         query obtains the fabric address of an N_PORT from its 64-bit
         world-wide unique name. The full set of supported Fibre Channel
         Name Server queries is specified in [FC-GS3].
     
         The Fabric Controller complements the static discovery capabilities
         provided by the Name Server through a service that dynamically
         alerts a Fibre Channel device whenever an N_PORT is added or
         removed from the configuration. A Fibre Channel device receives
         these notifications by subscribing to the service as specified in
         [FC-FS].
     
     4.6      Fibre Channel Information Elements
     
         The fundamental element of information in Fibre Channel is the
         frame.  A frame consists of a fixed header and up to 2112 bytes of
         payload having the structure described in section 4.7. The maximum
         frame size that may be transmitted between a pair of Fibre Channel
         devices is negotiable up to the payload limit, based on the size of
         the frame buffers in each Fibre Channel device and the path MTU
         supported by the fabric.
     
         Operations involving the transfer of information between N_PORT
         pairs are performed through 'Exchanges'.  In an Exchange,
         information is transferred in one or more ordered series of frames
         referred to as Sequences.
     
         Within this framework, an upper layer protocol is defined in terms
         of transactions carried by Exchanges. Each transaction, in turn,
         consists of protocol information units, each of which is carried by
         an individual Sequence within an Exchange.
     
     
     Monia et-al.               Standards Track                  [Page 14]


     iFCP Revision 6                                      October 2001
     
     
     4.7      Fibre Channel Frame Format
     
         A Fibre Channel frame consists of a header, payload and 32-bit CRC
         bracketed by SOF and EOF delimiters. The header contains the
         control information necessary to route frames between N_PORTs and
         manage Exchanges and Sequences. The following diagram gives a
         highly simplified view of the frame.
     
                     +-----------------------------+
                     |   Start-of-frame Delimiter  |
                     +-----+-----------------------+<----+
                     |     | Destination N_PORT    |     |
                     |     | Fabric Address (D_ID) |     |
                     |     |  (24-bits)            |     |
                     +-----+-----------------------+   24-byte
                     |     | Source N_PORT         |   Frame
                     |     | Fabric Address (S_ID) |   Header
                     |     | (24 bits)             |     |
                     +-----+-----------------------+     |
                     |    Control information for  |     |
                     |    frame type, Exchange     |     |
                     |    management, IU           |     |
                     |    segmentation and         |     |
                     |    re-assembly              |     |
                     +-----------------------------+<----+
                     |                             |
                     |        Frame payload        |
                     |       (0 û 2112 bytes)      |
                     |                             |
                     |                             |
                     |                             |
                     +-----------------------------+
                     |            CRC              |
                     +-----------------------------+
                     |    End-of-Frame Delimiter   |
                     +-----------------------------+
                        Figure 4 -- Fibre Channel Frame Format
     
     
         The source and destination N_PORT fabric addresses embedded in the
         S_ID and D_ID fields represent the physical MAC addresses of
         originating and receiving N_PORTs.
     
     4.7.1   N_PORT Address Model
     
         N_PORT fabric addresses are 24-bit values having the following
         format defined by the Fibre Channel specification [FC-FS]:
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 15]


     iFCP Revision 6                                      October 2001
     
     
               Bit   23       16 15         8 7        0
                    +-----------+------------+----------+
                    | Domain ID | Area ID    |  Port ID |
                    +-----------+------------+----------+
                     Figure 5 -- Fibre Channel Address Format
     
         A Fibre Channel device acquires an address when it is attached to
         the fabric. Such addresses are volatile and subject to change based
         on modifications in the fabric configuration.
     
         In a Fibre Channel fabric, each switch element has a unique Domain
         I/D assigned by the principal switch. The value of the Domain I/D
         ranges from 1 to 239 (0xEF). Each switch element, in turn,
         administers a block of addresses divided into area and port IDs.
         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.
     
     4.8      Fibre Channel Transport Services
     
         The Fibre Channel standard ([FC-FS])  defines the following classes
         of service provided by a fabric implementation:
     
         Class 1 û A dedicated physical circuit connecting two N_PORTs.
     
         Class 2 û A frame-multiplexed connection with end-to-end flow
         control and delivery confirmation.
     
         Class 3 û A frame-multiplexed connection with no provisions for
         end-to-end flow control or delivery confirmation.
     
         Class 3 service is similar to UDP or IP datagram service. Fibre
         channel storage devices using this class of service rely on the ULP
         implementation to detect and recover from transient device and
         transport errors.
     
         In addition to the above services, fabrics may implement additional
         quality of service policies.
     
         For service classes other than class 1, the Fibre Channel fabric is
         not required to provide in-order delivery of frames unless
         explicitly requested by the frame originator (and supported by the
         fabric). If ordered delivery is not in effect, it is the
         responsibility of the frame recipient to reconstruct the order in
         which frames were sent based on sequence information in the frame
         header.
     
     4.9      Login Processes
     
         The Login processes are the means whereby an N_PORT establishes the
         operating environment necessary to communicate with the fabric and
         other N_PORTs.  Fabric login (FLOGI) and destination N_PORT login
     
     Monia et-al.               Standards Track                  [Page 16]


     iFCP Revision 6                                      October 2001
     
     
         (PLOGI) are performed through procedures by which an N_PORT
         exchanges operating parameters with the fabric or another N_PORT.
     
         Since N_PORT addresses are volatile, an N_PORT login (PLOGI)
         operation is almost always preceded by a Name Server query to
         discover the Fibre Channel address of the remote device.  A common
         query type involves use of the world-wide unique name of an N_PORT
         to obtain the 24-bit N_PORT Fibre Channel address to which the
         PLOGI request is sent.
     
     5.       The iFCP Network Model
     
         The purpose of the iFCP protocol is to enable the implementation of
         Fibre Channel mixed or switched fabric functionality on an IP
         network in which IP components and technology replace the Fibre
         Channel switching and routing infrastructure described in section
         4.2.
     
         The following diagram shows a Fibre Channel fabric with attached
         devices. These are connected to the fabric through an N_PORT
         interface attached to a Fabric Port whose behavior is specified in
         [FC-FS]. In this case, the N_PORT and Fabric Port represent any of
         the variants described in section 4.2.
     
         Within the Fibre Channel device domain, fabric-addressable entities
         consist of other N_PORTs and devices internal to the fabric that
         perform the fabric services defined in [FC-GS3].
     
                     Fibre Channel Network
                 +--------+        +--------+
                 |  FC    |        |  FC    |
                 | Device |        | Device |
                 |........|        |........| Fibre Channel
                 | N_PORT |<......>| N_PORT | Device Domain
                 +---+----+        +----+---+       ^
                     |                  |           |
                 +---+----+        +----+---+       |
                 | Fabric |        | Fabric |       |
                 | Port   |        | Port   |       |
       ==========+========+========+========+==============
                 |         Fabric &         |       |
                 |     Fabric Services      |       v
                 |                          | Fibre Channel
                 +--------------------------+ Fabric Domain
                          Figure 6 -- A Fibre Channel Fabric
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 17]


     iFCP Revision 6                                      October 2001
     
     
     
     
           Gateway Region                   Gateway Region
      +--------+  +--------+           +--------+  +--------+
      |   FC   |  |  FC    |           |   FC   |  |   FC   |
      | Device |  | Device | Fibre     | Device |  | Device |  Fibre
      |........|  |........| Channel   |........|  |........|  Channel
      | N_PORT |  | N_PORT |<.........>| N_PORT |  | N_PORT |  Device
      +---+----+  +---+----+ Traffic   +----+---+  +----+---+  Domain
          |           |                     |           |         ^
      +---+----+  +---+----+           +----+---+  +----+---+     |
      | Fabric |  | Fabric |           | Fabric |  | Fabric |     |
      | Port   |  | Port   |           | Port   |  | Port   |     |
     =+========+==+========+===========+========+==+========+==========
      |    iFCP Layer      |<--------->|     iFCP Layer     |     |
      |....................|     ^     |....................|     |
      |     iFCP Portal    |     |     |     iFCP Portal    |     v
      +--------+-----------+     |     +----------+---------+    IP
           iFCP|Gateway      Control          iFCP|Gateway      Fabric
               |              Data                |
               |                                  |
               |                                  |
               |<------Encapsulated Frames------->|
               |      +------------------+        |
               |      |                  |        |
               +------+    IP Network    +--------+
                      |                  |
                      +------------------+
                    Figure 7 -- An iFCP Network with iFCP Gateways
     
     
         The above diagram shows one implementation of an equivalent iFCP
         fabric.  Two gateway regions are shown. Each consists of Fibre
         Channel devices directly connected to the iFCP fabric through
         fabric ports implemented as part of the edge switch or gateway.
     
         Looking into the fabric port on the Fibre Channel side of the
         gateway, the network appears as a Fibre Channel fabric. Here, the
         gateway presents remote N_PORTs as fabric-attached devices.
         Conversely, on the IP network side, the gateway presents each
         locally connected N_PORT as a logical Fibre Channel device.
     
     5.1      Fabric Topologies Supported by iFCP
     
         A property of this gateway architecture is that the fabric
         configuration and topology within the gateway region are opaque to
         the IP network and other gateway regions.  That is, the topology in
         the gateway region, whether it is loop- or switch-based, is hidden
         from the IP network and from other gateway regions. As a result,
         support for specific FC fabric topologies becomes a gateway
         implementation issue.  In such cases, the gateway incorporates
     
     
     Monia et-al.               Standards Track                  [Page 18]


     iFCP Revision 6                                      October 2001
     
     
         whatever functionality is required to present locally attached
         N_PORTs as logical iFCP devices.
     
         Regarding fabric topologies, the examples in this specification
         show an N_PORT directly connected to a gateway fabric port, this is
         done to keep the illustrations simple and does not reflect any
         fundamental limitation in the fabric configuration that an
         implementation can support.
     
     5.2      iFCP Transport Services
     
         N_PORT to N_PORT communications that traverse a TCP/IP network
         require the intervention of the iFCP layer within the gateway. This
         consists of the following operations:
     
         a) Execution of the frame addressing and mapping functions
            described in section 5.3.
     
         b) Execution of fabric-supplied link services addressed to one of
            the well-known Fibre Channel N_PORT addresses.
     
         c) Encapsulation of Fibre Channel frames for injection into the
            TCP/IP network and de-encapsulation of Fibre Channel frames
            received from the TCP/IP network.
     
         d) Establishment of an N_PORT login session in response to a PLOGI
            directed to a remote device.
     
         The following sections discuss the frame addressing mechanism and
         the way in which it is used to achieve communications transparency
         between N_PORTs.
     
     5.2.1   Fibre Channel Transport Services Supported by iFCP
     
         An iFCP fabric supports Class 2 and Class 3 Fibre Channel transport
         services as specified in [FC-FS].  An iFCP fabric does not support
         the Class 1 (dedicated connection) service.
     
     5.3      The iFCP N_PORT Address Model
     
         This section discusses the role of the N_PORT addressing model of
         section 4.7.1 in the routing of frames between locally and remotely
         attached N_PORTs.
     
         In the case of a remote N_PORT, where the frame traffic must
         traverse the IP network, the gateway must perform this routing
         transparently with respect to the locally attached N_PORT.
     
         To provide such transparency, the gateway maintains an association
         between the Fibre Channel address of a remote N_PORT, as seen by a
         locally attached device, and the corresponding address of the
         remote device on the IP network. To establish this association the
     
     Monia et-al.               Standards Track                  [Page 19]


     iFCP Revision 6                                      October 2001
     
     
         iFCP gateway assigns and manages Fibre Channel N_PORT fabric
         addresses as described in the following paragraphs.
     
         In an iFCP fabric, the iFCP gateway performs the address assignment
         and frame routing functions of an FC switch element. Unlike an FC
         switch, however, an iFCP gateway must also route frames to external
         devices attached to remote gateways on the IP network.
     
         In order to be transparent to FC devices, the gateway must route
         such frames using only the embedded 24-bit address. By exploiting
         its control of address allocation and access to frame traffic
         entering or leaving the gateway region, it is able to achieve the
         necessary transparency.
     
         The gateway may allocate device addresses in one of two ways:
     
         a) Address Translation Mode û A mode of address assignment in which
            the gateway allocates an N_PORT device address that is unique to
            the gateway region. The address of a remote device is
            represented in that gateway region by a gateway assigned N_PORT
            alias.
     
         b) Address Transparent Mode û A mode of address assignment in which
            the gateway allocates an N_PORT address that is unique across
            the set of gateway regions comprising a logical fabric.
     
         In address transparent mode, gateways within a logical fabric
         cooperate in the assignment of addresses to locally attached
         N_PORTs. Each gateway in control of a region is responsible for
         obtaining and distributing unique domain I/Ds from the address
         assignment authority as described in section 5.3.1.1. Consequently,
         within the scope of the logical fabric, the address of each N_PORT
         is unique.  For that reason, gateway-assigned aliases are not
         required to represent remote N_PORTs.
     
         All iFCP implementations MUST support operation in address
         translation mode. Support for address transparent mode is optional.
     
         The mode of gateway operation is settable in an implementation-
         specific manner.  The implementation MUST NOT allow the mode to be
         changed after iFCP sessions have been established.
     
         The choice of addressing mode involves the tradeoffs between
         scalability and transparency discussed below.
     
         The scalability constraints in address transparent mode are a
         consequence of the Fibre Channel address allocation policy
         described in section 4.7.1. As noted, a logical fabric using this
         address allocation scheme is limited to a combined total of 239
         gateways and Fibre Channel switch elements. As the system expands,
         an IP fabric may consist of many switch elements distributed
         throughout the enterprise, each of which controls a small number of
     
     Monia et-al.               Standards Track                  [Page 20]


     iFCP Revision 6                                      October 2001
     
     
         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
         iFCP gateways, Fibre Channel devices and switch elements may be
         internetworked.  This mode of address allocation also simplifies
         management of an iFCP network by eliminating the need for a
         centralized N_PORT address assignment authority.
     
         A consequence of address translation mode is that the 24-bit N_PORT
         address is no longer unique across the set of Fibre Channel devices
         connected to the IP network. As a result, when processing frame
         traffic to or from remote N_PORTs, the gateway must intervene to
         translate the 24-bit N_PORT addresses between the sending and
         receiving gateway regions.  These address operations involve:
     
         a)  Translating the N_PORT I/Ds in the frame header and
     
         b)  Translating N_PORT I/Ds carried in the payload of certain
             extended link service messages.
     
         The process of N_PORT I/D translation for the frame header is
         described in section 5.3.2.  The processing of link service
         messages with frame addresses in the payload is described in
         section 7.1.
     
         The details of the address transparent and address translation
         operational modes are discussed in the following sections.
     
     5.3.1   Operation in Address Transparent Mode
     
         In addition to the scalability limits discussed above, the
         following considerations and requirements apply to this mode of
         operation:
     
         a) There is increased dependency on the services of a central
            address assignment authority, such as iSNS. If connectivity with
            the server is lost, new DOMAIN_ID values cannot be automatically
            allocated as gateways and Fibre Channel switch elements are
            added to the logical fabric.  As a result, new gateways and
            switch elements cannot be automatically added to the ip fabric.
            Of course, it is always possible to add and manage such
            additional components manually.
     
         b) Coordination of iSNS servers is required. Multiple iFCP gateways
            set up with independently-administered address servers must be
            completely torn down and slaved under a single iSNS name server
            before they can be configured into the same logical fabric.  In
            contrast, operation in address translation mode requires only
            that the independent iSNS servers import client attributes from
     
     Monia et-al.               Standards Track                  [Page 21]


     iFCP Revision 6                                      October 2001
     
     
            other iSNS servers before client gateways under different iSNS
            authorities can be made to interoperate.
     
         c) iFCP gateways in address transparent mode will not interoperate
            with iFCP gateways that are not in transparent mode.
     
         d) When interoperating with locally attached Fibre Channel fabrics,
            the iFCP gateway MUST assume control of DOMAIN_ID assignments in
            accordance with the appropriate Fibre Channel standard or
            specification.  As described in section 5.3.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
            iFCP layer.
     
         The process for establishing the TCP/IP context associated with an
         N_PORT login session in this mode is similar to that specified for
         address translation mode (section 5.3.2).
     
     5.3.1.1  Transparent Mode Domain I/D Management
     
         As described above, each gateway and Fibre Channel switch in a
         logical fabric must have a unique domain I/D.  In a gateway region
         containing Fibre Channel switch elements, each element obtains a
         domain I/D by querying  the principal switch as described in [FC-
         SW2] -- in this case the iFCP gateway itself.  The gateway in turn
         may obtain domain I/Ds on demand from a central address allocation
         authority, such as an iSNS name server or manually from a pre-
         assigned block of IDs.  In that sense, the address authority (e.g.,
         iSNS) assumes the role of master switch for the logical fabric.
     
     5.3.1.2  Incompatibility with Address Translation Mode
     
         iFCP gateways in address transparent mode shall not originate or
         accept frames that do not have the TRN bit  set to one in the  iFCP
         flags field of the encapsulation header (see section 6.4.1).  The
         iFCP gateway shall immediately terminate any N_PORT sessions with
         the iFCP gateway from which it receives such frames.
     
     5.3.2   Operation in Address Translation Mode
     
         This section summarizes the process for managing the assignment of
         addresses within a gateway region, including the modification of FC
         frame addresses embedded in the frame header for frames sent and
         received from remotely attached N_PORTs.
     
         As described above, the scope of N_PORT addresses in this mode is
         local to the gateway region.  A principal switch within the gateway
         region, possibly the iFCP gateway itself, oversees the assignment
     
     Monia et-al.               Standards Track                  [Page 22]


     iFCP Revision 6                                      October 2001
     
     
         of such addresses in accordance with the rules specified in [FC-FS]
         and [FC-FLA].
     
         The assignment of N_PORT addresses to locally attached devices is
         controlled by the switch element to which the device is connected.
     
         When a remotely attached N_PORT is accessed, the gateway assigns a
         locally significant N_PORT alias.  This alias is used in place of
         the N_PORT I/D assigned by the remote gateway.  To perform address
         conversion and enable the appropriate routing, the gateway
         maintains a table mapping N_PORT aliases to the appropriate TCP/IP
         connection context and N_PORT ID of all remotely accessed  N_PORTs.
         The means by which translation table entries are created and
         updated are described in section 5.3.2.1.
     
     5.3.2.1  Translation Table Maintenance
     
         This section discusses the mechanisms for creating and maintaining
         the translation tables used by a gateway operating in address
         translation mode.  For purposes of illustration, Figure 8 shows an
         example of how a translation table entry might be formatted.
     
                          +--------------------------------+
                          |  IP Address of Remote Gateway  |
                          +--------------------------------+
                          |  N_PORT I/D                    |
                          +--------------------------------+
                          |  N_PORT Alias                  |
                          +--------------------------------+
                          |  N_PORT World-wide Unique Name |
                          +--------------------------------+
            Figure 8 -- Address Translation Table Entry for Remote Device
     
         Each entry contains the following information:
     
             IP Address of Remote Gateway -- IP address of the gateway to
             which the remote device is attached.
     
             N_PORT I/D --  N_PORT address assigned to the remote device by
             the remote iFCP gateway.
     
             N_PORT Alias -- N_PORT address assigned to the remote device by
             the 'local' iFCP gateway.
     
             N_PORT World-wide Unique Name -- 64-bit N_PORT world wide name
             as specified in [FC-FS].
     
         In addition to the table itself, the iFCP gateway is assumed to
         have some way of performing rapid table lookups when translating
         addresses for frame traffic as described in section 5.3.2.2.
     
     
     
     Monia et-al.               Standards Track                  [Page 23]


     iFCP Revision 6                                      October 2001
     
     
         Translation table entries may be built in response to the following
         Fibre Channel transactions:
     
         a) Name Server requests issued by locally-attached N_PORTs as part
            of Fibre Channel device discovery (see section 4.5) or,
     
         b) N_PORT PLOGI requests received from remote Fibre Channel devices
            (see section 7.3.7).
     
         An iFCP gateway converts a Fibre Channel Name Server request to an
         iSNS server query. Information returned in response to the query
         includes the IP address, N_PORT ID and N_PORT world wide unique
         name for the remote device. After building the table entry
         containing this information, the iFCP layer creates and adds the
         24-bit N_PORT alias.  It is this alias that is returned to the
         local N_PORT as the Fibre Channel address of the remotely attached
         device.
     
         The information in a PLOGI frame received from a remote device can
         also be used to construct a translation table entry. As described
         in section 7.3.7, the device's N_PORT world-wide unique name is
         obtained from the PLOGI request payload.  The IP address is
         available from the TCP/IP connection context and the N_PORT I/D is
         contained in the S_ID field of the PLOGI frame header. The N_PORT
         alias may then be assigned and used in address translation as
         specified in section 5.3.2.
     
     5.3.2.1.1  Updating a Translation Table Entry
     
         A translation table entry may become stale as the result of any
         event that invalidates or triggers a change in the fabric-assigned
         N_PORT network address, such as a fabric reconfiguration or the
         replacement of the Fibre Channel device.  A collateral effect of
         such an event is that the affected Fibre Channel devices terminate
         all N_PORT login sessions and discard or reject incoming FC-4 frame
         traffic. Consequently, frames directed to an N_PORT as the result
         of a stale translation table entry will be rejected or discarded by
         the receiving Fibre Channel device.
     
         Once the originating N_PORT learns of the reconfiguration, usually
         through the Fibre Channel state change notification mechanism, the
         normal name server lookup and PLOGI mechanisms needed to
         reestablish the N_PORT login session will automatically purge the
         translation table of such stale entries.
     
     5.3.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 the TCP connection context and the N_PORT ID assigned
         by the remote gateway. The translation process for outbound frames
         is shown below.
     
     Monia et-al.               Standards Track                  [Page 24]


     iFCP Revision 6                                      October 2001
     
     
              Raw Fibre Channel Frame
     +--------+-----------------------------------+    +--------------+
     |        |  Destination N_PORT Alias         |--->| Lookup TCP   |
     +--------+-----------------------------------+    | connection   |
     |        |  Source N_PORT ID                 |    | context      |
     +--------------------------------------------+    | and N_PORT ID|
     |                                            |    +------+-------+
     |        Control information,                |           | TCP
     |        Payload and FC CRC                  |           | conn
     |                                            |           | context
     +--------------------------------------------+           | &
                                                              | N_PORT
                                                              | ID
                                                              |
     After Address Translation and Encapsulation              |
     +--------------------------------------------+           |
     |          FC Encapsulation Header           |           |
     +--------------------------------------------+           |
     |            SOF Delimiter Word              |           |
     +============================================+           |
     |        |  Destination N_PORT ID            |<----------+
     +--------+-----------------------------------+
     |        |  Source N_PORT ID                 |
     +--------+-----------------------------------+
     |                                            |
     |        Control information, Payload        |
     |        and FC CRC                          |
     +============================================+
     |         EOF Delimiter Word                 |
     +--------------------------------------------+
         Figure 9 -- Outbound Frame Address Translation
     
         For inbound frames, a translation table lookup is performed to
         regenerate the N_PORT alias from the TCP connection context and
         N_PORT ID contained in the encapsulated FC frame. The translation
         process for inbound frames is shown below.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 25]


     iFCP Revision 6                                      October 2001
     
     
          Network Format of Inbound Frame
     +--------------------------------------------+     TCP
     |          FC Encapsulation Header           |     Connection
     +--------------------------------------------+     Context
     |            SOF Delimiter Word              |         |
     +============================================+         V
     |        |  Destination N_PORT ID            |     +---+----+
     +--------+-----------------------------------+     | Lookup |
     |        |  Source N_PORT ID                 |---->| Source |
     +--------+-----------------------------------+     | N_PORT |
     |                                            |     | Alias  |
     |        Control information, Payload        |     +----+---+
     |        and FC CRC                          |          | Source
     +============================================+          | N_PORT
     |         EOF Delimiter Word                 |          | Alias
     +--------------------------------------------+          |
                                                             |
                                                             |
     Frame after Address Translation and De-encapsulation    |
     +--------+-----------------------------------+          |
     |        |  Destination N_PORT ID            |          |
     +--------+-----------------------------------+          |
     |        |  Source N_PORT Alias              |<---------+
     +--------+-----------------------------------+
     |                                            |
     |        Control information, Payload,       |
     |        and FC CRC                          |
     +--------------------------------------------+
         Figure 10 -- Inbound Frame Address Translation
     
     
     5.3.2.3  Incompatibility with Address Transparent Mode
     
         iFCP gateways in address translation mode shall not originate or
         accept frames that have the TRN bit set to one in the iFCP flags
         field of the encapsulation header.  The iFCP gateway shall
         immediately abort any N_PORT login sessions with the iFCP gateway
         from which it receives such frames as described in section 6.2.3.2.
     
     6.       iFCP Protocol
     
     6.1      Overview
     
     6.1.1   iFCP Transport Services
     
         The main function of the iFCP protocol layer is to transport Fibre
         Channel frame images between locally and remotely attached N_PORTs.
     
         When transporting frames to a remote N_PORT, the iFCP layer
         encapsulates and routes the Fibre Channel frames comprising each
         Fibre Channel Information Unit via a predetermined TCP connection
         for transport across the IP network.
     
     Monia et-al.               Standards Track                  [Page 26]


     iFCP Revision 6                                      October 2001
     
     
         When receiving Fibre Channel frame images from the IP network, the
         iFCP layer de-encapsulates  and delivers each frame to the
         appropriate N_PORT.
     
         The iFCP layer processes the following types of traffic:
     
         a)  FC4 frame images associated with a Fibre Channel application
             protocol.
     
         b)  FC2 frames comprising Fibre Channel link service requests and
             responses
     
         c)  Fibre Channel broadcast frames
     
         d)  iFCP control messages required to setup or terminate an iFCP
             session.
     
         For FC4 N_PORT traffic and most FC2 messages the iFCP layer never
         interprets the contents of the frame payload.
     
         iFCP does interpret and process iFCP control messages and certain
         FC2 extended link service messages as described in section 6.1.2
     
     6.1.2   iFCP Support for  Link Services
     
         iFCP must intervene in the processing of those Fibre Channel
         Extended Link Service (ELS) messages which contain N_PORT addresses
         in the message payload or require other special handling, such as
         an N_PORT login request (PLOGI).
     
         In the former case, an iFCP gateway operating in address
         translation mode must supplement the payload with additional
         information that enables the receiving gateway to convert such
         embedded N_PORT addresses to its frame of reference.
     
         For out-bound Fibre Channel frames comprising such an ELS, the iFCP
         layer creates the supplemental information based on frame content,
         modifies the frame payload, then transmits the resulting Fibre
         Channel frame with supplemental data through the appropriate TCP
         connection.
     
         For incoming iFCP frames containing supplemented Fibre Channel
         ELSs, iFCP interprets the frame, including any supplemental
         information, modifies the frame content, and forwards the resulting
         frame to the destination N_PORT for further processing.
     
         Section 7.1 describes the processing of these Extended Link Service
         messages in detail.
     
     6.2      TCP Stream Transport of iFCP Frames
     
     6.2.1   iFCP Session Model
     
     Monia et-al.               Standards Track                  [Page 27]


     iFCP Revision 6                                      October 2001
     
     
         An iFCP session consists of the pair of N_PORTs comprising the
         session endpoints joined by a single TCP/IP connection.
     
         An N_PORT is identified by its network address consisting of:
     
         a) The N_PORT I/D assigned by the gateway to which the N_PORT is
            locally attached and
     
         b) The IP address of the gateway's iFCP Portal.
     
         Since only one iFCP session may exist between a pair of N_PORTs,
         the iFCP session is uniquely identified by the network addresses of
         the session end points.
     
         TCP connections that may be used for iFCP sessions between pairs of
         iFCP portals are either "bound" or "unbound".  An unbound
         connection is a TCP connection that is not actively supporting an
         iFCP session.  A gateway implementation MAY establish a pool of
         unbound connections to reduce the session setup time.  Such pre-
         existing TCP connections between iFCP Portals remain unbound and
         uncommitted until allocated to an iFCP session through a CBIND
         message (see section 8.1).
     
         When the iFCP layer detects a Port Login (PLOGI) message creating
         an iFCP session between a pair of N_PORTs, it may select an
         existing unbound TCP connection or establish a new TCP connection,
         and send the CBIND message down that TCP connection.  This
         allocates the TCP connection to that PLOGI login session.
     
     6.2.2   iFCP Session Management
     
         This section describes the protocols for establishing and
         terminating an N_PORT login session.
     
     6.2.2.1  Creating an iFCP Session
     
         An iFCP session may be in one of the following states:
     
         a) OPEN  --  The session state in which Fibre Channel frame images
            may be sent and received.
     
         b) OPEN PENDING -- The session state after a gateway has issued a
            CBIND request but no response has yet been received.  No Fibre
            Channel frames may be sent.
     
         The gateway SHALL initiate the creation of an iFCP session in
         response to a PLOGI ELS directed to a remote N_PORT from a locally
         attached N_PORT as described in the following steps.
     
         a) If no iFCP session exists, allocate a TCP connection to the
            remote gateway.  An implementation may use an existing
     
     
     Monia et-al.               Standards Track                  [Page 28]


     iFCP Revision 6                                      October 2001
     
     
            connection in the Unbound state or a new connection may be
            created and placed in the Unbound state.
     
         b) If a connection cannot be allocated or created due to limited
            resources, the gateway SHALL terminate the PLOGI with an LS_RJT
            response. The Reason Code field in the LS_RJT message shall be
            set to 0x09 (Unable to Perform Command Request) and the Reason
            Explanation SHALL be set to 0x29 (Insufficient Resources to
            Support Login).
     
         c) If an iFCP session in the OPEN state already exists to the
            remote N_PORT, the gateway SHALL forward the PLOGI ELS using the
            existing session.
     
         d) If the iFCP session does not exist, the gateway SHALL issue a
            CBIND session control message (see section 8.1) and place the
            session in the OPEN PENDING state.
     
         e) In the event that a CBIND response is returned with one of the
            following statuses, the PLOGI shall be terminated with an LS_RJT
            message.  Depending on the CBIND failure status, the Reason Code
            and Reason Explanation SHALL be set to the following values
            specified in [FC-FS].
     
             CBIND Failure     LS_RJT Reason     LS_RJT Reason Code
             Status            Code              Explanation
             -------------     -------------     ------------------
     
             Unspecified       Unable to Perform No additional
             Reason (16)       Command Request   explanation (0x00)
                               (0x09)
     
             No Such Device    Unable to Perform Invalid N_PORT Name
             (17)              Command Request   (0x0D).
                               (0x09)
     
             Lack of           Unable to Perform Insufficient
             Resources (19)    Command Request   Resources to Support
                               (0x09).           Login (0x29).
     
             Incompatible      Unable to Perform No additional
             address           Command Request   Explanation (0x00)
             translation mode  (0x09)
             (20)
     
             Incorrect iFCP    Unable to Perform No additional
             protocol version  Command Request   explanation (0x00)
             number (21)       (0x09)
     
         f) A CBIND response with a CBIND STATUS of "N_PORT session already
            exists" indicates that the remote gateway has concurrently
            initiated a CBIND request to create an iFCP session between the
     
     Monia et-al.               Standards Track                  [Page 29]


     iFCP Revision 6                                      October 2001
     
     
            same pair of N_PORTs. The receiving gateway SHALL terminate this
            attempt, return the connection to the Unbound state and prepare
            to respond to an incoming CBIND request as described below.
     
         The gateway receiving a CBIND request SHALL respond as follows:
     
         a) If the receiver has a duplicate iFCP session in the OPEN PENDING
            state, then the receiving gateway SHALL compare the Source Port
            Name  in the incoming CBIND payload with the Destination Port
            Name..
     
         b) If the Source Port Name is greater, the receiver shall issue a
            CBIND response of "Success" and SHALL place the session in the
            OPEN state.
     
         c) If the Source Port Name is less, the receiver shall issue a
            CBIND RESPONSE of Failed - N_PORT session already exists. The
            state of the receiver-initiated iFCP session SHALL BE unchanged.
     
         d) If there is no duplicate iFCP session, the receiving gateway
            SHALL issue a CBIND response. If a status of Success is
            returned, the receiving gateway SHALL create the iFCP session
            and place it in the OPEN state.
     
     6.2.2.2  Use of TCP Features and Settings
     
         This section describes ground rules for the use of TCP features in
         an iFCP session.  The core TCP protocol is defined in [RFC793].
         TCP implementation requirements and guidelines are specified in
         [RFC1122].
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 30]


     iFCP Revision 6                                      October 2001
     
     
         +-----------+------------+--------------+------------+------------+
         | Feature   | Applicable |  RFC         |  Peer-wise | Requirement|
         |           | RFCs       |  Status      |  agreement | Level      |
         |           |            |              |  required? |            |
         +===========+============+==============+============+============+
         | Keep Alive| [RFC1122]  |  None        |  No        | Should not |
         |           |(discussion)|              |            | use        |
         +-----------+------------+--------------+------------+------------+
         | Tiny      | [RFC896]   |  Standard    |  No        | Should not |
         | Segment   |            |              |            | use        |
         | Avoidance |            |              |            |            |
         | (Nagle)   |            |              |            |            |
         +-----------+------------+--------------+------------+------------+
         | Window    | [RFC1323]  |  Proposed    |  No        | Should use |
         | Scale     |            |  Standard    |            |            |
         +-----------+------------+--------------+------------+------------+
         | Wrapped   | [RFC1323]  |  Proposed    |  No        | Should use |
         | Sequence  |            |  Standard    |            |            |
         | Protection|            |              |            |            |
         | (PAWS)    |            |              |            |            |
         +-----------+------------+--------------+------------+------------+
         | Selective | [RFC2018], |  Proposed    |  Yes       | Should use |
         | Ack       | [RFC2883]  |  Standard    |            |            |
         +-----------+------------+--------------+------------+------------+
         | Congestion| [RFC2581]  |  Proposed    |  No        | Should use |
         | Control   |            |  Standard    |            |            |
         | with Fast |            |              |            |            |
         | Recovery  |            |              |            |            |
         +-----------+------------+--------------+------------+------------+
         | Explicit  | [RFC3168]  |  Standards   |  Yes       | May use    |
         | Congestion|            |  Track       |            |            |
         | Control   |            |              |            |            |
         +-----------+------------+--------------+------------+------------+
                      Table 1 -- Usage of Optional TCP Features
     
         The following sections describe these options in greater detail.
     
     6.2.2.2.1  Keep Alive
     
         Keep Alive speeds the detection and cleanup of dysfunctional TCP
         connections by sending traffic when a connection would otherwise be
         idle.  The issues are discussed in [RFC1122].
     
         In order to test the device more comprehensively, Fibre Channel
         applications, such as storage, may implement an equivalent keep
         alive function at the FC4 level. For that reason and the
         considerations described in [RFC1122], keep alive at the transport
         layer should not be implemented.
     
     6.2.2.2.2  'Tiny' Segment Avoidance (Nagle)
     
     
     
     Monia et-al.               Standards Track                  [Page 31]


     iFCP Revision 6                                      October 2001
     
     
         The Nagle algorithm described in [RFC896] is designed to avoid the
         overhead of small segments by delaying transmission in order to
         agglomerate transfer requests into a large segment.  In iFCP, such
         small transfers often contain I/O requests.  Hence, the
         transmission delay of the Nagle algorithm may decrease I/O
         throughput.  Hence, the Nagle algorithm should not be used.
     
     6.2.2.2.3  Window Scale
     
         Window scaling, as specified in [RFC1323], allows full utilization
         of links with large bandwidth - delay products and should be
         supported by an iFCP implementation.
     
     6.2.2.2.4  Wrapped Sequence Protection (PAWS)
     
         TCP segments are identified with 32-bit sequence numbers. In
         networks with large bandwidth - delay products, it is therefore
         possible for more than one TCP segment with the same sequence
         number to be in flight.  In iFCP, receipt of such a sequence out of
         order may cause out-of-order frame delivery or data corruption.
         Consequently, this feature SHOULD be supported as described in
         [RFC1323].
     
     6.2.2.2.5  Selective Acknowledge
     
         Selective acknowledge acknowledges individual segments as they
         arrive, rather than waiting for all prior missing segments to be
         delivered.  Consequently, error recovery is faster since only the
         unacknowledged segments must be resent.  Selective Acknowledge
         should therefore be supported as described in [RFC2018] and
         [RFC2883].
     
     6.2.2.2.6  Congestion Control with Fast Recovery
     
         Fast recovery, as specified in [RFC2581], involves the use of
         duplicate acknowledgements to expedite error recovery by notifying
         the sender that a segment may have been lost.  An iFCP
         implementation should support this feature.
     
     6.2.2.2.7  Explicit Congestion Control
     
         TCP congestion avoidance throttles the inflow of data to the
         network when data loss is experienced. Essentially, the system is
         driven beyond saturation before load shedding occurs.
     
         The method of explicit congestion notification in [RFC3168]
         specifies an approach for congestion avoidance that is triggered by
         impending rather than actual data loss and hence does not incur the
         error recovery penalties.  This method relies on the insertion of
         router-generated notifications into the TCP Acknowledgement to
         inform the sender when the system is approaching its load carrying
     
     
     Monia et-al.               Standards Track                  [Page 32]


     iFCP Revision 6                                      October 2001
     
     
         capacity. As such, it requires support by the routing
         infrastructure and may be supported by an iFCP implementation.
     
     6.2.2.3  Error Recovery and Cold Start
     
     6.2.2.3.1  Establishing Connections After Reboot or Cold Start
     
         When a TCP connection is established following a reboot or cold
         start, there is a possibility that pending traffic or traffic still
         in flight from a previous connection may interfere with traffic
         from the new connection.  To prevent such interference, a gateway
         performing a cold start should wait before initiating any TCP
         connections. The amount of wait time should be settable through the
         management interface. The value of 120 seconds specified in
         [RFC1323] is recommended as the default.
     
     6.2.2.3.2  Aborting a TCP Connection
     
         When aborting a TCP connection in response to on of the errors
         described in section 6.2.3.2, the connection SHOULD be terminated
         with a connection reset (RST).
     
     6.2.3   Terminating an N_PORT Login Session
     
         An N_PORT login session SHALL be terminated or aborted in response
         to one of the following events:
     
         a)  An LS_RJT response is returned to the gateway that issued the
             PLOGI ELS.  The gateway SHALL forward the LS_RJT to the local
             N_PORT and complete the session as described in section
             6.2.3.1.
     
         b)  An ACC received from a remote device in response to a LOGO. The
             gateway SHALL forward the ACC to the local N_PORT and complete
             the session as described in section 6.2.3.1.
     
         c)  For an FC frame received from the IP network, a gateway detects
             a CRC error in the encapsulation header. The gateway shall
             abort the session as described in section 6.2.3.2.
     
         d)  The TCP connection associated with the login session fails for
             any reason.  The gateway detecting the failed connection shall
             abort the session as described in section 6.2.3.2.
     
     6.2.3.1  N_PORT Login Session Completion
     
         An N_PORT login session is completed in response to a rejected
         PLOGI request as described in section 6.2.3 or a successful LOGO
         ELS.
     
         The gateway receiving one of the above responses shall issue an
         Unbind session control ELS as described in section 8.2.
     
     Monia et-al.               Standards Track                  [Page 33]


     iFCP Revision 6                                      October 2001
     
     
         In response to the Unbind message, either gateway may choose to
         close the connection or return it to a pool of unbound connections.
     
     6.2.3.2  Aborting an N_PORT Login Session
     
         An N_PORT login session SHALL be aborted if the TCP connection is
         spontaneously terminated or whenever one of the following occurs:
     
         a) An encapsulation error is detected as described in section
            6.4.3.
     
         b) The gateway receives an encapsulated frame from a gateway
            operating in an incompatible address translation mode as
            specified in section 5.3.2.3 or 5.3.1.2.
     
         In any event, the TCP connection shall be aborted as described in
         section 6.2.2.3.2..  If the local N_PORT has logged in to the
         remote N_PORT, the gateway SHALL send a LOGO to the local N_PORT.
     
     6.3      IANA Considerations
     
         There will be an IANA-assigned port for iFCP connections. This port
         will be used for both TCP traffic (iFCP regular traffic) and UDP
         traffic (iFCP broadcast services only, see 10.4). This well-known
         port will b                  e                                     r                   e                   g                   i                   s                   t                   r                   e                   d                   e                   w                                       i                   t                                       h                   A                   I                   A                   N                   .
     
         An iFCP Portal may initiate a connection using any TCP port number
         consistent with its implementation of the TCP/IP stack, provided
         each port number is unique.  To prevent the receipt of stale data
         associated with a previous connection using a given port number,
         the provisions of [RFC1323] SHOULD be observed.
     
     6.4      Encapsulation of Fibre Channel Frames
     
         This section describes the iFCP encapsulation of Fibre Channel
         frames.  The encapsulation is based on the common encapsulation
         format defined in [ENCAP].
     
         The format of an encapsulated frame is shown below:
     
                       +--------------------+
                       |       Header       |
                       +--------------------+-----+
                       |        SOF         |   f |
                       +--------------------+ F r |
                       |  FC frame content  | C a |
                       +--------------------+   m |
                       |        EOF         |   e |
                       +--------------------+-----+
                        Figure 11 -- Encapsulation Format
     
     
     
     Monia et-al.               Standards Track                  [Page 34]


     iFCP Revision 6                                      October 2001
     
     
         The encapsulation consists of a 7-word header, an SOF delimiter
         word, the FC frame (including the Fibre Channel CRC), and an EOF
         delimiter word.  The header and delimiter formats are described in
         the following sections.
     
     6.4.1   Encapsulation Header Format
     
     W|------------------------------Bit------------------------------|
     o|                                                               |
     r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
     d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
      +---------------+---------------+---------------+---------------+
     0|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
      +---------------+---------------+---------------+---------------+
     1|                  Reserved (must be zero)                      |
      +---------------+---------------+---------------+---------------+
     2| LS_COMMAND    |  iFCP Flags   |     SOF       |      EOF      |
      +-----------+---+---------------+-----------+---+---------------+
     3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
      +-----------+-------------------+-----------+-------------------+
     4|                      Time Stamp [integer]                     |
      +---------------------------------------------------------------+
     5|                      Time Stamp [fraction]                    |
      +---------------------------------------------------------------+
     6|                              CRC                              |
      +---------------------------------------------------------------+
     
     
         Common Encapsulation Fields:
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 35]


     iFCP Revision 6                                      October 2001
     
     
          Protocol#            IANA-assigned protocol number
                                identifying the protocol using the
                                encapsulation.  For iFCP the value is
                                (/TBD/).
     
          Version              Encapsulation version
     
          -Protocol#           Ones complement of the protocol#
     
          -Version             Ones complement of the version
     
          Flags                Encapsulation flags (see 6.4.1.1)
     
          Frame Length         Contains the length of the entire FC
                                Encapsulated frame including the FC
                                Encapsulation Header and the FC frame
                                (including SOF and EOF words) in units
                                of 32-bit words.
     
          -Flags               Ones-complement of the Flags field.
     
          -Frame Length        Ones-complement of the Frame Length
                                field.
     
          Time Stamp [integer] Integer component of the frame time
                                stamp in SNTP format [RFC2030].
     
          Time Stamp           Fractional component of the time stamp
          [fraction]           in SNTP format [RFC2030].
     
          CRC                  Header CRC.  MUST be valid for iFCP.
     
     
     
             The time stamp fields are used to enforce the limit on the
             lifetime of a Fibre Channel frame as described in section
             9.2.1.
     
          iFCP-specific fields:
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 36]


     iFCP Revision 6                                      October 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.
     
          iFCP Flags           iFCP-specific flags (see below)
     
          SOF                  Copy of the SOF delimiter encoding
                                (see section 6.4.2)
     
          EOF                  Copy of the EOF delimiter encoding
                                (see section 6.4.2)
     
     
     
         The iFCP flags word has the following format:
     
            |------------------------Bit----------------------------|
            |                                                       |
            |  23     22     21     20     19     18     17    16   |
            +------+------+------+------+------+------+------+------+
            |             Reserved             | SES  | TRN  |  AUG |
            +------+------+------+------+------+------+------+------+
                             Figure 12 -- iFCP Flags Word
     
         iFCP Flags:
     
         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.
     
     
     
     6.4.1.1  Common Encapsulation Flags
     
         The iFCP usage of the common encapsulation flags is shown below:
     
           |------------------------Bit--------------------------|
           |                                                     |
           |   31       30       29       28       27       26   |
           +--------------------------------------------+--------+
           |                  Reserved                  |  CRCV  |
           +--------------------------------------------+--------+
     
     
         For iFCP, the CRC field MUST be valid and CRCV MUST be set to one.
     
     Monia et-al.               Standards Track                  [Page 37]


     iFCP Revision 6                                      October 2001
     
     
     6.4.2   SOF and EOF Delimiter Fields
     
         The format of the delimiter fields is shown below.
     
     W|------------------------------Bit------------------------------|
     o|                                                               |
     r|3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1                    |
     d|1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0|
      +---------------+---------------+-------------------------------+
     0|      SOF      |      SOF      |     -SOF      |     -SOF      |
      +---------------+---------------+-------------------------------+
     1|                                                               |
      +-----                   FC frame content                  -----+
      |                                                               |
      +---------------+---------------+-------------------------------+
     n|      EOF      |      EOF      |     -EOF      |     -EOF      |
      +---------------+---------------+-------------------------------+
     Figure 13 -- FC Frame Encapsulation Format
     
          SOF (bits 31-24 and bits 23-16 in word 0):  iFCP uses the
          following subset of the SOF fields described in [ENCAP].
     
                               +-------+----------+
                               |  FC   |          |
                               |  SOF  | SOF Code |
                               +-------+----------+
                               | SOFi2 |   0x2D   |
                               | SOFn2 |   0x35   |
                               | SOFi3 |   0x2E   |
                               | SOFn3 |   0x36   |
                               +-------+----------+
             Table 2-- Translation of FC SOF Values to SOF Field Contents
     
         -SOF (bits 15-8 and 7-0 in word 0): The -SOF fields contain the
         ones complement of the value in the SOF fields.
     
         EOF (bits 31-24 and 23-16 in word n):  iFCP uses the following
         subset of EOF fields specified in [ENCAP].
     
                               +-------+----------+
                               |  FC   |          |
                               |  EOF  | EOF Code |
                               +-------+----------+
                               | EOFn  |   0x41   |
                               | EOFt  |   0x42   |
                               +-------+----------+
            Table 3 -- Translation of FC EOF Values to EOF Field Contents
     
         -EOF (bits 15-8 and 7-0 in word n): The -EOF fields contain the
         one's complement of the value in the EOF fields.
     
     
     
     Monia et-al.               Standards Track                  [Page 38]


     iFCP Revision 6                                      October 2001
     
     
         iFCP implementations SHALL place a copy of the SOF and EOF
         delimiter codes in the appropriate header fields.
     
     6.4.3   Frame Encapsulation
     
         A Fibre Channel Frame to be encapsulated MUST first be validated as
         described in [FC-FS].  Any frames received from a locally attached
         Fibre Channel device that do not pass the validity tests in [FC-FS]
         SHALL be discarded by the gateway.
     
         Frames types submitted for encapsulation and forwarding on the IP
         network SHALL have one of the SOF delimiters in Table 2 and an EOF
         delimiter from Table 3.  Other valid frame types MUST be processed
         internally by the gateway as specified in the appropriate Fibre
         Channel specification.
     
         Prior to submitting a frame for encapsulation, a gateway in address
         translation mode SHALL replace the D_ID address, and, if processing
         an augmented ELS, SHALL format the frame payload and add the
         supplemental information as specified in section 7.1.  The gateway
         SHALL then calculate a new FC CRC on the reformatted frame.
     
         A gateway in address transparent mode MAY encapsulate and transmit
         the frame image without recalculating the FC CRC.
     
         The frame originator MUST then create and fill in the header and
         the SOF and EOF delimiter words as specified above.
     
     6.4.4   Frame De-encapsulation
     
         The receiving gateway SHALL perform de-encapsulation as follows:
     
         Upon receiving the encapsulated frame, the gateway SHALL check the
         header CRC.  If the header CRC is invalid, the gateway SHALL
         terminate the N_PORT login session as described in section 6.2.3.2.
     
         After validating the header CRC, the receiving gateway MAY verify
         the frame propagation delay as described in section 9.2.1. If the
         propagation delay is too long, the frame SHALL be discarded.
         Otherwise, the gateway SHALL check the SOF and EOF in the
         encapsulation header.  A frame shall be discarded if it has an SOF
         code that is not in Table 2 or an EOF code that is not in Table 3.
     
         The gateway shall then de-encapsulate the frame.  If operating in
         address translation mode, the gateway shall:
     
         a) Check the FC CRC and discard the frame if the CRC is invalid.
     
         b) Replace the S_ID with the N_PORT alias of the frame originator
     
     
     
     
     Monia et-al.               Standards Track                  [Page 39]


     iFCP Revision 6                                      October 2001
     
     
         c) If processing an augmented ELS, replace the ELS frame with a
            copy whose payload has been modified as specified in section
            7.1.
     
         The de-encapsulated frame SHALL then be delivered to the N_PORT
         specified in the D_ID field.  If the frame contents have been
         modified by the receiving gateway, a new FC CRC SHALL be
         calculated.
     
     7.       Fibre Channel Link Services
     
         Link services provide a set of Fibre Channel functions that allow a
         port to send control information or request another port to perform
         a specific control function.
     
         Each Link Service message (request and reply) is carried by a Fibre
         Channel sequence, and can be segmented into multiple frames.
     
         The iFCP Layer is responsible for transporting link service
         messages across the IP fabric.  This includes mapping Link Service
         messages appropriately from the domain of the Fibre Channel
         transport to that of the IP network.  This process may require
         special processing and the inclusion of augmented data by the iFCP
         layer.
     
         Each link service or extended link service is processed according
         to one of the following rules:
     
         a) Transparent û The link service message and reply MUST be
            transported to the receiving N_PORT by the iFCP gateway without
            altering the message payload. The link service message and reply
            are not processed by the iFCP implementation.
     
         b) Augmented -  Applies to an extended link service reply or
            request containing Fibre Channel addresses in the payload or
            requiring other special processing by the iFCP 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 iFCP
            implementation.   The gateway SHALL respond to a rejected link
            service message by returning an LS_RJT response with a Reason
            Code of 0x0B (Command Not Supported) and a Reason Code
            Explanation of 0x0 (No Additional Explanation).
     
         This section describes the processing for augmented link services,
         including the manner in which augmentation data is transmitted over
         the IP network.
     
         Appendix A enumerates all link services and the iFCP processing
         policy that applies to each.
     
     Monia et-al.               Standards Track                  [Page 40]


     iFCP Revision 6                                      October 2001
     
     
     7.1      Augmented Link Service Messages
     
         Augmentation applies to extended link service requests that require
         the intervention of the iFCP 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:
     
         Word
           31      24 23                                             0
          +----------+------------------------------------------------+
         0| R_CTL    |                     D_ID                       |
          | [22]     | [Destination of extended link Service request] |
          +----------+------------------------------------------------+
         1| CS_CTL   |                     S_ID                       |
          |          | [Source of extended link service request]      |
          +----------+------------------------------------------------+
         2| TYPE     |                     F_CTL                      |
          +----------+------------------+-----------------------------+
         3| SEQ_ID   |        DF_CTL    |          SEQ_CNT            |
          +----------+------------------+-----------------------------+
         4|        OX_ID                |             RX_ID           |
          +-----------------------------+-----------------------------+
         5|                       Parameter                           |
          |                    [ 00 00 00 00 ]                        |
          +-----------------------------------------------------------+
         6|                       LS_COMMAND                          |
          |             [Extended Link Service Command Code]          |
          +-----------------------------------------------------------+
         7|                                                           |
         .|            Additional Service Request Parameters          |
         .|                     ( if any )                            |
         n|                                                           |
          +-----------------------------------------------------------+
                  Figure 14 -- Format of Extended Link Service Frame
     
     
     
     7.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.
     
     Monia et-al.               Standards Track                  [Page 41]


     iFCP Revision 6                                      October 2001
     
     
         Supplemental data includes information required by the receiving
         gateway to convert an N_PORT address in the payload to an N_PORT
         address in the receiving gatewayÆs address space. The following
         rules define the manner in which such supplemental data is packaged
         and referenced.
     
         For an N_PORT address field, the gateway originating the frame MUST
         set the value in the payload to identify the address translation
         type as follows:
     
             0x00 00 01 û The gateway receiving the frame from the IP
             network MUST replace the contents of the field with the N_PORT
             alias of the frame originator.  This translation type MUST be
             used when the address to be converted is that of the source
             N_PORT.
     
             0x00 00 02 û The gateway receiving the frame from the IP
             network MUST replace the contents of the field with the N_PORT
             I/D of the destination N_PORT.  This translation type MUST be
             used when the address to be converted is that of the
             destination N_PORT
     
             0x00 00 03 û The gateway receiving the frame from the IP
             network MUST reference augmentation data to set the field
             contents. The augmentation information is the 64-bit world wide
             identifier of the N_PORT as set forth in the Fibre Channel
             specification [FC-FS]. If not otherwise part of the ELS, this
             information MUST be appended 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.
     
     
     
         Since Fibre Channel addressing rules prohibit the assignment of
         fabric addresses with a domain I/D of 0, the above codes will never
         correspond to valid N_PORT fabric IDs.
     
         For translation type 3, the receiving gateway SHALL obtain the
         information needed to fill in the ELS field by converting the
         specified N_PORT world-wide identifier to a gateway IP address and
         N_PORT ID.  This information MUST be obtained through a name server
         query. If the N_PORT is locally attached, the gateway MUST fill in
         the field with the N_PORT ID.  If the N_PORT is remotely attached,
         the gateway MUST assign and fill in the field with an N_PORT alias.
         If an N_PORT alias has already been assigned, it MUST be reused.
     
         In the event that the sending gateway cannot obtain the world wide
         identifier of an N_PORT, or a receiving gateway cannot obtain the
         IP address and N_PORT ID, the gateway detecting the error SHALL
         terminate the request with an LS_RJT message as described in [FCS].
         The Reason Code SHALL be set to 0x07 (protocol error) and the
     
     Monia et-al.               Standards Track                  [Page 42]


     iFCP Revision 6                                      October 2001
     
     
         Reason Explanation SHALL be set to 0x1F (Invalid N_PORT
         identifier).
     
         Supplemental data is sent with the ELS request or ACC frames in one
         of the following ways:
     
         a) By appending the necessary data to the end of the ELS frame.
     
         b) By extending the sequence with 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 dependent on the format of the
         augmented ELS.
     
         After applying the supplemental data, the receiving gateway SHALL
         forward the resulting ELS frames to the destination N_PORT with the
         supplemental information removed.
     
         When the ACC response 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.
     
     7.3      Augmented Link Services
     
         The following Link Service Messages must receive special processing
         or be supplemented with additional control data.
     
         An encapsulated Fibre Channel frame that is part of an augmented
         ELS MUST have the AUG bit set to one in the iFCP FLAGS field of the
         encapsulation header as specified in section 6.4.1. 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.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 43]


     iFCP Revision 6                                      October 2001
     
     
         Link Service Message               LS_COMMAND      Mnemonic
         --------------------               ----------      --------
         Abort Exchange                    0x06 00 00 00       ABTX
         Discover Address                  0x52 00 00 00      ADISC
         Discover Address Accept           0x02 00 00 00    ADISC ACC
         FC Address Resolution Protocol    0x55 00 00 00    FARP-REPLY
         Reply
         FC Address Resolution Protocol    0x54 00 00 00     FARP-REQ
         Request
         Logout                            0x05 00 00 00       LOGO
         Port Login                        0x30 00 00 00      PLOGI
         Read Exchange Concise             0x13 00 00 00       REC
         Read Exchange Concise Accept      0x02 00 00 00     REC ACC
         Read Exchange Status Block        0x08 00 00 00       RES
         Read Exchange Status Block        0x02 00 00 00     RES ACC
         Accept
         Read Link Error Status Block      0x0F 00 00 00       RLS
         Read Sequence Status Block        0x09 00 00 00       RSS
         Reinstate Recovery Qualifier      0x12 00 00 00       RRQ
         Request Sequence Initiative       0x0A 00 00 00       RSI
         Third Party Process Logout        0x24 00 00 00      TPRLO
         Third Party Process Logout        0x02 00 00 00    TPRLO ACC
         Accept
     
         The formats of each augmented ELS, including supplemental data
         where applicable, are shown in the following sections.  Each ELS
         diagram shows the basic format, as specified in the applicable FC
         standard, followed by supplemental data as shown in the example
         below.
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    |                  LS_COMMAND                    |
         +------+------------+------------+-----------+----------+
         | 1    |                                                |
         | .    |                                                |
         | .    |                ELS Payload                     |
         |      |                                                |
         | n    |                                                |
         +======+============+============+===========+==========+
         | n+1  |                                                |
         |  .   |            Supplemental Data                   |
         |  .   |               (if any)                         |
         | n+k  |                                                |
         +======+================================================+
                      ELS Diagram (single FC Frame Format)
     
     7.3.1   Abort Exchange (ABTX)
     
         ELS Format:
     
     
     Monia et-al.               Standards Track                  [Page 44]


     iFCP Revision 6                                      October 2001
     
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x6  |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | RRQ Status |     Exchange Originator S_ID      |
         +------+------------+------------+-----------+----------+
         | 2    |   OX_ID of Tgt exchange | RX_ID of tgt exchange|
         +------+------------+------------+-----------+----------+
         | 3-10 |  Optional association header (32 bytes         |
         +======+============+============+===========+==========+
     
     
         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type (see      (type 3 only)
         -------------------    section 7.2)     ------------
                                 -----------
     
         Exchange Originator        1, 2              N/A
         S_ID
     
     
         Other Special Processing:
     
             None
     
     7.3.2   Discover Address (ADISC)
     
         Format of ADISC ELS:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x52 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Reserved   |  Hard address of ELS Originator   |
         +------+------------+------------+-----------+----------+
         | 2-3  |     Port Name of Originator                    |
         +------+------------+------------+-----------+----------+
         | 4-5  |     Node Name of originator                    |
         +------+------------+------------+-----------+----------+
         | 6    |  Rsvd      |  N_PORT I/D of ELS Originator     |
         +======+============+============+===========+==========+
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 45]


     iFCP Revision 6                                      October 2001
     
     
     
         Fields Requiring       Translation    Supplemental Data
         Address Translation     Type (see       (type 3 only)
         -------------------   section 7.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.
     
     7.3.3   Discover Address Accept (ADISC ACC)
     
         Format of ADISC ACC ELS:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x20 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Reserved   |  Hard address of ELS Originator   |
         +------+------------+------------+-----------+----------+
         | 2-3  |     Port Name of Originator                    |
         +------+------------+------------+-----------+----------+
         | 4-5  |     Node Name of originator                    |
         +------+------------+------------+-----------+----------+
         | 6    |  Rsvd      |  N_PORT I/D of ELS Originator     |
         +======+============+============+===========+==========+
     
     
         Fields Requiring       Translation    Supplemental Data
         Address Translation     Type (see       (type 3 only)
         -------------------   section 7.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.
     
     7.3.4   FC Address Resolution Protocol Reply (FARP-REPLY)
     
         The FARP-REPLY ELS is used in conjunction with the FARP-REQ ELS
         (see section 7.3.5) to perform the address resolution services
     
     
     Monia et-al.               Standards Track                  [Page 46]


     iFCP Revision 6                                      October 2001
     
     
         required by the FC-VI protocol [FC-VI] and the Fibre Channel
         mapping of IP and ARP specified in RFC 2625 [RFC2625].
     
         Format of FARP-REPLY ELS:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x55 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Match Addr |  Requesting N_PORT Identifier     |
         |      | Code Points|                                   |
         +------+------------+------------+-----------+----------+
         | 2    | Responder  |  Responding N_PORT Identifier     |
         |      | Action     |                                   |
         +------+------------+------------+-----------+----------+
         | 3-4  |     Requesting N_PORT Port_Name                |
         +------+------------+------------+-----------+----------+
         | 5-6  |     Requesting N_PORT Node_Name                |
         +------+------------+------------+-----------+----------+
         | 7-8  |     Responding N_PORT Port_Name                |
         +------+------------+------------+-----------+----------+
         | 9-10 |     Responding N_PORT Node_Name                |
         +------+------------+------------+-----------+----------+
         | 11-14|     Requesting N_PORT IP Address               |
         +------+------------+------------+-----------+----------+
         | 15-18|     Responding N_PORT IP Address               |
         +======+============+============+===========+==========+
     
     
     
     
         Fields Requiring       Translation    Supplemental Data
         Address Translation     Type (see       (type 3 only)
         -------------------   section 7.2)   -----------------
                                -------------
     
         Requesting N_PORT           2                N/A
         Identifier
     
         Responding N_PORT           1                N/A
         identifier
     
     
     
         Other Special Processing:
     
             None.
     
     
     7.3.5   FC Address Resolution Protocol Request (FARP-REQ)
     
     
     Monia et-al.               Standards Track                  [Page 47]


     iFCP Revision 6                                      October 2001
     
     
         The FARP-REQ ELS is used to in conjunction with the FC-VI protocol
         [FC-VI] and IP to FC mapping of RFC 2625 [RFC2625] to perform IP
         and FC address resolution in an FC fabric.  The FARP-REQ ELS is
         usually directed to the fabric broadcast server at well-known
         address 0xFF-FF-FF for retransmission to all attached N_PORTs.
         Section 10.4 describes the iFCP implementation of FC broadcast
         server functionality in an iFCP fabric.
     
         Format of FARP_REQ ELS:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x54 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Match Addr |  Requesting N_PORT Identifier     |
         |      | Code Points|                                   |
         +------+------------+------------+-----------+----------+
         | 2    | Responder  |  Responding N_PORT Identifier     |
         |      | Action     |                                   |
         +------+------------+------------+-----------+----------+
         | 3-4  |     Requesting N_PORT Port_Name                |
         +------+------------+------------+-----------+----------+
         | 5-6  |     Requesting N_PORT Node_Name                |
         +------+------------+------------+-----------+----------+
         | 7-8  |     Responding N_PORT Port_Name                |
         +------+------------+------------+-----------+----------+
         | 9-10 |     Responding N_PORT Node_Name                |
         +------+------------+------------+-----------+----------+
         | 11-14|     Requesting N_PORT IP Address               |
         +------+------------+------------+-----------+----------+
         | 15-18|     Responding N_PORT IP Address               |
         +======+============+============+===========+==========+
     
     
         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type (see      (type 3 only)
         -------------------   section 7.2)   -----------------
                                 -----------
     
         Requesting N_PORT           3        Requesting N_PORT
         Identifier                           Port Name
     
     
         Other Special Processing:
     
             None.
     
     
     7.3.6   Logout (LOGO)
     
         ELS Format:
     
     Monia et-al.               Standards Track                  [Page 48]


     iFCP Revision 6                                      October 2001
     
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x5  |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Rsvd       |     N_PORT I/D being logged out   |
         +------+------------+------------+-----------+----------+
         | 2-3  |  Port name of the LOGO originator (8 bytes)    |
         +======+============+============+===========+==========+
     
     
         This ELS shall always be sent as an augmented ELS regardless of the
         translation mode in effect.
     
         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type(see       (type 3 only)
         -------------------   section 7.2)    --------------
                                 -----------
     
         N_PORT I/D Being            1               N/A
         Logged Out
     
     
     
         Other Special Processing:
     
             See section 6.2.3.1.
     
     
     7.3.7   Port Login (PLOGI)
     
         PLOGI provides the mechanism for establishing a login session
         between two N_PORTs. In iFCP, a PLOGI request addressed to a
         remotely attached N_PORT may trigger the creation of an iFCP
         session, if one does not already exist.  Otherwise, the PLOGI and
         ACC payloads MUST be passed transparently to the destination
         N_PORT.
     
         The PLOGI request and ACC response carry information identifying
         the originating N_PORT, including specification of its capabilities
         and limitations.  If the destination N_PORT accepts the login
         request, it sends an accept (an ACC frame with PLOGI payload),
         specifying its capabilities and limitations.  This exchange
         establishes the operating environment for the two N_PORTs.
     
         The following figure is duplicated from [FC-FS], and shows the
         PLOGI message format for both request and accept (ACC) response.  A
         port will reject a PLOGI request by transmitting an LS_RJT message,
         which contains no payload.
     
     
     
     
     Monia et-al.               Standards Track                  [Page 49]


     iFCP Revision 6                                      October 2001
     
     
        Byte
        Offset
               +----------------------------------+
           0   |            LS_COMMAND            |     4 Bytes
               +----------------------------------+
           4   |     COMMON SERVICE PARAMETERS    |    16 Bytes
               +----------------------------------+
          20   |            PORT NAME             |     8 Bytes
               +----------------------------------+
          28   |            NODE NAME             |     8 Bytes
               +----------------------------------+
          36   |     CLASS 1 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          52   |     CLASS 2 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          68   |     CLASS 3 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          86   |     CLASS 4 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
         102   |        VENDOR VERSION LEVEL      |    16 Bytes
               +----------------------------------+
                        Total Length = 116 bytes
                Figure 15 -- Format of PLOGI Request and ACC Payloads
     
     
     
         Details on the above fields, including common and class-based
         service parameters, can be found in [FC-FS].
     
     7.3.8   Read Exchange Concise
     
         ELS Format:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x13 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Rsvd       |     Exchange Originator S_ID      |
         +------+------------+------------+-----------+----------+
         | 2    |          OX_ID          |         RX_ID        |
         +======+============+============+===========+==========+
         | 3-4  |Port name of the exchange originator (8 bytes)  |
         |      |   (present only for translation type 3)        |
         +======+============+============+===========+==========+
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 50]


     iFCP Revision 6                                      October 2001
     
     
         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type(see       (type 3 only)
         -------------------   section 7.2)  ------------------
                                 -----------
     
         Exchange Originator  1, 2 or 3      Port Name of the
         S_ID                                 Exchange
                                               Originator
     
     
     
         Other Special Processing:
     
             None.
     
     7.3.9   Read Exchange Concise Accept
     
         Format of ACC Response:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Acc = 0x02 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    |          OX_ID          |         RX_ID        |
         +------+------------+------------+-----------+----------+
         | 2    | Rsvd       | Exchange Originator N_PORT ID     |
         +------+------------+------------+-----------+----------+
         | 3    | Rsvd       | Exchange Responder N_PORT ID      |
         +------+------------+------------+-----------+----------+
         | 4    |         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 3 only)
         -------------------   section 7.2)    ------------------
                                 -----------
     
         Exchange Originator  1, 2 or 3      Port Name of the
         N_PORT I/D                           Exchange Originator
     
         Exchange Responder   1, 2 or 3      Port Name of the
         N_PORT I/D                           Exchange Responder
     
     
     
     
     Monia et-al.               Standards Track                  [Page 51]


     iFCP Revision 6                                      October 2001
     
     
         When supplemental data is required, the ELS shall always be
         extended by 4 words as shown above.  If the translation type for
         the Exchange Originator N_PORT I/D or the Exchange Responder N_PORT
         I/D is 1 or 2, the corresponding 8-byte port name SHALL be set to
         all zeros.
     
         Other Special Processing:
     
             None.
     
     7.3.10  Read Exchange Status Block (RES)
     
         ELS Format:
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15û8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x13 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Rsvd       |     Exchange Originator S_ID      |
         +------+------------+------------+-----------+----------+
         | 2    |          OX_ID          |         RX_ID        |
         +------+------------+------------+-----------+----------+
         | 3-10 |  Association header (may be optionally reqÆd)  |
         +======+============+============+===========+==========+
         | 11-12| Port name of the Exchange Originator (8 bytes) |
         +======+============+============+===========+==========+
     
     
         Fields Requiring       Translation     Supplemental Data
         Address Translation     Type(see        (type 3 only)
         -------------------   section 7.2)    ------------------
                                 -----------
     
         Exchange Originator  1, 2 or 3      Port Name of the
         S_ID                                 Exchange Originator
     
     
     
         Other Special Processing:
     
             None.
     
     7.3.11  Read Exchange Status Block Accept
     
         Format of ELS Accept Response:
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 52]


     iFCP Revision 6                                      October 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+2   |                                                |
         +======+============+============+===========+==========+
         |n+3-  | Port name of the Exchange Responder (8 bytes)  |
         |n+4  |                                                |
         +======+============+============+===========+==========+
     
         Fields Requiring       Translation     Supplemental Data
         Address Translation     Type(see         (type 3 only)
         -------------------   section 7.2)    ------------------
                                 -----------
     
         Exchange Originator  1, 2 or 3      Port Name of the
         N_PORT I/D                           Exchange Originator
     
         Exchange Responder   1, 2 or 3      Port Name of the
         N_0ORT I/D                           Exchange Responder
     
     
     
         When supplemental data is required, the ELS SHALL be extended by 4
         words as shown above. If the translation type for the Exchange
         Originator N_PORT I/D or the Exchange Responder N_PORT I/D is 1 or
         2, the corresponding 8-byte port name SHALL be set to all zeros.
     
         Other Special Processing:
     
             None.
     
     7.3.12  Read Link Error Status (RLS)
     
         ELS Format:
     
     
     
     Monia et-al.               Standards Track                  [Page 53]


     iFCP Revision 6                                      October 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-3  |           Port name of the N_PORT (8 bytes)    |
         +======+============+============+===========+==========+
     
         Fields Requiring       Translation   Supplemental Data (type
         Address Translation     Type(see            3 only)
         -------------------   section 7.2)     ------------------
                                 -----------
     
         N_PORT Identifier    1, 2 or 3      Port Name of the N_PORT
     
     
     
         Other Special Processing:
     
             None.
     
     7.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 3 only)
         -------------------   section 7.2)   ------------------
                                 -----------
     
         Exchange Originator  1, 2 or 3      Port Name of the
         S_ID                                 Exchange Originator
     
     
     
         Other Special Processing:
     
     
     
     Monia et-al.               Standards Track                  [Page 54]


     iFCP Revision 6                                      October 2001
     
     
             None.
     
     7.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 3 only)
         -------------------   section 7.2)  ------------------
                                 -----------
     
         Exchange Originator      1 or 2             N/A
         S_ID
     
     
     
         Other Special Processing:
     
             None.
     
     7.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)  |
         +======+============+============+===========+==========+
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 55]


     iFCP Revision 6                                      October 2001
     
     
         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type(see       (type 3 only)
         -------------------   section 7.2)  ------------------
                                 -----------
     
         Exchange Originator      1 or 2             N/A
         S_ID
     
     
     
         Other Special Processing:
     
             None.
     
     7.3.16  Third Party Process Logout (TPRLO)
     
         TPRLO provides a mechanism for an N_PORT (third party) to remove
         one or more process login sessions that exist between the
         destination N_PORT and other N_PORTs specified in the command.
         This command includes one or more TPRLO LOGOUT PARAMETER PAGEs,
         each of which when combined with the destination N_PORT identifies
         a process login to be terminated by the command.
     
         +--------+------------+--------------------+----------------------+
         | Word   | Bits 31û24 |    Bits 23û16      |     Bits 15 - 0      |
         +--------+------------+--------------------+----------------------+
         | 0      | Cmd = 0x24 | Page Length (0x10) |    Payload Length    |
         +--------+------------+--------------------+----------------------+
         | 1      |          TPRLO Logout Parameter Page 0                 |
         +--------+--------------------------------------------------------+
         | 5      |          TPRLO Logout Parameter Page 1                 |
         +--------+--------------------------------------------------------+
                                  ....
         +--------+--------------------------------------------------------+
         |(4*n)+1 |          TPRLO Logout Parameter page n                 |
         +--------+--------------------------------------------------------+
                         Figure 16 -- Format of TPRLO ELS
     
         Each TPRLO parameter page contains parameters identifying one or
         more image pairs and may be associated with a single FC4 protocol
         type, common to all FC4 protocol types between the specified image
         pair, or global to all specified image pairs. The format of an
         augmented TPRLO page is shown in Figure 17. Additional information
         on TPRLO can be found in [FC-FS].
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 56]


     iFCP Revision 6                                      October 2001
     
     
         +------+------------+------------+-----------+----------+
         | Word | Bits 31û24 | Bits 23û16 | Bits 15-8 | Bits 7-0 |
         +------+------------+------------+-----------+----------+
         | 0    | TYPE Code  | TYPE CODE  |                      |
         |      | or         | EXTENSION  |      TPRLO Flags     |
         |      | Common SVC |            |                      |
         |      | Parameters |            |                      |
         +------+------------+------------+-----------+----------+
         | 1    |         Third Party Process Associator         |
         +------+------------+------------+-----------+----------+
         | 2    |         Responder Process Associator           |
         +------+------------+------------+-----------+----------+
         | 3    | Reserved   | Third Party Originator N_PORT ID  |
         +======+============+============+===========+==========+
         | 4-5  | World Wide Name of Third Party Originator      |
         |      | N_PORT                                         |
         +------+------------------------------------------------+
          Figure 17 -- Format of an Augmented TPRLO Parameter Page
     
         The TPRLO flags that affect the processing of the augmented ELS are
         as follows:
     
         Bit 12:   Global Process logout.  When set to one, this bit
                    indicates that all image pairs for all N_PORTs of the
                    specified FC4 protocol shall be invalidated. When the
                    value of this bit is one, only one logout parameter page
                    is permitted in the TPRLO payload.
     
         Bit 13:   Third party Originator N_PORT Validity.  When set to
                    one, this bit indicates that word 3, bits 23-00 (Third
                    Party Originator N_PORT ID) are meaningful.
     
     
     
         If bit 13 has a value of zero and bit 12 has a value of one in the
         TPRLO flags field, then the ELS SHALL NOT be sent as an augmented
         ELS.
     
         Otherwise the originating gateway SHALL process the ELS as follows:
     
         a)  The first word of the TPRLO payload SHALL NOT be modified.
     
         b)  Each TPRLO parameter page shall be extended by two words as
             shown in Figure 17.
     
         c)  If word 0, bit 13 (Third Party Originator N_PORT I/D validity)
             in the TPRLO flags field has a value of one, then the sender
             shall place the world-wide port name of the fibre channel
             device's N_PORT in the extension words. The N_PORT I/D SHALL be
             set to 3. Otherwise, the contents of the extension words and
             the Third Party Originator N_PORT ID SHALL be set to zero.
     
     
     Monia et-al.               Standards Track                  [Page 57]


     iFCP Revision 6                                      October 2001
     
     
         d)  The ELS originator SHALL set the AUG bit in the encapsulation
             header of each augmented frame comprising the ELS (see section
             6.4.1).
     
         e)  If the ELS contains a single TPRLO parameter page, the
             originator SHALL increase the frame length as necessary to
             include the extended parameter page.
     
         f)  If the ELS to be augmented contains multiple TPRLO parameter
             pages, the FC frames created to contain the augmented ELS
             payload SHALL NOT exceed the maximum frame size that can be
             accepted by the destination N_PORT.
     
             Each Fibre Channel frame SHALL contain an integer number of
             extended TPRLO parameter pages. The maximum number of extended
             TPRLO parameter pages in a frame SHALL be limited to the number
             that can be held without exceeding the above upper limit. New
             frames resulting from the extension of the TPRLO pages to
             include the supplemental data shall be created by extending the
             SEQ_CNT in the Fibre Channel frame header. The SEQ_ID SHALL NOT
             be modified.
     
         The gateway receiving the augmented TPRLO ELS SHALL generate ELS
         frames to be sent to the destination N_PORT by copying word 0 of
         the ELS payload and processing each augmented parameter page as
         follows:
     
         a) If word 0, bit 13 has a value of one, create a parameter page by
            copying words 0 through 2 of the augmented parameter page.  The
            Third Party Originator N_PORT I/D in word 3 shall be generated
            by referencing the supplemental data as described in section
            7.2.
     
         b) If word 0, bit 13 has a value of zero, create a parameter page
            by copying words 0 through 3 of the augmented parameter page.
     
         The size of each frame to be sent to the destination N_PORT MUST
         NOT exceed the maximum frame size that the destination N_PORT can
         accept.  The sequence identifier in each frame header SHALL be
         copied from the augmented ELS and the sequence count shall be
         monotonically increasing.
     
     7.3.17  Third Party Logout Accept (TPRLO ACC)
     
         The format of the TPRLO ACC frame is shown in Figure 18.
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 58]


     iFCP Revision 6                                      October 2001
     
     
         +--------+------------+--------------------+----------------------+
         | Word   | Bits 31û24 |    Bits 23û16      |     Bits 15 - 0      |
         +--------+------------+--------------------+----------------------+
         | 0      | Cmd = 0x2  | Page Length (0x10) |    Payload Length    |
         +--------+------------+--------------------+----------------------+
         | 1      |          TPRLO Logout Parameter Page 0                 |
         +--------+--------------------------------------------------------+
         | 5      |          TPRLO Logout Parameter Page 1                 |
         +--------+--------------------------------------------------------+
                                  ....
         +--------+--------------------------------------------------------+
         |(4*n)+1 |          TPRLO Logout Parameter page n                 |
         +--------+--------------------------------------------------------+
                         Figure 18 -- Format of TPRLO ACC ELS
     
         The format of the parameter page and rules for parameter page
         augmentation are as specified in section 7.3.16.
     
     7.4      FLOGI Service Parameters Supported by an iFCP Gateway
     
         The FLOGI ELS is issued by an N_PORT that wishes to access the
         fabric transport services.
     
         The format of the FLOGI request and FLOGI ACC payloads are
         identical to the PLOGI request and ACC payloads described in
         section 7.3.7.  The figure in that section is duplicated below for
         convenience.
     
         Byte
         Offset
               +----------------------------------+
           0   |            LS_COMMAND            |     4 Bytes
               +----------------------------------+
           4   |     COMMON SERVICE PARAMETERS    |    16 Bytes
               +----------------------------------+
          20   |            PORT NAME             |     8 Bytes
               +----------------------------------+
          28   |            NODE NAME             |     8 Bytes
               +----------------------------------+
          36   |     CLASS 1 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          52   |     CLASS 2 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          68   |     CLASS 3 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
          86   |     CLASS 4 SERVICE PARAMETERS   |    16 Bytes
               +----------------------------------+
         102   |        VENDOR VERSION LEVEL      |    16 Bytes
               +----------------------------------+
                  Figure 19 -- FLOGI Request and ACC Payload Format
     
         A full description of each parameter is given in [FC-FS].
     
     Monia et-al.               Standards Track                  [Page 59]


     iFCP Revision 6                                      October 2001
     
     
         This section tabulates the protocol-dependant service parameters
         supported by a fabric port attached to an iFCP gateway.
     
         The service parameters carried in the payload of an FLOGI extended
         link service request MUST be set in accordance with
         Table 4.
     
         +-----------------------------------------+---------------+
         |                                         | Fabric Login  |
         |          Service Parameter              |    Class      |
         |                                         +---+---+---+---+
         |                                         | 1 | 2 | 3 | 4 |
         +-----------------------------------------+---+---+---+---+
         | Class Validity                          | n | M | M | n |
         +-----------------------------------------+---+---+---+---+
         | Service Options                         |               |
         +-----------------------------------------+---+---+---+---+
         |   Intermix Mode                         | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         |   Stacked Connect-Requests              | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         |   Sequential Delivery                   | n | M | M | n |
         +-----------------------------------------+---+---+---+---+
         |   Dedicated Simplex                     | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         |   Camp on                               | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         |   Buffered Class 1                      | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         |   Priority                              | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         | Initiator/Recipient Control             |               |
         +-----------------------------------------+---+---+---+---+
         |   Clock synchronization ELS capable     | n | n | n | n |
         +-----------------------------------------+---+---+---+---+
         Table 4 --  FLOGI Service Parameter Settings
     
     
         Notes:
     
              1) "y" indicates a parameter that applies to an iFCP gateway.
                  Gateway support for the feature is optional.
     
              2) "n" indicates a parameter or capability that is not
                  supported by the iFCP protocol.
     
              3) "M" indicates an applicable parameter that MUST be
                  supported by an iFCP gateway.
     
     8.       TCP Session Control Messages
     
     
     
     Monia et-al.               Standards Track                  [Page 60]


     iFCP Revision 6                                      October 2001
     
     
         TCP session control messages are used to create and manage an iFCP
         session as described in section 6.2.2. They are passed between peer
         iFCP Portals, and are only processed within the iFCP layer.
     
         The message format is based on the extended link service message
         template shown below.
     
         Word
           31<Bits>24 23<---------------Bits------------------------->0
          +----------+------------------------------------------------+
         0| R_CTL    |            D_ID [0x00 00 00]                   |
          |[Req = 22]| [Destination of extended link Service request] |
          |[Rep = 23]|                                                |
          +----------+------------------------------------------------+
         1| CS_CTL   |            S_ID [0x00 00 00]                   |
          | [0x0]    | [Source of extended link service request]      |
          +----------+------------------------------------------------+
         2|TYPE [0x1]|               F_CTL [0]                        |
          +----------+------------------+-----------------------------+
         3|SEQ_ID    | DF_CTL [0x00]    |          SEQ_CNT [0x00]     |
          |[0x0]     |                  |                             |
          +----------+------------------+-----------------------------+
         4|        OX_ID [0x0000]       |          RX_ID_[0x0000]     |
          +-----------------------------+-----------------------------+
         5|                       Parameter                           |
          |                    [ 00 00 00 00 ]                        |
          +-----------------------------------------------------------+
         6|                       LS_COMMAND                          |
          |               [Session Control Command Code]              |
          +-----------------------------------------------------------+
         7|                                                           |
         .|            Additional Session Control Parameters          |
         .|                     ( if any )                            |
         n|                                                           |
          +===========================================================+
         n|                   Fibre Channel CRC                       |
         +|                                                           |
         1+===========================================================+
                    Figure 20 -- Format of Session Control Message
     
     
         The LS_COMMAND value for the response remains the same as that used
         for the request.
     
         The session control ELS frame is terminated with a Fibre Channel
         CRC.
     
         The encapsulation header for the link Service frame carrying a TCP
         ELS message SHALL be set as follows:
     
         Encapsulation Header Fields:
     
     
     Monia et-al.               Standards Track                  [Page 61]


     iFCP Revision 6                                      October 2001
     
     
          LS_COMMAND           0
     
          iFCP Flags           SES = 1
     
                                TRN = 0
     
                                AUG = 0
     
          SOF code             SOFi3 encoding (0x2E)
     
          EOF code             EOFt encoding (0x42)
     
          Time Stamp Integer   0,0
          and Fraction fields
     
     
     
         The SOF and EOF delimiter words SHALL be set based on the SOF and
         EOF codes specified above.
     
         The following lists the session control messages and their
         corresponding LS_COMMAND values.
     
                     Request            LS_COMMAND Short Name  iFCP Support
                     -------            ---------- ----------  -----------
         Connection Bind                  0xE0       CBIND      REQUIRED
         Unbind Connection                0xE4      UNBIND      REQUIRED
     
     
     8.1      Connection Bind (CBIND)
     
         As described in section 6.2.2.1, the CBIND message and response are
         used to bind an N_PORT login session to a specific TCP connection
         and establish an iFCP session.  In the CBIND request message, the
         source and destination N_Ports are identified by the N_PORT network
         address (iFCP portal address and N_PORT ID).
     
         The following shows the format of the CBIND request.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 62]


     iFCP Revision 6                                      October 2001
     
     
         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE0 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |         Reserved        | Addr Mode | iFCP Ver |
         +------+-------------------------+-----------+----------+
         | 2    |                  User Info                     |
         +------+------------+------------+-----------+----------+
         | 3    |                                                |
         +------+                SOURCE PORT NAME                |
         | 4    |                                                |
         +------+------------------------------------------------+
         | 5    |                                                |
         +------+                DESTINATION PORT NAME           |
         | 6    |                                                |
         +------+------------------------------------------------+
     
         Addr Mode -  The address translation mode of the originating
         gateway.  0 = Address Translation mode, 1 = Address Transparent
         mode.
     
         iFCP Ver - iFCP version number. SHALL be set to 1.
     
         USER INFO - Contains any data desired by the requester.  This info
         MUST be echoed by the recipient in the CBIND response message.
     
         SOURCE PORT NAME - Contains the originating N_PORT's World Wide
         Port Name (WWPN).
     
         DESTINATION PORT NAME - Contains the destination N_PORT's World
         Wide Port Name (WWPN).
     
         The following shows the format of the CBIND response.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 63]


     iFCP Revision 6                                      October 2001
     
     
         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE0 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |         Reserved        | Addr Mode | iFCP Ver |
         +------+-------------------------+-----------+----------+
         | 2    |                  User Info                     |
         +------+------------+------------+-----------+----------+
         | 3    |                                                |
         +------+                SOURCE PORT NAME                |
         | 4    |                                                |
         +------+------------------------------------------------+
         | 5    |                                                |
         +------+                DESTINATION PORT NAME           |
         | 6    |                                                |
         +------+-------------------------+----------------------+
         | 7    |        Reserved         |     CBIND Status     |
         +------+-------------------------+----------------------+
         | 8    |        Reserved         |  CONNECTION HANDLE   |
         +------+-------------------------+----------------------+
                                   Total Length = 32
     
         Addr Mode -  The address translation mode of the responding
         gateway.  0 = Address Translation mode, 1 = Address Transparent
         mode.
     
         iFCP Ver - iFCP version number of the responding gateway. SHALL be
         set to 1.
     
         USER INFO - Contains the same value received in the USER INFO field
         of the CBIND request message.
     
         DESTINATION PORT NAME - Contains the destination N_PORT's World
         Wide Port Name (WWPN).
     
         CBIND STATUS - Indicates success or failure of the CBIND request.
         CBIND values are shown below.
     
              Value     Description
              -----     -----------
     
                0       Successful û No other status
             1 û 15     Reserved
               16       Failed û Unspecified Reason
               17       Failed û No such device
               18       Failed û N_PORT session already exists
               19       Failed û Lack of resources
               20       Failed - Incompatible address translation mode
               21       Failed - Incorrect protocol version number
             Others     Reserved
     
     
     Monia et-al.               Standards Track                  [Page 64]


     iFCP Revision 6                                      October 2001
     
     
     
     
         CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the iFCP
         Portal to identify the connection.
     
     8.2      Unbind Connection (UNBIND)
     
         UNBIND is used to release a bound TCP connection and return it to
         the pool of unbound TCP connections.  This message is transmitted
         in the connection that is to be unbound.
     
         The following is the format of the UNBIND request message.
     
         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE4 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |                  User Info                     |
         +------+------------+------------+-----------+----------+
         | 2    |       Reserved          |  Connection Handle   |
         +------+------------+------------+----------------------+
         | 3    |                  Reserved                      |
         +------+------------+------------+-----------+----------+
         | 4    |                  Reserved                      |
         +------+------------+------------+-----------+----------+
     
     
         CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the iFCP
         Portal to identify the connection
     
         The following shows the format of the UNBIND response message.
     
         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE4 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |                  User Info                     |
         +------+------------+------------+-----------+----------+
         | 2    |       Reserved          |  Connection Handle   |
         +------+------------+------------+-----------+----------+
         | 3    |                  Reserved                      |
         +------+------------+------------+-----------+----------+
         | 4    |                  Reserved                      |
         +------+------------+------------+-----------+----------+
         | 5    |         Reserved        |     UNBIND Status    |
         +------+------------+------------+-----------+----------+
     
     
         UNBIND STATUS - Indicates the success or failure of the UNBIND
         request.
     
     Monia et-al.               Standards Track                  [Page 65]


     iFCP Revision 6                                      October 2001
     
     
              Value     Description
              -----     -----------
     
                0       Successful û No other status
             1 û 15     Reserved
               16       Failed û Unspecified Reason
               17       Failed û No such device
               18       Failed û Connection ID Invalid
             Others     Reserved
     
     
         CONNECTION HANDLE (CHANDLE) - Contains a value assigned by the iFCP
         Portal to identify the unbound connection.
     
     9.       iFCP Error Detection
     
     9.1      Overview
     
         [FC-FS] defines error detection and recovery procedures.  These
         Fibre Channel-defined mechanisms continue to be available in the
         iFCP environment.
     
     9.2      Stale Frame Prevention
     
         Recovery from Fibre Channel protocol error conditions requires that
         frames associated with a failed or aborted Exchange drain from the
         fabric before Exchange resources can be safely reused.
     
         Since a Fibre Channel fabric may not preserve frame order, there is
         no deterministic way to purge such frames. Instead, the fabric
         guarantees that frame the lifetime will not exceed a specific limit
         (R_A_TOV).
     
         R_A_TOV is defined in [FC-FS] as "the maximum transit time within a
         fabric to guarantee that a lost frame will never emerge from the
         fabric".  For example, a value of 2 x R_A_TOV is the minimum time
         that the originator of an ELS request or FC4 ELS request must wait
         for the response to that request. The Fibre Channel default value
         for R_A_TOV is 10 seconds.
     
         The iFCP fabric MAY actively enforce limits on R_A_TOV as described
         in section 9.2.1.
     
     9.2.1   Enforcing R_A_TOV Limits
     
         The R_A_TOV limit on frame lifetimes MAY be enforced by means of
         the time stamp in the encapsulation header (see section 6.4.1) as
         described in this section.
     
         The budget for R_A_TOV SHOULD include allowances for the
         propagation delay through the gateway regions of the sending and
         receiving N_PORTs plus the propagation delay through the IP
     
     Monia et-al.               Standards Track                  [Page 66]


     iFCP Revision 6                                      October 2001
     
     
         network.  This latter component is referred to in this
         specification as IP_TOV.
     
         If enforced by a gateway, IP_TOV should be set well below the value
         of R_A_TOV specified for the iFCP fabric and should be stored in
         the iSNS server. IP_TOV should be set to 50 percent of R_A_TOV.
     
         The following paragraphs describe the requirements for
         synchronizing gateway time bases and the rules for measuring and
         enforcing propagation delay limits.
     
         The protocol for synchronizing a gateway time base is SNTP
         [RFC2030]. In order to insure that all gateways are time-aligned, a
         gateway SHOULD obtain the address of an SNTP-compatible time server
         via an iSNS query.  If multiple time server addresses are returned
         by the query, the servers must be synchronized and the gateway may
         use any server in the list. Alternatively, the server may return a
         multicast group address in support of operation in Anycast mode.
         Implementation of Anycast mode is as specified in [RFC2030],
         including the precautions defined in that document.  Multicast mode
         SHOULD NOT be used.
     
         An SNTP server may use any one of the time reference sources listed
         in [RFC2030]. The resolution of the time reference MUST be 125
         milliseconds or better.
     
         Stability of the SNTP server and gateway time bases should be 100
         ppm or better.
     
         With regard to its time base, the gateway is in either the
         Synchronized or Unsynchronized state.  When in the Unsynchronized
         state, the gateway SHALL:
     
         a)  Set the time stamp field to 0,0 for all outgoing frames
     
         b)  Ignore the time stamp field for all incoming frames.
     
         When in the synchronized state, the gateway SHALL
     
         a)  Set the time stamp field for each outgoing frame in accordance
             with the gateway's internal time base
     
         b)  Check the time stamp field of each incoming frame, following
             validation of the encapsulation header CRC as described in
             section 6.4.4.
     
         c)  If the incoming frame has a time stamp of 0,0, the receiving
             gateway SHALL NOT test the frame to determine if it is stale.
     
         d)  If the incoming frame has a non-zero time stamp, the receiving
             gateway SHALL compute the absolute value of the time in flight
     
     
     Monia et-al.               Standards Track                  [Page 67]


     iFCP Revision 6                                      October 2001
     
     
             and SHALL compare it against the value of IP_TOV specified for
             the IP fabric.
     
         e)  If the result in step (d) exceeds IP_TOV, the encapsulated
             frame shall be discarded.  Otherwise, the frame shall be de-
             encapsulated as described in section 6.4.4.
     
         A gateway SHALL enter the Synchronized state upon receiving a
         successful response to an SNTP query.
     
         A gateway shall enter the Unsynchronized state:
     
         a)  Upon power up and before successful completion of an SNTP query
     
         b)  Whenever the gateway looses contact with the SNTP server such
             that the gateway's time base may no longer be in alignment with
             that of the SNTP server. The criterion for determining loss of
             contact is implementation specific.
     
         Following loss of contact, it is recommended that the gateway enter
         the Unsynchronized state when the estimated time base drift
         relative to the SNTP reference is greater than ten percent of the
         IP_TOV limit. (Assuming all timers have an accuracy of 100 ppm and
         IP_TOV equals 5 seconds, the maximum allowable loss of contact
         duration would be about 42 minutes.)
     
         The gateway response to loss of synchronization is implementation-
         specific. The gateway MAY choose to abort all N_PORT login sessions
         with all remote gateways.
     
     10.      Fabric Services Supported by an iFCP implementation
     
         An iFCP gateway implementation MUST support the following fabric
         services:
     
        N_PORT ID Value           Description             Section
        ---------------           -----------             -------
          0xFF-FF-FE             F_PORT Server              10.1
     
          0xFF-FF-FD           Fabric Controller            10.2
     
          0xFF-FF-FC         Directory/Name Server          10.3
     
     
     
     
     
         In addition, an iFCP gateway MAY support the FC broadcast server
         functionality described in section 10.4.
     
     10.1     F_PORT Server
     
     
     Monia et-al.               Standards Track                  [Page 68]


     iFCP Revision 6                                      October 2001
     
     
         The F_PORT server SHALL support the FLOGI ELS as described in
         section 7.4 as well as the following ELSs specified in [FC-FS]:
     
         a) Request for fabric service parameters (FDISC),
     
         b) Request for the link error status (RLS),
     
         c) Read Fabric Timeout Values (RTV).
     
     10.2     Fabric Controller
     
         The Fabric Controller SHALL support the following ELSs as specified
         in [FC-FS]:
     
         a) State Change Notification (SCN),
     
         b) Registered State Change Notification (RSCN),
     
         c) State Change Registration (SCR).
     
     10.3     Directory/Name Server
     
         The Directory/Name server provides a registration service allowing
         an N_PORT to record or query the database for information about
         other N_PORTs.  The services are defined in [FC-GS3].  The queries
         are issued as FC-4 transactions using the FC-CT command transport
         protocol specified in [FC-GS3].
     
         In iFCP, name server requests are translated to the iSNS queries
         defined in [ISNS]. The definitions of name server objects are
         specified in [FC-GS3].
     
         The name server SHALL support record and query operations for
         directory subtype 0x02 (Name Server) and 0x03 (IP Address Server)
         and MAY support the FC-4 specific services as defined in [FC-GS3].
     
     10.4     iFCP Support for the FC Broadcast Service
     
         In Fibre Channel, frames are broadcast by addressing them to the
         broadcast server at well-known address 0xFF-FF-FF.   The broadcast
         server then replicates and delivers the frame to each attached
         N_PORT in all zones to which the originating device belongs.  Only
         class 3 (datagram) service is supported.
     
         In an iFCP system, outgoing frames to be broadcast are directed to
         the gateway-resident broadcast server by locally attached N_PORTs.
         The broadcast server then redistributes such frames as follows:
     
         a)  One copy is sent to each locally attached N_PORT in the same
             discovery domain as the originator.
     
     
     
     Monia et-al.               Standards Track                  [Page 69]


     iFCP Revision 6                                      October 2001
     
     
         b)  One copy is sent to the broadcast server in each remote gateway
             via a UDP datagram. The D_ID field is set to the well-known
             address of the FC broadcast server.  The datagram encapsulation
             format is identical to the iFCP encapsulation format described
             in section 6.4. The UDP datagram SHALL be sent to the IANA-
             assigned port number at the specified IP address. The DF bit
             SHALL be set to 1 in the IP header to prohibit IP fragmentation
             (see [RFC791]).
     
         On receiving an iFCP broadcast datagram via UDP, the broadcast
         server SHALL:
     
         a) Validate the encapsulation header as described in section 6.4.3.
            If the header is invalid, the frame SHALL be discarded.
     
         b) Convert the S_ID N_PORT address in the frame to an N_PORT alias
            as described in section 5.3.2, if address translation mode is in
            effect.
     
         c) If the AUG bit is set in the iFCP flags field, perform any
            special processing required by the ELS, including translation of
            any addresses in the payload.
     
         d) Replicate and redistribute the frame to all locally attached
            N_PORTs in the discovery domain of the sender.
     
         If no broadcast server is implemented, the receiving gateway SHALL
         discard an incoming broadcast frame from a remote gateway.
         Broadcast frames received from locally attached N_PORTs shall be
         processed as specified in[FC-GS3].
     
     11.      iFCP Security
     
     11.1     Overview
     
         iFCP relies upon the IPSec protocol suite to provide data
         confidentiality and authentication services and IKE as the key
         management protocol. Section 11.2 describes the security
         requirements arising from iFCPÆs operating environment while
         Section 11.3 describes the resulting design choices, their
         requirement levels, and how they apply to the iFCP protocol.
     
     11.2     iFCP Security Operating Requirements
     
     11.2.1  Context
     
         iFCP is a protocol designed for use by gateway devices deployed in
         enterprise data centers.  Such environments typically have security
         gateways designed to provide network security through isolation
         from public networks.  Furthermore, iFCP data may need to traverse
         security gateways in order to support SAN-to-SAN connectivity
         across public networks.
     
     Monia et-al.               Standards Track                  [Page 70]


     iFCP Revision 6                                      October 2001
     
     
     11.2.2  Security Threats
     
         Communicating iFCP gateways are vulnerable to attacks. Examples of
         attacks include attempts by an adversary to:
     
         a) Acquire confidential data and identities by snooping data
            packets.
     
         b) Modify packets containing iFCP data and control messages.
     
         c) Inject new packets into the iFCP session.
     
         d) Hijack the TCP connection carrying the iFCP session.
     
         e) Launch denial of service attacks against the iFCP gateway.
     
         f) Disrupt security negotiation process.
     
         g) Impersonate a legitimate security gateway.
     
         h) Compromise communication with the iSNS server.
     
         It is imperative to thwart these attacks, given that an iFCP
         gateway is the last line of defense for a whole Fibre Channel
         island, which may include several hosts and switches. To do so, the
         iFCP protocol MUST define confidentiality, authentication,
         integrity, and replay protection on a per-datagram basis.  It also
         MUST define a scalable approach to key management. Conformant
         implementations of the iFCP protocol MAY use such definitions.
     
     11.2.3  Performance Requirments
     
         iFCP security MUST be implementable at 1 Gbps throughput, and
         SHOULD be implementable at 10Gbps throughput.  These performance
         levels apply to aggregate gateway-to-gateway throughput, and
         include all TCP connections used to support N_PORT sessions between
         each pair of iFCP gateways.
     
     11.2.4  Interoperability Requirements with Security Gateways
     
         Enterprise data center networks are considered mission-critical
         facilities that must be isolated and protected from all possible
         security threats.  Such networks are usually protected by security
         gateways, which at a minimum provide a shield against denial of
         service attacks.  The iFCP security architecture should be able to
         leverage the protective services of the existing security
         infrastructure, including firewall protection, NAT and NAPT
         services, and IPSec VPN services available on existing security
         gateways.
     
     11.2.5  Statically and Dynamically Assigned IP Addresses
     
     
     Monia et-al.               Standards Track                  [Page 71]


     iFCP Revision 6                                      October 2001
     
     
         As iFCP gateways and switches are deployed within enterprise
         networks, it is expected that, like most routers and switches,
         gateway IP addresses will be statically assigned.  Consequently,
         IKE and IPSec features focused on supporting DHCP and other dynamic
         IP address assignment capabilities for mobile hosts are not
         strictly required. Since the iFCP protocol cannot rule out the use
         of dynamically assigned IP addresses however, the security
         definitions for the iFCP protocol shall not exhibit any
         vulnerability in the case of dynamically assigned IP addresses
         (e.g., via DHCP [RFC2131]).
     
     11.2.6  Authentication Requirements
     
         iFCP is a peer-to-peer protocol.  iFCP sessions may be initiated by
         either or both peer gateways.  Consequently, bi-directional
         authentication of peer gateways MUST be provided.
     
         Fibre Channel, operating system and user identities are transparent
         to the iFCP protocol.  IKE and IPSec authentication used to protect
         iFCP traffic shall be based upon the IP addresses of the
         communicating peer gateways.
     
         iFCP gateways shall use Discovery Domain information obtained from
         the iSNS server [ISNS] to determine whether the initiating Fibre
         Channel N_PORT should be allowed access to the target N_PORT.
         N_PORT identities used in the Port Login (PLOGI) process shall be
         considered authenticated provided the PLOGI request is received
         from the remote gateway over a secure, IPSec-protected connection.
     
         There is no requirement that the identities used in authentication
         be kept confidential.
     
     11.2.7  Confidentiality Requirements
     
         iFCP traffic may traverse insecure public networks, and therefore
         implementations MUST have per-packet encryption capabilities to
         provide confidentiality.
     
     11.2.8  Rekeying Requirements
     
         Due to the high data transfer rates and the amount of data
         involved, an iFCP gateway implementation MUST support the
         capability to rekey each phase 2 security association in time
         intervals as often as every 25 seconds. The iFCP gateway MUST
         provide the capability for forward secrecy in the rekeying process.
     
     11.2.9  Resource Requirements
     
         iFCP gateways and switches will typically be embedded systems
         deployed on racks in air-conditioned data center facilities.  Such
         embedded systems may include hardware chipsets to provide data
     
     
     Monia et-al.               Standards Track                  [Page 72]


     iFCP Revision 6                                      October 2001
     
     
         encryption, authentication, and integrity processing.  Therefore,
         memory and CPU resources are generally not a constraining factor.
     
     11.2.10 Usage Requirments
     
         It must be possible for compliant iFCP implementations to
         administratively disable any and all security mechanisms.  It must
         also be possible to apply different security requirements to
         individual N_PORT login session. Implementations may elect to
         expose such fine level of control through a management interface or
         through interaction with the iSNS.
     
     11.2.11 iSNS Requirements
     
         iSNS [ISNS] is an invariant in all iFCP deployments.  iFCP gateways
         use iSNS for discovery services, and MAY use security policies
         configured in the iSNS database as the basis for algorithm
         negotiation in IKE. The iSNS specification must define mechanisms
         to secure communication between an iFCP gateway and iSNS server(s).
     
     11.3     iFCP Security Design
     
     11.3.1  Enabling Technologies
     
         Applicable technology from IPsec and IKE is defined in the
         following suite of specifications:
     
           [RFC2401] Security Architecture for the Internet Protocol
     
           [RFC2402] IP Authentication Header
     
           [RFC2404] The Use of HMAC-SHA-1-96 Within ESP and AH
     
           [RFC2405] The ESP DES-CBC Cipher Algorithm With Explicit IV
     
           [RFC2406] IP Encapsulating Security Payload
     
           [RFC2407] The Internet IP Security Domain of Interpretation for
                      ISAKMP
     
           [RFC2408] Internet Security Association and Key Management
                      Protocol (ISAKMP)
     
           [RFC2409] The Internet Key Exchange (IKE)
     
           [RFC2410] The NULL Encryption Algorithm and Its use with IPSEC
     
           [RFC2451] The ESP CBC-Mode Cipher Algorithms
     
           [RFC2709] Security Model with Tunnel-mode IPsec for NAT Domains
     
     
     
     Monia et-al.               Standards Track                  [Page 73]


     iFCP Revision 6                                      October 2001
     
     
         The implementation of IPsec and IKE is required according the
         following guidelines.
     
         Support for the IP Encapsulating Security Payload (ESP) [RFC2406]
         is MANDATORY to implement. As stated in [RFC2406], the following
         authentication algorithms MUST be implemented:
     
         a) HMAC with SHA1 [RFC2404]
     
         b) NULL authentication
     
         Contingent on RFC availability, the Advanced Encryption Standard
         specified in [AES] with Extended Cipher Block Chaining [XCBC]
         SHOULD be implemented.
     
         As stated in [RFC2406], the following encryption algorithms MUST be
         implemented:
     
         a) DES in CBC mode [RFC2405]
     
         b) NULL encryption [RFC2410]
     
         c) 3DES in CBC mode [RFC2451] (due to its far greater cipher
            strengths compared to DES).
     
         Contingent on the availability of the appropriate RFCs, AES counter
         mode encryption [AESCTR] SHOULD be implemented.
     
         Finally, it is recommended that DES in CBC mode [RFC2405] SHOULD
         NOT be used due to its inherent weakness.
     
         A conformant iFCP protocol implementation MUST implement IPsec ESP
         in tunnel mode [RFC2709], and SHOULD implement IPsec ESP in
         transport mode [RFC2406].
     
         Regarding key management, [RFC2409] states that pre-shared secret
         key authentication is MANDATORY to implement, whereas signature key
         authentication SHOULD be implemented (see section 11.3.4 regarding
         the use of certificates). [RFC2409] defines the following
         requirement levels for IKE Modes:
     
         Phase-1 Main Mode MUST be implemented
     
         Phase-1 Aggressive Mode SHOULD be implemented
     
         Phase-2 Quick Mode MUST be implemented
     
         Phase-2 Quick Mode with key exchange payload MUST be implemented.
     
         In addition, Phase-1 Main Mode SHOULD NOT be used in conjunction
         with pre-shared keys, due to Main ModeÆs vulnerability to men-in-
         the-middle-attackers when group pre-shared keys are used. It is
     
     Monia et-al.               Standards Track                  [Page 74]


     iFCP Revision 6                                      October 2001
     
     
         also required that Aggressive Mode MUST be implemented as a valid
         alternative to Main Mode. In all Phases and Modes, iFCP support is
         limited to using IP addresses as identities.
     
     11.3.1.1 The Advanced Encryption Standard
     
         The Advanced Encryption Standard described in [AES] is a draft
         standard currently being developed under NIST auspices along with
         XCBC [XCBC] the companion specification for extended cipher block
         chaining.  In addition, [MOSK01] and [WALK01] represent IETF work
         in progress to standardize the AES OCB and CTR modes of operation
         respectively.
     
         While these new technologies may offer significant gains in
         efficiency compared to existing encryption standards, there are
         barriers to consideration due to the lack of approved FIPS
         standards and stableRFCs needed to specify the implementation in an
         IP environment.
     
         Nevertheless, considering the potential value of these
         technologies, AES and XCBC should be implemented when the
         appropriate standards and RFCs are developed.
     
     11.3.2  Use of IKE and IPsec
     
         Each IP address supporting iFCP communication shall be capable of
         establishing one or more Phase-1 IKE Security Associations (SA) to
         other IP addresses configured as peer iFCP gateways, using the IP
         address as the identity. Such a security association may be
         established at a gatewayÆs initialization time, or may be deferred
         until the first TCP connection with security requirements is
         established.
     
         Unlike Phase-1 SAs, a Phase-2 SA maps to an individual TCP
         connection. It protects the setup process of the underlying TCP
         connection and all its subsequent TCP traffic. TCP connections
         protected by the phase 2 SA are either in the unbound state, or are
         bound to a specific N_PORT login session.  The creation of an IKE
         Phase-2 SA may be triggered by a policy rule supplied through a
         management interface, or by N_PORT properties registered with the
         iSNS server. Similarly, the use of Key Exchange payload in Quick
         Mode for perfect forward secrecy may be dictated through a
         management interface or by N_PORT properties registered with the
         iSNS server. This specification allows multiple implementation
         strategies, in which the establishment of an IKE Phase-2 SA occurs
         at different times. Examples of implementation strategies include:
     
         a) The definition of a unique security policy for all TCP
            connections regardless of their bound or unbound state. Thus, an
            unbound TCP connection can be bound to an N_PORT login session
            without the need to incur a new IKE Phase-2 SA.
     
     
     Monia et-al.               Standards Track                  [Page 75]


     iFCP Revision 6                                      October 2001
     
     
         b) Multiple security policies for unbound TCP connections and
            active N_PORT login sessions. In this case, an unbound TCP
            connection becomes bound to an N_PORT login session after
            establishing a new IKE Phase-2 SA matching the new security
            policy for that N_PORT session.
     
         c) No support for a pool of unbound connections. In this case, a
            new IKE Phase-2 SA and TCP connection must be started anytime a
            new N_PORT login session is created.
     
         If the implementation does use unbound TCP connections, then an IKE
         Phase-2 SA MUST protect each of such unbound connections.
     
         As expected, the successful establishment of a IKE Phase-2 SA
         results in the creation of two uni-directional IPsec SAs fully
         qualified by the tuple <SPI, destination address, ESP>.
     
         Should a TCP connection be torn down (as opposed to joining a pool
         of unbound connections), the associated Phase-2 SA SHALL be
         terminated upon expiration of the TIME WAIT timeout value (see
         [RFC793]).
     
         Upon receiving a Phase 1 delete message, an iFCP implementation
         SHALL tear down all the Phase 2 SAs spawned off of that Phase 1 SA,
         followed by the Phase 1 SA itself. Upon receiving a Phase 2 delete
         message, iFCP implementations will behave according to the state of
         the TCP connection protected by the SA in question. If the TCP
         session was terminated (either via FINs or RSTs), then a Phase 2
         delete message SHALL terminate the IPsec SAs and any state formerly
         associated with that Phase 2 SA. If, however, the TCP session is
         maintained, then a Phase 2 delete message shall trigger a new Quick
         Mode exchange.  To minimize the use of SA resources while the TCP
         session is idle, evaluation of the exchange results may be deferred
         until new data is ready to be sent.
     
     11.3.3  Minimal Security Policy
     
         An iFCP implementation MAY be able to administratively disable
         security mechanisms for individual N_PORT login sessions. This
         implies that IKE and IPsec security associations may not be
         established for one or more of such sessions. A configuration of
         this type may be accomplished through a management interface or
         through attributes set in the iSNS server.
     
     11.3.4  Certificates
     
         As an alternative to pre-shared keys, signature key authentication
         is permitted.
     
         [The contents of this section is TBS.]
     
     12.      Quality of Service Considerations
     
     Monia et-al.               Standards Track                  [Page 76]


     iFCP Revision 6                                      October 2001
     
     
     12.1     Minimal requirements
     
         Conforming iFCP protocol implementations SHALL correctly
         communicate gateway-to-gateway even across one or more intervening
         best-effort IP regions. The timings with which such gateway-to
         gateway communication is performed, however, will greatly depend
         upon BER, packet losses, latency, and jitter experienced throughout
         the best-effort IP regions. The higher these parameters, the higher
         will be the gap measured between iFCP observed behaviors and
         baseline iFCP behaviors (i.e., as produced by two iFCP gateways
         directly connected to one another).
     
     12.2     High-assurance
     
         It is expected that many iFCP deployments will benefit from a high
         degree of assurance on the behaviors of the intervening IP regions,
         with resulting high-assurance on the overall end-to-end path, as
         directly experienced by Fibre Channel applications. Such assurance
         on the IP behaviors stems from the intervening IP regions
         supporting standard Quality-of-Service (QoS) techniques, fully
         complementary to iFCP, such as:
     
         a) Congestion avoidance by over-provisioning of the network
     
         b) Integrated Services [RFC1633] QoS
     
         c) .Differentiated Services [RFC2475] QoS
     
         d) .Multi-Protocol Label Switching [RFC3031]
     
         In the most general definition, two iFCP gateways are separated by
         one or more independently managed IP regions, some of which
         implement some of the QoS solutions mentioned above. The IP regions
         with these QoS solutions are said to support Service Level
         Agreements (SLAs). Such agreements finalize requirements on network
         parameters such as bandwidth, loss, latency, jitter, burst length.
         The requirements may be expressed in absolute or relative terms,
         and apply to a unidirectional flow of packets. Depending on the QoS
         techniques available, the dynamic stipulation of a SLA may require
         the iFCP gateway to interact with network ancillary functions such
         admission control and bandwidth brokers (with RSVP or other
         signalling protocols that an IP region may accept).
     
         Due to the fact that Fibre Channel Class 2 and Class 3 do not
         currently support fractional bandwidth guarantees, and that iFCP is
         committed to supporting Fibre Channel semantics, it is impossible
         for an iFCP gateway to autonomously infer bandwidth requirements
         from streaming Fibre Channel traffic. Rather, the requirements on
         bandwidth or other network parameters need to be injected out-of-
         band into a iFCP gateway (or the node that will actually negotiate
         the SLA on the gateway's behalf) through mechanisms outside the
     
     
     Monia et-al.               Standards Track                  [Page 77]


     iFCP Revision 6                                      October 2001
     
     
         scope of this specification (e.g., through a management interface
         into the iFCP gateway).
     
         The administrator of a iFCP gateway MAY thus stipulate a Service
         Level Agreement with the local IP region for one, several, or all
         of an iFCP gateway's TCP sessions used by iFCP. Alternately, this
         responsibility may be delegated to a node downstream. Since one TCP
         connection is dedicated to each N_PORT login session , an
         individual N_PORT to N_PORT flow can enjoy a customized SLA.
     
         To render the best emulation of Fibre Channel possible over IP, it
         is anticipated that typical SLAs will specify a fixed amount of
         bandwidth, null losses, and, to a lesser degree of relevance, low
         latency, and low jitter. For example, an IP region using DiffServ
         QoS may support SLAs of this nature by applying EF DSCPs to the
         iFCP traffic. For the same SLA, another IP region might as well use
         a different DSCP or different QoS techniques alltogether. The way
         different QoS techniques are re-mapped at the edge of different
         intervening IP regions is beyond the scope of this specification.
     
         [00-603] describes a proposal to add fractional bandwidth
         guarantees to Class 2 and 3 (migrating it from Class 4). In such
         proposal, the bandwidth parameters would surface in the FLOGI
         request and accept, and PLOGI request and accept. In this case, it
         will become possible for an iFCP gateway to trap this information
         and autonomously remap it onto the SLA negotiation mechanism
         required by the local IP region, without resorting to out-of-band
         QoS management. Such an in-band QoS mechanism would result in true
         end-to-end provisioning of network resources. Forthcoming revisions
         of this iFCP specification will build upon this new opportunity.
     
     
     
     13.      Author's Addresses
     
     
         Charles Monia                    Franco Travostino
         Rod Mullendore                   Director, Content
         Josh Tseng                       Internetworking Lab,
     
         Nishan Systems                   Victor Firoiu
         3850 North First Street
         San Jose, CA  95134              Nortel Networks
         Phone: 408-519-3986              3 Federal Street
         Email:                           Billerica, MA  01821
         cmonia@nishansystems.com         Phone:  978-288-7708
                                          Email:
                                          travos@nortelnetworks.com
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 78]


     iFCP Revision 6                                      October 2001
     
     
         David Robinson                   Wayland Jeong
         Sun Microsystems                 Troika Networks
         Senior Staff Engineer            Vice President, Hardware
         M/S UNWK16-301                   Engineering
         901 San Antonio Road             2829 Townsgate Road Suite
         Palo Alto, CA  94303-4900        200
         Phone: 510-936-2337               Westlake Village, CA  91361
         Email:                            Phone: 805-370-2614
         David.Robinson@sun.com            Email:
                                           wayland@troikanetworks.com
     
         Rory Bolt                        Paul Rutherford
         Quantum/ATL                      ADIC
         Director, System Design          Vice President, Technology &
         101 Innovation Drive             Software
         Irvine, CA 92612                 1143 Willows Road N.E.
         Phone: 949-856-7760              P.O. Box 97057
         Email: rbolt@atlp.com            Redmond, WA  98073-9757
                                           Phone: 425-881-8004
                                           Email:
                                           paul.rutherford@adic.com
     
         Mark Edwards
         Senior Systems Architect
         Eurologic Development, Ltd.
         4th Floor, Howard House
         Queens Ave, UK.  BS8 1SD
         Phone: +44 (0)117 930 9600
         Email:
         medwards@eurologic.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 79]


     iFCP Revision 6                                      October 2001
     
     
                                    Appendix A
     
     A.       iFCP Support for Fibre Channel Link Services
     
         For reference purposes, this appendix enumerates all the Fibre
         Channel link services and the manner in which each shall be
         processed by an iFCP implementation. The iFCP processing policies
         are defined in section 7.
     
     A.1      Basic Link Services
     
         The basic link services are shown in the following table.
     
                                Basic Link Services
     
             Name              Description             iFCP Policy
             ----              -----------             ----------
     
           ABTS      Abort Sequence                   Transparent
           BA_ACC    Basic Accept                     Transparent
           BA_RJT    Basic Reject                     Transparent
           NOP       No Operation                     Transparent
           PRMT      Preempted                        Rejected
                                                       (Applies to
                                                       Class 1 only)
           RMC       Remove Connection                Rejected
                                                       (Applies to
                                                       Class 1 only)
     
     
     A.2      Link Services Processed Transparently
     
         The following link service requests and responses MUST be processed
         transparently as defined in section 7.
     
                  ELSs Processed Transparently
     
             Name              Description
             ----              -----------
     
           ACC       Accept
           ADVC      Advise Credit
           CSR       Clock Synchronization Request
           CSU       Clock Synchronization Update
           ECHO      Echo
           ESTC      Estimate Credit
           ESTS      Establish Streaming
           FACT      Fabric Activate Alias_ID
           FAN       Fabric Address Notification
           FDACT     Fabric Deactivate Alias_ID
           FDISC     Discover F_Port Service
                     Parameters
     
     Monia et-al.               Standards Track                  [Page 80]


     iFCP Revision 6                                      October 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 iFCP implementation as described in the
         referenced section listed in the table.
     
                          Augmented Link Services
     
             Name              Description             Section
             ----              -----------             -------
     
           ABTX      Abort Exchange                     7.3.1
           ADISC     Discover Address                   7.3.2
     
     Monia et-al.               Standards Track                  [Page 81]


     iFCP Revision 6                                      October 2001
     
     
           ADISC     Discover Address Accept            7.3.3
           ACC
           FARP-     Fibre Channel Address              7.3.4
           REPLY     Resolution Protocol Reply
           FARP-REQ  Fibre Channel Address              7.3.5
                     Resolution Protocol Request
           LOGO      N_PORT Logout                      7.3.6
           PLOGI     Port Login                         7.3.7
           REC       Read Exchange Concise              7.3.8
           REC ACC   Read Exchange Concise Accept       7.3.9
           RES       Read Exchange Status Block         7.3.10
           RES ACC   Read Exchange Status Block         7.3.11
                     Accept
           RLS       Read Link Error Status Block       7.3.12
           RRQ       Reinstate Recovery Qualifier       7.3.14
           RSI       Request Sequence Initiative        7.3.15
           RSS       Read Sequence Status Block         7.3.13
           TPRLO     Third Party Process Logout         7.3.16
           TPRLO     Third Party Process Logout         7.3.17
           ACC       Accept
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 82]


     iFCP Revision 6                                      October 2001
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 83]


     iFCP Revision 6                                      October 2001
     
     
     
     
                                      Appendix B
     
     B.       Performance of The iFCP Session Model
     
         This appendix provides a quantitative analysis of the claim that N
         TCP connections carrying the traffic of all the <N_PORT, N_PORT>
         sessions active between gateways provide significantly higher
         aggregate average throughput than a single TCP connection carrying
         the same <N_PORT, N_PORT> sessions. The analysis shows that the
         difference is proportional to the square of the number of TCP
         sessions, N.
     
         This analyses is based on three fundamental assumptions: (i) all
         the available bandwidth in a link is available to iFCP traffic,
         (ii) the sender has always data ready to send (as is most likely
         the case with a backup application), and (iii) the maximum window
         size at the two TCP ends (i.e., the iFCP gateways) is set to the
         link nominal capacity multiplied by the round-trip-time (so as to
         have the highest chances of saturating the link yet without unduly
         raising buffering requirements at the end nodes). The N^2 factor
         that emerges from this analysis is essentially due to the way TCP
         congestion control reacts to packet losses.
     
     B.1      Relationship of Throughput to Packet Losses
     
         There are several reasons for packet losses: network congestion,
         link errors and network errors. Network congestion is pervasive in
         current IP networks, where the only way to control congestion is
         through dropping packets. Techniques for loss prevention, such as
         traffic engineering, admission control and bandwidth reservation,
         are not widely deployed and hence are not a factor in the behavior
         of existing networks.
     
         Even in a perfectly engineered network, link errors occur. Assuming
         a link error rate equal to that specified for Fibre Channel (10^-
         12) and a 10Gb/s link, there is one error every 100 seconds.
         Network errors also occur with significant frequency in IP
         networks. Jonathan Stone and Craig Partridge recently reported in
         [PART00] that network errors caught by the TCP checksum occur with
         significant frequency. Between one packet in 1100 and one in 32000
         have errors which get past the link CRC and are detected by the
         TCP/IP checksum.
     
         TCP throughput is impacted by each packet loss. Following TCP's
         congestion control algorithm (supported by the Tahoe, Reno, New-
         Reno, and SACK implementations (see [RFC2018] and [RFC2883]), each
         packet loss results in the TCP sender's congestion window being
         reduced to half of its current value, and therefore (assuming
         constant Round Trip Time), TCP's throughput is halved. After that,
         the window increases by roughly one packet every two Round Trip
     
     Monia et-al.               Standards Track                  [Page 84]


     iFCP Revision 6                                      October 2001
     
     
         Times (assuming the widely-used Delayed-Acknowledgement algorithm).
         The temporary decrease in TCP's rate translates into a missed
         opportunity to transmit a given amount of data. As we show in the
         following Background section, for N storage connections sharing an
         IP "pipe" of rate E, the amount of data missing the opportunity to
         be transmitted due to a packet loss is:
     
                            D(N) = E^2/(N^2)*RTT^2/(256*M)
     
         where RTT = Round Trip Time, M = packet size.
     
         For example, for a set of N=100 connections totaling E=10Gb/s,
         RTT=10ms, M=1500B, the data not transmitted in time due to a packet
         loss is D(N)=2.6MB. For the same set transported over one TCP
         session, the data not sent in time is D(1)= 26GB, a 10,000 fold
         increase. The time interval for TCP to recover its sending rate to
         its initial value after a packet loss is I(N)= 0.833 seconds in the
         case N TCP connections, and I(1)=83.3seconds in the case of a
         single TCP connection. Observe that in the latter case, the time to
         recover its rate, I(1)=83.3s, is of the same order of magnitude as
         the time between two packet losses due exclusively to a link Bit
         Error Rate of 10^-12. In other words, a packet loss occurs almost
         immediately after TCP has recovered its rate.
     
         This means that a single TCP connection delivers on average about
         3/4 of the required 10Gb/s rate, since 1/4 of the rate is lost
         during the time the TCP rate is increasing linearly from 1/2 to
         full rate. (More precisely, the effective rate is 8.27Gb/s because
         1/4 of the rate is lost during 83.3s, and the time between two
         errors is now 120.825s due to a decreased sending rate). By
         comparison, N TCP connections deliver approximately 9.99979Gb/s
         (i.e., lost 1/4 of one TCP full rate of 100Mb/s during 0.833s out
         of a 100s interval).
     
         If the impact of TCP checksum errors is also considered, the TCP
         sending rate is limited to an average of (8M/RTT)sqrt(3/4p), where
         p is the probability of packet loss (see [PADHYE00] for details).
         For M=1500, RTT=10ms and p=1/32000, TCP throughput is about
         240Mb/s. For p=1/1100, maximum TCP throughput is 34.4Mb/s.
         Therefore, to fill a 10Gb/s line, about 42 simultaneous TCP flows
         are required (in the case where p=1/32000) or 291 TCP flows (in the
         case where p=1/1100).
     
         Practically, for these reasons the iFCP protocol supports
         combinations of M <N_PORT, N_PORT> tuples using N TCP connections,
         with M, N >= 1, and with an individual  <N_PORT, N_PORT> tuple
         using at most one TCP connection (thus M >= N).
     
     B.2      Background.
     
         For a TCP session to sustain a rate of C bits/second, the TCP's
         maximum congestion window W (measured in number of packets) has to
     
     Monia et-al.               Standards Track                  [Page 85]


     iFCP Revision 6                                      October 2001
     
     
         be at least W0=RTT*C/(8*M) where RTT = Round Trip Time in seconds,
         M = packet size in Bytes. The following analyses assumes W=W0.
         Later, the problems with the alternative W>W0 are discussed.
     
         The time needed by the TCP sender to recover from a single packet
         loss and have its sending rate reach the previous C value is
     
                        I = 2*RTT*W/2 = RTT*W = RTT^2*C/(8*M).
     
         The total amount of data (in Bytes) missing the opportunity to be
         transmitted in this time interval I is:
     
                           D = C/8*I/4 = C^2*RTT^2/(256*M)
     
         Consider a set of <N_PORT, N_PORT> tuples sharing an IP "pipe" of
         rate E to be transported in N TCP sessions. Assuming all
         connections are processed equally, each TCP session sends at a rate
         of E/N. One packet loss impacts only one TCP session, and thus, the
         total amount of data missing the opportunity to be transmitted due
         to a packet loss is
     
                           D(N) = E^2/(N^2)*RTT^2/(256*M).
     
         On the other hand, if the same set of <N_PORT, N_PORT> tuples
         sharing an IP "pipe" of rate E is transported in one TCP session
         only, the total amount of data losing the opportunity to be
         transmitted due to a packet loss is
     
                         D(1) = E^2*RTT^2/(256*M) = D(N)*N^2.
     
         The impact of packet losses on the single-TCP solution can be
         reduced by configuring the maximum congestion window to be larger
         than the bandwidth*delay product, W>W0.  But in this case, only W0
         packets can be in transit on the line, while the rest (up to the
         current window size) need to be stored in a queue at the line's
         ingress. In order to provide full line rate utilization assuming
         periodic losses, the maximum congestion window should be at least
         2*W0, due to TCP's congestion
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 86]


     iFCP Revision 6                                      October 2001
     
     
     
     
     Full Copyright Statement
     
     
         "Copyright (C) The Internet Society, October 2001. All Rights
         Reserved. This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in part,
         without restriction of any kind, provided that the above copyright
         notice and this paragraph are included on all such copies and
         derivative works. However, this document itself may not be modified
         in any way, such as by removing the copyright notice or references
         to the Internet Society or other Internet organizations, except as
         needed for the purpose of developing Internet standards in which
         case the procedures for copyrights defined in the Internet
         Standards process must be followed, or as required to translate it
         into languages other than English.
     
         The limited permissions granted above are perpetual and will not be
         revoked by the Internet Society or its successors or assigns.
     
         This document and the information contained herein is provided on
         an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
         IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
         THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
         WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 87]


     iFCP Revision 6                                      October 2001
     
     
     
     
     
                                    References
     
        [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.
     
        [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997
     
        [FC-FS] dpANS X3.XXX-200X, "Fibre Channel Framing and Signaling
           Interface", Revision 1.2, NCITS Project 1331-D, February 2001
     
        [FC-SW2] dpANS X3.XXX-2000X, "Fibre Channel Switch Fabric -2 (FC-
           SW2)", revision 5.2, NCITS Project 1305-D, May 2001
     
        [FC-GS3] dpANS X3.XXX-200X, "Fibre Channel Generic Services -3 (FC-
           GS3)", revision 7.01, NCITS Project 1356-D, November 2000
     
        [FC-FLA] TR-20-199X, "Fibre Channel Fabric Loop Attachment (FC-
           FLA)", revision 2.7, NCITS Project 1235-D, August 1997
     
        [Kembel] Kembel, R., "Fibre Channel, A Comprehensive Introduction",
           Northwest Learning Associates Inc., 2000, ISBN 0-931836-84-0
     
         Kembel, R., "The Fibre Channel Consultant, Arbitrated Loop", Robert
         W. Kembel, Northwest Learning Associates, 2000, ISBN 0-931836-84-0
     
        [RFC793] Postel, J., "Transmission Control Protocol", RFC 793,
           September, 1981
     
        [RFC1122] Braden, S., "Requirements for Internet Hosts --
           Communication Layers", RFC 1122, October 1989
     
        [RFC896] Nagel, J., "Congestion Control in IP/TCP Networks", RFC
           896, January 1984
     
        [RFC1323] Jacobsen, V., et-al., "TCP Extensions for High
           Performance", RFC 1323, May, 1992
     
     
     
        [RFC2018] Mathis, M., et-al., TCP Selective Acknowledgement
           Options", RFC 2018, October 1996
     
        [RFC2883] Floyd, S., et-al., An Extension to the Selective
           Acknowledge (SACK) Option for TCP", RFC 2883, July 2000
     
        [RFC2581] Allman, M., et-al., "TCP Congestion Control", RFC 2581,
           April 1991
     
     
     Monia et-al.               Standards Track                  [Page 88]


     iFCP Revision 6                                      October 2001
     
     
     
        [RFC3168] Ramakrishnan, K., et-al., "The Addition of Explicit
           Congestion Notification (ECN) to IP", RFC 3168, September 2001
     
        [ENCAP] Weber, et-al., "FC Frame Encapsulation", draft-ietf-ips-
           fcencapsulation-01.txt, May 2001
     
        [RFC2030] Mills, D., RFC 2030, "Simple Network Time Protocol (SNTP)"
           Version 4, October 1996
     
        [RFC2625] Rajagopal, M., et-al., RFC 2625, "IP and ARP over Fibre
           Channel", June 1999
     
        [ISNS] Tseng, J., et-al., "iSNS Internet Storage Name Service",
           draft-ietf-ips-04.txt, July 2001
     
        [RFC791] Postel, J., RFC 791, "The Internet Protocol", September
           1981
     
        [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
           2131, March 1997
     
        [RFC2401] Kent, S., Atkinson, R., RFC 2401, "Security Architecture
           for the Internet Protocol", November 1998
     
        [RFC2402] Kent, S., Atkinson, R., RFC 2402, "IP Authentication
           Header", November 1998
     
        [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within
           ESP and AH", RFC 2404, November 1998
     
        [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher
           Algorithm With Explicit IV" RFC 2405, November 1998
     
        [RFC2406] Kent, S., Atkinson, R., RFC 2406, "Encapsulating Security
           Protocol", November 1998
     
        [RFC2407] Piper, D., RFC 2407, " The Internet IP Security Domain of
           Interpretation for ISAKMP", November 1998
     
        [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., RFC
           2408, "Internet Security Association and Key Management Protocol
           (ISAKMP)" November 1998
     
        [RFC2409] D. Harkins, D. Carrel, RFC 2409, "The Internet Key
           Exchange (IKE)",  November 1998
     
        [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and
           Its use with IPSEC", RFC 2410, November 1998
     
     
     
     
     Monia et-al.               Standards Track                  [Page 89]


     iFCP Revision 6                                      October 2001
     
     
     
        [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher
           Algorithms", RFC 2451, November 1998
     
        [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
           NAT Domains", RFC 2709, October 1999
     
        [RFC2404] Glenn, R., Madson, C., "The Use of HMAC-SHA-1-96 Within
           ESP and AH", RFC 2404, November 1998
     
        [AES] FIPS Publication XXX, "Advanced Encyption Standard (AES)",
           Draft, 2001, Available from
           http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
     
        [XCBC] Black, J., Rogaway, P., "A Suggestion for Handling Arbitrary
           Length Messages with the CBC MAC". Available from
           http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc-
           mac/xcbc-mac-spec.pdf
     
        [RFC2405] Doraswamy, N., Madson, C., "The ESP DES-CBC Cipher
           Algorithm With Explicit IV" RFC 2405, November 1998
     
        [RFC2410] Glenn, R., Kent, S., "The NULL Encryption Algorithm and
           Its use with IPSEC", RFC 2410, November 1998
     
        [RFC2451] Adams, R., Pereira, R., "The ESP CBC-Mode Cipher
           Algorithms", RFC 2451, November 1998
     
        [AESCTR] Lipmaa, H., Rogaway, P., Wagner, D., "CTR-Mode Encryption",
           2001. Available from
           http://csrc.nist.gov/encryption/modes/proposedmodes/ctr/ctr-
           spec.pdf
     
        [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
           NAT Domains", RFC 2709, October 1999
     
        [AES] FIPS Publication XXX, "Advanced Encyption Standard (AES)",
           Draft, 2001, Available from
           http://csrc.nist.gov/publications/drafts/dfips-AES.pdf
     
        [XCBC] Black, J., Rogaway, P., "A Suggestion for Handling Arbitrary
           Length Messages with the CBC MAC". Available from
           http://csrc.nist.gov/encryption/modes/proposedmodes/xcbc-
           mac/xcbc-mac-spec.pdf
     
        [MOSK01] Moskowitz, R., Walker, J., "The AES128 OCB Mode of
           Operation and Its Use with IPsec", Internet draft (work in
           progress), draft-moskowitz-aes128-ocb-00.txt, September 2001.
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 90]


     iFCP Revision 6                                      October 2001
     
     
     
        [WALK01] Walker, J., Moskowitz, R., "The AES128 CTR Mode of
           Operation and Its Use with IPsec", Internet draft (work in
           progress), draft-moskowitz-aes128-ctr-00.txt, September 2001.
     
        [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services
           in the Internet Architecture: an Overview", RFC 1633, June 1994
     
        [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
           and W. Weiss, "An Architecture for Differentiated Services", RFC
           2475, December 1998
     
        [RFC3031] Rosen, E., Viswanathan, A. and Callon, R., "Multi-Protocol
           Label Switching Architecture", RFC 3031, January 2001
     
        [00-603] Stephens, G., Warden, G. T11/00-603, "Fractional Bandwidth,
           Class 2, Class 3", October 2000
     
        [PART00] Partridge, C and J. Stone, "When The CRC and TCP Checksum
           Disagree", ACM SIGCOMM, September 2000
     
        [PADHYE00] Padhye, J, Firoiu, D, Kurose, J., "Modeling TCP Reno
           Performance: A Simple Model and its Empirical Validation"
           IEEE/ACM Transactions on Networking, April 2000
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     Monia et-al.               Standards Track                  [Page 91]
     

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/