OIF's Fabric Unification Isn't About the Fabric

What's interesting about the Optical Internetworking Forum (OIF) 's unified packet/OTN switch fabric is that it doesn't actually create a new, unified switch fabric.

The implementation agreement for the OTN over Packet Fabric Protocol was published Wednesday morning on the OIF's website (PDF form). The idea is to use one switch fabric to handle packet and Optical Transport Network (OTN) traffic.

But the fabric in the specification is a normal packet fabric. The implementation puts all the work on the OTN line cards: They get modified to parcel OTN feeds into packets.

The whole idea is to save money for telecom equipment companies building transport gear, routers and switches. Systems can support OTN and packets without having two switch fabrics, says Winston Mok, the technical editor of the implementation agreement.

It seems this would also make the protocol easier to implement. The switch fabric is often the heart of a system design. It's easier to change out line cards (which are made to be interchangable) than it is to tweak a switch fabric.

The packetized OTN traffic would probably have to get some priority, because OTN expects to see a constant bit rate. "They don't like long delays," Mok says.

Along those lines, the protocol includes a way for the OTN cards to preserve the timing that's associated with a particular OTN flow. It's done in code: The line card sends out packets of varying sizes, and the proportion of sizes indicates the required rate of transmission. For example, if the switch fabric is optimized for 128-byte packets, and the transmitting card is sending lots of 126- and 127-byte packets, that means the OTN transmission rate isn't very high.

"Signaling -- the frequency -- is the bulk of what this implementation agreement is about," Mok says.

The protocol isn't meant for every system. OTN traffic that's very time-sensitive should still go through pure OTN switches, Mok says. (Packet switching is inherently slower than OTN switching.) But he thinks that would be a small fraction of cases.

And of course, someone building a system for OTN only, not packets, would have no use for the protocol.

Some equipment vendors are already offering a version of the OTN-over-packet fabric; the protocol is "definitely doable" in a field programmable gate array (FPGA), Mok says.

— Craig Matsumoto, West Coast Editor, Light Reading

Pete Baldwin 12/5/2012 | 4:46:55 PM
re: OIF's Fabric Unification Isn't About the Fabric

That trick of "signaling" by varying the packet sizes sounds really cool, I have to admit.

So, now you're all gonna tell me it's something that's been used in wireless networks for decades, right?  :)

paolo.franzoi 12/5/2012 | 4:46:55 PM
re: OIF's Fabric Unification Isn't About the Fabric

Don't know about wireless networks.

But if you want me to point you to some patents that use that kind of technology, I can (as the primary inventor) from the late 80s in the design of ATM switch fabrics before the existence of the standard adaptation layers (i.e. I invented my on AALs before AAL0 - AAL5 existed, of course we were inventing our own ATM fabrics at the same time).



houxuanhu 12/5/2012 | 4:46:53 PM
re: OIF's Fabric Unification Isn't About the Fabric

Hi, Dear  Craig, As you have a lot of oppotunity to contact with optical Industry experts, What's your feeling/point on OTN switching and MPLS-TP swicthing in Metro application  in next 3-5 years?

You know, Juniper and Cisco all began to push MPLS switch machine for optical transport ( maybe Juniper first in Core with big machine, Cisco with smaller CPT in metro/access), while others mostly provide OTN based switch machines ( maybe also support packet switch).

rhr 12/5/2012 | 4:45:42 PM
re: OIF's Fabric Unification Isn't About the Fabric GÇ£Packet switching is inherently slower than OTN switchingGÇ¥: Interested as to what is it about packet that makes it slower to switch compared to OTN traffic?
Sign In