tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7145

 
 
 

Internet Small Computer System Interface (iSCSI) Extensions for the Remote Direct Memory Access (RDMA) Specification

Part 5 of 5, p. 78 to 91
Prev RFC Part

 


prevText      Top      Up      ToC       Page 78 
11.  Security Considerations

   When iSER is layered on top of an RCaP layer and provides the RDMA
   extensions to the iSCSI protocol, the security considerations of iSER
   are the same as that of the underlying RCaP layer.  For iWARP, this
   is described in [RDMAP] and [RDDPSEC], plus the updates to both of
   those RFCs that are contained in [IPSEC-IPS].

   Since iSER-assisted iSCSI protocol is still functionally iSCSI from a
   security considerations perspective, all of the iSCSI security
   requirements as described in [iSCSI] apply.  If iSER is layered on
   top of a non-IP-based RCaP layer, all the security protocol
   mechanisms applicable to that RCaP layer are also applicable to an
   iSCSI/iSER connection.  If iSER is layered on top of a non-IP
   protocol, the IPsec mechanism as specified in [iSCSI] MUST be
   implemented at any point where the iSER protocol enters the IP
   network (e.g., via gateways), and the non-IP protocol SHOULD
   implement (optional to use) a packet-by-packet security protocol
   equal in strength to the IPsec mechanism specified by [iSCSI].

   In order to protect target RCaP connection resources from possible
   resource exhaustion attacks, allocation of such resources for a new
   connection MUST be delayed until it is reasonably certain that the
   new connection is not part of a resource exhaustion attack (e.g.,
   until after the SecurityNegotiation stage of Login); see Section
   5.1.2.

   A valid STag exposes I/O Buffer resources to the network for access
   via the RCaP.  The security measures for the RCAP and iSER described
   in the above paragraphs can be used to protect data in an I/O buffer
   from undesired disclosure or modification, and these measures are of
   heightened importance for implementations that retain (e.g., cache)
   STags for use in multiple tasks (e.g., iSCSI I/O operations) because
   the resources are exposed to the network for a longer period of time.

   A complementary means of controlling I/O Buffer resource exposure is
   invalidation of the STag after completion of the associated task, as
   specified in Section 1.5.1.  The use of Send with Invalidate messages
   (which cause remote STag invalidation) is OPTIONAL, therefore the
   iSER layer MUST NOT rely on use of a Send with Invalidate by its
   Remote Peer to cause local STag invalidation.  If an STag is expected
   to be invalid after completion of a task, the iSER layer MUST check
   the STag and invalidate it if it is still valid.

Top      Up      ToC       Page 79 
12.  IANA Considerations

   IANA has added the following entries to the "iSCSI Login/Text Keys"
   registry:

      MaxAHSLength, RFC 7145

      TaggedBufferForSolicitedDataOnly, RFC 7145

      iSERHelloRequired, RFC 7145

   IANA has updated the following entries in the "iSCSI Login/Text Keys"
   registry to reference this RFC.

      InitiatorRecvDataSegmentLength

      MaxOutstandingUnexpectedPDUs

      RDMAExtensions

      TargetRecvDataSegmentLength

   IANA has also changed the reference to RFC 5046 for the "iSCSI
   Login/Text Keys" registry to refer to this RFC.

   IANA has updated the registrations of the iSER Opcodes 1-3 in the
   "iSER Opcodes" registry to reference this RFC.  IANA has also changed
   the reference to RFC 5046 for the "iSER Opcodes" registry to refer to
   this RFC.

13.  References

13.1.  Normative References

   [RFC5046]   Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah,
               H., and P. Thaler, "Internet Small Computer System
               Interface (iSCSI) Extensions for Remote Direct Memory
               Access (RDMA)", RFC 5046, October 2007.

   [iSCSI]     Chadalapaka, M., Satran, J., Meth, K., and D. Black,
               "Internet Small Computer System Interface (iSCSI)
               Protocol (Consolidated)", RFC 7143, April 2014.

   [RDMAP]     Recio, R., Metzler, B., Culley, P., Hilland, J., and D.
               Garcia, "A Remote Direct Memory Access Protocol
               Specification", RFC 5040, October 2007.

