There is already a fair chunk of functionality in FOS but, being a support-engineer, you always come up with features and functions that will improve storage fabrics.

Being on a Ficon course last week and meeting some Brocade friends I requested them to add the following to the (most likely) long RFE (Request for Enhancement) list.

XISL traffic shaping

As you know as of FOS 7 Brocade provides the ability to use, so called, XISL’s which are virtual ISL’s capable of traversing frames that are between tow different virtual fabrics. They use the extended frame headers (see here) to move frames back-and forth between the logical switches which make up the virtual fabic. So here is the problem. Very often the functionality of virtual fabrics is used to segregate between different business profiles. This way it is possible to keep production traffic away from test & dev etc. If directors and switches are cascaded and the use of XISL’s between them makes a good business sense, the common denominator between the switches obviously become these XISL’s. As there currently is no method to segregate the traffic patterns based upon virtual switch/fabric membership these may significantly impact each other. If a test engineers is working on a VMware SDRS solution and is moving VMs and datastores around you might see a severe impact on production traffic if this traverses the same XISL. My proposal is to have some sort of traffic shaping policy so a priority based flow is configurable on these XISL’s based on virtual fabric membership. Brocade is already using the CS_CTL byte for similar purposes however that is a method where end-to-end support is needed and thus might not be suitable for existing environments.

Protocol intermix separation

For those of you running a storage environment where SCSI, IP and Ficon is traversing ISL’s you’ll most likely have found out the burden of having different architecture restrictions imposed in the same fabric. Although virtual fabrics have alleviated the administration a bit, there still are some problems you cannot do within a Brocade environment. Traffic separation on E-ports is one of those examples. Unless you want to embark on a TI_ZONE journey which requires you to maintain a meticulously accurate end-to-end path administration you are not able to segregate different protocols onto certain ISL’s as you can with Cisco trunking. Cisco provides an option where you can allocate one or more VSAN(s) onto an ISL so only that (or those) VSAN(s) will be able to traverse the ISL. To have a similar option on Brocade ISL’s (and XISL’s) I’ve proposed to have a look at the TYPE field in the FC frame header plus the VFT_Header field in the extended FC frame-header. The type field in the FC frame header contains the type of data (duhh) of a particular frame. Frame types like SCSI (0x08), SBCCS (0x1B and 0x1C) and services like BLS (0x00) and ELS (0x01) have their own designation. This way you can configure certain protocol definitions or fabric membership on a particular ISL. The configuration of ISL’s and XISL’s becomes more flexible and allows you to overcome certain restrictions (like for instance hop-count in a Ficon environment) in a much simpler way.

If this is then combined with the traffic shaping/prioritization as mentioned above, you’re able to configure a very fine-grained control over what is going over which ISL/XISL at which priority. This improves overall stability of different kinds of traffic and environments if designed correctly.

I don’t know if these proposals will be implemented or not but they do provide a much better option than what is currently available with TI_ZONEs plus it is far easier to administer with much less room for error. If you like these proposals start nagging at you Brocade representative to expedite this. 🙂

Lets see what the future brings.

Regards,

Erwin