Hello,
I had an email exchange with the iSER folks earlier this summer where I
submitted the attached proposal for consideration. It does not contain
the local port number because nobody seems to set it to a meaningful
value. More food for thought.
-David
Roland Dreier wrote:
Roland> I have a few minor quibbles with this proposal. I think
Roland> it would be better to have only the IP version, source and
Roland> destination IPs and local in the CM private data.
err-- "...and local PORT NUMBER in the CM private data..."
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
--- Begin Message ---
I'd like to propose a
standard IBTA
Hello/HelloAck message carried in the CM private data area and IANA
port number to IB service ID mapping for use by IETF RDMA protocols
mapped onto IB. I'm hoping that this extension will enable iSER, NFS,
and perhaps future iWARP ULPs to transmit IP address information that
is needed for authentication and advertise well-known service locations.
The proposal
consists of the following changes to version 1.2 of volume 1 IBTA
specification:
1) When the Service ID is in the IBTA assigned range as described in
section A3.2.3.1 where byte 6 is set to 0x02, the CM REQ packet
will contain the following
Hello message starting at offset 140 (start of private data area):
bit 0 1 2
3
byte 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | MajV | MinV | IPV | Cap | Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | Src IP (127-96)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | Src IP (
95-64)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15 | Src IP (
63-32)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19 | Src IP (
31-00)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
20-23 | Dst IP
(127-96)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
24-27 | Dst IP (
95-64)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
28-31 | Dst IP (
63-32)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
32-35 | Dst IP (
31-00)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
- MajV (4 bits) - The Major Protocol version number. The value
must be
set to 1. The accepting peer shall reject the connection if MajV in
the Hello message does not match its local value.
- MinV (4 bits) - The Minor Protocol version number.
The value
must be set to 1. The accepting peer shall not reject the
connection, solely on the basis that MinV of the Hello message does not
match its
local value. This enables future protocol extensions which are
upwardly compatible.
- IPV (4 bits) - The Internet Protocol version number of the
end-point
address field (fields Src IP and Dst IP). If IPV = 0x4, the IP
addresses are IP version 4
format (32 bit addresses). If IPV = 0x6, then both IP addresses are IP
version 6 format (128 bit addresses). All other IPV values are
reserved. The accepting peer shall reject the connection if IPV of the
Hello message has a value other than 0x4 or 0x6.
- Cap (4 bits) - The Capabilities field conveys the connecting
peer’s
capabilities. The following capabilities are defined:
| Bit Position |
Capability
|
Description
|
0
|
INVALIDATE_CAP
|
Supports incoming Send w/Invalidate
opcode
|
1
|
VABTO_CAP |
Supports incoming ZBVA Messages |
2-3
|
reserved
|
transmitted as zero and not checked at receiver
|
where:
- The connecting peer shall set the INVALIDATE_CAP bit in the
Cap field
in Hello Message only if it can support incoming invalidate messages.
If the accepting peer does not support Send w/Invalidate, it will
ignore the Invalidate Capability advertisement.
- The connecting peer shall set the ZBVA_CAP bit in the Cap
field in Hello Message only if it can support Zero based
Virtual Addresses (ZBVA). If the accepting peer does not
support ZBVA, it
will ignore the ZBVA Capability advertisement.
- Internet Protocol Address (128 bits) - The Internet Protocol
(IP)
address for the local interface (Src IP) and remote interface (Dst
IP). These can be either IPv4 or IPv6 addresses, as specified by the
IPV field. If Src IP and Dst IP of the Hello Message are IPv4
addresses, as
specified by the IPV field, then Src IP (31-0) and Dst IP (31-0) shall
be used to transmit the source and destination IP addresses,
respectively, and bits Src IP (127-32) and Dst IP (127-32) shall be set
to zero.
and the CM REP packet will contain the following HelloAck
Message starting at offset 36 (start of private data area):
bit 0 1
2
3
byte 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-4 | MajV | MinV | Rsrd | Cap | Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
- MajV (4 bits) - The Major Protocol version number. The value
must
be set to 1. The accepting peer shall reject the connection if MajV in
the HelloAck message does not match its local value.
- MinV (4 bits) - The Minor Protocol version number.
The value
must be set to 1.
The accepting peer shall not reject the connection, solely on the basis
that MinV of the HelloAck Message does not match its local value. This
enables
future protocol extensions which are upwardly compatible.
- Cap (4 bits) - The Capabilities field conveys the connecting
peer’s
capabilities. The following capabilities are defined:
| Bit Position |
Capability
|
Description
|
0
|
INVALIDATE_CAP
|
Supports incoming Send w/Invalidate
opcode
|
1
|
ZBVA_CAP |
Supports incoming ZBVA messages |
2-3
|
reserved
|
transmitted as zero and not checked at receiver
|
where:
- The connecting peer shall set the INVALIDATE_CAP bit in the
Cap field
in Hello Message only if it can support incoming invalidate messages.
If the accepting peer does not support Send w/Invalidate, it will
ignore the Invalidate Capability advertisement.
- The connecting peer shall set the ZBVA_CAP bit in the Cap
field in Hello Message only if it can support Zero based
Virtual Addresses (ZBVA). If the accepting peer does not
support ZBVA, it
will ignore the ZBVA Capability advertisement.
2) In addition, the format of the IBTA service IDs as
described in section A3.2.3.1 will be extended to
include an "iWARP port" range where byte 6 is set to 0x02 and byte 7
and
8 contain the IANA assigned TCP port number. For example, the port
number would be:
- 2049, the default port number, for NFS.
- 3260, the the default port number, for iSER.
Note, some iWARP ULPs exchange RDMA parameters, such as IRD and ORD,
during connection setup. These ULPs should either (a) establish a TCP
connection to exchange these parameters, or (b) use the remaining CM
private data after the proposed Hello/HelloAck message
described above. Also note,
the
there is no local port in the Hello message because no requirement for
it has been identified.
|
--- End Message ---
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