Top      Up      ToC       Page 80 
   [DDP]       Shah, H., Pinkerton, J., Recio, R., and P. Culley,
               "Direct Data Placement over Reliable Transports", RFC
               5041, October 2007.

   [MPA]       Culley, P., Elzur, U., Recio, R., Bailey, S., and J.
               Carrier, "Marker PDU Aligned Framing for TCP
               Specification", RFC 5044, October 2007.

   [RDDPSEC]   Pinkerton, J. and E. Deleganes, "Direct Data Placement
               Protocol (DDP) / Remote Direct Memory Access Protocol
               (RDMAP) Security", RFC 5042, October 2007.

   [TCP]       Postel, J., "Transmission Control Protocol", STD 7, RFC
               793, September 1981.

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IPSEC-IPS] Black, D. and P. Koning, "Securing Block Storage
               Protocols over IP: RFC 3723 Requirements Update for IPsec
               v3", RFC 7146, April 2014.

13.2.  Informative References

   [SAM5]      INCITS Technical Committee T10, "SCSI Architecture Model
               - 5 (SAM-5)", T10/BSR INCITS 515 rev 04, Committee Draft.

   [iSCSI-SAM] Knight, F. and M. Chadalapaka, "Internet Small Computer
               System Interface (iSCSI) SCSI Features Update", RFC 7144,
               April 2014.

   [DA]        Chadalapaka, M., Hufferd, J., Satran, J., and H. Shah,
               "DA: Datamover Architecture for the Internet Small
               Computer System Interface (iSCSI)", RFC 5047, October
               2007.

   [IB]        InfiniBand Architecture Specification Volume 1 Release
               1.2, October 2004

   [IPoIB]     Chu, J. and V. Kashyap, "Transmission of IP over
               InfiniBand (IPoIB)", RFC 4391, April 2006.

Top      Up      ToC       Page 81 
Appendix A.  Summary of Changes from RFC 5046

   All changes are backward compatible with RFC 5046 except for item #8,
   which reflects all known implementations of iSER, each of which has
   implemented this change, despite its absence in RFC 5046.  As a
   result, a hypothetical implementation based on RFC 5046 will not
   interoperate with an implementation based on this version of the
   specification.

   1.  Removed the requirement that a connection be opened in "normal"
       TCP mode and transitioned to zero-copy mode.  This allows the
       specification to conform to existing implementations for both
       InfiniBand and iWARP.  Changes were made in Sections 1, 3.1.6,
       4.2, 5.1, 5.1.1, 5.1.2, 5.1.3, 10.1.3.4, and 11.

   2.  Added a clause in Section 6.2 to clarify that
       MaxRecvDataSegmentLength must be ignored if it is declared in the
       Login Phase.

   3.  Added a clause in Section 6.2 to clarify that the initiator must
       not send more than InitiatorMaxRecvDataSegmentLength worth of
       data when a NOP-Out request is sent with a valid Initiator Task
       Tag.  Since InitiatorMaxRecvDataSegmentLength can be smaller than
       TargetMaxRecvDataSegmentLength, returning the original data in
       the NOP-Out request in this situation can overflow the receive
       buffer unless the length of the data sent with the NOP-Out
       request is less than InitiatorMaxRecvDataSegmentLength.

   4.  Added a SHOULD negotiate recommendation for
       MaxOutstandingUnexpectedPDUs in Section 6.7.

   5.  Added MaxAHSLength key in Section 6.8 to set a limit on the AHS
       Length.  This is useful when posting receive buffers in knowing
       what the maximum possible message length is in a PDU that
       contains AHS.

   6.  Added TaggedBufferForSolicitedDataOnly key in Section 6.9 to
       indicate how the memory region will be used.  An initiator can
       treat the memory regions intended for unsolicited and solicited
       data differently and can use different registration modes.  In
       contrast, RFC 5046 treats the memory occupied by the data as a
       contiguous (or virtually contiguous, by means of scatter-gather
       mechanisms) and homogenous region.  Adding a new key will allow
       different memory models to be accommodated.  Changes were also
       made in Section 7.3.1.

