tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4172

 
 
 

iFCP - A Protocol for Internet Fibre Channel Storage Networking

Part 3 of 4, p. 47 to 85
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 47 
6.  TCP Session Control Messages

   TCP session control messages are used to create and manage an iFCP
   session as described in Section 5.2.2.  They are passed between peer
   iFCP Portals and are only processed within the iFCP layer.

   The message format is based on the fibre channel extended link
   service message template shown below.

    Word
      0<--Bits-->7 8<---------------Bits------------------------>31
     +------------+------------------------------------------------+
    0| R_CTL      |            D_ID [0x00 00 00]                   |
     |[Req = 0x22]| [Destination of extended link Service request] |
     |[Rep = 0x23]|                                                |
     +------------+------------------------------------------------+
    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 17. Format of Session Control Message

Top      Up      ToC       Page 48 
   The LS_COMMAND value for the response remains the same as that used
   for the request.

   The session control frame is terminated with a fibre channel CRC.
   The frame SHALL be encapsulated and de-encapsulated according to the
   rules specified in Section 5.3.

   The encapsulation header for the link Service frame carrying a
   session control message SHALL be set as follows:

   Encapsulation Header Fields:

      LS_COMMAND_ACC       0

      iFCP Flags           SES = 1

                           TRP = 0

                           INT = 0

      SOF code             SOFi3 encoding (0x2E)

      EOF code             EOFt encoding (0x42)

   The encapsulation time stamp words SHALL be set as described for each
   message type.

   The SOF and EOF delimiter words SHALL be set based on the SOF and EOF
   codes specified above.

Top      Up      ToC       Page 49 
   Table 6 lists the values assigned to byte 0 of the LS_COMMAND field
   for iFCP session control messages.

   +--------------+-------------------------+----------+-------------+
   | LS_COMMAND   |       Function          | Mnemonic | iFCP        |
   | field, byte 0|                         |          | Support     |
   +--------------+-------------------------+----------+-------------+
   |    0xE0      |    Connection Bind      |  CBIND   |  REQUIRED   |
   +--------------+-------------------------+----------+-------------+
   |    0xE4      |    Unbind Connection    |  UNBIND  |  REQUIRED   |
   +--------------+-------------------------+----------+-------------+
   |    0xE5      | Test Connection Liveness|  LTEST   |  REQUIRED   |
   +--------------+-------------------------+----------+-------------+
   | 0x01-0x7F    |    Vendor-Specific      |          |             |
   +--------------+-------------------------+----------+-------------+
   |    0x00      | Reserved -- Unassignable|          |             |
   +--------------+-------------------------+----------+-------------+
   | All other    |    Reserved             |          |             |
   | values       |                         |          |             |
   +--------------+-------------------------+----------+-------------+

        Table 6. Session Control LS_COMMAND Field, Byte 0 Values

Top      Up      ToC       Page 50 
6.1.  Connection Bind (CBIND)

   As described in Section 5.2.2.2, the CBIND message and response are
   used to bind an N_PORT login to a specific TCP connection and
   establish an iFCP session.  In the CBIND request message, the source
   and destination N_PORTs are identified by their worldwide port names.
   The time stamp words in the encapsulation header SHALL be set to zero
   in the request and response message frames.

   The following shows the format of the CBIND request.

      +------+------------+------------+-----------+----------+
      | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
      +------+------------+------------+-----------+----------+
      | 0    | Cmd = 0xE0 |   0x00     |   0x00    |  0x00    |
      +------+------------+------------+-----------+----------+
      | 1    |  LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
      |      |        (Seconds)        |           |          |
      +------+-------------------------+-----------+----------+
      | 2    |                  USER INFO                     |
      +------+------------+------------+-----------+----------+
      | 3    |                                                |
      +------+              SOURCE N_PORT NAME                |
      | 4    |                                                |
      +------+------------------------------------------------+
      | 5    |                                                |
      +------+              DESTINATION N_PORT NAME           |
      | 6    |                                                |
      +------+------------------------------------------------+

   Addr Mode:             The addressing mode of the originating
                          gateway.  0 = Address Translation mode;
                          1 = Address Transparent mode.

   iFCP Ver:              iFCP version number.  SHALL be set to 1.

   LIVENESS TEST          If non-zero, requests that the receiving
   INTERVAL:              gateway transmit an LTEST message at the
                          specified interval in seconds.  If set to
                          zero, LTEST messages SHALL NOT be sent.

   USER INFO:             Contains any data desired by the requestor.
                          This information MUST be echoed by the
                          recipient in the CBIND response message.

   SOURCE N_PORT NAME:    The Worldwide Port Name (WWPN) of the N_PORT
                          locally attached to the gateway originating
                          the CBIND request.

