Comments on: Explaining RTI architectures http://blog.egenera.com/2009/06/explaining-rti-architectures/?utm_source=rss&utm_medium=rss&utm_campaign=explaining-rti-architectures Delivering Confidence to your Cloud Tue, 23 Nov 2010 20:15:46 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: Mark http://blog.egenera.com/2009/06/explaining-rti-architectures/#comment-282 Mark Sat, 30 Jan 2010 21:49:03 +0000 http://blog.egenera.com/?p=119#comment-282 A couple of points. I am familiar with InfiniBand based I/O consolidation and FCoE based I/O consolidation. There is a big difference between the two today, and that is in the fact InfiniBand requires a protocol change. The storage protocols on the IB wire (SCSI RDMA Protocol, iSER, vHBA) are different from the the protocol on the native interface (FC). The same can be the case for IP, where the protocols on the IB wire (vNIC, Sockets Direct Protocol) are different from the native interface (Ethernet). IP over InfiniBand keeps the IP packet the same on the IB wire, but has to offer new L2 functionality as it is not Ethernet. FCoE does not change protocols, it simply deencapsulates FC frames from the native FC transport and encapsulates FC frames into enhanced Ethernet Jumbo Frames. FC information (WWNs, headers, etc.) are preserved. FCoE has to replace FC discovery protocols with something similar on Ethernet, which it does via FIP. IP traffic has not protocol change whatsoever in an FCoE environment. On the IB side, they are looking at a similar approach as FCoE with the concept of FCoIB, where FC frames would be carried on InfiniBand. Which brings up the second point. If the protocols remain native, dynamic fabrics are required. Even if HP used no FC, and accessed storage via iSCSI, Virtual Connect would be required to decouple storage addressing from physical hardware, allowing stateless computing. The same holds true for Cisco UCS. Since FCoE uses native FC protocols and addressing, virtualizing the addressing (what you call "dynamic fabrics") is required to make Cisco UCS blades stateless. Also, Dell, with FlexAddress, and IBM, with BladeCenter Open Fabric Manager, provide dynamic fabric capability. A couple of points. I am familiar with InfiniBand based I/O consolidation and FCoE based I/O consolidation. There is a big difference between the two today, and that is in the fact InfiniBand requires a protocol change. The storage protocols on the IB wire (SCSI RDMA Protocol, iSER, vHBA) are different from the the protocol on the native interface (FC). The same can be the case for IP, where the protocols on the IB wire (vNIC, Sockets Direct Protocol) are different from the native interface (Ethernet). IP over InfiniBand keeps the IP packet the same on the IB wire, but has to offer new L2 functionality as it is not Ethernet.

FCoE does not change protocols, it simply deencapsulates FC frames from the native FC transport and encapsulates FC frames into enhanced Ethernet Jumbo Frames. FC information (WWNs, headers, etc.) are preserved. FCoE has to replace FC discovery protocols with something similar on Ethernet, which it does via FIP. IP traffic has not protocol change whatsoever in an FCoE environment.

On the IB side, they are looking at a similar approach as FCoE with the concept of FCoIB, where FC frames would be carried on InfiniBand.

Which brings up the second point. If the protocols remain native, dynamic fabrics are required. Even if HP used no FC, and accessed storage via iSCSI, Virtual Connect would be required to decouple storage addressing from physical hardware, allowing stateless computing. The same holds true for Cisco UCS. Since FCoE uses native FC protocols and addressing, virtualizing the addressing (what you call “dynamic fabrics”) is required to make Cisco UCS blades stateless.

Also, Dell, with FlexAddress, and IBM, with BladeCenter Open Fabric Manager, provide dynamic fabric capability.

]]>