tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4172


iFCP - A Protocol for Internet Fibre Channel Storage Networking

Part 2 of 4, p. 18 to 47
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 18 
4.  The iFCP Network Model

   The iFCP protocol enables the implementation of fibre channel fabric
   functionality on an IP network in which IP components and technology
   replace the fibre channel switching and routing infrastructure
   described in Section 3.2.

   The example of Figure 6 shows a fibre channel network with attached
   devices.  Each device accesses the network through an N_PORT
   connected to an interface whose behavior is specified in [FC-FS] or
   [FC-AL2].  In this case, the N_PORT represents any of the variants
   described in Section 3.2.  The interface to the fabric may be an

   Within the fibre channel device domain, addressable entities consist
   of other N_PORTs and fibre channel devices internal to the network
   that perform the fabric services defined in [FC-GS3].

Top      Up      ToC       Page 19 
                      Fibre Channel Network
                  +--------+        +--------+
                  |  FC    |        |  FC    |
                  | Device |        | Device |
                  |........| FC     |........| Fibre Channel
                  | N_PORT |<......>| N_PORT | Device Domain
                  +---+----+ Traffic+----+---+       ^
                      |                  |           |
                  +---+----+        +----+---+       |
                  | Fabric |        | Fabric |       |
                  | Port   |        | Port   |       |
                  |       FC Network &       |       |
                  |     Fabric Services      |       v
                  |                          | Fibre Channel
                  +--------------------------+ Network Domain

                    Figure 6. A Fibre Channel Network

            Gateway Region                   Gateway Region
       +--------+  +--------+           +--------+  +--------+
       |   FC   |  |  FC    |           |   FC   |  |   FC   |
       | Device |  | Device |           | Device |  | Device |  Fibre
       |........|  |........| FC        |........|  |........|  Channel
       | N_PORT |  | N_PORT |<.........>| N_PORT |  | N_PORT |  Device
       +---+----+  +---+----+ Traffic   +----+---+  +----+---+  Domain
           |           |                     |           |         ^
       +---+----+  +---+----+           +----+---+  +----+---+     |
       | F_PORT |  | F_PORT |           | F_PORT |  | F_PORT |     |
       |    iFCP Layer      |<--------->|     iFCP Layer     |     |
       |....................|     ^     |....................|     |
       |     iFCP Portal    |     |     |     iFCP Portal    |     v
       +--------+-----------+     |     +----------+---------+    IP
            iFCP|Gateway      Control          iFCP|Gateway      Network
                |              Data                |
                |                                  |
                |                                  |
                |<------Encapsulated Frames------->|
                |      +------------------+        |
                |      |                  |        |
                +------+    IP Network    +--------+
                       |                  |

                     Figure 7. An iFCP Fabric Example

Top      Up      ToC       Page 20 
   One example of an equivalent iFCP fabric is shown in Figure 7.  The
   fabric consists of two gateway regions, each accessed by a single
   iFCP gateway.

   Each gateway contains two standards-compliant F_PORTs and an iFCP
   Portal for attachment to the IP network.  Fibre channel devices in
   the region are those locally connected to the iFCP fabric through the
   gateway fabric ports.

   Looking into the fabric port, the gateway appears as a fibre channel
   switch element.  At this interface, remote N_PORTs are presented as
   fabric-attached devices.  Conversely, on the IP network side, the
   gateway presents each locally connected N_PORT as a logical fibre
   channel device.

   Extrapolating to the general case, each gateway region behaves like
   an autonomous system whose configuration is invisible to the IP
   network and other gateway regions.  Consequently, in addition to the
   F_PORT shown in the example, a gateway implementation may
   transparently support the following fibre channel interfaces:

      Inter-Switch Link -- A fibre channel switch-to-switch interface
      used to access a region containing fibre channel switch elements.
      An implementation may support the E_PORT defined by [FC-SW2] or
      one of the proprietary interfaces provided by various fibre
      channel switch vendors.  In this case, the gateway acts as a
      border switch connecting the gateway region to the IP network.

      FL_PORT -- An interface that provides fabric access for loop-
      attached fibre channel devices, as specified in [FC-FLA].

      L_PORT -- An interface through which a gateway may emulate the
      fibre channel loop environment specified in [FC-AL2].  As
      discussed in appendix B, the gateway presents remotely accessed
      N_PORTS as loop-attached devices.

   The manner in which these interfaces are provided by a gateway is
   implementation specific and therefore beyond the scope of this

   Although each region is connected to the IP network through one
   gateway, a region may incorporate multiple gateways for added
   performance and fault tolerance if the following conditions are met:

   a) The gateways MUST coordinate the assignment of N_PORT IDs and
      aliases so that each N_PORT has one and only one address.

Top      Up      ToC       Page 21 
   b) All iFCP traffic between a given remote and local N_PORT pair MUST
      flow through the same iFCP session (see Section 5.2.1).  However,
      iFCP sessions to a given remotely attached N_PORT need not
      traverse the same gateway.

   Coordinating address assignments and managing the flow of traffic is
   implementation specific and outside the scope of this specification.

4.1.  iFCP Transport Services

   N_PORT to N_PORT communications that traverse a TCP/IP network
   require the intervention of the iFCP layer within the gateway.  This
   consists of the following operations:

   a) Execution of the frame-addressing and -mapping functions described
      in Section 4.4.

   b) Encapsulation of fibre channel frames for injection into the
      TCP/IP network and de-encapsulation of fibre channel frames
      received from the TCP/IP network.

   c) Establishment of an iFCP session in response to a PLOGI directed
      to a remote device.

   Section 4.4 discusses the iFCP frame-addressing mechanism and the way
   that it is used to achieve communications transparency between

4.1.1.  Fibre Channel Transport Services Supported by iFCP

   An iFCP fabric supports Class 2 and Class 3 fibre channel transport
   services, as specified in [FC-FS].  An iFCP fabric does not support
   Class 4, Class 6, or Class 1 (dedicated connection) service.  An
   N_PORT discovers the classes of transport services supported by the
   fabric during fabric login.

