Storage networking is like SNA

I’m writing this post while travelling to the Net Field Day 2010, the successor to the awesome Tech Field Day 2010 during which the FCoTR technology was launched. It’s thus only fair to extend that fantastic merger of two technologies we all love, look at the bigger picture and compare storage networking with SNA.


  • If you’re too young to understand what I’m talking about, don’t worry. Yes, you’ve missed all the beauties of RSRB/DLSw, CIP, APPN/APPI and the likes, but major technology shifts happen every other decade or so, so you’ll be able to use FC/FCoE/iSCSI analogies the next time (and look like a dinosaur to the rookies). Make sure, though, that you read the summary.
  • I’ll use present tense throughout the post when comparing both environments although SNA should be mostly history by now.

Application layer. SNA and storage networking use a venerable application protocol invented decades ago: 3270 data stream (SNA) and SCSI (storage). But while IBM knew how to design protocols, the storage industry obviously didn’t ... that’s why SNA was able to run over everything (including barbed wire), while SAN requires overengineered switches and lossless network.

Early days. SNA and SAN started modestly: one was running over low-speed modem connections, the other one over 15 meters of flat ribbon cable. SNA was obviously better designed, as the modem connections were always noisy and lossy (and the protocol stack had to cope with that), while you could pretend the ribbon cable has zero defects.

Moving to LAN. Both environments eventually got LAN connectivity. In both cases, the vendors considered themselves so unique that they simply had to reinvent the wheel. IBM created Token Ring (to get deterministic performance which they thought was absolutely necessary to transport 80x24 screens across a 4 Mbps network every 30 seconds) and the storage industry created lossless Fiber Channel because they thought it’s better to overengineer the network than to use a decent transport protocol.

Integration. After decades of SNA and SAN dominance, disruptive vendors (in both cases primarily Cisco) decided to tackle the integration of SNA/SAN with the other mainstream technology environment (Ethernet+IP). Not surprisingly, it turns out you can use the same three major integration options in both cases:



Long-distance encapsulation over TCP/IP



Transport native frames over Ethernet LAN

LLC2 over Ethernet


Application protocol in TCP/IP



Can we learn anything from the history? Fifteen years ago, everyone was implementing DLSw networks and migrating from Token Ring to Ethernet as fast as possible (running SNA stack on workstations connected to Ethernet LAN).

But soon enough the TN3270 clients became reasonably stable and implemented the extra features needed by weird applications (for example, screen scraping). IBM also started offering Ethernet host attachment with TN3270 server running on the host (or you could use Cisco’s Channel Interface Processor – CIP – with TN3270 server) and we’ve seen a lot of people dropping SNA/LLC2 altogether and migrating to TN3270, replacing 3720-over-SNA-over-LLC2-over-DLSw-over-TCP/IP with TN3270-over-TCP/IP.

Do you want to draw a parallel to today’s FCoE versus iSCSI debate (not forgetting iSCSI is already doing amazingly well)?

Last but not least, don’t forget that you’ll hear a lot about storage protocols (and nothing about SNA) in the Data Center 3.0 for Networking Engineers webinar (buy a recording or yearly subscription).

Add comment