Top      Up      ToC       Page 51 
   DESTINATION N_PORT     The Worldwide Port Name (WWPN) of the
   NAME:                  N_PORT locally attached to the gateway
                          receiving the CBIND request.

   The following shows the format of the CBIND response.

         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE0 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |  LIVENESS TEST INTERVAL | Addr Mode | iFCP Ver |
         |      |      (Seconds)          |           |          |
         +------+-------------------------+-----------+----------+
         | 2    |                  USER INFO                     |
         +------+------------+------------+-----------+----------+
         | 3    |                                                |
         +------+               SOURCE N_PORT NAME               |
         | 4    |                                                |
         +------+------------------------------------------------+
         | 5    |                                                |
         +------+              DESTINATION N_PORT NAME           |
         | 6    |                                                |
         +------+-------------------------+----------------------+
         | 7    |        Reserved         |     CBIND Status     |
         +------+-------------------------+----------------------+
         | 8    |        Reserved         |  CONNECTION HANDLE   |
         +------+-------------------------+----------------------+

                           Total Length = 36

   Addr Mode:             The address translation mode of the
                          responding gateway.  0 = Address
                          Translation mode, 1 = Address Transparent
                          mode.

   iFCP Ver:              iFCP version number.  Shall be set to 1.

   LIVENESS TEST          If non-zero, requests that the gateway
   INTERVAL:              receiving the CBIND RESPONSE transmit an
                          LTEST message at the specified interval in
                          seconds.  If zero, LTEST messages SHALL NOT
                          be sent.

   USER INFO:             Echoes the value received in the USER INFO
                          field of the CBIND request message.

Top      Up      ToC       Page 52 
   SOURCE N_PORT NAME:    Contains the Worldwide Port Name (WWPN) of
                          the N_PORT locally attached to the gateway
                          issuing the CBIND request.

   DESTINATION N_PORT     Contains the Worldwide Port Name (WWPN) of
   NAME:                  the N_PORT locally attached to the gateway
                          issuing the CBIND response.

   CBIND STATUS:          Indicates success or failure of the CBIND
                          request.  CBIND values are shown below.

   CONNECTION HANDLE:     Contains a value assigned by the gateway to
                          identify the connection.  The connection
                          handle is required when the UNBIND
                          request is issued.

   CBIND Status       Description
   ------------       -----------

       0              Success
     1 - 15           Reserved
       16             Failed - Unspecified Reason
       17             Failed - No such device
       18             Failed - iFCP session already exists
       19             Failed - Lack of resources
       20             Failed - Incompatible address translation mode
       21             Failed - Incorrect protocol version number
       22             Failed - Gateway not Synchronized (see Section
                      8.2)
       Others         Reserved

6.2.  Unbind Connection (UNBIND)

   UNBIND is used to terminate an iFCP session and disassociate the TCP
   connection as described in Section 5.2.3.

   The UNBIND message is transmitted over the connection that is to be
   unbound.  The time stamp words in the encapsulation header shall be
   set to zero in the request and response message frames.

Top      Up      ToC       Page 53 
   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                      |
         +------+------------+------------+-----------+----------+

   USER INFO              Contains any data desired by the requestor.
                          This information MUST be echoed by the
                          recipient in the UNBIND response message.

   CONNECTION HANDLE:     Contains the gateway-assigned value from
                          the CBIND request.

   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    |
         +------+------------+------------+-----------+----------+

   USER INFO              Echoes the value received in the USER INFO
                          field of the UNBIND request message.

   CONNECTION HANDLE:     Echoes the CONNECTION HANDLE specified in
                          the UNBIND request message.

Top      Up      ToC       Page 54 
   UNBIND STATUS:         Indicates the success or failure of the
                          UNBIND request as follows:

         Unbind Status      Description
         -------------      -----------

                  0         Successful - No other status
               1 - 15       Reserved
                 16         Failed - Unspecified Reason
                 18         Failed - Connection ID Invalid
               Others       Reserved

6.3.  LTEST -- Test Connection Liveness

   The LTEST message is sent at the interval specified in the CBIND
   request or response payload.  The LTEST encapsulation time stamp
   SHALL be set as described in Section 8.2.1 and may be used by the
   receiver to compute an estimate of propagation delay.  However, the
   propagation delay limit SHALL NOT be enforced.

         +------+------------+------------+-----------+----------+
         | Word |   Byte 0   |   Byte 1   |   Byte 2  |  Byte 3  |
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0xE5 |   0x00     |   0x00    |  0x00    |
         +------+------------+------------+-----------+----------+
         | 1    |  LIVENESS TEST INTERVAL |        Reserved      |
         |      |        (Seconds)        |                      |
         +------+-------------------------+----------------------+
         | 2    |                   COUNT                        |
         +------+------------+------------+-----------+----------+
         | 3    |                                                |
         +------+              SOURCE N_PORT NAME                |
         | 4    |                                                |
         +------+------------------------------------------------+
         | 5    |                                                |
         +------+              DESTINATION N_PORT NAME           |
         | 6    |                                                |
         +------+------------------------------------------------+

   LIVENESS TEST          Copy of the LIVENESS TEST INTERVAL
   INTERVAL:              specified in the CBIND request or reply
                          message.

   COUNT:                 Monotonically increasing value, initialized
                          to 0 and incremented by one for each
                          successive LTEST message.