4.2.  iFCP Device Discovery and Configuration Management

   An iFCP implementation performs device discovery and iFCP fabric
   management through the Internet Storage Name Service defined in
   [ISNS].  Access to an iSNS server is required to perform the
   following functions:

   a) Emulate the services provided by the fibre channel name server
      described in Section 3.3.1, including a mechanism for
      asynchronously notifying an N_PORT of changes in the iFCP fabric

Top      Up      ToC       Page 22 
   b) Aggregate gateways into iFCP fabrics for interoperation.

   c) Segment an iFCP fabric into fibre channel zones through the
      definition and management of device discovery scopes, referred to
      as 'discovery domains'.

   d) Store and distribute security policies, as described in Section

   e) Implementation of the fibre channel broadcast mechanism.

4.3.  iFCP Fabric Properties

   A collection of iFCP gateways may be configured for interoperation as
   either a bounded or an unbounded iFCP fabric.

   Gateways in a bounded iFCP fabric operate in address transparent
   mode, as described in Section 4.5.  In this mode, the scope of a
   fibre channel N_PORT address is fabric-wide and is derived from
   domain IDs issued by the iSNS server from a common pool.  As
   discussed in Section 4.3.2, the maximum number of domain IDs allowed
   by the fibre channel limits the configuration of a bounded iFCP

   Gateways in an unbounded iFCP fabric operate in address translation
   mode as described in Section 4.6.  In this mode, the scope of an
   N_PORT address is local to a gateway region.  For fibre channel
   traffic between regions, the translation of frame-embedded N_PORT
   addresses is performed by the gateway.  As discussed below, the
   number of switch elements and gateways in an unbounded iFCP fabric
   may exceed the limits of a conventional fibre channel fabric.

   All iFCP gateways MUST support unbounded iFCP fabrics.  Support for
   bounded iFCP fabrics is OPTIONAL.

   The decision to support bounded iFCP fabrics in a gateway
   implementation depends on the address transparency, configuration
   scalability, and fault tolerance considerations given in the
   following sections.

4.3.1.  Address Transparency

   Although iFCP gateways in an unbounded fabric will convert N_PORT
   addresses in the frame header and payload of standard link service
   messages, a gateway cannot convert such addresses in the payload of
   vendor- or user-specific fibre channel frame traffic.

Top      Up      ToC       Page 23 
   Consequently, although both bounded and unbounded iFCP fabrics
   support standards-compliant FC-4 protocol implementations and link
   services used by mainstream fibre channel applications, a bounded
   iFCP fabric may also support vendor- or user-specific protocol and
   link service implementations that carry N_PORT IDs in the frame

4.3.2.  Configuration Scalability

   The scalability limits of a bounded fabric configuration are a
   consequence of the fibre channel address allocation policy discussed
   in Section 3.7.1.  As noted, a bounded iFCP fabric using this address
   allocation scheme is limited to a combined total of 239 gateways and
   fibre channel switch elements.  As the system expands, the network
   may grow to include many switch elements and gateways, each of which
   controls a small number of devices.  In this case, the limitation in
   switch and gateway count may become a barrier to extending and fully
   integrating the storage network.

   Since N_PORT fibre channel addresses in an unbounded iFCP fabric are
   not fabric-wide, the limits imposed by fibre channel address
   allocation only apply within the gateway region.  Across regions, the
   number of iFCP gateways, fibre channel devices, and switch elements
   that may be internetworked are not constrained by these limits.  In
   exchange for improved scalability, however, implementations must
   consider the incremental overhead of address conversion, as well as
   the address transparency issues discussed in Section 4.3.1.

4.3.3.  Fault Tolerance

   In a bounded iFCP fabric, address reassignment caused by a fault or
   reconfiguration, such as the addition of a new gateway region, may
   cascade to other regions, causing fabric-wide disruption as new
   N_PORT addresses are assigned.  Furthermore, before a new gateway can
   be merged into the fabric, its iSNS server must be slaved to the iSNS
   server in the bounded fabric to centralize the issuance of domain
   IDs.  In an unbounded iFCP fabric, coordinating the iSNS databases
   requires only that the iSNS servers exchange client attributes with
   one another.

   A bounded iFCP fabric also has an increased dependency on the
   availability of the iSNS server, which must act as the central
   address assignment authority.  If connectivity with the server is
   lost, new DOMAIN_ID values cannot be automatically allocated as
   gateways and fibre channel switch elements are added.