Top      Up      ToC       Page 82 
   7.  Added iSERHelloRequired key in Section 6.10 to allow an initiator
       to allocate connection resources after the login process by
       requiring the use of the iSER Hello messages before sending iSCSI
       PDUs.  The default is "No" since iSER Hello messages have not
       been implemented and are not in use.  Changes were made in
       Sections 5.1.1, 5.1.2, 5.1.3, 8.2, 9.3, 9.4, 10.1.3.2, and
       10.1.3.4.

   8.  Added two 64-bit fields in iSER header in Section 9.2 for the
       Read Base Offset and the Write Base Offset to accommodate a non-
       zero Base Offset.  This allows one implementation such as the
       Open Fabrics Enterprise Distribution (OFED) stack to be used in
       both the InfiniBand and the iWARP environment.

       Changes were made in the definitions of Base Offset,
       Advertisement, and Tagged Buffer.  Changes were also made in
       Sections 1.5.1, 1.6, 1.7, 7.3.1, 7.3.3, 7.3.5, 7.3.6, 9.1, 9.3,
       9.4, 9.5.1, and 9.5.2.  This change is not backward compatible
       with RFC 5046, but it was part of all known implementations of
       iSER at the time this document was developed.

   9.  Remove iWARP-specific behavior.  Changes were made in the
       definitions of RDMA Operation and Send Message Type.

       Clarifications were added in Section 1.5.2 on the use of SendSE
       and SendInvSE.  These clarifications reflect a removal of the
       requirements in RFC 5046 for the use of these messages, as
       implementations have not followed RFC 5046 in this area.  Changes
       affecting Send with Invalidate were made in Sections 1.5.1, 1.6,
       1.7, 4.1, and 7.3.2.  Changes affecting Terminate were made in
       Sections 10.1.2.1 and 10.1.2.2.  Changes were made in Appendix B
       to remove iWARP headers.

   10. Removed denial-of-service descriptions for the initiator in
       Section 5.1.1 since they are applicable for the target only.

   11. Clarified in Section 1.5.1 that STag invalidation is the
       initiator's responsibility for security reasons, and the
       initiator cannot rely on the target using an Invalidate version
       of Send.  Added text in Section 11 on Stag invalidation.

Top      Up      ToC       Page 83 
Appendix B.  Message Format for iSER

   This section is for information only and is NOT part of the standard.

B.1.  iWARP Message Format for iSER Hello Message

   The following figure depicts an iSER Hello Message encapsulated in an
   iWARP SendSE Message.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MPA Header            |  DDP Control  | RDMA Control  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Reserved                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       (Send) Queue Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 (Send) Message Sequence Number                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      (Send) Message Offset                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0010b | Zeros | 0001b | 0001b |           iSER-IRD            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |

   |                           MPA CRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 6: SendSE Message Containing an iSER Hello Message

Top      Up      ToC       Page 84 
B.2.  iWARP Message Format for iSER HelloReply Message

   The following figure depicts an iSER HelloReply Message encapsulated
   in an iWARP SendSE Message.  The Reject (REJ) flag is set to zero.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         MPA Header            |  DDP Control  | RDMA Control  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Reserved                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       (Send) Queue Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 (Send) Message Sequence Number                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      (Send) Message Offset                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0011b |Zeros|0| 0001b | 0001b |           iSER-ORD            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           MPA CRC                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 7: SendSE Message Containing an iSER HelloReply Message

Top      Up      ToC       Page 85 
B.3.  iSER Header Format for SCSI Read Command PDU

   The following figure depicts a SCSI Read Command PDU embedded in an
   iSER Message.  For this particular example, in the iSER header, the
   Write STag Valid flag is set to zero, the Read STag Valid flag is set
   to one, the Write STag field is set to all zeros, the Write Base
   Offset field is set to all zeros, the Read STag field contains a
   valid Read STag, and the Read Base Offset field contains a valid Base
   Offset for the Read Tagged Buffer.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0001b |0|1|                  All zeros                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         All Zeros                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         All Zeros                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Read STag                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                       Read Base Offset                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SCSI Read Command PDU                   |
   //                                                             //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Figure 8: iSER Header Format for SCSI Read Command PDU