Top      Up      ToC       Page 55 
   SOURCE N_PORT NAME:    Contains a copy of the SOURCE N_PORT NAME
                          specified in the CBIND request.

   DESTINATION N_PORT     Contains a copy of the DESTINATION N_PORT
   NAME:                  NAME specified in the CBIND request.

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.

   There are three types of link services:

   a) Basic

   b) Extended

   c) ULP-specific (FC-4)

   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 network.  This includes mapping link service messages
   appropriately from the domain of the fibre channel transport to that
   of the IP network.  This process may require special processing and
   the inclusion of supplemental data by the iFCP layer.

   Each link service MUST be processed according to one of the following
   rules:

   a) Pass-through - The link service message and reply MUST be
      delivered to the receiving N_PORT by the iFCP protocol layer
      without altering the message payload.  The link service message
      and reply are not processed by the iFCP protocol layer.

   b) Special -  Applies to a link service reply or request requiring
      the intervention of the iFCP layer before forwarding to the
      destination N_PORT.  Such messages may contain fibre channel
      addresses in the payload or may require other special processing.

   c) Rejected - When issued by a locally attached N_PORT, the specified
      link service request MUST be rejected by the iFCP gateway.  The
      gateway SHALL return an LS_RJT response with a Reason Code of 0x0B
      (Command Not Supported), and a Reason Code Explanation of 0x0 (No
      Additional Explanation).

Top      Up      ToC       Page 56 
   This section describes the processing for special link services,
   including the manner in which supplemental data is added to the
   message payload.

   Appendix A enumerates all link services and the iFCP processing
   policy that applies to each.

7.1.  Special Link Service Messages

   Special link service messages require the intervention of the iFCP
   layer before forwarding to the destination N_PORT.  Such intervention
   is required in order to:

   a) service any link service message that requires special handling,
      such as a PLOGI, and

   b) service any link service message that has an N_PORT address in the
      payload in address translation mode only .

   Unless the link service description specifies otherwise, support for
   each special link service is MANDATORY.

   Such messages SHALL be transmitted in a fibre channel frame with the
   format shown in Figure 18 for extended link services or Figure 19 for
   FC-4 link services.

Top      Up      ToC       Page 57 
    Word
      0<---Bit-->7 8<-------------------------------------------->31
     +------------+------------------------------------------------+
    0| R_CTL      |                     D_ID                       |
     |[Req = 0x22]|[Destination of extended link Service request]  |
     |[Rep = 0x23]|                                               |
     +------------+------------------------------------------------+
    1| CS_CTL     |                     S_ID                       |
     |            | [Source of extended link service request]      |
     +------------+------------------------------------------------+
    2| TYPE       |                     F_CTL                      |
     | [0x01]     |                                                |
     +------------+------------------+-----------------------------+
    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 18. Format of an Extended Link Service Frame

Top      Up      ToC       Page 58 
    Word
      0<---Bit-->7 8<-------------------------------------------->31
     +------------+------------------------------------------------+
    0| R_CTL      |                     D_ID                       |
     |[Req = 0x32]|   [Destination of FC-4 link Service request]   |
     |[Rep = 0x33]|                                                |
     +------------+------------------------------------------------+
    1| CS_CTL     |                     S_ID                       |
     |            |    [Source of FC-4 link service request]       |
     +------------+------------------------------------------------+
    2| TYPE       |                     F_CTL                      |
     | (FC-4      |                                                |
     |  specific) |                                                |
     +------------+------------------+-----------------------------+
    3| SEQ_ID     |        DF_CTL    |          SEQ_CNT            |
     +------------+------------------+-----------------------------+
    4|         OX_ID                 |             RX_ID           |
     +-------------------------------+-----------------------------+
    5|                        Parameter                            |
     |                     [ 00 00 00 00 ]                         |
     +-------------------------------------------------------------+
    6|                        LS_COMMAND                           |
     |               [FC-4 Link Service Command Code]              |
     +-------------------------------------------------------------+
    7|                                                             |
    .|             Additional Service Request Parameters           |
    .|                      ( if any )                             |
    n|                                                             |
     +-------------------------------------------------------------+

            Figure 19. Format of an FC-4 Link Service Frame