Top      Up      ToC       Page 24 
4.4.  The iFCP N_PORT Address Model

   This section discusses iFCP extensions to the fibre channel
   addressing model of Section 3.7.1, which are required for the
   transparent routing of frames between locally and remotely attached

   In the iFCP protocol, an N_PORT is represented by the following

   a) A 24-bit N_PORT ID.  The fibre channel N_PORT address of a locally
      attached device.  Depending on the gateway addressing mode, the
      scope is local either to a region or to a bounded iFCP fabric.  In
      either mode, communications between N_PORTs in the same gateway
      region use the N_PORT ID.

   b) A 24-bit N_PORT alias.  The fibre channel N_PORT address assigned
      by each gateway operating in address translation mode to identify
      a remotely attached N_PORT.  Frame traffic is intercepted by an
      iFCP gateway and directed to a remotely attached N_PORT by means
      of the N_PORT alias.  The address assigned by each gateway is
      unique within the scope of the gateway region.

   c) An N_PORT network address.  A tuple consisting of the gateway IP
      address, TCP port number, and N_PORT ID.  The N_PORT network
      address identifies the source and destination N_PORTs for fibre
      channel traffic on the IP network.

   To provide transparent communications between a remote and local
   N_PORT, a gateway MUST maintain an iFCP session descriptor (see
   Section reflecting the association between the fibre channel
   address representing the remote N_PORT and the remote device's N_PORT
   network address.  To establish this association, the iFCP gateway
   assigns and manages fibre channel N_PORT fabric addresses as
   described in the following paragraphs.

   In an iFCP fabric, the iFCP gateway performs the address assignment
   and frame routing functions of an FC switch element.  Unlike an FC
   switch, however, an iFCP gateway must also direct frames to external
   devices attached to remote gateways on the IP network.

   In order to be transparent to FC devices, the gateway must deliver
   such frames using only the 24-bit destination address in the frame
   header.  By exploiting its control of address allocation and access
   to frame traffic entering or leaving the gateway region, the gateway
   is able to achieve the necessary transparency.

Top      Up      ToC       Page 25 
   N_PORT addresses within a gateway region may be allocated in one of
   two ways:

   a) Address Translation Mode - A mode of N_PORT address assignment in
      which the scope of an N_PORT fibre channel address is unique to
      the gateway region.  The address of a remote device is represented
      in that gateway region by its gateway-assigned N_PORT alias.

   b) Address Transparent Mode - A mode of N_PORT address assignment in
      which the scope of an N_PORT fibre channel address is unique
      across the set of gateway regions comprising a bounded iFCP

   In address transparent mode, gateways within a bounded fabric
   cooperate in the assignment of addresses to locally attached N_PORTs.
   Each gateway in control of a region is responsible for obtaining and
   distributing unique domain IDs from the address assignment authority,
   as described in Section 4.5.1.  Consequently, within the scope of a
   bounded fabric, the address of each N_PORT is unique.  For that
   reason, gateway-assigned aliases are not required for representing
   remote N_PORTs.

   All iFCP implementations MUST support operations in address
   translation mode.  Implementation of address transparent mode is
   OPTIONAL but, of course, must be provided if bounded iFCP fabric
   configurations are to be supported.

   The mode of gateway operation is settable in an implementation-
   specific manner.  The implementation MUST NOT:

   a) allow the mode to be changed after the gateway begins processing
      fibre channel frame traffic,

   b) permit operation in more than one mode at a time, or

   c) establish an iFCP session with a gateway that is not in the same

4.5.  Operation in Address Transparent Mode

   The following considerations and requirements apply to this mode of

   a) iFCP gateways in address transparent mode will not interoperate
      with iFCP gateways that are not in address transparent mode.

Top      Up      ToC       Page 26 
   b) When interoperating with locally attached fibre channel switch
      elements, each iFCP gateway MUST assume control of DOMAIN_ID
      assignments in accordance with the appropriate fibre channel
      standard or vendor-specific protocol specification.  As described
      in Section 4.5.1, DOMAIN_ID values that are assigned to FC
      switches internal to the gateway region must be issued by the iSNS

   c) When operating in address transparent Mode, fibre channel address
      translation SHALL NOT take place.

   When operating in address transparent mode, however, the gateway MUST
   establish and maintain the context of each iFCP session in accordance
   with Section 5.2.2.

4.5.1.  Transparent Mode Domain ID Management

   As described in Section 4.5, each gateway and fibre channel switch in
   a bounded iFCP fabric has a unique domain ID.  In a gateway region
   containing fibre channel switch elements, each element obtains a
   domain ID by querying the principal switch as described in [FC-SW2]
   -- in this case, the iFCP gateway itself.  The gateway, in turn,
   obtains domain IDs on demand from the iSNS name server acting as the
   central address allocation authority.  In effect, the iSNS server
   assumes the role of principal switch for the bounded fabric.  In that
   case, the iSNS database contains:

   a) The definition for one or more bounded iFCP fabrics, and

   b) For each bounded fabric, a worldwide-unique name identifying each
      gateway in the fabric.  A gateway in address transparent mode MUST
      reside in one, and only one, bounded fabric.

   As the Principal Switch within the gateway region, an iFCP gateway in
   address transparent mode SHALL obtain domain IDs for use in the
   gateway region by issuing the appropriate iSNS query, using its
   worldwide name.

4.5.2.  Incompatibility with Address Translation Mode

   Except for the session control frames specified in Section 6, iFCP
   gateways in address transparent mode SHALL NOT originate or accept
   frames that do not have the TRP bit set to one in the iFCP flags
   field of the encapsulation header (see Section 5.3.1).  The iFCP
   gateway SHALL immediately terminate all iFCP sessions with the iFCP
   gateway from which it receives such frames.

