Description of Working Group:

InfiniBand is an emerging standard intended as an interconnect for
processor and I/O systems and devices (see the Infiniband Trade
Association web site at http://www.infinibandta.org for details). IP
is one type of traffic (and a very important one) that could use this
interconnect. InfiniBand would benefit greatly from a standardized
method of handling IP traffic on IB fabrics. It is also important to
be able to manage InfiniBand devices in a common way.

This working group has two tasks:

- specify the protocols and encapsulations to transport IPv4/v6 over
an InfiniBand fabric.

- specify a set of MIB objects to allow management of the InfiniBand
fabric itself.

The initial scope of the WG was limited to the use of the basic IB
Unreliable Datagram (UD) transport mode for transporting IP over
Infiniband. With that work mostly done, the scope has been extended to
develop an optional mechanism for transporting IP over other IB
transport modes. In particular, there is a desire to transport IP over
one or both of IB's connected modes, which enable the use of a much
larger MTU than the IB link MTU size. They also provide improved
reliability and performance through the use of link level orderly and
reliable delivery, and IB's automatic path migration (APM) feature.
However, care must be taken to ensure that use of an IB reliable
transport does not unduly interfere with the retransmission and
congestion control mechanisms used by higher layers (e.g., TCP and
SCTP).

Other more advanced functionalities such as mapping IP QOS into
IB-specific capabilities remain out of scope of the WG charter.

No Request For Comments

IP over InfiniBand: 55th IETF Atlanta (11/18/02 - Meeting Minutes by Sunay
Tripathi)
========================================
==========================
Agenda
Charter update
IPoIB MIBs status
IPoIB connected mode
Wrap up
Charter Update - Jerry Chu (Sun Microsystems)
IPoIB connected mode was added and approved by IESG.
Care must be taken to avoid interference between reliability
algoriths at different level.
See the updated WG web page
http://www.ietf.org/html.charters/ipoib-charter.html
Drafts under IESG review
Link and multicast draft
Encapsulation draft
DHCP over IB draft
ADs have already commented. Need to address ADs comments.
MIBs Status - Sean Harnedy (InfiniSwitch corporation).
6 MIBs currently defined in the WG charter
Sean discussed the current status of each MIB (what was the current
revision etc).
Next steps -
Interest in defining new MIBS?
Update IDs to new 1.1 IBTA sepc.
Advance current MIB work.
Gather any implementation experience.
Any Interest in a IPoIB Management overview doc?
Advance certain IPoIB MIB to WG last call.
IPoIB connected mode - Vivek Kashyap (IBM)
Vivek will mail out the presentation slides to the mailing list. The
main point in the presentation was you need to know the destination GID to
initiate connection and possibilities on how to resolve the GID.
Jerry asked if the proposal uses IP address hosted on a UD QP to
identify its equivalent RC/UC QP, wouldn't it require a thousand IB
connections when there are a thousand IP addresses hosted on the same UD QP
interface? Vivek said he needs to think about this. Jerry mentioned a
similar issue with the UD QPN - it takes GID+QPN (UD) to uniquely
idetifiy an IPoIB link interface. But UD-QPN is not present in the
proposal when identifying RC/UC QP.
Some discussions continued on how MTU is determined. AD commented that
it's probably worth defining a default MTU for IPoIB UC/RC to save some
trouble. A follow-on comment was made on using two separate
connections for IPv6 and IPv4 because the former supports jumbograms (>
64KB).
Wrap up - Jerry Chu
Now that the IBA 1.1 specs have been released, Jerry asked the draft
authors to verify the contents of their drafts against the 1.1 specs.
AD (Thomas Narten) asked how much more change is expected in the
future, e.g. what is the next IBA release (2.0?) and when? Will any
future change require modifications to the IPoIB specs? Jerry believed that
is unlikely because IBTA must maintain a high degree of
compatibility between newer specs and the old ones. The 1.1 release
mainly addresses the management and multicast areas, both are
incomplete in the 1.0 release.
No more questions were asked so the WG meeting was concluded.