Smooth sailing for SAS? Not all technologies are created equal.

Any new technology inspires a certain amount of skepticism. But while interoperability and conformance are always issues, some new technologies have smoother sailing than others. A case in point is Serial-Attached SCSI (SAS), an emerging standard developed to meet the needs of mainstream enterprise-class storage systems. From a technical perspective, SAS promises relatively easy interoperability and a smooth adoption curve for several reasons; chief among them, that SAS was built on well-established protocols with a solid track record of stability and scalability.

Technologies run into interoperability hurdles when every aspect of the technology is new, from the physical layer all the way up the stack. Technologies avoid this problem by only attempting to solve a single problem and using proven technologies as a foundation.

[FIGURE 1 OMITTED]

Think of it this way, imagine you are to build a new house, and while going over the plans with the contractor, he mentions you have a choice of materials for the foundation. You could choose to build with new materials which, though costly, promise great performance. Your contractor, however, has little or no experience working with them. On the other hand, you could go with good old reliable concrete, which of course your contractor knows exactly how to handle. Most people would choose the more common, proven, and less expensive material.

The principles are similar in buying enterprise-class storage. Do IT managers want a technology that is brand new, promises to solve all of their problems and deliver incredible performance, but is expensive, difficult to maintain, possibly non-interoperable, and unfamiliar to most IT personnel? Well, maybe some do, but most would do better to choose plain old concrete. Something reasonably priced, familiar, and proven to work is going to be a safer bet.

Obviously some technologies lend themselves to this approach more than others. But as the knowledge base grows for older technologies such as Ethernet, SCSI (Small Computer System Interface), and TCP/IP (Transmission Control Protocol/Internet Protocol) it's natural that the innovators of new technologies, and eventually the standards bodies, start to take advantage of this.

One example would be iSCSI. iSCSI has had very few interoperability problems for two reasons. First, its developers didn't start from scratch but built upon what had already been proven to work: SCSI, a twenty-year-old ubiquitous peripherals protocol, and TCP/IP, which runs the Internet. Using these two proven technologies as a foundation, iSCSI stands on its own. Second, the iSCSI protocol was rigorously tested long before it ever hit the market. The University of New Hampshire InterOperability Lab (UNH-IOL), for example, has held numerous industry-wide iSCSI plugfests since July 2001. Of course, initially these plugfests found bugs in implementations and were able to feed revisions and clarifications back into the standard. But from that very first plugfest, iSCSI worked. At these plugfests, which continue to be held, prototypes go through a series of conformance and interoperability tests, helping developers to refine their products and make the technology as a whole interoperable and therefore more attractive to end users.

[FIGURE 2 OMITTED]

SAS follows a path similar to iSCSI's. Instead of trying to create an entirely new physical layer, SAS has a physical layer similar to 10-Gigabit Ethernet's Attachment Unit Interface specification (XAUI). XAUI uses four serial channels running in parallel at 3.125 GBps to create a 10-Gigabit connection. SAS and Serial ATA have taken this technology and used only one channel, running at 3 or 1.5 GBps to connect a disk and a Host Bus Adapter. Thus, the Physical Layer of SAS is not brand new, but has already been developed and refined by the Institute of Electrical and Electronics Engineers (IEEE).

SAS and Serial ATA share a similar Out of Band Protocol (OOB) used to let end nodes identify each other as SAS or SATA devices and perform initialization. This technology is already on the market in SATA. SAS uses OOB both for initialization and for interoperability with SATA devices. At the encoding layer, SAS uses 8b10b encoding to create transmission characters and primitives from bits. This is the same encoding method used by Fibre Channel and Gigabit Ethernet. By using such a tried and true encoding method, SAS architects ensure that there won't be any surprises at this layer when the technology is deployed.

SAS is also poised to be easily interoperable with the ubiquitous Microsoft Windows operating system. Windows supports SCSI devices through a special type of device driver called the SCSI Miniport driver. Microsoft designed this driver so that support for new SCSI devices is easy to implement in Windows, and support of SAS on Windows is thus assured.

So considering these preceding elements, it's clear that SAS is being built on a solid foundation. SAS architects haven't had to reinvent the wheel, just tweak it. Instead of trying to create a completely new technology based on the latest research, one that would solve any and all of the problems of the storage and data communications industry, SAS has opted to tackle just one problem, the physical limitations of parallel SCSI. It has wisely opted to solve this problem in a simple, straightforward and efficient way. The result is that SAS should be interoperable, scalable, easy to deploy, and easy to maintain, right from the start.

This kind of focused and simple approach to the standard is the first ingredient for an easily interoperable technology; the second is early testing. Here too, SAS makes the grade

The SCSI Trade Association will be sponsoring a series of SAS Plugfests throughout the remainder of 2004. Hosted at the UNH-IOL, these plugfests will feature interop and conformance testing at each layer of SAS technology.

Testing at the SAS Plugfest will center on test plans developed under the supervision of the STA Plugfest Technical Committee. Test suite providers (including UNH-IOL, test equipment vendors, and systems integrators) will develop and implement specific test procedures to be performed at the plugfest. Testing begins at the Physical layer as defined in the SAS standard, and moves all the way up to the application layer. In addition, test procedures will be defined to test important SAS features such as Speed negotiation, SATA interoperability, hot plug, expanders, wide l-anes, domain discovery, and multi-initiator topologies. It is hoped that with such a comprehensive test plan, any problems will be solved early, well before SAS products are available on the market. This should cement SAS interoperability so that storage buyers can be confident that the products they buy will work together.

There are two key ingredients that help ensure that a new technology can be stable and interoperable early on. The first is a solid foundation on tried and true technologies, as opposed to a rocky one on new and unproven technology. SAS does this with its heritage of SCSI. Fibre Channel, and 10Gbit Ethernet. The second is rigorous formal testing, long before the products hit the market. For SAS, this will be ongoing throughout 2004 as the UNH-IOL and STA team up to test SAS implementations in every way possible. From what we've seen of SAS so far, these ingredients should combine to make fairly smoothing sailing for SAS right out of the gate.

www.iol.unh.edu

www.scsita.org

David Woolf is a test engineer at University of New Hampshire's InterOperability Lab (Durham, NH)