Top      Up      ToC       Page 27 
4.6.  Operation in Address Translation Mode

   This section describes the process for managing the assignment of
   addresses within a gateway region that is part of an unbounded iFCP
   fabric, including the modification of FC frame addresses embedded in
   the frame header for frames sent and received from remotely attached

   As described in Section 4.4, the scope of N_PORT addresses in this
   mode is local to the gateway region.  A principal switch within the
   gateway region, possibly the iFCP gateway itself, oversees the
   assignment of such addresses, in accordance with the rules specified
   in [FC-FS] and [FC-FLA].

   The assignment of N_PORT addresses to locally attached devices is
   controlled by the switch element to which the device is connected.

   The assignment of N_PORT addresses for remotely attached devices is
   controlled by the gateway by which the remote device is accessed.  In
   this case, the gateway MUST assign a locally significant N_PORT alias
   to be used in place of the N_PORT ID assigned by the remote gateway.
   The N_PORT alias is assigned during device discovery, as described in

   To perform address conversion and to enable the appropriate routing,
   the gateway MUST establish an iFCP session and generate the
   information required to map each N_PORT alias to the appropriate
   TCP/IP connection context and N_PORT ID of the remotely accessed
   N_PORT.  These mappings are created and updated by means specified in
   Section  As described in that section, the required mapping
   information is represented by the iFCP session descriptor reproduced
   in Figure 8.

                      |TCP Connection Context |
                      |  Local N_PORT ID      |
                      |  Remote N_PORT ID     |
                      |  Remote N_PORT Alias  |

      Figure 8. iFCP Session Descriptor (from Section

Top      Up      ToC       Page 28 
   Except for frames comprising special link service messages (see
   Section 7.2), outbound frames are encapsulated and sent without
   modification.  Address translation is deferred until receipt from the
   IP network, as specified in Section 4.6.1.

4.6.1.  Inbound Frame Address Translation

   For inbound frames received from the IP network, the receiving
   gateway SHALL reference the session descriptor to fill in the D_ID
   field with the destination N_PORT ID and the S_ID field with the
   N_PORT alias it assigned.  The translation process for inbound frames
   is shown in Figure 9.

        Network Format of Inbound Frame
   +--------------------------------------------+            iFCP
   |          FC Encapsulation Header           |           Session
   +--------------------------------------------+           Descriptor
   |            SOF Delimiter Word              |              |
   +========+===================================+              V
   |        |         D_ID Field                |     +--------+-----+
   +--------+-----------------------------------+     | Lookup source|
   |        |         S_ID Field                |     | N_PORT Alias |
   +--------+-----------------------------------+     | and          |
   |        Control Information, Payload,       |     | destination  |
   |        and FC CRC                          |     | N_PORT ID    |
   |                                            |     +--------+-----+
   |                                            |              |
   |                                            |              |
   +============================================+              |
   |         EOF Delimiter Word                 |              |
   +--------------------------------------------+              |
   Frame after Address Translation and De-encapsulation        |
   +--------+-----------------------------------+              |
   |        |  Destination N_PORT ID            |<-------------+
   +--------+-----------------------------------+              |
   |        |  Source N_PORT Alias              |<-------------+
   |                                            |
   |        Control information, Payload,       |
   |        and FC CRC                          |

            Figure 9. Inbound Frame Address Translation

Top      Up      ToC       Page 29 
   The receiving gateway SHALL consider the contents of the S_ID and
   D_ID fields to be undefined when received.  After replacing these
   fields, the gateway MUST recalculate the FC CRC.

4.6.2.  Incompatibility with Address Transparent Mode

   iFCP gateways in address translation mode SHALL NOT originate or
   accept frames that have the TRP bit set to one in the iFCP flags
   field of the encapsulation header.  The iFCP gateway SHALL
   immediately abort all iFCP sessions with the iFCP gateway from which
   it receives frames such as those described in Section 5.2.3.

5.  iFCP Protocol

5.1.  Overview

5.1.1.  iFCP Transport Services

   The main function of the iFCP protocol layer is to transport fibre
   channel frame images between locally and remotely attached N_PORTs.

   When transporting frames to a remote N_PORT, the iFCP layer
   encapsulates and routes the fibre channel frames comprising each
   fibre channel Information Unit via a predetermined TCP connection for
   transport across the IP network.

   When receiving fibre channel frame images from the IP network, the
   iFCP layer de-encapsulates and delivers each frame to the appropriate

   The iFCP layer processes the following types of traffic:

   a) FC-4 frame images associated with a fibre channel application

   b) FC-2 frames comprising fibre channel link service requests and

   c) Fibre channel broadcast frames.

   d) iFCP control messages required to set up, manage, or terminate an
      iFCP session.

   For FC-4 N_PORT traffic and most FC-2 messages, the iFCP layer never
   interprets the contents of the frame payload.

   iFCP does interpret and process iFCP control messages and certain
   link service messages, as described in Section 5.1.2.

Top      Up      ToC       Page 30 
5.1.2.  iFCP Support for Link Services

   iFCP must intervene in the processing of those fibre channel link
   service messages that contain N_PORT addresses in the message payload
   or that require other special handling, such as an N_PORT login
   request (PLOGI).

   In the former case, an iFCP gateway operating in address translation
   mode MUST supplement the payload with additional information that
   enables the receiving gateway to convert such embedded N_PORT
   addresses to its frame of reference.

   For out bound fibre channel frames comprising such a link service,
   the iFCP layer creates the supplemental information based on frame
   content, modifies the frame payload, and then transmits the resulting
   fibre channel frame with supplemental data through the appropriate
   TCP connection.

   For incoming iFCP frames containing supplemented fibre channel link
   service frames, iFCP must interpret the frame, including any
   supplemental information, modify the frame content, and forward the
   resulting frame to the destination N_PORT for further processing.

   Section 7.1 describes the processing of these link service messages
   in detail.

5.2.  TCP Stream Transport of iFCP Frames

5.2.1.  iFCP Session Model

   An iFCP session consists of the pair of N_PORTs comprising the
   session endpoints joined by a single TCP/IP connection.  No more than
   one iFCP session SHALL exist between a given pair of N_PORTs.

   An N_PORT is identified by its network address, consisting of:

   a) the N_PORT ID assigned by the gateway to which the N_PORT is
      locally attached, and

   b) the iFCP Portal address, consisting of its IP address and TCP port

   Because 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

Top      Up      ToC       Page 31 
   is a TCP connection that is not actively supporting an iFCP session.
   A gateway implementation MAY establish a pool of unbound connections
   to reduce the session setup time.  Such pre-existing TCP connections
   between iFCP Portals remain unbound and uncommitted until allocated
   to an iFCP session through a CBIND message (see Section 6.1).

   When the iFCP layer creates an iFCP session, it may select an
   existing unbound TCP connection or establish a new TCP connection and
   send the CBIND message down that TCP connection.  This allocates the
   TCP connection to that iFCP session.

5.2.2.  iFCP Session Management

   This section describes the protocols and data structures required to
   establish and terminate an iFCP session.  The Remote N_PORT Descriptor

   In order to establish an iFCP session, an iFCP gateway MUST maintain
   information allowing it to locate a remotely attached N_PORT.  For
   explanatory purposes, such information is assumed to reside in a
   descriptor with the format shown in Figure 10.

                    |  N_PORT Worldwide Unique Name  |
                    |  iFCP Portal Address           |
                    |  N_PORT ID of Remote N_PORT    |
                    |  N_PORT Alias                  |

                    Figure 10. Remote N_PORT Descriptor

   Each descriptor aggregates the following information about a remotely
   attached N_PORT:

      N_PORT Worldwide Unique Name -- 64-bit N_PORT worldwide name as
      specified in [FC-FS].  A Remote N_PORT descriptor is uniquely
      identified by this parameter.

      iFCP Portal Address -- The IP address and TCP port number
      referenced when creation of the TCP connection associated with an
      iFCP session is requested.

      N_PORT ID --  N_PORT fibre channel address assigned to the remote
      device by the remote iFCP gateway.