7.2.  Link Services Requiring Payload Address Translation

   This section describes the handling for link service frames
   containing N_PORT addresses in the frame 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 link service messages
   SHALL NOT be sent as special frames unless other processing by the
   iFCP layer is required.

   Supplemental data includes information required by the receiving
   gateway to convert an N_PORT address in the payload to an N_PORT
   address in the receiving gateway's address space.  The following
   rules define the manner in which such supplemental data shall be
   packaged and referenced.

Top      Up      ToC       Page 59 
   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 ID of the
      destination N_PORT.  This translation type MUST be used when the
      address to be converted is that of the destination N_PORT

      0x00 00 03 - The gateway receiving the frame from the IP network
      MUST reference the specified supplemental data to set the field
      contents.  The supplemental information is the 64-bit worldwide
      identifier of the N_PORT, as set forth in the fibre channel
      specification [FC-FS].  If not otherwise part of the link service
      payload, this information MUST be appended in accordance with the
      applicable link service description.  Unless specified otherwise,
      this translation type SHALL NOT be used if the address to be
      converted corresponds to that of the frame originator or
      recipient.

   Since fibre channel addressing rules prohibit the assignment of
   fabric addresses with a domain ID of 0, the above codes will never
   correspond to valid N_PORT fabric IDs.

   If the sending gateway cannot obtain the worldwide identifier of an
   N_PORT, the gateway SHALL terminate the request with an LS_RJT
   message as described in [FC-FS].  The Reason Code SHALL be set to
   0x07 (protocol error), and the Reason Explanation SHALL be set to
   0x1F (Invalid N_PORT identifier).

   Supplemental data is sent with the link service request or ACC frames
   in one of the following ways:

   a) By appending the necessary data to the end of the link service
      frame.

   b) By extending the sequence with additional frames.

   In the first case, a new frame SHALL be created whose length includes
   the supplemental data.  The procedure for extending the link service
   sequence with additional frames is dependent on the link service
   type.

Top      Up      ToC       Page 60 
   For each field requiring address translation, the receiving gateway
   SHALL reference the translation type encoded in the field and replace
   it with the N_PORT address as shown in Table 7.

         +------------------+------------------------------------+
         |    Translation   |          N_PORT Translation        |
         |    Type Code     |                                    |
         +------------------+------------------------------------+
         | 0x00 00 01       | Replace field contents with N_PORT |
         |                  | alias of frame originator.         |
         +------------------+------------------------------------+
         | 0x00 00 02       | Replace field contents with N_PORT |
         |                  | ID of frame recipient.             |
         +------------------+------------------------------------+
         |                  | Lookup N_PORT via iSNS query.      |
         |                  | If locally attached, replace with  |
         | 0x00 00 03       | N_PORT ID.                         |
         |                  | If remotely attached, replace with |
         |                  | N_PORT alias from remote N_PORT.   |
         |                  | descriptor (see Section 5.2.2.1).  |
         +------------------+------------------------------------+

                 Table 7. Link Service Address Translation

   For translation type 3, the receiving gateway SHALL obtain the
   information needed to fill in the field in the link service frame
   payload by converting the specified N_PORT worldwide identifier to a
   gateway IP address and N_PORT ID.  This information MUST be obtained
   through an iSNS name server query.  If the query is unsuccessful, the
   gateway SHALL terminate the request with an LS_RJT response message
   as described in [FC-FS].  The Reason Code SHALL be set to 0x07
   (protocol error), and the Reason Explanation SHALL be set to 0x1F
   (Invalid N_PORT identifier).

   After applying the supplemental data, the receiving gateway SHALL
   forward the resulting link service frames to the destination N_PORT
   with the supplemental information removed.

Top      Up      ToC       Page 61 
7.3.  Fibre Channel Link Services Processed by iFCP

   The following Extended and FC-4 Link Service Messages must receive
   special processing.

         Extended Link Service            LS_COMMAND   Mnemonic
         Messages                         ----------   --------
         ----------------------
         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           0x55 00 00 00 FARP-REPLY
         Protocol Reply
         FC Address Resolution           0x54 00 00 00 FARP-REQ
         Protocol 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           0x02 00 00 00 REC ACC
         Accept
         Read Exchange Status Block      0x08 00 00 00 RES
         Read Exchange Status Block      0x02 00 00 00 RES ACC
         Accept
         Read Link Error Status          0x0F 00 00 00 RLS
         Block
         Read Sequence Status Block      0x09 00 00 00 RSS
         Reinstate Recovery              0x12 00 00 00 RRQ
         Qualifier
         Request Sequence                0x0A 00 00 00 RSI
         Initiative
         Scan Remote Loop                0x7B 00 00 00 SRL
         Third Party Process Logout      0x24 00 00 00 TPRLO
         Third Party Process Logout      0x02 00 00 00 TPRLO ACC
         Accept

         FC-4 Link Service Messages       LS_COMMAND   Mnemonic
         --------------------------       ----------   --------
         FCP Read Exchange Concise       0x13 00 00 00 FCP REC
         FCP Read Exchange Concise       0x02 00 00 00 FCP REC
         Accept                                        ACC

   Each encapsulated fibre channel frame that is part of a special link
   service MUST have the SPC bit set to one in the iFCP FLAGS field of
   the encapsulation header, as specified in Section 5.3.1.  If an ACC
   link service response requires special processing, the responding
   gateway SHALL place a copy of LS_COMMAND bits 0 through 7, from the