Top      Up      ToC       Page 86 
B.4.  iSER Header Format for SCSI Write Command PDU

   The following figure depicts a SCSI Write Command PDU embedded in an
   iSER Message.  For this particular example, in the iSER header, the
   Write STag Valid flag is set to one, the Read STag Valid flag is set
   to zero, the Write STag field contains a valid Write STag, the Write
   Base Offset field contains a valid Base Offset for the Write Tagged
   Buffer, the Read STag field is set to all zeros since it is not used,
   and the Read Base Offset field is set to all zeros.

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0001b |1|0|                  All zeros                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Write STag                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      Write Base Offset                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         All Zeros                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         All Zeros                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SCSI Write Command PDU                  |
   //                                                             //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Figure 9: iSER Header Format for SCSI Write Command PDU

Top      Up      ToC       Page 87 
B.5.  iSER Header Format for SCSI Response PDU

   The following figure depicts a SCSI Response PDU embedded in an iSER
   Message:

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0001b |0|0|                  All Zeros                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                           All Zeros                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       SCSI Response PDU                       |
   //                                                             //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 10: iSER Header Format for SCSI Response PDU

Top      Up      ToC       Page 88 
Appendix C.  Architectural Discussion of iSER over InfiniBand

   This section explains how an InfiniBand network (with Gateways) would
   be structured.  It is informational only and is intended to provide
   insight on how iSER is used in an InfiniBand environment.

C.1.  Host Side of iSCSI and iSER Connections in InfiniBand

   Figure 11 defines the topologies in which iSCSI and iSER will be able
   to operate on an InfiniBand Network.

   +---------+ +---------+ +---------+ +---------+ +--- -----+
   |  Host   | |  Host   | |   Host  | |   Host  | |   Host  |
   |         | |         | |         | |         | |         |
   +---+-+---+ +---+-+---+ +---+-+---+ +---+-+---+ +---+-+---+
   |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA| |HCA|
   +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+ +-v-+
     |----+------|-----+-----|-----+-----|-----+-----|-----+---> To IB
   IB|        IB |        IB |        IB |        IB |    SubNet2 SWTCH
   +-v-----------v-----------v-----------v-----------v---------+
   |                  InfiniBand Switch for Subnet1            |
   +---+-----+--------+-----+--------+-----+------------v------+
       | TCA |        | TCA |        | TCA |            |
       +-----+        +-----+        +-----+            | IB
      /  IB   \      /  IB   \      /       \     +--+--v--+--+
     |  iSER   |    |  iSER   |    |  IPoIB  |    |  | TCA |  |
     | Gateway |    | Gateway |    | Gateway |    |  +-----+  |
     |   to    |    |   to    |    |   to    |    | Storage   |
     |  iSCSI  |    |  iSER   |    |   IP    |    | Controller|
     |   TCP   |    |  iWARP  |    |Ethernet |    +-----+-----+
     +---v-----|    +---v-----|    +----v----+
         | EN           | EN            | EN
         +--------------+---------------+----> to IP based storage
           Ethernet links that carry iSCSI or iWARP

                Figure 11: iSCSI and iSER on IB

   In Figure 11, the Host systems are connected via the InfiniBand Host
   Channel Adapters (HCAs) to the InfiniBand links.  With the use of IB
   switch(es), the InfiniBand links connect the HCA to InfiniBand Target
   Channel Adapters (TCAs) located in gateways or Storage Controllers.
   An iSER-capable IB-IP Gateway converts the iSER Messages encapsulated
   in IB protocols to either standard iSCSI, or iSER Messages for iWARP.
   An [IPoIB] Gateway converts the InfiniBand [IPoIB] protocol to IP
   protocol, and in the iSCSI case, permits iSCSI to be operated on an
   IB Network between the Hosts and the [IPoIB] Gateway.