Top      Up      ToC       Page 32 
      N_PORT Alias -- N_PORT fibre channel address assigned to the
      remote device by the 'local' iFCP gateway when it operates in
      address translation mode.

   An iFCP gateway SHALL have one and only one descriptor for each
   remote N_PORT it accesses.  If a descriptor does not exist, one SHALL
   be created using the information returned by an iSNS name server
   query.  Such queries may result from:

   a) a fibre channel Name Server request originated by a locally
      attached N_PORT (see Sections 3.5 and 9.3), or

   b) a CBIND request received from a remote fibre channel device (see

   When creating a descriptor in response to an incoming CBIND request,
   the iFCP gateway SHALL perform an iSNS name server query using the
   worldwide port name of the remote N_PORT in the SOURCE N_PORT NAME
   field within the CBIND payload.  The descriptor SHALL be filled in
   using the query results.

   After creating the descriptor, a gateway operating in address
   translation mode SHALL create and add the 24-bit N_PORT alias.  Updating a Remote N_PORT Descriptor

   A Remote N_PORT descriptor SHALL only be updated as the result of an
   iSNS query to obtain information for the specified worldwide port
   name or from information returned by an iSNS state change
   notification.  Following such an update, a new N_PORT alias SHALL NOT
   be assigned.

   Before such an update, the contents of a descriptor may have become
   stale because of an event that invalidated or triggered a change in
   the N_PORT network address of the remote device, such as a fabric
   reconfiguration or the device's removal or replacement.

   A collateral effect of such an event is that a fibre channel device
   that has been added or whose N_PORT ID has changed will have no
   active N_PORT logins.  Consequently, FC-4 traffic directed to such an
   N_PORT, because of a stale descriptor, will be rejected or discarded.

   Once the originating N_PORT learns of the reconfiguration, usually
   through the name server state change notification mechanism,
   information returned in the notification or the subsequent name
   server lookup needed to reestablish the iFCP session will
   automatically purge such stale data from the gateway.

Top      Up      ToC       Page 33  Deleting a Remote N_PORT Descriptor

   Deleting a remote N_PORT descriptor is equivalent to freeing up the
   corresponding N_PORT alias for reuse.  Consequently, the descriptor
   MUST NOT be deleted while there are any iFCP sessions that reference
   the remote N_PORT.

   Descriptors eligible for deletion should be removed based on a last
   in, first out policy.  Creating an iFCP Session

   An iFCP session may be in one of the following states:

      OPEN  --  The session state in which fibre channel frame images
      may be sent and received.

      OPEN PENDING -- The session state after a gateway has issued a
      CBIND request but no response has yet been received.  No fibre
      channel frames may be sent.

   The session may be initiated in response to a PLOGI ELS (see Section or for any other implementation-specific reason.

   The gateway SHALL create the iFCP session as follows:

   a) Locate the remote N_PORT descriptor corresponding to the session
      end point.  If the session is created in order to forward a fibre
      channel frame, then the session endpoint may be obtained by
      referencing the remote N_PORT alias contained in the frame header
      D_ID field.  If no descriptor exists, an iFCP session SHALL NOT be

   b) Allocate a TCP connection to the gateway to which the remote
      N_PORT is locally attached.  An implementation may use an existing
      connection in the Unbound state, or a new connection may be
      created and placed in the Unbound state.

      When a connection is created, the IP address and TCP Port number
      SHALL be obtained by referencing the remote N_PORT descriptor as
      specified in Section

   c) If the TCP connection cannot be allocated or cannot be created due
      to limited resources, the gateway SHALL terminate session

Top      Up      ToC       Page 34 
   d) If the TCP connection is aborted for any reason before the iFCP
      session enters the OPEN state, the gateway SHALL respond in
      accordance with Section 5.2.3 and MAY terminate the attempt to
      create a session or MAY try to establish the TCP connection again.

   e) The gateway SHALL then issue a CBIND session control message (see
      Section 6.1) and place the session in the OPEN PENDING state.

   f) If a CBIND response is returned with a status other than "Success"
      or "iFCP session already exists", the session SHALL be terminated,
      and the TCP connection returned to the Unbound state.

   g) A CBIND STATUS of "iFCP session already exists" indicates that the
      remote gateway has concurrently initiated a CBIND request to
      create an iFCP session between the same pair of N_PORTs.  A
      gateway receiving such a response SHALL terminate this attempt and
      process the incoming CBIND request in accordance with Section

   h) In response to a CBIND STATUS of "Success", the gateway SHALL
      place the session in the OPEN state.

   Once the session is placed in the OPEN state, an iFCP session
   descriptor SHALL be created, containing the information shown in
   Figure 11:

                        |TCP Connection Context |
                        |  Local N_PORT ID      |
                        |  Remote N_PORT ID     |
                        |  Remote N_PORT Alias  |

                     Figure 11. iFCP Session Descriptor

      TCP Connection Context -- Information required to identify the TCP
      connection associated with the iFCP session.

      Local N_PORT ID --  N_PORT ID of the locally attached fibre
      channel device.

      Remote N_PORT ID -- N_PORT ID assigned to the remote device by the
      remote gateway.