Top      Up      ToC       Page 62 
   link service request frame, in the LS_COMMAND_ACC field of the ACC
   encapsulation header.  Supplemental data (if any) MUST be appended as
   described in the following section.

   The format of each special link service message, including
   supplemental data, where applicable, is shown in the following
   sections.  Each description shows the basic format, as specified in
   the applicable FC standard, followed by supplemental data as shown in
   the example below.

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    |                  LS_COMMAND                    |
         +------+------------+------------+-----------+----------+
         | 1    |                                                |
         | .    |                                                |
         | .    |          Link Service Frame Payload            |
         |      |                                                |
         | n    |                                                |
         +======+============+============+===========+==========+
         | n+1  |                                                |
         |  .   |            Supplemental Data                   |
         |  .   |               (if any)                         |
         | n+k  |                                                |
         +======+================================================+

               Figure 20. Special Link Service Frame Payload

Top      Up      ToC       Page 63 
7.3.1.  Special Extended Link Services

   The following sections define extended link services for which
   special processing is required.

7.3.1.1.  Abort Exchange (ABTX)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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.

Top      Up      ToC       Page 64 
7.3.1.2.  Discover Address (ADISC)

      Format of ADISC ELS:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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 ID  of ELS Originator     |
         +======+============+============+===========+==========+

         Fields Requiring       Translation    Supplemental Data
         Address Translation     Type (see       (type 3 only)
         -------------------    Section 7.2)     -------------
                                ------------

         N_PORT ID of ELS            1                N/A
         Originator

         Other Special Processing:

            The Hard Address of the ELS originator SHALL be set to 0.

Top      Up      ToC       Page 65 
7.3.1.3.  Discover Address Accept (ADISC ACC)

      Format of ADISC ACC ELS:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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 ID of ELS Originator      |
         +======+============+============+===========+==========+

         Fields Requiring       Translation    Supplemental Data
         Address Translation     Type (see       (type 3 only)
         -------------------    Section 7.2)     -------------
                                ------------

         N_PORT ID of ELS            1                N/A
         Originator

         Other Special Processing:

            The Hard Address of the ELS originator SHALL be set to 0.

Top      Up      ToC       Page 66 
7.3.1.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.1.5) to perform the address resolution services 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 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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.

Top      Up      ToC       Page 67 
7.3.1.5.  FC Address Resolution Protocol Request (FARP-REQ)

   The FARP-REQ ELS is used 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 9.4 describes the iFCP implementation of FC broadcast server
   functionality in an iFCP fabric.

      Format of FARP_REQ ELS:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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

         Responding N_PORT           3        Responding N_PORT
         Identifier                           Port Name

Top      Up      ToC       Page 68 
         Other Special Processing:

            None.

7.3.1.6.  Logout (LOGO) and LOGO ACC

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x5  |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Rsvd       |     N_PORT ID being logged out    |
         +------+------------+------------+-----------+----------+
         | 2-3  |  Port name of the LOGO originator (8 bytes)    |
         +======+============+============+===========+==========+

   This ELS SHALL always be sent as a special 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 ID Being             1               N/A
         Logged Out

         Other Special Processing:

            See Section 5.2.3.

7.3.1.7.  Port Login (PLOGI) and PLOGI ACC

   A PLOGI ELS establishes fibre channel communications between two
   N_PORTs and triggers the creation of an iFCP session if one does not
   exist.

   The PLOGI request and ACC response carry information identifying the
   originating N_PORT, including a specification of its capabilities.
   If the destination N_PORT accepts the login request, it sends an
   Accept response (an ACC frame with PLOGI payload) specifying its
   capabilities.  This exchange establishes the operating environment
   for the two N_PORTs.

