FCoMPLS – attack of the zombies

A while ago someone asked me whether I think FC-over-MPLS would be a good PhD thesis. My response: while it’s always a good move to combine two totally unrelated fields in your PhD thesis (that almost guarantees you will be able to generate several unique and thus publishable articles), FCoMPLS might be tough because you’d have to make MPLS lossless. However, where there’s a will, there’s a way ... straight from the haze of the “Just because you can doesn’t mean you should” cloud comes FC-BB_PW defined in FC-BB-5 and several IETF drafts.

My first brief encounter with FCoMPLS was a twitxchange with Miroslaw Burnejko who responded to my “must be another lame joke” tweet with a link to a NANOG presentation briefly mentioning it and an RFC draft describing the FCoMPLS flow control details. If you know me, you have probably realized by now that I simply had to dig deeper.

FC-BB_PW architecture is defined in FC-BB-5. It uses the traditional AToM pseudowire paradigm, making it completely different from FCoE (or FCoTR). The MPLS-based pseudowire simply extends a fiber channel link between adjacent FC nodes and provides lossless data transport across an MPLS cloud; all the higher-layer functions are performed by the FC nodes.

By now you should be wondering how you can make MPLS lossless. draft-ietf-pwe3-fc-flow bases FC-BB_PW flow control on a venerable field-proven mechanism called LAPB (yes, the same thing used in X.25 and LLC2). Pseudowire endpoints acknowledge frames received through the pseudowire with RR frames and request retransmission of missing frames with SREJ frames. In case you’re an SDLC aficionado wondering where the RNR frame is, don’t worry; RNR’s are also part of the flow control mechanism, providing a truly graceful way of indicating that you’re totally out of buffer space. Oh, and just in case packet drops would not be a sufficient indicator of link congestion, they implemented the throughput equation specified in the TCP-Friendly Rate Control protocol.

If you’re still not persuaded that the whole FCoMPLS shenanigan should be published on April 1st, let’s take a brief history lesson: protocols providing lossless hop-by-hop transport through explicit acknowledgement scheme (including LAPB) were designed to work in low-speed high-loss environment. No wonder you’ll find most of technologies using this approach (including X.25, SNA/LLC2 and Reliable PPP) in dusty networking history books. Resurfacing the same approach in gigabit environment makes absolutely no sense.

OK, one might understand the need for slim and efficient retransmission protocol in early 1990’s when the CPU power was expensive and the Ethernet cards provided barebones packet transmission functionality. Welcome to the new millennium where Intel’s 10GB adapters with full TCP offload cost less than $1500 and where most engineers consider FCIP and iSCSI viable long-distance SCSI transport technologies. But I’m positive there must be a startup hidden somewhere developing FCoMPLS technology ... and once a major vendor acquires them, their marketing department will be delighted to share the wonders of another fantastic MPLS 2.0 technology with us.

3 comments:

  1. I'm boggled. Why transport FC over MPLS natively ? It's bad enough that FC exists at all. Instead of solving problems in the protocol they said "network must be lossless" and avoided all the hard work.

    Of course, the fact that FC networking costs ten times a data network would not be a motivating factor would it ? After all, they needed to design their own fibre optic cabling, high end xcvrs, lossless forwarding fabrics etc etc.

    However, I'm mightily impressed by the use of the legacy technology to make it work. The more cruft they slap on, the better it will be. We will be making a fortune out of this idiocy.

    fantastic.

    ReplyDelete
  2. Ivan,

    Great post. FC should go and more people are realizing that nowdays. If you were to start a PHD today what would be your thesis?

    ReplyDelete
  3. My PhD thesis? Something to do with "how do we fix IP protocol stack?"

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.