Top      Up      ToC       Page 35 
      Remote N_PORT Alias -- Alias assigned to the remote N_PORT by the
      local gateway when it operates in address translation mode.  If in
      this mode, the gateway SHALL copy this parameter from the Remote
      N_PORT descriptor.  Otherwise, it is not filled in.  Responding to a CBIND Request

   The gateway receiving a CBIND request SHALL respond as follows:

   a) If the receiver has a duplicate iFCP session in the OPEN PENDING
      state, then the receiving gateway SHALL compare the Source N_PORT
      Name in the incoming CBIND payload with the Destination N_PORT

   b) If the Source N_PORT Name is greater, the receiver SHALL issue a
      CBIND response of "Success" and SHALL place the session in the
      OPEN state.

   c) If the Source N_PORT Name is less, the receiver shall issue a
      CBIND RESPONSE of Failed - N_PORT session already exists.  The
      state of the receiver-initiated iFCP session SHALL BE unchanged.

   d) If there is no duplicate iFCP session in the OPEN PENDING state,
      the receiving gateway SHALL issue a CBIND response.  If a status
      of Success is returned, the receiving gateway SHALL create the
      iFCP session and place it in the OPEN state.  An iFCP session
      descriptor SHALL be created as described in Section

   e) If a remote N_PORT descriptor does not exist, one SHALL be created
      and filled in as described in Section  Monitoring iFCP Connectivity

   During extended periods of inactivity, an iFCP session may be
   terminated due to a hardware failure within the gateway or through
   loss of TCP/IP connectivity.  The latter may occur when the session
   traverses a stateful intermediate device, such as a NA(P)T box or
   firewall, that detects and purges connections it believes are unused.

   To test session liveness, expedite the detection of connectivity
   failures, and avoid spontaneous connection termination, an iFCP
   gateway may maintain a low level of session activity and monitor the
   session by requesting that the remote gateway periodically transmit
   the LTEST message described in Section 6.3.  All iFCP gateways SHALL
   support liveness testing as described in this specification.

Top      Up      ToC       Page 36 
   A gateway requests the LTEST heartbeat by specifying a non-zero value
   for the LIVENESS TEST INTERVAL in the CBIND request or response
   message as described in Section 6.1.  If both gateways seek to
   monitor liveness, each must set the LIVENESS TEST INTERVAL in the
   CBIND request or response.

   Upon receiving such a request, the gateway providing the heartbeat
   SHALL transmit LTEST messages at the specified interval.  The first
   message SHALL be sent as soon as the iFCP session enters the OPEN
   state.  LTEST messages SHALL NOT be sent when the iFCP session is not
   in the OPEN state.

   An iFCP session SHALL be terminated as described in Section 5.2.3 if:

   a) the contents of the LTEST message are incorrect, or

   b) an LTEST message is not received within twice the specified
      interval or the iFCP session has been quiescent for longer than
      twice the specified interval.

   The gateway to receive the LTEST message SHALL measure the interval
   for the first expected LTEST message from when the session is placed
   in the OPEN state.  Thereafter, the interval SHALL be measured
   relative to the last LTEST message received.

   To maximize liveness test coverage, LTEST messages SHOULD flow
   through all the gateway components used to enter and retrieve fibre
   channel frames from the IP network, including the mechanisms for
   encapsulating and de-encapsulating fibre channel frames.

   In addition to monitoring a session, information in the LTEST message
   encapsulation header may also be used to compute an estimate of
   network propagation delay, as described in Section 8.2.1.  However,
   the propagation delay limit SHALL NOT be enforced for LTEST traffic.  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

Top      Up      ToC       Page 37 
   | Feature   | Applicable |  RFC         |  Peer-Wise | Requirement|
   |           | RFCs       |  Status      |  Agreement | Level      |
   |           |            |              |  Required? |            |
   | Keep Alive| [RFC1122]  |  None        |  No        | Should not |
   |           |(discussion)|              |            | use        |
   | Tiny      | [RFC896]   |  Standard    |  No        | Should not |
   | Segment   |            |              |            | use        |
   | Avoidance |            |              |            |            |
   | (Nagle)   |            |              |            |            |
   | Window    | [RFC1323]  |  Proposed    |  No        | Should use |
   | Scale     |            |  Standard    |            |            |
   | Wrapped   | [RFC1323]  |  Proposed    |  No        | SHOULD use |
   | Sequence  |            |  Standard    |            |            |
   | Protection|            |              |            |            |
   | (PAWS)    |            |              |            |            |

                 Table 1. Usage of Optional TCP Features

   The following sections describe these options in greater detail.  Keep Alive

   Keep Alive speeds the detection and cleanup of dysfunctional TCP
   connections by sending traffic when a connection would otherwise be
   idle.  The issues are discussed in [RFC1122].

   In order to test the device more comprehensively, fibre channel
   applications, such as storage, may implement an equivalent keep alive
   function at the FC-4 level.  Alternatively, periodic liveness test
   messages may be issued as described in Section  Because of
   these more comprehensive end-to-end mechanisms and the considerations
   described in [RFC1122], keep alive at the transport layer should not
   be implemented.  'Tiny' Segment Avoidance (Nagle)

   The Nagle algorithm described in [RFC896] is designed to avoid the
   overhead of small segments by delaying transmission in order to
   agglomerate transfer requests into a large segment.  In iFCP, such
   small transfers often contain I/O requests.  The transmission delay
   of the Nagle algorithm may decrease I/O throughput.  Therefore, the
   Nagle algorithm should not be used.

Top      Up      ToC       Page 38  Window Scale

   Window scaling, as specified in [RFC1323], allows full use of links
   with large bandwidth - delay products and should be supported by an
   iFCP implementation.  Wrapped Sequence Protection (PAWS)

   TCP segments are identified with 32-bit sequence numbers.  In
   networks with large bandwidth - delay products, it is possible for
   more than one TCP segment with the same sequence number to be in
   flight.  In iFCP, receipt of such a sequence out of order may cause
   out-of-order frame delivery or data corruption.  Consequently, this
   feature SHOULD be supported as described in [RFC1323].