Top      Up      ToC       Page 69 
   The following figure is duplicated from [FC-FS], and shows the PLOGI
   message format for both the request and Accept (ACC) response.  An
   N_PORT will reject a PLOGI request by transmitting an LS_RJT message
   containing no payload.

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x3  |   0x00     |    0x00   |   0x00   |
         |      | Acc = 0x2  |            |           |          |
         +------+------------+------------+-----------+----------+
         | 1-4  |            Common Service Parameters           |
         +------+------------+------------+-----------+----------+
         | 5-6  |            N_PORT Name                         |
         +------+------------+------------+-----------+----------+
         | 7-8  |            Node Name                           |
         +------+------------+------------+-----------+----------+
         | 9-12 |            Class 1 Service Parameters          |
         +------+------------+------------+-----------+----------+
         |13-17 |            Class 2 Service Parameters          |
         +------+------------+------------+-----------+----------+
         |18-21 |            Class 3 Service Parameters          |
         +------+------------+------------+-----------+----------+
         |22-25 |            Class 4 Service Parameters          |
         +------+------------+------------+-----------+----------+
         |26-29 |            Vendor Version Level                |
         +======+============+============+===========+==========+

            Figure 21. Format of PLOGI Request and ACC Payloads

   Details of the above fields, including common and class-based service
   parameters, can be found in [FC-FS].

   Special Processing

      As specified in Section 5.2.2.2, a PLOGI request addressed to a
      remotely attached N_PORT MUST cause the creation of an iFCP
      session if one does not exist.  Otherwise, the PLOGI and PLOGI ACC
      payloads MUST be passed through without modification to the
      destination N_PORT using the existing iFCP session.  In either
      case, the SPC bit must be set in the frame encapsulation header as
      specified in 5.3.3.

      If the CBIND to create the iFCP session fails, the issuing gateway
      SHALL terminate the PLOGI with an LS_RJT response.  The Reason
      Code and Reason Code Explanation SHALL be selected from Table 8
      based on the CBIND failure status.

Top      Up      ToC       Page 70 
      +---------------+-------------------+---------------------+
      | 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       | Unable to Perform | Invalid N_PORT      |
      | Device (17)   | Command Request   | Name (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   | (0x09)            |                     |
      | Mode (20)     |                   |                     |
      +---------------+-------------------+---------------------+
      | Incorrect iFCP| Unable to Perform | No Additional       |
      | Protocol      | Command Request   | Explanation (0x00)  |
      | version Number| (0x09)            |                     |
      | (21)          |                   |                     |
      +---------------+-------------------+---------------------+
      | Gateway Not   | Unable to Perform | No Additional       |
      | Synchronized  | Command Request   | Explanation (0x00)  |
      | (22)          | (0x09)            |                     |
      +---------------+-------------------+---------------------+

           Table 8. PLOGI LS_RJT Status for CBIND Failures

Top      Up      ToC       Page 71 
7.3.1.8.  Read Exchange Concise (REC)

      Link Service Request Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  |Bits 16-24 |Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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)        |
         +======+============+============+===========+==========+

         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.

Top      Up      ToC       Page 72 
7.3.1.9.  Read Exchange Concise Accept (REC ACC)

      Format of REC ACC Response:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  |Bits 16-24 |Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    | Acc = 0x02 |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    |          OX_ID          |         RX_ID        |
         +------+------------+------------+-----------+----------+
         | 2    | Rsvd       | Originator Address Identifier     |
         +------+------------+------------+-----------+----------+
         | 3    | Rsvd       | Responder Address Identifier      |
         +------+------------+------------+-----------+----------+
         | 4    |       FC4VALUE  (FC-4-Dependent Value)         |
         +------+------------+------------+-----------+----------+
         | 5    |       E_STAT (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)    ------------------
                                -----------

         Originator Address     1, 2, or 3      Port Name of the
         Identifier                             Exchange Originator

         Responder Address      1, 2, or 3      Port Name of the
         Identifier                             Exchange Responder

   When supplemental data is required, the frame SHALL always be
   extended by 4 words as shown above.  If the translation type for the
   Originator Address Identifier or the Responder Address Identifier is
   1 or 2, the corresponding 8-byte port name SHALL be set to all zeros.

         Other Special Processing:

            None.

Top      Up      ToC       Page 73 
7.3.1.10.  Read Exchange Status Block (RES)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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.

Top      Up      ToC       Page 74 
7.3.1.11.  Read Exchange Status Block Accept (RES ACC)

      Format of ELS Accept Response:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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 [FC-FS]                     |
         +======+============+============+===========+==========+
         |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 ID                              Exchange Originator

         Exchange Responder     1, 2, or 3      Port Name of the
         N_PORT ID                              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 ID or the Exchange Responder N_PORT ID is 1 or 2,
   the corresponding 8-byte port name SHALL be set to all zeros.

         Other Special Processing:

            None.

