The FC frame header has not changed since its inception back in the late 80-ies. This shows the absolute rock-solid backward compatibility towards previous generation platforms and vendors. Obviously the the FC protocol itself has grown and evolved with marked demands to provide an extremely flexible transport mechanism for the most demanding storage environments. When you start to design a new protocol the concept of future proofing is a must and sits very high on the top of the design list. Not only does it require insight into current markets and requirements but also a huge set of extremely smart brains to come up with possible scenario’s of what might be required in years to come. You don’t want it to become obsolete in 5 years time because there were inherent flaws in the protocol. Next to that your have to facilitate options which allows for flexible expansion of functions and features of which none of the above brains had ever thought of. (Did somebody know about VMware back in 1990?) The concepts of NPIV where not on the radar back then. So what is the structure of this protocol that makes it so flexible.
Tag CloudBNA bottleneckmon brocade buffer credits cisco cloud data centre decoding disk encoding errors Ethernet event fabric fabrics FabricWatch FCoE fibre channel fillwords fill words firmware FOS future hba HDS Hitachi isl linux maintenance management MAPS microsoft open source optical performance resilient security SFP storage support switches T10 T11 VMware zoning