Download PPT Version

iSER on SCTP & IB
draft-hufferd-ips-iser-sctp-ib-00.txt
Generalizations to iSER specification
John Hufferd
Mike Ko
Yaron Haviv
Abstract
• The iSCSI Extensions for RDMA document currently
specifies the RDMA data transfer capability for iSCSI
over iWARP/TCP
• This new document generalizes the iSER document to
permit it to be used with other RDMA capable protocols
such as
– iWARP/SCTP
– InfiniBand
– etc.
• It also describes what should be defined in the InfiniBand
Trade Association and what things are appropriate for
specification in the IETF
2
Motivation
• Current wordage in iSER is only applicable to iSER on
iWARP/TCP
• It was felt that the protocol should be made generic for
RDMA LLPs, and that includes:
– iWARP/SCTP
– InfiniBand
– Etc.
• Makes an iSCSI based protocol apply across more
Networks, and eliminates some of the management and
discovery protocols that would otherwise be needed
– For example, would not have to fix the short comings of SRP
(SCSI RDMA Protocol) on IB
Goals
• To specify changes/adjustments that should be
considered to the wordage in the iSER
document to make it more General
• These changes should not modify the basic
operation of iSCSI/iSER when operating on
iWARP/TCP
• Some of the terminology needed to be clarified
as to the applicability of the terms to the actual
LLP used
Examples of changes (1)
• The term “iWARP protocol suite” is replaced by
“RDMA-Capable Protocol”
• The term “iWARP layer” will be replaced by
“RDMA-capable protocol layer”
• Wherever the “iWARP” term is specific to the TCP
implementation, it will be replaced with
“iWARP/TCP”
• The term “RNIC” will be replaced with “RDMACapable Controller”
– The clause “such as an RNIC” will be added as needed
Examples of changes (2)
• The Steering Tag (STag) term will have its definition
extended such at the IB “Local Steering Tag (L-Key)” and
the “Remote Steering Tag (R-Key)” are included in the
STag definition by way of example
• The Definitions for IRD and ORD terms will have their
definition extended such that the IB “Responder
Resources”, and Initiator Depth” are included in the
definitions by way of example
• The Term RDMA-capable protocol (RCP) will be defined
and used when ever any RDMA wire protocol or RDMA
protocol stack is applicable
– RDMAP should be used only when it explicitly refers the iWARP
protocol (TCP or SCTP)
Examples of changes (3)
• The Term “RDMAP Stream” will be replaced by
the term “RCP Stream” and defined as:
– RCP Stream - A single bidirectional association
between the peer RDMA-capable protocol layers on
two Nodes over a single transport-level stream.
• For TCP or SCTP, an RCP Stream is also known as an
RDMAP Stream.
• For iSER/TCP, the association is created when the
connection transitions to iSER-assisted mode following a
successful Login Phase during which iSER support is
negotiated.
– Needed since SCTP and IB start their RCP stream
mode at connection time
Examples of changes (4)
• The term “RCP Message” should be defined and
used as a replacement for the term “RDMAP
Message” the definition will be:
– RCP Message – The sequence of packets of the
RDMA-capable protocol which represent a single
RDMA operation or a part of RDMA Read Operation.
For TCP or SCTP, an RCP Message is also known as
an RDMAP Message
• When discussing the iSER Hello and HelloReply
Messages the term "iSER Message" will be used
– Instead of “RDMAP Message”
– This distinction is needed in order to accommodate
LLPs that have native message delivery capability,
such as SCTP or IB
Example of Changes (5)
• We permit the iSCSI layer (if appropriate) to use the
RCP message mode capability immediately after
connection establishment before enabling iSER-assisted
mode
– Appropriate for SCTP or IB
– In this case the iSER Hello and HelloReply Messages are not
the first RCP Messages, but they are the first iSER Messages
• Added a discussion of connection establishment along
with the use of the “RCP messaging protocol”, for
exchanging Login Request and Login Response
Messages
– Examples are discussed that are appropriate for SCTP and IB,
along with the transitioning of the connection to iSER mode
Examples of changes (6)
• The discussion of Security specifies that
all non IP protocols will define their own
requirements for IPsec
– However the iSCSI requirements for IPsec are
still required:
• Wherever an iSER Message enters an IP
environment from a non IP one (such as IB)
– The iSCSI/iSER requirement for IPsec on IP
based protocols such as TCP and SCTP
• Will continue to require IPsec as a must implement
Generic example of iSCSI/iSER
layering in Full Feature Mode
IB Informative Section
• Information on how iSER would be used in an IB
network is included in the Draft
– Not intended to be included in the iSER draft unless
included in an informational Appendix
– Various Network topologies are shown
• Host Side IB Network, including Gateways
• Storage Side that includes iSER/IB
– IB iSER discovery process is described
• Use of IP over IB (IPoIB)
– SendTargets
– SLP
– iSNS
• Conversion of IP address into IB GID via ARP processes
– Discussion of what the IBTA needs to define
Host Side iSER/IB Topology
Storage Side with iSER/IB
Info: What the IBTA needs to define
• Means for permitting a Host to establish an iSCSI/iSER connection
with a peer InfiniBand end-node
– Indicating when that end node does not support iSER
• So the Host would be able to fall back to iSCSI/TCP over IPoIB
• 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 accept iSCSI via IPoIB
• How to operate in an environment where ZBTO, and SendInvSE are
optional
• iSER ServiceID
• How the ServiceID can be added to the IP port number during the
connection process
Info: Key Implementation areas that
do NOT require IBTA specification
• How implementations determine which
iSCSI/iSER portal group to use
– Basing the decision on new information that may be
placed in the iSCSI discovery information is
Not required
– Simple trial selection is acceptable
• How implementations determine how to best
handle the concept of MC/S as it deals with
multiple IB Addresses:Ports per Portal Group
Preferred Change to Discovery Data
• Useful to have a connection type associated with the
Portal Group Tag
– Will permit the most appropriate connections to be made without
needless connection tries and failures
– Useful for iSER/iWARP/TCP
– Useful for iSER/iWARP/SCTP
– Useful for iSER/IB
– Proposed Syntax
• IP Address:Port[, PG#[, Type#]]
Portal Group Type
iSCSI
iSER/iWARP/TCP
iSER/iWARP/SCTP
iSER/iWARP/IB
IANA Portal Group Type Value
0, or blank
1
2
3
Recommendations
• Have Mike Ko update the iSER wordage
as indicated by this draft
• Include the IB sections as Informational
Appendices in iSER draft
• Send Discovery Data changes to the
authors of iSCSI, iSNS, & SLP for iSCSI