Last Modifield: 05/13/2002
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.
1. Specify standards track procedures for transporting IP over IB. This includes:
- supporting ARP/ND packets in order to map IP addresses into IB link-layer addresses.
- define encapsulations for carrying ARP, IPv4 and IPv6 packets over IB
- Define how to transport IP multicast over IB.
2. Specify a standards track channel adapter MIB that allows management of an InfiniBand channel adapter. There will require that InfiniBand types be added to the ifType defined by IANA
3. Specify a standards track baseboard management MIB that will allow management of specified device properties
4. Specify sample counter MIBs to allow InfiniBand sample counters to be exposed to external SNMP management applications
5. Specify an optional, standards track encapsulation for carrying IPv4 and IPv6 packets over either IB unreliable connections or reliable connections.
|Done||Submit initial Internet-Draft of ARP encapsulation|
|Done||Submit initial Internet-Draft of Requirements/Overview|
|Done||Submit initial Internet-Draft of IP V4/V6 Encapsulation|
|Done||Submit initial Internet-Draft of Infiniband-Like MIB|
|JUL 01||Submit initial Internet-Draft of Channel Adapter MIB|
|Done||Submit initial Internet-Draft of Multicast|
|NOV 01||Submit initial Internet-Draft of Baseboard MIB|
|NOV 01||Submit initial Internet-Draft of Sample Counter MIB|
|FEB 02||Submit initial Internet-Draft of Subnet Mangement MIB|
|MAR 02||Submit ARP/IP/Multicast encapsulation drafts for IESG Last Call|
|MAR 02||Submit Infiniband-Like MIB for IESG Last Call|
|MAR 02||Submit Channel Adapter MIB for IESG Last Call|
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.