Top      Up      ToC       Page 39 
5.2.3.  Terminating iFCP Sessions

   iFCP sessions SHALL be terminated in response to one of the events in
   Table 2:

   |                Event                      |     iFCP Sessions   |
   |                                           |     to Terminate    |
   | PLOGI terminated with LS_RJT response     | Peer N_PORT         |
   | State change notification indicating      | All iFCP Sessions   |
   | N_PORT removal or reconfiguration.        | from the            |
   |                                           | reconfigured N_PORT |
   | LOGO ACC response from peer N_PORT        | Peer N_PORT         |
   | ACC response to LOGO ELS sent to F_PORT   | All iFCP sessions   |
   | server (D_ID = 0xFF-FF-FE) (fabric        | from the originating|
   | logout)                                   | N_PORT              |
   | Implicit N_PORT LOGO as defined in        | All iFCP sessions   |
   | [FC-FS]                                   | from the N_PORT     |
   |                                           | logged out          |
   | LTEST Message Error (see Section | Peer N_PORT         |
   | Non fatal encapsulation error as          | Peer N_PORT         |
   | specified in Section 5.3.3                |                     |
   | Failure of the TCP connection associated  | Peer N_PORT         |
   | with the iFCP session                     |                     |
   | Receipt of an UNBIND session control      | Peer N_PORT         |
   | message                                   |                     |
   | Gateway enters the Unsynchronized state   | All iFCP sessions   |
   | (see Section 8.2.1)                       |                     |
   | Gateway detects incorrect address mode    | All iFCP sessions   |
   | to peer gateway(see Section 4.6.2)        | with peer gateway   |

                   Table 2. Session Termination Events

Top      Up      ToC       Page 40 
   If a session is being terminated due to an incorrect address mode
   with the peer gateway, the TCP connection SHALL be aborted by means
   of a connection reset (RST) without performing an UNBIND.  Otherwise,
   if the TCP connection is still open following the event, the gateway
   SHALL shut down the connection as follows:

   a) Stop sending fibre channel frames over the TCP connection.

   b) Discard all incoming traffic, except for an UNBIND session control

   c) If an UNBIND message is received at any time, return a response in
      accordance with Section 6.2.

   d) If session termination was not triggered by an UNBIND message,
      issue the UNBIND session control message, as described in Section

   e) If the UNBIND message completes with a status of Success, the TCP
      connection MAY remain open at the discretion of either gateway and
      may be kept in a pool of unbound connections in order to speed up
      the creation of a new iFCP session.

      If the UNBIND fails for any reason, the TCP connection MUST be
      terminated.  In this case, the connection SHOULD be aborted with a
      connection reset (RST).

   For each terminated session, the session descriptor SHALL be deleted.
   If a session was terminated by an event other than an implicit LOGO
   or a LOGO ACC response, the gateway shall issue a LOGO to the locally
   attached N_PORT on behalf of the remote N_PORT.

   To recover resources, either gateway may spontaneously close an
   unbound TCP connection at any time.  If a gateway terminates a
   connection with a TCP close operation, the peer gateway MUST respond
   by executing a TCP close.

5.3.  Fibre Channel Frame Encapsulation

   This section describes the iFCP encapsulation of fibre channel
   frames.  The encapsulation complies with the common encapsulation
   format defined in [ENCAP], portions of which are included here for

Top      Up      ToC       Page 41 
   The format of an encapsulated frame is shown below:

                     |       Header       |
                     |        SOF         |   f |
                     +--------------------+ F r |
                     |  FC frame content  | C a |
                     +--------------------+   m |
                     |        EOF         |   e |

                   Figure 12. Encapsulation Format

   The encapsulation consists of a 7-word header, an SOF delimiter word,
   the FC frame (including the fibre channel CRC), and an EOF delimiter
   word.  The header and delimiter formats are described in the
   following sections.

5.3.1.  Encapsulation Header Format

   o|                                                               |
   r|                    1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3|
   d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   0|   Protocol#   |    Version    |  -Protocol#   |   -Version    |
   1|                  Reserved (must be zero)                      |
   2| LS_COMMAND_ACC|  iFCP Flags   |     SOF       |      EOF      |
   3|   Flags   |   Frame Length    |   -Flags  |   -Frame Length   |
   4|                      Time Stamp [integer]                     |
   5|                      Time Stamp [fraction]                    |
   6|                              CRC                              |

                 Figure 13. Encapsulation Header Format

   Common Encapsulation Fields:

   Protocol#            IANA-assigned protocol number identifying the
                        protocol using the encapsulation.  For iFCP, the
                        value assigned by [ENCAP] is 2.