Top      Up      ToC       Page 75 
7.3.1.12.  Read Link Error Status (RLS)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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
         Address Translation     Type (see       (type 3 only)
         -------------------    Section 7.2)    -----------------
                                -----------

         N_PORT Identifier      1, 2, or 3      Port Name of the
                                                N_PORT

         Other Special Processing:

            None.

Top      Up      ToC       Page 76 
7.3.1.13.  Read Sequence Status Block (RSS)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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:

            None.

Top      Up      ToC       Page 77 
7.3.1.14.  Reinstate Recovery Qualifier (RRQ)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 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.

Top      Up      ToC       Page 78 
7.3.1.15.  Request Sequence Initiative (RSI)

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x0A |   0x00     |    0x00   |   0x00   |
         +------+------------+------------+-----------+----------+
         | 1    | Rsvd       |     Exchange Originator S_ID      |
         +------+------------+------------+-----------+----------+
         | 2    |          OX_ID          |         RX_ID        |
         +------+------------+------------+-----------+----------+
         | 3-10 |  Association Header (may be optionally req**d)  |
         +======+============+============+===========+==========+

         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type (see      (type 3 only)
         -------------------    Section 7.2)   ------------------
                                -----------

         Exchange Originator      1 or 2             N/A
         S_ID

         Other Special Processing:

            None.

Top      Up      ToC       Page 79 
7.3.1.16.  Scan Remote Loop (SRL)

   SRL allows a remote loop to be scanned to detect changes in the
   device configuration.  Any changes will trigger a fibre channel state
   change notification and subsequent update of the iSNS database.

      ELS Format:

         +------+------------+------------+-----------+----------+
         | Word | Bits 0-7   | Bits 8-15  | Bits 16-24|Bits 25-31|
         +------+------------+------------+-----------+----------+
         | 0    | Cmd = 0x7B |           Reserved                |
         +------+------------+------------+-----------+----------+
         | 1    | Flag       | Address Identifier of the FL_PORT |
         |      |            | (see B.1)                         |
         +======+============+============+===========+==========+
         | 2-3  | Worldwide Name of the Remote FL_PORT           |
         +======+============+============+===========+==========+

         Fields Requiring       Translation   Supplemental Data
         Address Translation     Type (see      (type 3 only)
         -------------------    Section 7.2)  ------------------
                                -----------

         Address Identifier         3         Worldwide Name of
         of the FL_PORT                       the Remote FL_PORT

   Other Special Processing:

      The D_ID field is the address of the Domain Controller associated
      with the remote loop.  The format of the Domain Controller address
      is the hex 'FF FC' || Domain_ID, where Domain_ID is the gateway-
      assigned alias representing the remote gateway or switch element
      being queried.  After translation by the remote gateway, the D_ID
      identifies the gateway or switch element to be scanned within the
      remote gateway region.

      The FLAG field defines the scope of the SRL.  If set to 0, all
      loop port interfaces on the given switch element or gateway are
      scanned.  If set to one, the loop port interface on the gateway or
      switch element to be scanned MUST be specified in bits 8 through
      31.

      If the Flag field is zero, the SRL request SHALL NOT be sent as a
      special ELS.

Top      Up      ToC       Page 80 
      If the Domain_ID represents a remote switch or gateway and an iFCP
      session to the remote Domain Controller does not exist, the
      requesting gateway SHALL create the iFCP session.

7.3.1.17.  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 0-7   |     Bits 8-15      |     Bits 16 - 31     |
   +--------+------------+--------------------+----------------------+
   | 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 22. Format of TPRLO ELS

   Each TPRLO parameter page contains parameters identifying one or more
   image pairs and may be associated with a single FC-4 protocol type
   that is common to all FC-4 protocol types between the specified image
   pair or global to all specified image pairs.  The format of a TPRLO
   page requiring address translation is shown in Figure 23.  Additional
   information on TPRLO can be found in [FC-FS].

Top      Up      ToC       Page 81 
      +------+------------+------------+-----------+----------+
      | Word | Bits 0-7   | Bits 8-15  |       Bits 16-31     |
      +------+------------+------------+-----------+----------+
      | 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  | Worldwide Name of Third Party Originator       |
      |      | N_PORT                                         |
      +------+------------------------------------------------+

        Figure 23. Format of an Augmented TPRLO Parameter Page

   The TPRLO flags that affect supplemented ELS processing are as
   follows:

   Bit 18:   Third party Originator N_PORT Validity.  When set to one,
             this bit indicates that word 3, bits 8-31 (Third Party
             Originator N_PORT ID), are meaningful.

   Bit 19:   Global Process logout.  When set to one, this bit indicates
             that all image pairs for all N_PORTs of the specified FC-4
             protocol shall be invalidated.  When the value of this bit
             is one, only one logout parameter page is permitted in the
             TPRLO payload.

   If bit 18 has a value of zero and bit 19 has a value of one in the
   TPRLO flags field, then the ELS SHALL NOT be sent as a special ELS.

   Otherwise, the originating gateway SHALL process the ELS as follows:

   a) The first word of the TPRLO payload SHALL NOT be modified.

   b) Each TPRLO parameter page shall be extended by two words as shown
      in Figure 23.

