HP Networking
Discover how the new HP Networking combines the technologies and alliances of 3Com, ProCurve and TippingPoint into the next networking leader.

This is not the convergence you were looking for

By Deepak Munjal, HP Networking Strategist

 

I’ve written in the past about the benefits of a converged infrastructure and we would probably all agree that managing one network is simpler than managing two or even three. But there is generally a one-time cost associated with moving to a converged infrastructure before achieving these benefits. Most customers also look at an overall return on investment (ROI) before evaluating the move to a new model. Today, we will look at convergence of storage and data networks and compare different methods on how to scale your converged networks even further.

 

Where we are today on the road to convergence

 

When I first spoke about storage convergence and technologies like FCoE and iSCSI in my blog last year, I argued that iSCSI was a well-developed storage convergence protocol but for many Fibre Channel customers, FCoE might be a better path since it preserves their SAN investments.  I also advised that FCoE should only be implemented at the edge (single-hop) and not in the core (multi-hop) because standards were not fully developed and customers could not assume interoperability between multiple vendors in a multi-hop FCoE environment. For customers that are concerned about interoperability and open standards, single-hop FCoE provided an easy path to convergence while also providing the largest ROI since the majority of ports are the edge.

 

roi.png 

 

Well, time has passed and vendors and standards bodies have offered new approaches to solve the congestion problem inherent with large, multi-hop core networks.

 

Initially, the industry believed that FCoE would work best as a lightweight protocol running over a lossless Ethernet core network that would guarantee the congestion-free, in-order delivery of storage traffic.  To that end, the DCB suite of protocols was created by the IEEE to solve this problem both at the edge and the core.  Enhanced Ethernet protocols such as PFC, ETS, and QCN were standardized and as many vendors began to offer them, customers started to deploy FCoE, especially at the edge.

 

dcb.png

 

But as I wrote about in my previous blog, there were disagreements between vendors on how best to deploy a multi-hop FCoE network. Although PFC and ETS can be successfully used at the edge to maintain prioritization of storage traffic, congestion might still occur in the core. Congestion notification (QCN) was seen a possible solution to address congestion in a multi-hop FCoE network. QCN in conjunction with a layer 2 multi-pathing protocol (L2MP) would allow an Ethernet core to achieve similar performance, resiliency, and stability as a native Fibre Channel SAN.

 

QCN requires new switching hardware and L2MP isn’t pervasively implemented. There is also some confusion as Fibre Channel switch vendors (Cisco and Brocade) rushed to offer solutions for L2MP that are incompatible with each other. Again, customers who wanted to deploy multi-hop FCoE would have to choose a single vendor and likely give up any hope for interoperability.  That doesn’t sound like the Ethernet market we know and love does it?

 

More recently, Fibre Channel switch vendors have come up with another solution. Why not run a full Fibre Channel stack on every FCoE switch and make each hop a Fibre Channel Forwarder (FCF) obviating the need for Ethernet to provide the flow control and routing functions? This actually sounds like a very simple idea and addresses the problem of deploying multi-hop FCoE networks without the need for QCN.

 

But the question has to be asked: Is this really convergence? 

 

If each FCoE switch is also running the full Fibre Channel protocol, why bother with convergence at all and just run two separate networks? In fact, I would argue that this approach actually adds more complexity and limits interoperability even further than the non-converged model. Now each FCoE switch is necessarily more complex (and expensive!) than a regular data center 10GbE switch and you're still managing two stacks.  At least with the typical Ethernet network, customers have comfort that there is some level of interoperability between vendors.  This approach seems to limit FCoE interoperability to no better than where the Fibre Channel industry is today. Again, I don’t think is the direction most customers want the Ethernet industry to go.

 

The comparison to VoIP

 

The last time convergence was being discussed this much was with VoIP ten years ago. I recall that most data networking vendors pushed for a “pure” model where voice packets would be transported over a native standards-based IP/Ethernet network while voice vendors (Lucent and Nortel at the time) opted for a “hybrid” model where switches would run both voice and data protocols to maintain control of their large legacy installed base. Yes, the IETF and IEEE had to develop enhancements to their respective protocols to equal the QoS requirements that voice enjoyed over a TDM network. But in the end, VoIP was successful because it ran over a ubiquitous, standards-based, open network and not a proprietary hybrid one.  Early adopters who chose proprietary or hybrid solutions instead of waiting for these final standards paid a dear price.  Those who waited or implemented in a phased approach over time enjoyed much larger savings.  Customers should be asking why Cisco and Brocade are playing by the same playbook as Lucent and Nortel did ten years ago.

 

Ethernet and IP have come a long way in the past few decades supporting new kinds of applications every year. I believe the industry will come together to solve the problem of transporting Fibre Channel traffic over Ethernet in a multi-hop environment that doesn’t depend on maintaining the status quo. If we can’t, then customers will likely vote with their pocketbooks and look for an alternative solution that meets these requirements. Today, that looks more and more like iSCSI.  Henry Newman at ESG seems to agree with me.

 

If Fibre Channel switch vendors say you need a layer 3 protocol to reliably transport storage over Ethernet, can we at least choose IP as that layer 3 protocol and maybe use iSCSI instead?   Just one step on the path to a converged infrastructure.

 

>> Experience HP's entire portfolio of enterprise business products, solutions and services by attending HP Discover Las Vegas June 6-10 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
About the Author(s)
  • Editor and writer with 12+ years experience in the corporate software and technology sectors.
  • Teri is responsible for the social media program for the HP Networking and HP Storage business units. Teri has has held global roles in IT, Operations, Sales, Partner Programs, Communications, and Marketing at HP.


Follow Us