Top      Up      ToC       Page 89 
C.2.  Storage Side of iSCSI and iSER Mixed Network Environment

   Figure 12 shows a storage controller that has three different portal
   groups: one supporting only iSCSI (TPG-4), one supporting iSER/iWARP
   or iSCSI (TPG-2), and one supporting iSER/IB (TPG-1).  Here, "TPG"
   stands for "Target Portal Group".

                  |                |                |
                  |                |                |
            +--+--v--+----------+--v--+----------+--v--+--+
            |  | IB  |          |iWARP|          | EN  |  |
            |  |     |          | TCP |          | NIC |  |
            |  |(TCA)|          | RNIC|          |     |  |
            |  +-----|          +-----+          +-----+  |
            |   TPG-1            TPG-2            TPG-4   |
            |  9.1.3.3          9.1.2.4          9.1.2.6  |
            |                                             |
            |                  Storage Controller         |
            |                                             |
            +---------------------------------------------+

   Figure 12: Storage Controller with TCP, iWARP, and IB Connections

   The normal iSCSI portal group advertising processes (via the Service
   Location Protocol (SLP), Internet Storage Name Service (iSNS), or
   SendTargets) are available to a Storage Controller.

C.3.  Discovery Processes for an InfiniBand Host

   An InfiniBand Host system can gather portal group IP addresses from
   SLP, iSNS, or the SendTargets discovery processes by using TCP/IP via
   [IPoIB].  After obtaining one or more remote portal IP addresses, the
   Initiator uses the standard IP mechanisms to resolve the IP address
   to a local outgoing interface and the destination hardware address
   (Ethernet MAC or InfiniBand Global Identifier (GID) of the target or
   a gateway leading to the target).  If the resolved interface is an
   [IPoIB] network interface, then the target portal can be reached
   through an InfiniBand fabric.  In this case, the Initiator can
   establish an iSCSI/TCP or iSCSI/iSER session with the Target over
   that InfiniBand interface, using the hardware address (InfiniBand
   GID) obtained through the standard Address Resolution Protocol (ARP)
   processes.

   If more than one IP address is obtained through the discovery
   process, the Initiator should select a Target IP address that is on
   the same IP subnet as the Initiator, if one exists.  This will avoid
   a potential overhead of going through a gateway when a direct path
   exists.

Top      Up      ToC       Page 90 
   In addition, a user can configure manual static IP route entries if a
   particular path to the target is preferred.

C.4.  IBTA Connection Specifications

   It is outside the scope of this document, but it is expected that the
   InfiniBand Trade Association (IBTA) has or will define:

   *  The iSER ServiceID

   *  A means for permitting a Host to establish a connection with a
      peer InfiniBand end-node, and that peer indicating when that end-
      node supports iSER, so the Host would be able to fall back to
      iSCSI/TCP over [IPoIB].

   *  A means for permitting the Host to establish connections with IB
      iSER connections on storage controllers or IB iSER-connected
      Gateways in preference to IPoIB-connected Gateways/Bridges or
      connections to Target Storage Controllers that also accept iSCSI
      via [IPoIB].

   *  A means for combining the IB ServiceID for iSER and the IP port
      number such that the IB Host can use normal IB connection
      processes, yet ensure that the iSER target peer can actually
      connect to the required IP port number.

Appendix D.  Acknowledgments

   The authors acknowledge the following individuals for identifying
   implementation issues and/or suggesting resolutions to the issues
   clarified in this document: Robert Russell, Arne Redlich, David
   Black, Mallikarjun Chadalapaka, Tom Talpey, Felix Marti, Robert
   Sharp, Caitlin Bestler, Hemal Shah, Spencer Dawkins, Pete Resnick,
   Ted Lemon, Pete McCann, and Steve Kent.  Credit also goes to the
   authors of the original iSER Specification [RFC5046], including
   Michael Ko, Mallikarjun Chadalapaka, John Hufferd, Uri Elzur, Hemal
   Shah, and Patricia Thaler.  This document benefited from all of their
   contributions.

Top      Up      ToC       Page 91 
Authors' Addresses

   Michael Ko

   EMail: mkosjc@gmail.com


   Alexander Nezhinsky
   Mellanox Technologies
   13 Zarchin St.
   Raanana 43662
   Israel

   Phone: +972-74-712-9000
   EMail: alexandern@mellanox.com, nezhinsky@gmail.com