Top      Up      ToC       Page 82 
   c) If word 0, bit 18 (Third Party Originator N_PORT ID validity), in
      the TPRLO flags field has a value of one, then the sender shall
      place the worldwide port name of the fibre channel device's N_PORT
      in the extension words.  The N_PORT ID SHALL be set to 3.
      Otherwise, the contents of the extension words and the Third Party
      Originator N_PORT ID SHALL be set to zero.

   d) The ELS originator SHALL set the SPC bit in the encapsulation
      header of each augmented frame comprising the ELS (see Section
      5.3.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 18, 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 ID in word 3 shall be generated by
      referencing the supplemental data as described in Section 7.2.

   b) If word 0, bit 18, 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.

Top      Up      ToC       Page 83 
7.3.1.18.  Third Party Logout Accept (TPRLO ACC)

   The format of the TPRLO ACC frame is shown in Figure 24.

   +--------+------------+--------------------+----------------------+
   | Word   |  Bits 0-7  |     Bits 8-15      |     Bits 16 - 31     |
   +--------+------------+--------------------+----------------------+
   | 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 24. Format of TPRLO ACC ELS

   The format of the parameter page and rules for parameter page
   augmentation are as specified in Section 7.3.1.17.

7.3.2.  Special FC-4 Link Services

   The following sections define FC-4 link services for which special
   processing is required.

7.3.2.1.  FC-4 Link Services Defined by FCP

   The format of FC-4 link service frames defined by FCP can be found in
   [FCP-2].

7.3.2.1.1.  FCP Read Exchange Concise (FCP REC)

   The payload format for this link service is identical to the REC
   extended link service specified in Section 7.3.1.8 and SHALL be
   processed as described in that section.  The FC-4 version will become
   obsolete in [FCP-2].  However, in order to support devices
   implemented against early revisions of FCP-2, an iFCP gateway MUST
   support both versions.

Top      Up      ToC       Page 84 
7.3.2.1.2.  FCP Read Exchange Concise Accept (FCP REC ACC)

   The payload format for this link service is identical to the REC ACC
   extended link service specified in Section 7.3.1.9 and SHALL be
   processed as described in that section.  The FC-4 version will become
   obsolete in [FCP-2].  However, in order to support devices
   implemented against earlier revisions of FCP-2, an iFCP gateway MUST
   support both versions.

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.1.7.

      +------+------------+------------+-----------+----------+
      | Word | Bits 0-7   | Bits 8-15  |Bits 16-24 |Bits 25-31|
      +------+------------+------------+-----------+----------+
      | 0    | Cmd = 0x4  |   0x00     |    0x00   |   0x00   |
      |      | Acc = 0x2  |            |           |          |
      +------+------------+------------+-----------+----------+
      | 1-4  |            Common Service Parameters           |
      +------+------------+------------+-----------+----------+
      | 5-6  |            N_PORT Name                         |
      +------+------------+------------+-----------+----------+
      | 7-8  |            Node Name                           |
      +------+------------+------------+-----------+----------+
      | 9-12 |            Class 1 Service Parameters          |
      +------+------------+------------+-----------+----------+
      |13-17 |            Class 2 Service Parameters          |
      +------+------------+------------+-----------+----------+
      |18-21 |            Class 3 Service Parameters          |
      +------+------------+------------+-----------+----------+
      |22-25 |            Class 4 Service Parameters          |
      +------+------------+------------+-----------+----------+
      |26-29 |            Vendor Version Level                |
      +======+============+============+===========+==========+

           Figure 25. FLOGI Request and ACC Payload Format

   A full description of each parameter is given in [FC-FS].

   This section tabulates the protocol-dependent service parameters
   supported by a fabric port attached to an iFCP gateway.

Top      Up      ToC       Page 85 
   The service parameters carried in the payload of an FLOGI extended
   link service request MUST be set in accordance with Table 9.

      +-----------------------------------------+---------------+
      |                                         | 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 9. FLOGI Service Parameter Settings

   Notes:

      1) "n" indicates a parameter or capability that is not supported
         by the iFCP protocol.

      2) "M" indicates an applicable parameter that MUST be supported by
         an iFCP gateway.


Next RFC Part