From ipoverib-admin@ietf.org Thu Apr 3 00:11:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24657 for ; Thu, 3 Apr 2003 00:11:18 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335CMK26834; Thu, 3 Apr 2003 00:12:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335BLK26777 for ; Thu, 3 Apr 2003 00:11:21 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24635 for ; Thu, 3 Apr 2003 00:08:44 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA29508 for ; Wed, 2 Apr 2003 22:11:11 -0700 (MST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h335BB2J617298; Wed, 2 Apr 2003 21:11:11 -0800 (PST) Message-Id: <200304030511.h335BB2J617298@jurassic.eng.sun.com> Date: Wed, 2 Apr 2003 21:11:08 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-03.txt To: Kanoj.Sarcar@Sun.COM Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Krfn7d0Iqh4/jKyrzasQZw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, ... >Of course, if the typical case is that join/attach will not fail >(ie the number of mcg's are not too great), we can probably punt >on this, but at least with a note that a limit on the number of >IP multicast groups exists depending on member hca's and fabric >(switch/SM) capability. How about adding the following note to the draft regarding this vunerability? 11.0 New Vunerability in IB Multicast Many IB multicast functions are subject to new types of failure due to resource constrains compared to Ethernet multicast. This includes the creation of an IB multicast group, the join call, both the "SendOnlyNonMember", the "FullMember", and the "NonMember" joins, and the attaching of a QP to a multicast group. In general, these failure conditions are implementation dependent, and are believed to be rare. Usually a failure can be propagated back to a foreground operation to cause the operation to fail. But some IB multicast functions are not tied to any foreground operation, making their failures difficult to notice. E.g., if an IP multicast router attempts to "NonMember" join a newly created multicast group in the local subnet, but the join call fails, packet forwarding for that particular multicast group will likely to fail silently without the notice of local multicast senders. This type of problems add more vulnerability to the already unreliable IP multicast operations. Implementations should log error messages upon any IB multicast failure. Network administrators should be aware of this vulnerability, and preserve enough multicast resources if IP multicast will be used heavily, or a certain degree of reliability is expected. Thanks, Jerry > >Thanks. > >Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Apr 3 00:59:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24666 for ; Thu, 3 Apr 2003 00:11:18 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h335DO326879 for ipoverib-archive@odin.ietf.org; Thu, 3 Apr 2003 00:13:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335DOK26876 for ; Thu, 3 Apr 2003 00:13:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24649 for ; Thu, 3 Apr 2003 00:10:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335CMK26834; Thu, 3 Apr 2003 00:12:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h335BLK26777 for ; Thu, 3 Apr 2003 00:11:21 -0500 Received: from patan.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24635 for ; Thu, 3 Apr 2003 00:08:44 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA29508 for ; Wed, 2 Apr 2003 22:11:11 -0700 (MST) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h335BB2J617298; Wed, 2 Apr 2003 21:11:11 -0800 (PST) Message-Id: <200304030511.h335BB2J617298@jurassic.eng.sun.com> Date: Wed, 2 Apr 2003 21:11:08 -0800 (PST) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-03.txt To: Kanoj.Sarcar@Sun.COM Cc: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Krfn7d0Iqh4/jKyrzasQZw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Kanoj, ... >Of course, if the typical case is that join/attach will not fail >(ie the number of mcg's are not too great), we can probably punt >on this, but at least with a note that a limit on the number of >IP multicast groups exists depending on member hca's and fabric >(switch/SM) capability. How about adding the following note to the draft regarding this vunerability? 11.0 New Vunerability in IB Multicast Many IB multicast functions are subject to new types of failure due to resource constrains compared to Ethernet multicast. This includes the creation of an IB multicast group, the join call, both the "SendOnlyNonMember", the "FullMember", and the "NonMember" joins, and the attaching of a QP to a multicast group. In general, these failure conditions are implementation dependent, and are believed to be rare. Usually a failure can be propagated back to a foreground operation to cause the operation to fail. But some IB multicast functions are not tied to any foreground operation, making their failures difficult to notice. E.g., if an IP multicast router attempts to "NonMember" join a newly created multicast group in the local subnet, but the join call fails, packet forwarding for that particular multicast group will likely to fail silently without the notice of local multicast senders. This type of problems add more vulnerability to the already unreliable IP multicast operations. Implementations should log error messages upon any IB multicast failure. Network administrators should be aware of this vulnerability, and preserve enough multicast resources if IP multicast will be used heavily, or a certain degree of reliability is expected. Thanks, Jerry > >Thanks. > >Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Thu Apr 3 13:01:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04466 for ; Thu, 3 Apr 2003 13:01:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I3EK09125; Thu, 3 Apr 2003 13:03:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I2wK09111 for ; Thu, 3 Apr 2003 13:02:58 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04412 for ; Thu, 3 Apr 2003 13:00:06 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18904 for ; Thu, 3 Apr 2003 11:02:34 -0700 (MST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33I2XHP001102 for ; Thu, 3 Apr 2003 10:02:33 -0800 (PST) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HCS004DT4S9VT@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Thu, 03 Apr 2003 10:02:33 -0800 (PST) Date: Thu, 03 Apr 2003 10:02:33 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-03.txt To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E8C7739.B4733541@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200304030511.h335BB2J617298@jurassic.eng.sun.com> Content-Transfer-Encoding: 7BIT Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT "H.K. Jerry Chu" wrote: > > Kanoj, > ... > > > >Of course, if the typical case is that join/attach will not fail > >(ie the number of mcg's are not too great), we can probably punt > >on this, but at least with a note that a limit on the number of > >IP multicast groups exists depending on member hca's and fabric > >(switch/SM) capability. > > How about adding the following note to the draft regarding this > vunerability? Jerry, Looks good, just one comment below. > > 11.0 New Vunerability in IB Multicast > > Many IB multicast functions are subject to new types of failure due > to resource constrains compared to Ethernet multicast. This includes > the creation of an IB multicast group, the join call, both the > "SendOnlyNonMember", the "FullMember", and the "NonMember" joins, and > the attaching of a QP to a multicast group. > > In general, these failure conditions are implementation dependent, > and are believed to be rare. Usually a failure can be propagated back > to a foreground operation to cause the operation to fail. But some IB > multicast functions are not tied to any foreground operation, making > their failures difficult to notice. E.g., if an IP multicast router > attempts to "NonMember" join a newly created multicast group in the > local subnet, but the join call fails, packet forwarding for that > particular multicast group will likely to fail silently without the > notice of local multicast senders. This type of problems add more > vulnerability to the already unreliable IP multicast operations. > > Implementations should log error messages upon any IB multicast > failure. Network administrators should be aware of this > vulnerability, and preserve enough multicast resources if IP > multicast will be used heavily, or a certain degree of reliability is > expected. How about somehow adding in verbiage like (this takes care of the most likely cause of above mentioned failure): E.g, making sure the IP multicast router is using an HCA with ample IBA multicast resources. Thanks. Kanoj > > Thanks, > > Jerry > > > > >Thanks. > > > >Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Thu Apr 3 13:01:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04474 for ; Thu, 3 Apr 2003 13:01:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33I4CT09172 for ipoverib-archive@odin.ietf.org; Thu, 3 Apr 2003 13:04:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I4CK09169 for ; Thu, 3 Apr 2003 13:04:12 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04445 for ; Thu, 3 Apr 2003 13:01:19 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I3EK09125; Thu, 3 Apr 2003 13:03:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33I2wK09111 for ; Thu, 3 Apr 2003 13:02:58 -0500 Received: from pheriche.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04412 for ; Thu, 3 Apr 2003 13:00:06 -0500 (EST) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18904 for ; Thu, 3 Apr 2003 11:02:34 -0700 (MST) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail2sun.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h33I2XHP001102 for ; Thu, 3 Apr 2003 10:02:33 -0800 (PST) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HCS004DT4S9VT@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Thu, 03 Apr 2003 10:02:33 -0800 (PST) Date: Thu, 03 Apr 2003 10:02:33 -0800 From: Kanoj Sarcar Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-03.txt To: "H.K. Jerry Chu" Cc: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E8C7739.B4733541@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200304030511.h335BB2J617298@jurassic.eng.sun.com> Content-Transfer-Encoding: 7BIT Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT "H.K. Jerry Chu" wrote: > > Kanoj, > ... > > > >Of course, if the typical case is that join/attach will not fail > >(ie the number of mcg's are not too great), we can probably punt > >on this, but at least with a note that a limit on the number of > >IP multicast groups exists depending on member hca's and fabric > >(switch/SM) capability. > > How about adding the following note to the draft regarding this > vunerability? Jerry, Looks good, just one comment below. > > 11.0 New Vunerability in IB Multicast > > Many IB multicast functions are subject to new types of failure due > to resource constrains compared to Ethernet multicast. This includes > the creation of an IB multicast group, the join call, both the > "SendOnlyNonMember", the "FullMember", and the "NonMember" joins, and > the attaching of a QP to a multicast group. > > In general, these failure conditions are implementation dependent, > and are believed to be rare. Usually a failure can be propagated back > to a foreground operation to cause the operation to fail. But some IB > multicast functions are not tied to any foreground operation, making > their failures difficult to notice. E.g., if an IP multicast router > attempts to "NonMember" join a newly created multicast group in the > local subnet, but the join call fails, packet forwarding for that > particular multicast group will likely to fail silently without the > notice of local multicast senders. This type of problems add more > vulnerability to the already unreliable IP multicast operations. > > Implementations should log error messages upon any IB multicast > failure. Network administrators should be aware of this > vulnerability, and preserve enough multicast resources if IP > multicast will be used heavily, or a certain degree of reliability is > expected. How about somehow adding in verbiage like (this takes care of the most likely cause of above mentioned failure): E.g, making sure the IP multicast router is using an HCA with ample IBA multicast resources. Thanks. Kanoj > > Thanks, > > Jerry > > > > >Thanks. > > > >Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Tue Apr 8 20:58:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10189 for ; Tue, 8 Apr 2003 20:58:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3912N815974; Tue, 8 Apr 2003 21:02:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3911i815945 for ; Tue, 8 Apr 2003 21:01:44 -0400 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10135 for ; Tue, 8 Apr 2003 20:56:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA01679 for ; Tue, 8 Apr 2003 17:58:48 -0700 (PDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h390wmcU012942 for ; Tue, 8 Apr 2003 17:58:48 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HD100MH9XE0FW@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Tue, 08 Apr 2003 17:58:48 -0700 (PDT) Date: Tue, 08 Apr 2003 17:58:48 -0700 From: Kanoj Sarcar To: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E937048.564A18C7@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] DHCP clarification Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Hi, While going over section 2 of ipoib/dhcp draft, I realized that it can be cleaned up somewhat (in my opinion, ie; to others, it might be quite clear already). Accordingly, I came up with the following verbiage. If there are some improvements in here, it should be used to reword the section. 2.2 Use of the BROADCAST flag A DHCP client on IPoIB MUST set the BROADCAST flag (and set 'ciaddr' to zero) in DHCPREQUEST messages and DHCPDISCOVER messages sent when it is not in the BOUND or RENEWING states (ie it is in INIT-REBOOT or SELECTING states). For other cases, the client SHOULD NOT set the BROADCAST flag if it can receive the server's unicast responses. As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING states. In these cases, the DHCP server attempts to unicast DHCP responses to the address filled in by the client in 'ciaddr' by using IPoIB ARP to resolve the link address. The reason I think this is clearer is because: 1. It makes it clear that the BROADCAST flag has to be set in DHCPDISCOVER. 2. It makes it clear that the BROADCAST flag needs to be set for DHCPREQUEST only in INIT-REBOOT/SELECTING states. 3. It allows that servers might broadcast responses (allowed per 2131, see last paragraph section 4.1). 4. It allows that servers might respond with DHCPNAK. 5. It allows that there might be other reasons for clients to set BROADCAST bit (specifically for INFORM, see 2131 table 5). 6. It does not make it illegal for clients to set BROADCAST bit for whatever other reason. Unless there is a good reason (other than known issues) to make it illegal, I am not sure if this was intended. I could not find any MUST NOT reference wrt BROADCAST bit in 2131. Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Tue Apr 8 20:58:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10199 for ; Tue, 8 Apr 2003 20:58:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3913Gi16004 for ipoverib-archive@odin.ietf.org; Tue, 8 Apr 2003 21:03:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3913G816001 for ; Tue, 8 Apr 2003 21:03:16 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10181 for ; Tue, 8 Apr 2003 20:57:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3912N815974; Tue, 8 Apr 2003 21:02:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3911i815945 for ; Tue, 8 Apr 2003 21:01:44 -0400 Received: from nwkea-mail-1.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10135 for ; Tue, 8 Apr 2003 20:56:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA01679 for ; Tue, 8 Apr 2003 17:58:48 -0700 (PDT) Received: from phys-ha1sun-1 (phys-ha1sun-1.Eng.Sun.COM [129.144.135.11]) by engmail1mpk.Eng.Sun.COM (8.12.8+Sun/8.12.8/ENSMAIL,v2.2) with ESMTP id h390wmcU012942 for ; Tue, 8 Apr 2003 17:58:48 -0700 (PDT) Received: from Sun.COM (sr1-usun-06.Eng.Sun.COM [129.144.135.9]) by ha1sun-mail1.eng.sun.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0HD100MH9XE0FW@ha1sun-mail1.eng.sun.com> for ipoverib@ietf.org; Tue, 08 Apr 2003 17:58:48 -0700 (PDT) Date: Tue, 08 Apr 2003 17:58:48 -0700 From: Kanoj Sarcar To: ipoverib@ietf.org Reply-to: Kanoj.Sarcar@Sun.COM Message-id: <3E937048.564A18C7@Sun.COM> MIME-version: 1.0 X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Ipoverib] DHCP clarification Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, While going over section 2 of ipoib/dhcp draft, I realized that it can be cleaned up somewhat (in my opinion, ie; to others, it might be quite clear already). Accordingly, I came up with the following verbiage. If there are some improvements in here, it should be used to reword the section. 2.2 Use of the BROADCAST flag A DHCP client on IPoIB MUST set the BROADCAST flag (and set 'ciaddr' to zero) in DHCPREQUEST messages and DHCPDISCOVER messages sent when it is not in the BOUND or RENEWING states (ie it is in INIT-REBOOT or SELECTING states). For other cases, the client SHOULD NOT set the BROADCAST flag if it can receive the server's unicast responses. As described in [RFC2131], 'ciaddr' MUST be filled in with client's IP address during BOUND, RENEWING or REBINDING states. In these cases, the DHCP server attempts to unicast DHCP responses to the address filled in by the client in 'ciaddr' by using IPoIB ARP to resolve the link address. The reason I think this is clearer is because: 1. It makes it clear that the BROADCAST flag has to be set in DHCPDISCOVER. 2. It makes it clear that the BROADCAST flag needs to be set for DHCPREQUEST only in INIT-REBOOT/SELECTING states. 3. It allows that servers might broadcast responses (allowed per 2131, see last paragraph section 4.1). 4. It allows that servers might respond with DHCPNAK. 5. It allows that there might be other reasons for clients to set BROADCAST bit (specifically for INFORM, see 2131 table 5). 6. It does not make it illegal for clients to set BROADCAST bit for whatever other reason. Unless there is a good reason (other than known issues) to make it illegal, I am not sure if this was intended. I could not find any MUST NOT reference wrt BROADCAST bit in 2131. Thanks. Kanoj _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Apr 14 03:17:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26369 for ; Mon, 14 Apr 2003 03:17:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7OJ828885; Mon, 14 Apr 2003 03:24:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7MY828767 for ; Mon, 14 Apr 2003 03:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26250 for ; Mon, 14 Apr 2003 03:14:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194yDB-0000J5-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:05 -0400 Received: from patan.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 194yDA-0000J0-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:04 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA13850; Mon, 14 Apr 2003 01:17:05 -0600 (MDT) Received: from sr1-ctpe06-01 (sr1-ctpe06-01.Taiwan.Sun.COM [129.158.184.33]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h3E7Gsmq974423; Mon, 14 Apr 2003 00:17:04 -0700 (PDT) Message-Id: <200304140717.h3E7Gsmq974423@jurassic.eng.sun.com> Date: Mon, 14 Apr 2003 15:17:03 +0800 (CST) From: Hsiao-keng Chu Reply-To: Hsiao-keng Chu To: ipoverib@ietf.org Cc: bill@strahm.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Jw1OKBSxq7dm8lZb1Sju1A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Subject: [Ipoverib] 56th IETF IPoIB meeting minutes Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , IP over InfiniBand: 56th IETF San Francisco (3/18/03) - Meeting Minutes Sean Harnedy Vivek Kashyap ================================================================== There were approximately twenty people in attendance at the IPOIB Working Group meeting. Agenda Intro from Working Group Chairs IPoIB MIBs status IPoIB connected mode Wrap up Introduction - Jerry Chu (Sun Microsystems) & Bill Strahm (Sun Microsystems) The co-chairs, Jerry Chu and Bill Strahm, presented the agenda and circulated the blue attendance sheets. Sean Harnedy and Vivek Kashyap volunteered to take the minutes. The co-chairs first introduced the document status. The Protocol drafts, encapsulation, link and multicast, and DHCP, are all up for IESG review and last call comments. The AD (Tom Narten from IBM) is looking into when they will be moved onto the RFC track. IPoIB MIBs Status - Sean Harnedy (InfiniSwitch Corporation) ----------------------------------------------------------- Sean updated the WG on the progress of the MIBs. The primary action item that has happened since the last meeting was that the MIBs were updated to the IBTA 1.1 spec. (The BMA MIB update is still in progress). There has also been a number of guidelines on writing RFCs, Internet-Drafts, and MIB documents that need to be reviewed to be sure the MIBs and the Internet-Drafts are in compliance. After this, more IETF people will check the MIBs and then they can be advanced to Working Group last call before becoming RFCs. There was a discussion of adding new MIBs, but nothing definite was agreed upon at the meeting. Sean asked if anyone had MIB implementation experience to send comments to the mailing list. There was a discussion, largely between Bill & Thomas, on the process of moving the drafts to become RFCs. It was discussed that the 6 drafts may be prioritised and then put on MIB doctor's list. The textual conventions draft is required by all other drafts and hence should be at the head of the list. Before submitting to MIB doctor's list all known problems should be fixed. IPoIB connected mode - Vivek Kashyap (IBM) ------------------------------------------ Vivek presented his draft on IPOIB in Connected Mode (CM). The two types of connected mode proposed were reliable and unreliable. He noted that since unreliable datagram had to be supported by all InfiniBand network entities, the UD discovery (via multicast) already being used could be reused for Connected Mode. The two major benefits of using CM are large MTU and redundancy (using the InfiniBand Automatic Path Recovery feature). It is also more reliable. The actual CM address resolution is a bit more complex and involves 3 phases: UD multicast, the use of Communication Manager (CM REQ, CM REPLY, CM RTU), and then the IP connection. There was also a discussion on the size of the messages. Is even 64K packets too small? At 10X IB is capable of supporting very large MTUs. This is a prime candidate for the use of Connected Mode. The large MTU may make IB more appealing than competing Ethernet technologies. There was a discussion of the use of "cookies" in the address resolution phase. The next version of the draft will specify the QPN of the UD QP used for address resolution. The MTU negotiation was also discussed. There will be a desired MTU and a minimum MTU field. The connection setup will use IB MADs. There will be a Service ID field and a private data field that holds the desired and minimum MTU fields. There was a discussion of PVCs for setting up existing connections. Vivek summarized the draft including benefits of CM and the reuse of UD features (Ethertype field and ARP). The main difference is the IB connection phase with the Communication Manager steps. He asked for questions. One question was what if the CM cannot support desired MTU of 64K? Answer: Connection may be setup with smaller MT. There was a question about the use of Inverse ARP (for creating PVCs). Should this be added to the spec? Vivek said he will release another revision of the draft but suggested that one could avoid Inverse ARP. It was discussed that after fixing some minor comments received on the encapsulation and multicast drafts the drafts be put on working group last call. Vivek will submit the next version of the architecture draft updated as per the latest set of drafts and IB spec 1.1. Jerry and Bill closed the meeting. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Apr 14 03:17:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26384 for ; Mon, 14 Apr 2003 03:17:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E7PB228939 for ipoverib-archive@odin.ietf.org; Mon, 14 Apr 2003 03:25:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7PB828936 for ; Mon, 14 Apr 2003 03:25:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26354 for ; Mon, 14 Apr 2003 03:17:09 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194yFh-0000KD-00 for ipoverib-web-archive@ietf.org; Mon, 14 Apr 2003 03:19:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194yFh-0000K9-00 for ipoverib-web-archive@ietf.org; Mon, 14 Apr 2003 03:19:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7OJ828885; Mon, 14 Apr 2003 03:24:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E7MY828767 for ; Mon, 14 Apr 2003 03:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26250 for ; Mon, 14 Apr 2003 03:14:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194yDB-0000J5-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:05 -0400 Received: from patan.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 194yDA-0000J0-00 for ipoverib@ietf.org; Mon, 14 Apr 2003 03:17:04 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA13850; Mon, 14 Apr 2003 01:17:05 -0600 (MDT) Received: from sr1-ctpe06-01 (sr1-ctpe06-01.Taiwan.Sun.COM [129.158.184.33]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h3E7Gsmq974423; Mon, 14 Apr 2003 00:17:04 -0700 (PDT) Message-Id: <200304140717.h3E7Gsmq974423@jurassic.eng.sun.com> Date: Mon, 14 Apr 2003 15:17:03 +0800 (CST) From: Hsiao-keng Chu Reply-To: Hsiao-keng Chu To: ipoverib@ietf.org Cc: bill@strahm.net MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Jw1OKBSxq7dm8lZb1Sju1A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Subject: [Ipoverib] 56th IETF IPoIB meeting minutes Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , IP over InfiniBand: 56th IETF San Francisco (3/18/03) - Meeting Minutes Sean Harnedy Vivek Kashyap ================================================================== There were approximately twenty people in attendance at the IPOIB Working Group meeting. Agenda Intro from Working Group Chairs IPoIB MIBs status IPoIB connected mode Wrap up Introduction - Jerry Chu (Sun Microsystems) & Bill Strahm (Sun Microsystems) The co-chairs, Jerry Chu and Bill Strahm, presented the agenda and circulated the blue attendance sheets. Sean Harnedy and Vivek Kashyap volunteered to take the minutes. The co-chairs first introduced the document status. The Protocol drafts, encapsulation, link and multicast, and DHCP, are all up for IESG review and last call comments. The AD (Tom Narten from IBM) is looking into when they will be moved onto the RFC track. IPoIB MIBs Status - Sean Harnedy (InfiniSwitch Corporation) ----------------------------------------------------------- Sean updated the WG on the progress of the MIBs. The primary action item that has happened since the last meeting was that the MIBs were updated to the IBTA 1.1 spec. (The BMA MIB update is still in progress). There has also been a number of guidelines on writing RFCs, Internet-Drafts, and MIB documents that need to be reviewed to be sure the MIBs and the Internet-Drafts are in compliance. After this, more IETF people will check the MIBs and then they can be advanced to Working Group last call before becoming RFCs. There was a discussion of adding new MIBs, but nothing definite was agreed upon at the meeting. Sean asked if anyone had MIB implementation experience to send comments to the mailing list. There was a discussion, largely between Bill & Thomas, on the process of moving the drafts to become RFCs. It was discussed that the 6 drafts may be prioritised and then put on MIB doctor's list. The textual conventions draft is required by all other drafts and hence should be at the head of the list. Before submitting to MIB doctor's list all known problems should be fixed. IPoIB connected mode - Vivek Kashyap (IBM) ------------------------------------------ Vivek presented his draft on IPOIB in Connected Mode (CM). The two types of connected mode proposed were reliable and unreliable. He noted that since unreliable datagram had to be supported by all InfiniBand network entities, the UD discovery (via multicast) already being used could be reused for Connected Mode. The two major benefits of using CM are large MTU and redundancy (using the InfiniBand Automatic Path Recovery feature). It is also more reliable. The actual CM address resolution is a bit more complex and involves 3 phases: UD multicast, the use of Communication Manager (CM REQ, CM REPLY, CM RTU), and then the IP connection. There was also a discussion on the size of the messages. Is even 64K packets too small? At 10X IB is capable of supporting very large MTUs. This is a prime candidate for the use of Connected Mode. The large MTU may make IB more appealing than competing Ethernet technologies. There was a discussion of the use of "cookies" in the address resolution phase. The next version of the draft will specify the QPN of the UD QP used for address resolution. The MTU negotiation was also discussed. There will be a desired MTU and a minimum MTU field. The connection setup will use IB MADs. There will be a Service ID field and a private data field that holds the desired and minimum MTU fields. There was a discussion of PVCs for setting up existing connections. Vivek summarized the draft including benefits of CM and the reuse of UD features (Ethertype field and ARP). The main difference is the IB connection phase with the Communication Manager steps. He asked for questions. One question was what if the CM cannot support desired MTU of 64K? Answer: Connection may be setup with smaller MT. There was a question about the use of Inverse ARP (for creating PVCs). Should this be added to the spec? Vivek said he will release another revision of the draft but suggested that one could avoid Inverse ARP. It was discussed that after fixing some minor comments received on the encapsulation and multicast drafts the drafts be put on working group last call. Vivek will submit the next version of the architecture draft updated as per the latest set of drafts and IB spec 1.1. Jerry and Bill closed the meeting. _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Mon Apr 21 07:41:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10218 for ; Mon, 21 Apr 2003 07:41:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBq1823124; Mon, 21 Apr 2003 07:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBh9822787 for ; Mon, 21 Apr 2003 07:43:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09744; Mon, 21 Apr 2003 07:31:35 -0400 (EDT) Message-Id: <200304211131.HAA09744@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 21 Apr 2003 07:31:35 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-03.txt Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : IP encapsulation and address resolution over InfiniBand networks Author(s) : V. Kashyap, J. Chu Filename : draft-ietf-ipoib-ip-over-infiniband-03.txt Pages : 15 Date : 2003-4-18 This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbour solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipoib-ip-over-infiniband-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-18131747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-18131747.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Mon Apr 21 07:42:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10233 for ; Mon, 21 Apr 2003 07:41:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LBr1G23198 for ipoverib-archive@odin.ietf.org; Mon, 21 Apr 2003 07:53:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBr1823195 for ; Mon, 21 Apr 2003 07:53:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10166 for ; Mon, 21 Apr 2003 07:41:29 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197ZiB-0006vZ-00 for ipoverib-web-archive@ietf.org; Mon, 21 Apr 2003 07:43:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197ZiB-0006vV-00 for ipoverib-web-archive@ietf.org; Mon, 21 Apr 2003 07:43:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBq1823124; Mon, 21 Apr 2003 07:52:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LBh9822787 for ; Mon, 21 Apr 2003 07:43:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09744; Mon, 21 Apr 2003 07:31:35 -0400 (EDT) Message-Id: <200304211131.HAA09744@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipoverib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 21 Apr 2003 07:31:35 -0400 Subject: [Ipoverib] I-D ACTION:draft-ietf-ipoib-ip-over-infiniband-03.txt Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over InfiniBand Working Group of the IETF. Title : IP encapsulation and address resolution over InfiniBand networks Author(s) : V. Kashyap, J. Chu Filename : draft-ietf-ipoib-ip-over-infiniband-03.txt Pages : 15 Date : 2003-4-18 This document specifies the frame format for transmission of IP and ARP packets over InfiniBand networks. Unless explicitly specified, the term 'IP' refers to both IPv4 and IPv6. The term 'ARP' refers to all the ARP protocols/op-codes such as ARP/RARP. This document also describes the method of forming IPv6 link-local addresses, and the content of the source/target link layer address option used in Neighbour solicitation and advertisement, router advertisement, router redirect and router solicitation on IPv6 over InfiniBand. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipoib-ip-over-infiniband-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-18131747.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipoib-ip-over-infiniband-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipoib-ip-over-infiniband-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-18131747.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Apr 30 15:56:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22229 for ; Wed, 30 Apr 2003 15:56:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UK0S811224; Wed, 30 Apr 2003 16:00:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJxc811058 for ; Wed, 30 Apr 2003 15:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22181 for ; Wed, 30 Apr 2003 15:53:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Axg2-00038o-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 15:55:38 -0400 Received: from pheriche.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19Axg1-00038l-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 15:55:37 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA25666 for ; Wed, 30 Apr 2003 13:56:15 -0600 (MDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h3UJuE2h706792 for ; Wed, 30 Apr 2003 12:56:15 -0700 (PDT) Message-Id: <200304301956.h3UJuE2h706792@jurassic.eng.sun.com> Date: Wed, 30 Apr 2003 12:56:15 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Skulk_of_Foxes_208_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --Skulk_of_Foxes_208_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Azw4zW4X0vL66SCZYLY9Cg== A new revision of the draft is included below to incorporate comments from the list. The main change from the -03 version is the addition of a new section 11 on new types of vulnearbility in IB multicast. Please comment asap before the draft can go back to IETF last call. Thanks, Jerry --Skulk_of_Foxes_208_000 Content-Type: TEXT/plain; name="draft-ietf-ipoib-link-multicast-04.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-ietf-ipoib-link-multicast-04.txt Content-MD5: EsCgSD7pPE3U80LhcFnvNQ== INTERNET-DRAFT H.K. Jerry Chu Sun Microsystems Vivek Kashyap IBM Expires: November, 2003 May, 2003 IP link and multicast over InfiniBand networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a method for setting up IP subnets and multicast services over InfiniBand(TM) networks. Discussions in this document are applicable to both IPv4 and IPv6, unless explicitly specified. A separate document will cover unicast and encapsulation of IP datagrams over InfiniBand networks. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Basic IPoIB Transport - Unreliable Datagram 4.0 IB Multicast Architecture 5.0 IB Links vs. IPoIB Links Chu & Kashyap [Page 1] draft-ietf-ipoib-link-multicast-04.txt May 2003 6.0 Setting up an IPoIB Link 6.1 Maximum Transmission Unit 6.2 IPoIB Link Q_Key 6.3 Other Link Attributes 7.0 The IPoIB Broadcast Group 8.0 Mapping for other Multicast Groups 9.0 Sending and Receiving IP Multicast Packets 10.0 IP Multicast Routing 11.0 New Types of Vulnerability in IB Multicast 12.0 Security Considerations 13.0 Acknowledgments 14.0 References 15.0 Author's Address 16.0 Full Copyright Statement 1.0 Introduction InfiniBand Architecture (IBA) defines four layers of network services corresponding to layer one through layer four of the OSI reference model. For the purpose of running IP over an InfiniBand (IB) network, the IB link, network, and transport layers collectively constitute the data link layer to the IP stack. One can find a general overview of IB architecture related to IP networks in [IPoIB_ARCH]. This document will focus on the necessary steps in order to lay out an IP network on top of an IB network. It will describe all the elements of an IP over InfiniBand (IPoIB) link, how to configure its associated attributes, and how to set up basic broadcast and multicast services for it. IPoIB links are the building blocks upon which an IP network consisting of many IP subnets connected by routers can be built. Subnetting allows the containment of broadcast traffic within a single link. It also provides certain degree of isolation for the administration purpose between nodes on different subnets. 2.0 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3.0 Basic IPoIB Transport - Unreliable Datagram InfiniBand defines four types of transport services [IBTA]. They are reliable connection, unreliable connection, reliable datagram, unreliable datagram. IBA also defines a special raw datagram service Chu & Kashyap [Page 2] draft-ietf-ipoib-link-multicast-04.txt May 2003 for encapsulation purpose. Both unreliable datagram and raw datagram define support for multicast. They provide the basic transport mechanism that best matches the IP datagram paradigm. IB unreliable datagram provides many additional features such as the partition key (P_Key) protection, multiple queue pairs (QPs), and Q_Key protection. Moreover, it defines a 32-bit invariant CRC checksum, which provides a much stronger protection against data corruption, compared with the 16-bit CRC that a raw datagram carries. For these reasons, IB unreliable datagram is considered to be a much better choice as the basic IPoIB transport than the raw datagram, and is chosen as the default IPoIB transport mechanism ([IPoIB_ARCH], [IPoIB_ENCAP]). 4.0 IB Multicast Architecture The following discussion gives a short overview of the multicast architecture in InfiniBand. For a complete specification, the reader is referred to [IBTA]. IBA defines two layers of multicast services. Its link layer uses multicast LIDs (MLIDs) in the Local Route Header (LRH). LIDs are allocated by the Subnet Manager (SM) and fall in the range between 0xC0000 to 0xFFFE (approximately 16k). MLIDs are used by IB switches to program their multicast forwarding tables. An IB switch implementation may support much fewer MLIDs in its forwarding table though. The IB network layer uses multicast GIDs (MGIDs) in the Global Route Header (GRH). MGIDs closely resemble IPv6 multicast addresses [AARCH] shown below. | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ Figure 1 [IPoIB_ARCH] describes each field in more details. Since every IB multicast packet is required to carry a LRH and a GRH, both a valid MGID and a valid MLID are needed before an IB multicast packet can be constructed. An IB multicast group is uniquely identified by a valid MGID. Before a MGID can be used within an IB subnet, either as a destination Chu & Kashyap [Page 3] draft-ietf-ipoib-link-multicast-04.txt May 2003 address of a multicast packet, or to represent a multicast group that an IB node can join, an IB multicast group corresponding to the MGID must be created through the Subnet Administrator (SA). Besides the the MGID, the creator of an IB multicast group must supply values of path MTU, P_Key, Q_Key, Service Level (SL), FlowLabel, TClass that are appropriate for all the potential clients of the multicast group to use. In return, SA will allocate a MLID to be used by switches in the local IB subnet. Unreliable multicast is defined by IBA as an optional functionality for channel adaptors (CAs) and switches. In today's IP technology, link multicast has become an indispensable function for better supporting a modern IP network. For this reason, it is required that an IPoIB fabric supports multicast. This includes all the CAs and switches that are part of an IP network. 5.0 IB Links vs. IPoIB Links A link segment on top of which an IP subnet can be configured is defined in [IPV6] as a communication facility or medium over which nodes can communicate at the "link" layer. For most types of communication media, the boundary between different data link segments closely follows the physical topology of the network. For instance, an Ethernet network connected by switches, hubs, or bridges usually forms a single link segment and broadcast/multicast domain. Different Ethernet segments can be connected by IP routers at the network layer to form an IP network. InfiniBand defines its own link-layer and subnets consisting of nodes connected by IB switches and routers. However, the IPoIB link boundary need not follow the IB link boundary. Nodes residing on different IB subnets can still communicate directly with one another through IB routers at the InfiniBand network layer. This communication at the network layer applies to unicast as well as multicast. The ultimate requirement for two nodes in the same IB fabric to communicate at the IB level, besides physical connectivity, is a common P_Key. Partitioning in IB provides an isolation mechanism among nodes in an IB fabric, much like VLANs in the Ethernet network. Each port of an HCA (Host Channel Adaptor) contains a P_Key table holding all the valid P_Keys the port is allowed to use. The P_Key table is set up by the SM of the local IB subnet. Each QP is programmed with a P_Key from the local P_Key table. This P_Key is carried in all the outgoing packets from the QP, and is used to compare against the P_Key of all incoming packets to the QP. Any packet with an invalid P_Key will be Chu & Kashyap [Page 4] draft-ietf-ipoib-link-multicast-04.txt May 2003 discarded by the QP and a P_Key violation trap will be generated. IB switches may optionally enforce partition checking too. Following the above, IB partitions are the natural choice for defining IPoIB link boundary. It also provides much needed flexibility for a network administrator to group nodes logically into different subnets in a large network. 6.0 Setting up an IPoIB Link A network administrator defines an IPoIB link by setting up an IB partition and assigning it a unique P_Key. Since a full-duplex communication is required among IP nodes, full-membership P_Keys, that is, those with the high-order bit set to 1 shall be used. An IB partition may or may not span multiple IB subnets; and whether it does or not is mostly transparent to IPoIB. Each node attached to an IB partition MUST have one of its HCAs assigned the P_Key to use. Note that the P_key table of an HCA port may contain many P_Keys. It is up to the implementation to define the method by which the P_Key relevant to a particular IPoIB subnet is determined and conveyed to the IPoIB stack. For instance, implementations may resort to a manual configuration when choosing the P_key or a set of P_Keys for IPoIB, and rely on DHCP [DHCP] to assign an IP subnet number to each IPoIB link. Once an IB partition is established for IPoIB use, the link MTU and Q_Key are two other attributes that must be chosen before an IPoIB link can be configured. 6.1 Maximum Transmission Unit IB defines five permissible maximum payload sizes (MTUs). They are 256, 512, 1024, 2048 and 4096 bytes. [IPV6] requires a link MTU of 1280 bytes or greater. To be better compatible with Ethernet, the dominant network media in both the LAN and WAN environment, the IPoIB link MTU should be 1500 bytes or greater. This leaves only 2048 and 4096 bytes as the two acceptable MTUs for IPoIB. Channel adaptors supporting a MTU less than the minimal requirement can still expose an acceptable MTU to IP through an adaptation layer that fragments larger messages into smaller IB packets, and reassembles them on the receiving end. But this must be done in a way that is transparent to the IP stack. It is up to the network administrator to select a link MTU to use when configuring an IPoIB link. The link MTU SHALL not be greater than the MTU of any IB devices on the IPoIB link. Here the IB devices include IB switches, CAs, or routers. Chu & Kashyap [Page 5] draft-ietf-ipoib-link-multicast-04.txt May 2003 In general, a maximum link MTU should be employed whenever possible to attain a better throughput performance. One caveat is that once a link MTU is chosen for a given IPoIB link, nodes connected by CAs of a smaller MTU won't be able to join the link unless the whole link and all the devices attached to it are reconfigured to use the smaller MTU. It may be desirable in some case to use a smaller link MTU than the full size. For example, bridging an IPoIB link with an Ethernet link could be made much easier if the IPoIB link MTU is reduced to 1500 bytes. For IPv4, this may require a manual configuration of a different link MTU than the maximum that all the nodes support. For IPv6, one can use the MTU option of the router advertisement [DISC] to announce a smaller MTU to all the nodes. In case an IPoIB link spans more than one IB subnet, the IPoIB link MTU MUST not exceed the path MTU of any path connecting two nodes in the same IB partition. It is up to the network administrator to determine the appropriate path MTU value that will work for any node in the same IPoIB link. 6.2 IPoIB Link Q_Key A Q_Key is programmed by the source QP in every IB datagram, and is compared against the Q_Key of the destination QP. A Q_Key violation will cause the offending datagram to be dropped, and a Q_Key violation counter to be incremented on the receiving port. A trap is also generated if the feature is supported on that port. A single Q_Key must be selected for all the QPs attached to an IPoIB link to use. It is recommended that a controlled Q_Key be used with the high order bit set. This is to prevent non-privileged software from fabricating and sending out bogus IP datagrams. All QPs configured for a given IPoIB link SHALL be assigned the same per-link Q_Key. 6.3 Other Link Attributes TClass, FlowLabel, HopLimit, and SL are four other attributes that are required if an IPoIB link covers more than a single IB subnet. The selection of these values are implementation dependent. Implementations must take into account the topology of IB subnets comprising the IPoIB link to ensure a successful communication between any two nodes in the same IPoIB link. 7.0 The IPoIB Broadcast Group Once an IB partition is created with link attributes identified for Chu & Kashyap [Page 6] draft-ietf-ipoib-link-multicast-04.txt May 2003 an IPoIB link, the network administrator must create a special IB all-node multicast group (henceforth referred to as the broadcast group) with these link attributes for every node on the IPoIB link to join. The creation of an IB multicast group is through the use of the "MCMemberRecord" SA attribute as described in the IBA specification. The MGID of an IPoIB broadcast group will embed in it the P_Key of the IB partition that defines the IPoIB link. A special signature is also embedded to identify all the MGIDs for IPoIB use only. For IPv4 over IB, the signature will be "0x401B". For IPv6 over IB, the signature will be "0x601B". For an IPv4 subnet, the MGID for this special IB multicast group SHALL have the following format: | 8 | 4 | 4 | 16 bits | 16 bits | 48 bits | 32 bits | +--------+----+----+----------------+---------+----------+---------+ |11111111|0001|scop|0100000000011011|< P_Key >|00.......0|| +--------+----+----+----------------+---------+----------+---------+ Figure 2 For an IPv6 subnet, the format of the MGID SHALL look like this: | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | +--------+----+----+----------------+---------+--------------------+ |11111111|0001|scop|0110000000011011|< P_Key >|000.............0001| +--------+----+----+----------------+---------+--------------------+ Figure 3 As for the scop bits, if the IPoIB link is fully contained within a single IB subnet, the scop bits SHALL be set to 2 (link-local). Otherwise the scope will be set higher. The broadcast group for IPv4 will serve to provide a broadcast service for protocols like ARP to use. When a node is first brought up on an IPoIB link identified by a P_Key, it must look for the right broadcast group to join. This is done by querying the SA MCMemberRecord database for a multicast group with a MGID matching the one constructed from the link P_Key and the IPoIB signature. The node SHOULD always look for a MGID of a link- local scope first before attempting one with a greater scope. Once the right MGID and broadcast group are identified, the local Chu & Kashyap [Page 7] draft-ietf-ipoib-link-multicast-04.txt May 2003 node SHOULD use the MTU associated with the broadcast group. In case the MTU of the broadcast group is greater than what the local HCA can support, the node can not join the IPoIB link and operate as an IP node. Otherwise the local node must join the broadcast group as a "full member" and use the rest of link attributes associated with the group for all future communication to the link. In addition to the special all-node multicast group for broadcast purpose, an all-router multicast group SHOULD be created at link configuration time if an IP router will be attached to the link. This is to facilitate IP multicast operations described later. An IB multicast group for the all-router MGID must cover every IB subnet that the IPoIB link encompasses. The format of the all-router MGID will be covered in the next section. 8.0 Mapping for other Multicast Groups The general IP multicast [IPMULT] support over IB is similar to the case of the special broadcast group discussed above. An algorithmic mapping is used so that given an IP multicast address, individual host can compute the corresponding IB multicast address (MGID) all by itself without having to consult an external entity. This also removes the need for an externally maintained IP to IB multicast mapping table. The IPoIB multicast mapping is depicted in Figure 4. The same mapping function is used for both IPv4 and IPv6 except the IPoIB signature field. | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | +------ -+----+----+-----------------+---------+--------------------+ |11111111|0001|scop||< P_Key >| group ID | +--------+----+----+-----------------+---------+--------------------+ Figure 4 Since a MGID allocated for transporting IP multicast datagrams is considered only a transient link-layer multicast address, all IB MGIDs allocated for IPoIB purpose SHOULD have T = 1. The scope bits SHALL be the same as that of the all-node MGID for the same IPoIB link. An IP multicast address is used together with a given IPoIB link P_Key to form the MGID of the IB multicast group. For IPv6 the lower 80-bit of the group ID is used directly in the lower 80-bit of the MGID. For IPv4, the group ID is only 28-bit long and the rest of the 80 bits are filled with 0. Chu & Kashyap [Page 8] draft-ietf-ipoib-link-multicast-04.txt May 2003 The rest of the bits are the same as those of the broadcast MGID. For example, on an IPoIB link that is fully contained within a single IB subnet with a P_Key of 0x8006, the MGIDs for the all-router multicast group with group ID 2 [AARCH, IGMP2] are: FF12:401B:8006:0:0:0:0:2 or FF12:401B:8006::2 for IPv4 in a compressed format, and FF12:601B:8006:0:0:0:0:2 or FF12:601B:8006::2 for IPv6 in a compressed format. A special case exists for the IPv4 limited broadcast address "255.255.255.255" [HOSTS]. The address SHALL be mapped to the broadcast MGID for IPv4 networks as described in section 7 above. Also the IPv6 all-node multicast address "FF0X::1" [AARCH] maps naturally to the the special broadcast MGID for IPv6 networks. 9.0 Sending and Receiving IP Multicast Packets Multicast in InfiniBand differs in a number of ways from multicast in Ethernet. This adds some complexity to an IPoIB implementation when supporting IP multicast over IB. A) An IB multicast group must be explicitly created through the SA before it can be used. This implies that in order to send a packet destined for an IP multicast address, the IPoIB implementation must check with the SA on the outbound link first for a "MCMemberRecord" that matches the MGID. If one does exist, the MLID associated with the multicast group is used as the DLID for the packet. Otherwise, it implies no member exists on the local link. The packet SHOULD be forwarded to locally connected routers. This is to allow local routers to forward the packet to multicast listeners on remote networks. The specific mechanism for a sender to forward packets to routers are left to implementations. One can use, for example, the broadcast group, or the all-router multicast group for this purpose. Chu & Kashyap [Page 9] draft-ietf-ipoib-link-multicast-04.txt May 2003 B) A multicast sender must join the target multicast group as a "SendOnlyNonMember" before outgoing multicast messages from it can be successfully routed. The "SendOnlyNonMember" join is different from the regular "FullMember" join in two aspects. First, both types of joins enable multicast packets to be routed FROM the local port, but only the "FullMember" join causes multicast packets to be routed TO the port. Second, the sender port of a "SendOnlyNonMember" join will not be counted as a member of the multicast group for purposes of group creation and deletion. The following code snippet demonstrates the steps in a typical implementation when processing an egress multicast packet. if the egress port is already a "SendOnlyNonMember", or a "FullMember" => send the packet else if the target multicast group exists => do "SendOnlyNonMember" join => send the packet else if the all-router multicast group exists => send the packet to all routers else => drop the packet Implementations should cache the information about the existence of an IB multicast group, its MLID and other attributes. This is to avoid expensive SA calls on every outgoing multicast packet. The cache may need to be validated periodically. Senders should also subscribe to the multicast group create and delete traps in order to monitor the status of specific IB multicast groups. Multicast packets directed to the all-router multicast group due to a lack of listener on the local subnet must be forwarded to the right multicast group if the group is created later. This happens when a listener shows up on the local subnet. A node joining an IP multicast group must first construct a MGID according to the rule described in section 8 above. Once the correct MGID is calculated, the node must call the SA of the outbound link to attempt a "FullMember" join of the IB multicast group corresponding to the MGID. If the IB multicast group doesn't already exist, one must be created first with the IPoIB link MTU. For the rest of attributes, it is recommended the same values from the all-node multicast/broadcast group be used. The join request will cause the local port to be added to the multicast group. It also enables the SM to program IB switches and Chu & Kashyap [Page 10] draft-ietf-ipoib-link-multicast-04.txt May 2003 routers with the new multicast information to ensure the correct forwarding of multicast packets for the group. When a node leaves an IP multicast group, it SHOULD make a "FullMember" leave request to the SA. This gives SM an opportunity to update relevant forwarding information, to delete an IB multicast group if the local port is the last FullMember to leave, and free up the MLID allocated for it. The specific algorithm is implementation- dependent, and is out of the scope of this document. Note that for an IPoIB link that spans more than one IB subnet connected by IB routers, an adequate multicast forwarding support at the IB level is required for multicast packets to reach listeners on a remote IB subnet. The specific mechanism for this will be covered in [IBTA], and is beyond the scope of IPoIB. 10.0 IP Multicast Routing IP multicast routing requires multicast routers to receive a copy of every link multicast packet on a locally connected link [IPMULT, IP6MLD]. For Ethernet this is usually achieved by turning on the promiscuous multicast mode on a locally connected Ethernet interface. IBA does not provide any hardware support for promiscuous multicast mode. Fortunately a promiscuous multicast mode can be emulated in the software running on a router through the following steps. A) Obtain a list of all active IB multicast groups from the local SA. B) Make a "NonMember" join request to the SA for every group that has a signature in its MGID matching the one for either IPv4 or IPv6. C) Subscribe to the IB multicast group creation events using a wildcarded MGID so that the router can "NonMember" join all IB multicast groups created subsequently for IPv4 or IPv6. The "NonMember" join has the same effect as a "FullMember" join except that the former will not be counted as a member of the multicast group for purposes of group creation or deletion. That is, when the last "FullMember" leaves a multicast group, the group can be safely deleted by the SA without concerning any "NonMember" routers. 11.0 New Types of Vulnerability in IB Multicast Many IB multicast functions are subject to failures due to a number of possible resource constraints. These include the creation of IB multicast groups, the join calls ("SendOnlyNonMember", "FullMember", and "NonMember"), and the attaching of a QP to a multicast group. Chu & Kashyap [Page 11] draft-ietf-ipoib-link-multicast-04.txt May 2003 In general, the occurrence of these failure conditions is highly implementation dependent, and is believed to be rare. Usually a failed multicast operation at the IB level can be propagated back to the IP level, causing the original operation to fail, and the initiator of the operation to be notified. But some IB multicast functions are not tied to any foreground operation, making their failures hard to detect. E.g., if an IP multicast router attempts to "NonMember" join a newly created multicast group in the local subnet, but the join call fails, packet forwarding for that particular multicast group will likely to fail silently, that is, without the attention of local multicast senders. This type of problems can add more vulnerability to the already unreliable IP multicast operations. Implementations should log error messages upon any failure from an IB multicast operation. Network administrators should be aware of this vulnerability, and preserve enough multicast resources at the points where IP multicast will be used heavily. E.g., HCAs with ample multicast resources should be used at any IP multicast router. 12.0 Security Considerations All the operations for creating and configuring an IPoIB link described in this document, including assigning P_Keys to CAs, creating IB multicast groups in SA, creating and attaching QPs to IB multicast groups,... etc, are privileged operations, and MUST be protected by the underlying operating system. This is to prevent malicious, non-privileged software from hijacking important resources and configurations. For example, A bogus IPoIB broadcast group may prevent a proper one from being created when the network administrator tries to set up a link. Controlled Q_Keys SHOULD be used in IPoIB links. This is to prevent non-privileged software from fabricating IP datagrams to send, as mentioned in section 6.2. 13.0 Acknowledgments The authors would like to thank Bruce Beukema, David Brean, Dan Cassiday, Aditya Dube, Yaron Haviv, Michael Krause, Thomas Narten, Erik Nordmark, Greg Pfister, Renato Recio, Kanoj Sarcar, Satya Sharma, and David L. Stevens for their suggestions and many clarifications on the IBA specification. 14.0 References [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Chu & Kashyap [Page 12] draft-ietf-ipoib-link-multicast-04.txt May 2003 [DHCP] R. Droms "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [HOSTS] Braden R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989 [IBTA] InfiniBand Architecture Specification, Release 1.0.a by InfiniBand Trade Association at www.infinibandta.org [IGMP2] Fenner W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [IPMULT] Deering S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [IPoIB_ARCH] draft-ietf-ipoib-architecture-01.txt [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-01.txt [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [IP6MLD] Deering S., Fenner W., Haberman B., "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.0 Author's Address H.K. Jerry Chu 17 Network Circle, UMPK17-201 Menlo Park, CA 94025 USA Phone: +1 650 786-5146 EMail: jerry.chu@sun.com Vivek Kashyap IBM 15450, SW Koll Parkway Beaverton, OR 97006 Chu & Kashyap [Page 13] draft-ietf-ipoib-link-multicast-04.txt May 2003 Phone: 503 578 3422 EMail: vivk@us.ibm.com 16.0 Full Copyright Statement Copyright (C) The Internet Society (2003>. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chu & Kashyap [Page 14] --Skulk_of_Foxes_208_000-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Apr 30 15:56:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22243 for ; Wed, 30 Apr 2003 15:56:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UK2H326824 for ipoverib-archive@odin.ietf.org; Wed, 30 Apr 2003 16:02:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UK2H826819 for ; Wed, 30 Apr 2003 16:02:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22219 for ; Wed, 30 Apr 2003 15:56:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Axia-00039p-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 15:58:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Axia-00039k-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 15:58:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UK0S811224; Wed, 30 Apr 2003 16:00:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UJxc811058 for ; Wed, 30 Apr 2003 15:59:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22181 for ; Wed, 30 Apr 2003 15:53:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Axg2-00038o-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 15:55:38 -0400 Received: from pheriche.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19Axg1-00038l-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 15:55:37 -0400 Received: from jurassic.eng.sun.com ([129.146.17.55]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA25666 for ; Wed, 30 Apr 2003 13:56:15 -0600 (MDT) Received: from taipei (taipei.Eng.Sun.COM [129.146.85.178]) by jurassic.eng.sun.com (8.12.9+Sun/8.12.9) with SMTP id h3UJuE2h706792 for ; Wed, 30 Apr 2003 12:56:15 -0700 (PDT) Message-Id: <200304301956.h3UJuE2h706792@jurassic.eng.sun.com> Date: Wed, 30 Apr 2003 12:56:15 -0700 (PDT) From: "H.K. Jerry Chu" Reply-To: "H.K. Jerry Chu" To: ipoverib@ietf.org MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Skulk_of_Foxes_208_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc Subject: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , --Skulk_of_Foxes_208_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Azw4zW4X0vL66SCZYLY9Cg== A new revision of the draft is included below to incorporate comments from the list. The main change from the -03 version is the addition of a new section 11 on new types of vulnearbility in IB multicast. Please comment asap before the draft can go back to IETF last call. Thanks, Jerry --Skulk_of_Foxes_208_000 Content-Type: TEXT/plain; name="draft-ietf-ipoib-link-multicast-04.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-ietf-ipoib-link-multicast-04.txt Content-MD5: EsCgSD7pPE3U80LhcFnvNQ== INTERNET-DRAFT H.K. Jerry Chu Sun Microsystems Vivek Kashyap IBM Expires: November, 2003 May, 2003 IP link and multicast over InfiniBand networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a method for setting up IP subnets and multicast services over InfiniBand(TM) networks. Discussions in this document are applicable to both IPv4 and IPv6, unless explicitly specified. A separate document will cover unicast and encapsulation of IP datagrams over InfiniBand networks. Table of Contents 1.0 Introduction 2.0 Terminology 3.0 Basic IPoIB Transport - Unreliable Datagram 4.0 IB Multicast Architecture 5.0 IB Links vs. IPoIB Links Chu & Kashyap [Page 1] draft-ietf-ipoib-link-multicast-04.txt May 2003 6.0 Setting up an IPoIB Link 6.1 Maximum Transmission Unit 6.2 IPoIB Link Q_Key 6.3 Other Link Attributes 7.0 The IPoIB Broadcast Group 8.0 Mapping for other Multicast Groups 9.0 Sending and Receiving IP Multicast Packets 10.0 IP Multicast Routing 11.0 New Types of Vulnerability in IB Multicast 12.0 Security Considerations 13.0 Acknowledgments 14.0 References 15.0 Author's Address 16.0 Full Copyright Statement 1.0 Introduction InfiniBand Architecture (IBA) defines four layers of network services corresponding to layer one through layer four of the OSI reference model. For the purpose of running IP over an InfiniBand (IB) network, the IB link, network, and transport layers collectively constitute the data link layer to the IP stack. One can find a general overview of IB architecture related to IP networks in [IPoIB_ARCH]. This document will focus on the necessary steps in order to lay out an IP network on top of an IB network. It will describe all the elements of an IP over InfiniBand (IPoIB) link, how to configure its associated attributes, and how to set up basic broadcast and multicast services for it. IPoIB links are the building blocks upon which an IP network consisting of many IP subnets connected by routers can be built. Subnetting allows the containment of broadcast traffic within a single link. It also provides certain degree of isolation for the administration purpose between nodes on different subnets. 2.0 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3.0 Basic IPoIB Transport - Unreliable Datagram InfiniBand defines four types of transport services [IBTA]. They are reliable connection, unreliable connection, reliable datagram, unreliable datagram. IBA also defines a special raw datagram service Chu & Kashyap [Page 2] draft-ietf-ipoib-link-multicast-04.txt May 2003 for encapsulation purpose. Both unreliable datagram and raw datagram define support for multicast. They provide the basic transport mechanism that best matches the IP datagram paradigm. IB unreliable datagram provides many additional features such as the partition key (P_Key) protection, multiple queue pairs (QPs), and Q_Key protection. Moreover, it defines a 32-bit invariant CRC checksum, which provides a much stronger protection against data corruption, compared with the 16-bit CRC that a raw datagram carries. For these reasons, IB unreliable datagram is considered to be a much better choice as the basic IPoIB transport than the raw datagram, and is chosen as the default IPoIB transport mechanism ([IPoIB_ARCH], [IPoIB_ENCAP]). 4.0 IB Multicast Architecture The following discussion gives a short overview of the multicast architecture in InfiniBand. For a complete specification, the reader is referred to [IBTA]. IBA defines two layers of multicast services. Its link layer uses multicast LIDs (MLIDs) in the Local Route Header (LRH). LIDs are allocated by the Subnet Manager (SM) and fall in the range between 0xC0000 to 0xFFFE (approximately 16k). MLIDs are used by IB switches to program their multicast forwarding tables. An IB switch implementation may support much fewer MLIDs in its forwarding table though. The IB network layer uses multicast GIDs (MGIDs) in the Global Route Header (GRH). MGIDs closely resemble IPv6 multicast addresses [AARCH] shown below. | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ Figure 1 [IPoIB_ARCH] describes each field in more details. Since every IB multicast packet is required to carry a LRH and a GRH, both a valid MGID and a valid MLID are needed before an IB multicast packet can be constructed. An IB multicast group is uniquely identified by a valid MGID. Before a MGID can be used within an IB subnet, either as a destination Chu & Kashyap [Page 3] draft-ietf-ipoib-link-multicast-04.txt May 2003 address of a multicast packet, or to represent a multicast group that an IB node can join, an IB multicast group corresponding to the MGID must be created through the Subnet Administrator (SA). Besides the the MGID, the creator of an IB multicast group must supply values of path MTU, P_Key, Q_Key, Service Level (SL), FlowLabel, TClass that are appropriate for all the potential clients of the multicast group to use. In return, SA will allocate a MLID to be used by switches in the local IB subnet. Unreliable multicast is defined by IBA as an optional functionality for channel adaptors (CAs) and switches. In today's IP technology, link multicast has become an indispensable function for better supporting a modern IP network. For this reason, it is required that an IPoIB fabric supports multicast. This includes all the CAs and switches that are part of an IP network. 5.0 IB Links vs. IPoIB Links A link segment on top of which an IP subnet can be configured is defined in [IPV6] as a communication facility or medium over which nodes can communicate at the "link" layer. For most types of communication media, the boundary between different data link segments closely follows the physical topology of the network. For instance, an Ethernet network connected by switches, hubs, or bridges usually forms a single link segment and broadcast/multicast domain. Different Ethernet segments can be connected by IP routers at the network layer to form an IP network. InfiniBand defines its own link-layer and subnets consisting of nodes connected by IB switches and routers. However, the IPoIB link boundary need not follow the IB link boundary. Nodes residing on different IB subnets can still communicate directly with one another through IB routers at the InfiniBand network layer. This communication at the network layer applies to unicast as well as multicast. The ultimate requirement for two nodes in the same IB fabric to communicate at the IB level, besides physical connectivity, is a common P_Key. Partitioning in IB provides an isolation mechanism among nodes in an IB fabric, much like VLANs in the Ethernet network. Each port of an HCA (Host Channel Adaptor) contains a P_Key table holding all the valid P_Keys the port is allowed to use. The P_Key table is set up by the SM of the local IB subnet. Each QP is programmed with a P_Key from the local P_Key table. This P_Key is carried in all the outgoing packets from the QP, and is used to compare against the P_Key of all incoming packets to the QP. Any packet with an invalid P_Key will be Chu & Kashyap [Page 4] draft-ietf-ipoib-link-multicast-04.txt May 2003 discarded by the QP and a P_Key violation trap will be generated. IB switches may optionally enforce partition checking too. Following the above, IB partitions are the natural choice for defining IPoIB link boundary. It also provides much needed flexibility for a network administrator to group nodes logically into different subnets in a large network. 6.0 Setting up an IPoIB Link A network administrator defines an IPoIB link by setting up an IB partition and assigning it a unique P_Key. Since a full-duplex communication is required among IP nodes, full-membership P_Keys, that is, those with the high-order bit set to 1 shall be used. An IB partition may or may not span multiple IB subnets; and whether it does or not is mostly transparent to IPoIB. Each node attached to an IB partition MUST have one of its HCAs assigned the P_Key to use. Note that the P_key table of an HCA port may contain many P_Keys. It is up to the implementation to define the method by which the P_Key relevant to a particular IPoIB subnet is determined and conveyed to the IPoIB stack. For instance, implementations may resort to a manual configuration when choosing the P_key or a set of P_Keys for IPoIB, and rely on DHCP [DHCP] to assign an IP subnet number to each IPoIB link. Once an IB partition is established for IPoIB use, the link MTU and Q_Key are two other attributes that must be chosen before an IPoIB link can be configured. 6.1 Maximum Transmission Unit IB defines five permissible maximum payload sizes (MTUs). They are 256, 512, 1024, 2048 and 4096 bytes. [IPV6] requires a link MTU of 1280 bytes or greater. To be better compatible with Ethernet, the dominant network media in both the LAN and WAN environment, the IPoIB link MTU should be 1500 bytes or greater. This leaves only 2048 and 4096 bytes as the two acceptable MTUs for IPoIB. Channel adaptors supporting a MTU less than the minimal requirement can still expose an acceptable MTU to IP through an adaptation layer that fragments larger messages into smaller IB packets, and reassembles them on the receiving end. But this must be done in a way that is transparent to the IP stack. It is up to the network administrator to select a link MTU to use when configuring an IPoIB link. The link MTU SHALL not be greater than the MTU of any IB devices on the IPoIB link. Here the IB devices include IB switches, CAs, or routers. Chu & Kashyap [Page 5] draft-ietf-ipoib-link-multicast-04.txt May 2003 In general, a maximum link MTU should be employed whenever possible to attain a better throughput performance. One caveat is that once a link MTU is chosen for a given IPoIB link, nodes connected by CAs of a smaller MTU won't be able to join the link unless the whole link and all the devices attached to it are reconfigured to use the smaller MTU. It may be desirable in some case to use a smaller link MTU than the full size. For example, bridging an IPoIB link with an Ethernet link could be made much easier if the IPoIB link MTU is reduced to 1500 bytes. For IPv4, this may require a manual configuration of a different link MTU than the maximum that all the nodes support. For IPv6, one can use the MTU option of the router advertisement [DISC] to announce a smaller MTU to all the nodes. In case an IPoIB link spans more than one IB subnet, the IPoIB link MTU MUST not exceed the path MTU of any path connecting two nodes in the same IB partition. It is up to the network administrator to determine the appropriate path MTU value that will work for any node in the same IPoIB link. 6.2 IPoIB Link Q_Key A Q_Key is programmed by the source QP in every IB datagram, and is compared against the Q_Key of the destination QP. A Q_Key violation will cause the offending datagram to be dropped, and a Q_Key violation counter to be incremented on the receiving port. A trap is also generated if the feature is supported on that port. A single Q_Key must be selected for all the QPs attached to an IPoIB link to use. It is recommended that a controlled Q_Key be used with the high order bit set. This is to prevent non-privileged software from fabricating and sending out bogus IP datagrams. All QPs configured for a given IPoIB link SHALL be assigned the same per-link Q_Key. 6.3 Other Link Attributes TClass, FlowLabel, HopLimit, and SL are four other attributes that are required if an IPoIB link covers more than a single IB subnet. The selection of these values are implementation dependent. Implementations must take into account the topology of IB subnets comprising the IPoIB link to ensure a successful communication between any two nodes in the same IPoIB link. 7.0 The IPoIB Broadcast Group Once an IB partition is created with link attributes identified for Chu & Kashyap [Page 6] draft-ietf-ipoib-link-multicast-04.txt May 2003 an IPoIB link, the network administrator must create a special IB all-node multicast group (henceforth referred to as the broadcast group) with these link attributes for every node on the IPoIB link to join. The creation of an IB multicast group is through the use of the "MCMemberRecord" SA attribute as described in the IBA specification. The MGID of an IPoIB broadcast group will embed in it the P_Key of the IB partition that defines the IPoIB link. A special signature is also embedded to identify all the MGIDs for IPoIB use only. For IPv4 over IB, the signature will be "0x401B". For IPv6 over IB, the signature will be "0x601B". For an IPv4 subnet, the MGID for this special IB multicast group SHALL have the following format: | 8 | 4 | 4 | 16 bits | 16 bits | 48 bits | 32 bits | +--------+----+----+----------------+---------+----------+---------+ |11111111|0001|scop|0100000000011011|< P_Key >|00.......0|| +--------+----+----+----------------+---------+----------+---------+ Figure 2 For an IPv6 subnet, the format of the MGID SHALL look like this: | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | +--------+----+----+----------------+---------+--------------------+ |11111111|0001|scop|0110000000011011|< P_Key >|000.............0001| +--------+----+----+----------------+---------+--------------------+ Figure 3 As for the scop bits, if the IPoIB link is fully contained within a single IB subnet, the scop bits SHALL be set to 2 (link-local). Otherwise the scope will be set higher. The broadcast group for IPv4 will serve to provide a broadcast service for protocols like ARP to use. When a node is first brought up on an IPoIB link identified by a P_Key, it must look for the right broadcast group to join. This is done by querying the SA MCMemberRecord database for a multicast group with a MGID matching the one constructed from the link P_Key and the IPoIB signature. The node SHOULD always look for a MGID of a link- local scope first before attempting one with a greater scope. Once the right MGID and broadcast group are identified, the local Chu & Kashyap [Page 7] draft-ietf-ipoib-link-multicast-04.txt May 2003 node SHOULD use the MTU associated with the broadcast group. In case the MTU of the broadcast group is greater than what the local HCA can support, the node can not join the IPoIB link and operate as an IP node. Otherwise the local node must join the broadcast group as a "full member" and use the rest of link attributes associated with the group for all future communication to the link. In addition to the special all-node multicast group for broadcast purpose, an all-router multicast group SHOULD be created at link configuration time if an IP router will be attached to the link. This is to facilitate IP multicast operations described later. An IB multicast group for the all-router MGID must cover every IB subnet that the IPoIB link encompasses. The format of the all-router MGID will be covered in the next section. 8.0 Mapping for other Multicast Groups The general IP multicast [IPMULT] support over IB is similar to the case of the special broadcast group discussed above. An algorithmic mapping is used so that given an IP multicast address, individual host can compute the corresponding IB multicast address (MGID) all by itself without having to consult an external entity. This also removes the need for an externally maintained IP to IB multicast mapping table. The IPoIB multicast mapping is depicted in Figure 4. The same mapping function is used for both IPv4 and IPv6 except the IPoIB signature field. | 8 | 4 | 4 | 16 bits | 16 bits | 80 bits | +------ -+----+----+-----------------+---------+--------------------+ |11111111|0001|scop||< P_Key >| group ID | +--------+----+----+-----------------+---------+--------------------+ Figure 4 Since a MGID allocated for transporting IP multicast datagrams is considered only a transient link-layer multicast address, all IB MGIDs allocated for IPoIB purpose SHOULD have T = 1. The scope bits SHALL be the same as that of the all-node MGID for the same IPoIB link. An IP multicast address is used together with a given IPoIB link P_Key to form the MGID of the IB multicast group. For IPv6 the lower 80-bit of the group ID is used directly in the lower 80-bit of the MGID. For IPv4, the group ID is only 28-bit long and the rest of the 80 bits are filled with 0. Chu & Kashyap [Page 8] draft-ietf-ipoib-link-multicast-04.txt May 2003 The rest of the bits are the same as those of the broadcast MGID. For example, on an IPoIB link that is fully contained within a single IB subnet with a P_Key of 0x8006, the MGIDs for the all-router multicast group with group ID 2 [AARCH, IGMP2] are: FF12:401B:8006:0:0:0:0:2 or FF12:401B:8006::2 for IPv4 in a compressed format, and FF12:601B:8006:0:0:0:0:2 or FF12:601B:8006::2 for IPv6 in a compressed format. A special case exists for the IPv4 limited broadcast address "255.255.255.255" [HOSTS]. The address SHALL be mapped to the broadcast MGID for IPv4 networks as described in section 7 above. Also the IPv6 all-node multicast address "FF0X::1" [AARCH] maps naturally to the the special broadcast MGID for IPv6 networks. 9.0 Sending and Receiving IP Multicast Packets Multicast in InfiniBand differs in a number of ways from multicast in Ethernet. This adds some complexity to an IPoIB implementation when supporting IP multicast over IB. A) An IB multicast group must be explicitly created through the SA before it can be used. This implies that in order to send a packet destined for an IP multicast address, the IPoIB implementation must check with the SA on the outbound link first for a "MCMemberRecord" that matches the MGID. If one does exist, the MLID associated with the multicast group is used as the DLID for the packet. Otherwise, it implies no member exists on the local link. The packet SHOULD be forwarded to locally connected routers. This is to allow local routers to forward the packet to multicast listeners on remote networks. The specific mechanism for a sender to forward packets to routers are left to implementations. One can use, for example, the broadcast group, or the all-router multicast group for this purpose. Chu & Kashyap [Page 9] draft-ietf-ipoib-link-multicast-04.txt May 2003 B) A multicast sender must join the target multicast group as a "SendOnlyNonMember" before outgoing multicast messages from it can be successfully routed. The "SendOnlyNonMember" join is different from the regular "FullMember" join in two aspects. First, both types of joins enable multicast packets to be routed FROM the local port, but only the "FullMember" join causes multicast packets to be routed TO the port. Second, the sender port of a "SendOnlyNonMember" join will not be counted as a member of the multicast group for purposes of group creation and deletion. The following code snippet demonstrates the steps in a typical implementation when processing an egress multicast packet. if the egress port is already a "SendOnlyNonMember", or a "FullMember" => send the packet else if the target multicast group exists => do "SendOnlyNonMember" join => send the packet else if the all-router multicast group exists => send the packet to all routers else => drop the packet Implementations should cache the information about the existence of an IB multicast group, its MLID and other attributes. This is to avoid expensive SA calls on every outgoing multicast packet. The cache may need to be validated periodically. Senders should also subscribe to the multicast group create and delete traps in order to monitor the status of specific IB multicast groups. Multicast packets directed to the all-router multicast group due to a lack of listener on the local subnet must be forwarded to the right multicast group if the group is created later. This happens when a listener shows up on the local subnet. A node joining an IP multicast group must first construct a MGID according to the rule described in section 8 above. Once the correct MGID is calculated, the node must call the SA of the outbound link to attempt a "FullMember" join of the IB multicast group corresponding to the MGID. If the IB multicast group doesn't already exist, one must be created first with the IPoIB link MTU. For the rest of attributes, it is recommended the same values from the all-node multicast/broadcast group be used. The join request will cause the local port to be added to the multicast group. It also enables the SM to program IB switches and Chu & Kashyap [Page 10] draft-ietf-ipoib-link-multicast-04.txt May 2003 routers with the new multicast information to ensure the correct forwarding of multicast packets for the group. When a node leaves an IP multicast group, it SHOULD make a "FullMember" leave request to the SA. This gives SM an opportunity to update relevant forwarding information, to delete an IB multicast group if the local port is the last FullMember to leave, and free up the MLID allocated for it. The specific algorithm is implementation- dependent, and is out of the scope of this document. Note that for an IPoIB link that spans more than one IB subnet connected by IB routers, an adequate multicast forwarding support at the IB level is required for multicast packets to reach listeners on a remote IB subnet. The specific mechanism for this will be covered in [IBTA], and is beyond the scope of IPoIB. 10.0 IP Multicast Routing IP multicast routing requires multicast routers to receive a copy of every link multicast packet on a locally connected link [IPMULT, IP6MLD]. For Ethernet this is usually achieved by turning on the promiscuous multicast mode on a locally connected Ethernet interface. IBA does not provide any hardware support for promiscuous multicast mode. Fortunately a promiscuous multicast mode can be emulated in the software running on a router through the following steps. A) Obtain a list of all active IB multicast groups from the local SA. B) Make a "NonMember" join request to the SA for every group that has a signature in its MGID matching the one for either IPv4 or IPv6. C) Subscribe to the IB multicast group creation events using a wildcarded MGID so that the router can "NonMember" join all IB multicast groups created subsequently for IPv4 or IPv6. The "NonMember" join has the same effect as a "FullMember" join except that the former will not be counted as a member of the multicast group for purposes of group creation or deletion. That is, when the last "FullMember" leaves a multicast group, the group can be safely deleted by the SA without concerning any "NonMember" routers. 11.0 New Types of Vulnerability in IB Multicast Many IB multicast functions are subject to failures due to a number of possible resource constraints. These include the creation of IB multicast groups, the join calls ("SendOnlyNonMember", "FullMember", and "NonMember"), and the attaching of a QP to a multicast group. Chu & Kashyap [Page 11] draft-ietf-ipoib-link-multicast-04.txt May 2003 In general, the occurrence of these failure conditions is highly implementation dependent, and is believed to be rare. Usually a failed multicast operation at the IB level can be propagated back to the IP level, causing the original operation to fail, and the initiator of the operation to be notified. But some IB multicast functions are not tied to any foreground operation, making their failures hard to detect. E.g., if an IP multicast router attempts to "NonMember" join a newly created multicast group in the local subnet, but the join call fails, packet forwarding for that particular multicast group will likely to fail silently, that is, without the attention of local multicast senders. This type of problems can add more vulnerability to the already unreliable IP multicast operations. Implementations should log error messages upon any failure from an IB multicast operation. Network administrators should be aware of this vulnerability, and preserve enough multicast resources at the points where IP multicast will be used heavily. E.g., HCAs with ample multicast resources should be used at any IP multicast router. 12.0 Security Considerations All the operations for creating and configuring an IPoIB link described in this document, including assigning P_Keys to CAs, creating IB multicast groups in SA, creating and attaching QPs to IB multicast groups,... etc, are privileged operations, and MUST be protected by the underlying operating system. This is to prevent malicious, non-privileged software from hijacking important resources and configurations. For example, A bogus IPoIB broadcast group may prevent a proper one from being created when the network administrator tries to set up a link. Controlled Q_Keys SHOULD be used in IPoIB links. This is to prevent non-privileged software from fabricating IP datagrams to send, as mentioned in section 6.2. 13.0 Acknowledgments The authors would like to thank Bruce Beukema, David Brean, Dan Cassiday, Aditya Dube, Yaron Haviv, Michael Krause, Thomas Narten, Erik Nordmark, Greg Pfister, Renato Recio, Kanoj Sarcar, Satya Sharma, and David L. Stevens for their suggestions and many clarifications on the IBA specification. 14.0 References [AARCH] Hinden, R. and S. Deering "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Chu & Kashyap [Page 12] draft-ietf-ipoib-link-multicast-04.txt May 2003 [DHCP] R. Droms "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [HOSTS] Braden R., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989 [IBTA] InfiniBand Architecture Specification, Release 1.0.a by InfiniBand Trade Association at www.infinibandta.org [IGMP2] Fenner W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [IPMULT] Deering S., "Host Extensions for IP Multicasting", RFC 1112, August 1989. [IPoIB_ARCH] draft-ietf-ipoib-architecture-01.txt [IPoIB_ENCAP] draft-ietf-ipoib-ip-over-infiniband-01.txt [IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [IP6MLD] Deering S., Fenner W., Haberman B., "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 15.0 Author's Address H.K. Jerry Chu 17 Network Circle, UMPK17-201 Menlo Park, CA 94025 USA Phone: +1 650 786-5146 EMail: jerry.chu@sun.com Vivek Kashyap IBM 15450, SW Koll Parkway Beaverton, OR 97006 Chu & Kashyap [Page 13] draft-ietf-ipoib-link-multicast-04.txt May 2003 Phone: 503 578 3422 EMail: vivk@us.ibm.com 16.0 Full Copyright Statement Copyright (C) The Internet Society (2003>. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Chu & Kashyap [Page 14] --Skulk_of_Foxes_208_000-- _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Apr 30 19:21:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29407 for ; Wed, 30 Apr 2003 19:21:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNQ8821126; Wed, 30 Apr 2003 19:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNPm821096 for ; Wed, 30 Apr 2003 19:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29341 for ; Wed, 30 Apr 2003 19:19:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0tT-0004Tv-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 19:21:43 -0400 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 19B0tN-0004Tg-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 19:21:37 -0400 Received: from localhost (bill@localhost) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id h3UN5sN10918; Wed, 30 Apr 2003 19:05:54 -0400 Date: Wed, 30 Apr 2003 19:05:54 -0400 (EDT) From: Bill Strahm X-X-Sender: To: "H.K. Jerry Chu" cc: Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: <200304301956.h3UJuE2h706792@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Based on having both the encasulation draft and the multicast draft available for comments I would like a quick 1 week last call (ending at 11:59 PM May 7th PST) on these documents before passing them back to the IESG. If you have any comments on the drafts please send them to the list early so they can be handled in time to ask our area director to start an IESG last call as soon as possible after the 7th. Thomas, I know you had some issues with these drafts that are hopefully covered by these updated documents. Can you please give a yes/no during this timeframe that you are happy to carry these onto the IESG for us ? Bill (IPoIB co-chair) On Wed, 30 Apr 2003, H.K. Jerry Chu wrote: > A new revision of the draft is included below to incorporate comments > from the list. The main change from the -03 version is the addition > of a new section 11 on new types of vulnearbility in IB multicast. > > Please comment asap before the draft can go back to IETF last > call. > > Thanks, > > Jerry > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Apr 30 19:21:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29421 for ; Wed, 30 Apr 2003 19:21:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UNR7g21156 for ipoverib-archive@odin.ietf.org; Wed, 30 Apr 2003 19:27:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNR7821153 for ; Wed, 30 Apr 2003 19:27:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29387 for ; Wed, 30 Apr 2003 19:20:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0uk-0004V0-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 19:23:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B0uk-0004Ux-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 19:23:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNQ8821126; Wed, 30 Apr 2003 19:26:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UNPm821096 for ; Wed, 30 Apr 2003 19:25:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29341 for ; Wed, 30 Apr 2003 19:19:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0tT-0004Tv-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 19:21:43 -0400 Received: from kairos.dsa.uqam.ca ([132.208.43.57]) by ietf-mx with esmtp (Exim 4.12) id 19B0tN-0004Tg-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 19:21:37 -0400 Received: from localhost (bill@localhost) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id h3UN5sN10918; Wed, 30 Apr 2003 19:05:54 -0400 Date: Wed, 30 Apr 2003 19:05:54 -0400 (EDT) From: Bill Strahm X-X-Sender: To: "H.K. Jerry Chu" cc: Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt In-Reply-To: <200304301956.h3UJuE2h706792@jurassic.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Based on having both the encasulation draft and the multicast draft available for comments I would like a quick 1 week last call (ending at 11:59 PM May 7th PST) on these documents before passing them back to the IESG. If you have any comments on the drafts please send them to the list early so they can be handled in time to ask our area director to start an IESG last call as soon as possible after the 7th. Thomas, I know you had some issues with these drafts that are hopefully covered by these updated documents. Can you please give a yes/no during this timeframe that you are happy to carry these onto the IESG for us ? Bill (IPoIB co-chair) On Wed, 30 Apr 2003, H.K. Jerry Chu wrote: > A new revision of the draft is included below to incorporate comments > from the list. The main change from the -03 version is the addition > of a new section 11 on new types of vulnearbility in IB multicast. > > Please comment asap before the draft can go back to IETF last > call. > > Thanks, > > Jerry > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From ipoverib-admin@ietf.org Wed Apr 30 20:09:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00871 for ; Wed, 30 Apr 2003 20:09:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410E3826534; Wed, 30 Apr 2003 20:14:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410Ct826416 for ; Wed, 30 Apr 2003 20:12:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00712 for ; Wed, 30 Apr 2003 20:06:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B1d4-0004s3-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 20:08:50 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19B1co-0004r3-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 20:08:34 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4107AQs257766 for ; Wed, 30 Apr 2003 20:07:10 -0400 Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h41079o3088104 for ; Wed, 30 Apr 2003 18:07:09 -0600 Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt To: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Thu, 1 May 2003 05:07:15 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 4, 2003) at 04/30/2003 18:07:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Bill, FYI: I have posted -04 encapsulation draft to include a comment I received recently. Fixed figure 2/3 misalbelling/reference. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Bill Strahm To: "H.K. Jerry Chu" Sent by: cc: ipoverib-admin@ie Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt tf.org 04/30/2003 04:05 PM Based on having both the encasulation draft and the multicast draft available for comments I would like a quick 1 week last call (ending at 11:59 PM May 7th PST) on these documents before passing them back to the IESG. If you have any comments on the drafts please send them to the list early so they can be handled in time to ask our area director to start an IESG last call as soon as possible after the 7th. Thomas, I know you had some issues with these drafts that are hopefully covered by these updated documents. Can you please give a yes/no during this timeframe that you are happy to carry these onto the IESG for us ? Bill (IPoIB co-chair) On Wed, 30 Apr 2003, H.K. Jerry Chu wrote: > A new revision of the draft is included below to incorporate comments > from the list. The main change from the -03 version is the addition > of a new section 11 on new types of vulnearbility in IB multicast. > > Please comment asap before the draft can go back to IETF last > call. > > Thanks, > > Jerry > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib From mailnull@www1.ietf.org Wed Apr 30 20:55:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00885 for ; Wed, 30 Apr 2003 20:09:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h410F4H26588 for ipoverib-archive@odin.ietf.org; Wed, 30 Apr 2003 20:15:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410F4826585 for ; Wed, 30 Apr 2003 20:15:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00843 for ; Wed, 30 Apr 2003 20:08:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B1f8-0004ta-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 20:10:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B1f8-0004tX-00 for ipoverib-web-archive@ietf.org; Wed, 30 Apr 2003 20:10:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410E3826534; Wed, 30 Apr 2003 20:14:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h410Ct826416 for ; Wed, 30 Apr 2003 20:12:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00712 for ; Wed, 30 Apr 2003 20:06:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B1d4-0004s3-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 20:08:50 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19B1co-0004r3-00 for ipoverib@ietf.org; Wed, 30 Apr 2003 20:08:34 -0400 Received: from westrelay04.boulder.ibm.com (westrelay04.boulder.ibm.com [9.17.193.32]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4107AQs257766 for ; Wed, 30 Apr 2003 20:07:10 -0400 Received: from d03nm122.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay04.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h41079o3088104 for ; Wed, 30 Apr 2003 18:07:09 -0600 Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt To: ipoverib@ietf.org X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: From: Vivek Kashyap Date: Thu, 1 May 2003 05:07:15 -0700 X-MIMETrack: Serialize by Router on D03NM122/03/M/IBM(Release 6.0.1 [IBM]|April 4, 2003) at 04/30/2003 18:07:09 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: ipoverib-admin@ietf.org Errors-To: ipoverib-admin@ietf.org X-BeenThere: ipoverib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over InfiniBand WG Discussion List List-Post: List-Help: List-Subscribe: , Bill, FYI: I have posted -04 encapsulation draft to include a comment I received recently. Fixed figure 2/3 misalbelling/reference. Vivek -- Vivek Kashyap Linux Technology Center, IBM vivk@us.ibm.com kashyapv@us.ibm.com Ph: 503 578 3422 T/L: 775 3422 Bill Strahm To: "H.K. Jerry Chu" Sent by: cc: ipoverib-admin@ie Subject: Re: [Ipoverib] draft-ietf-ipoib-link-multicast-04.txt tf.org 04/30/2003 04:05 PM Based on having both the encasulation draft and the multicast draft available for comments I would like a quick 1 week last call (ending at 11:59 PM May 7th PST) on these documents before passing them back to the IESG. If you have any comments on the drafts please send them to the list early so they can be handled in time to ask our area director to start an IESG last call as soon as possible after the 7th. Thomas, I know you had some issues with these drafts that are hopefully covered by these updated documents. Can you please give a yes/no during this timeframe that you are happy to carry these onto the IESG for us ? Bill (IPoIB co-chair) On Wed, 30 Apr 2003, H.K. Jerry Chu wrote: > A new revision of the draft is included below to incorporate comments > from the list. The main change from the -03 version is the addition > of a new section 11 on new types of vulnearbility in IB multicast. > > Please comment asap before the draft can go back to IETF last > call. > > Thanks, > > Jerry > _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib _______________________________________________ IPoverIB mailing list IPoverIB@ietf.org https://www1.ietf.org/mailman/listinfo/ipoverib