Top      Up      ToC       Page 42 
   Version              Encapsulation version, as specified in [ENCAP].

   -Protocol#           Ones complement of the Protocol#.

   -Version             Ones complement of the version.

   Flags                Encapsulation flags (see

   Frame Length         Contains the length of the entire FC
                        Encapsulated frame, including the FC
                        Encapsulation Header and the FC frame (including
                        SOF and EOF words) in units of 32-bit words.

   -Flags               Ones complement of the Flags field.

   -Frame Length        Ones complement of the Frame Length field.

   Time Stamp [integer] Integer component of the frame time stamp, as
                        specified in [ENCAP].

   Time Stamp           Fractional component of the time stamp,
   [fraction]           as specified in [ENCAP].

   CRC                  Header CRC.  MUST be valid for iFCP.

   The time stamp fields are used to enforce the limit on the lifetime
   of a fibre channel frame as described in Section 8.2.1.

   iFCP-Specific Fields:

   LS_COMMAND_ACC       For a special link service ACC response to be
                        processed by iFCP, the LS_COMMAND_ACC field
                        SHALL contain a copy of bits 0 through 7 of the
                        LS_COMMAND to which the ACC applies.  Otherwise,
                        the LS_COMMAND_ACC field SHALL be set to zero.

   iFCP Flags           iFCP-specific flags (see below).

   SOF                  Copy of the SOF delimiter encoding (see Section

   EOF                  Copy of the EOF delimiter encoding (see Section

Top      Up      ToC       Page 43 
   The iFCP flags word has the following format:

        |                                                       |
        |   8      9     10     11     12     13     14    15   |
        |             Reserved             | SES  | TRP  |  SPC |

                       Figure 14. iFCP Flags Word

   iFCP Flags:

   SES         1 = Session control frame (TRP and SPC MUST be 0)

   TRP         1 = Address transparent mode enabled

               0 = Address translation mode enabled

   SPC         1 = Frame is part of a link service message requiring
                   special processing by iFCP prior to forwarding to the
                   destination N_PORT.  Common Encapsulation Flags

   The iFCP usage of the common encapsulation flags defined in [ENCAP]
   is shown in Figure 15:

         |                                                     |
         |    0        1        2        3        4        5   |
         |                  Reserved                  |  CRCV  |

               Figure 15. iFCP Common Encapsulation Flags

   For iFCP, the CRC field MUST be valid, and CRCV MUST be set to one.

Top      Up      ToC       Page 44 
5.3.2.  SOF and EOF Delimiter Fields

   The format of the delimiter fields is shown below.

   o|                                                               |
   r|                      1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 3 3|
   d|0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1|
   0|      SOF      |      SOF      |     -SOF      |     -SOF      |
   1|                                                               |
    +-----                   FC frame content                  -----+
    |                                                               |
   n|      EOF      |      EOF      |     -EOF      |     -EOF      |

                Figure 16. FC Frame Encapsulation Format

   SOF (bits 0-7 and bits 8-15 in word 0):  iFCP uses the following
   subset of the SOF fields specified in [ENCAP].  For convenience,
   these are reproduced in Table 3.  The authoritative encodings should
   be obtained from [ENCAP].

                           |  FC   |          |
                           |  SOF  | SOF Code |
                           | SOFi2 |   0x2D   |
                           | SOFn2 |   0x35   |
                           | SOFi3 |   0x2E   |
                           | SOFn3 |   0x36   |

       Table 3. Translation of FC SOF Values to SOF Field Contents

   -SOF (bits 16-23 and 24-31 in word 0): The -SOF fields contain the
   ones complement the value in the SOF fields.

   EOF (bits 0-7 and 8-15 in word n):  iFCP uses the following subset of
   EOF fields specified in [ENCAP].  For convenience, these are
   reproduced in Table 4.  The authoritative encodings should be
   obtained from [ENCAP].

Top      Up      ToC       Page 45 
                           |  FC   |          |
                           |  EOF  | EOF Code |
                           | EOFn  |   0x41   |
                           | EOFt  |   0x42   |

       Table 4. Translation of FC EOF Values to EOF Field Contents

   -EOF (bits 16-23 and 24-31 in word n): The -EOF fields contain the
   ones complement the value in the EOF fields.

   iFCP implementations SHALL place a copy of the SOF and EOF delimiter
   codes in the appropriate header fields.

5.3.3.  Frame Encapsulation

   A fibre channel Frame to be encapsulated MUST first be validated as
   described in [FC-FS].  Any frames received from a locally attached
   fibre channel device that do not pass the validity tests in [FC-FS]
   SHALL be discarded by the gateway.

   If the frame is a PLOGI ELS, the creation of an iFCP session, as
   described in Section, may precede encapsulation.  Once the
   session has been created, frame encapsulation SHALL proceed as

   The S_ID and D_ID fields in the frame header SHALL be referenced to
   look up the iFCP session descriptor (see Section  If no
   iFCP session descriptor exists, the frame SHALL be discarded.

   Frame types submitted for encapsulation and forwarding on the IP
   network SHALL have one of the SOF delimiters in Table 3 and an EOF
   delimiter from Table 4.  Other valid frame types MUST be processed
   internally by the gateway as specified in the appropriate fibre
   channel specification.

   If operating in address translation mode and processing a special
   link service message requiring the inclusion of supplemental data,
   the gateway SHALL format the frame payload and add the supplemental
   information specified in Section 7.1.  The gateway SHALL then
   calculate a new FC CRC on the reformatted frame.

   Otherwise, the frame contents SHALL NOT be modified and the gateway
   MAY encapsulate and transmit the frame image without recalculating
   the FC CRC.

Top      Up      ToC       Page 46 
   The frame originator MUST then create and fill in the header and the
   SOF and EOF delimiter words, as specified in Sections 5.3.1 and

5.3.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 valid, the receiving gateway SHALL
   check the iFCP flags field.  If one of the error conditions in Table
   5 is detected, the gateway SHALL handle the error as specified in
   Section 5.2.3.

      |      Condition               |      Error Type         |
      | Header CRC Invalid           | Encapsulation error     |
      | SES = 1, TRP or SPC not 0    | Encapsulation error     |
      | SES = 0, TRP set incorrectly | Incorrect address mode  |

                 Table 5. Encapsulation Header Errors

   The receiving gateway SHALL then verify the frame propagation delay
   as described in Section 8.2.1.  If the propagation delay is too long,
   the frame SHALL be discarded.  Otherwise, the gateway SHALL check the
   SOF and EOF in the encapsulation header.  A frame SHALL be discarded
   if it has an SOF code that is not in Table 3 or an EOF code that is
   not in Table 4.

   The gateway SHALL then de-encapsulate the frame as follows:

   a) Check the FC CRC and discard the frame if the CRC is invalid.

   b) If operating in address translation mode, replace the S_ID field
      with the N_PORT alias of the frame originator, and the D_ID with
      the N_PORT ID, of the frame recipient.  Both parameters SHALL be
      obtained from the iFCP session descriptor.

   c) If processing a special link service message, replace the frame
      with a copy whose payload has been modified as specified in
      Section 7.1.

Top      Up      ToC       Page 47 
   The de-encapsulated frame SHALL then be forwarded to the N_PORT
   specified in the D_ID field.  If the frame contents have been
   modified by the receiving gateway, a new FC CRC SHALL be calculated.

(page 47 continued on part 3)

Next RFC Part