x
Optical/IP

Multiservice Nirvana

In the world of data networks, vastness is a value. The enterprise network needs extending we are told. LANs will leave the campus and head out across the metro or WAN. Businesses require new levels of continuity for distributed storage and computing resources. Of course, everybody must also access the Internet.

For carriers, simplicity is a value: Many protocols over a single, unified infrastructure would be ideal. This, in short, is the multiservice network that is often requested but has never been built.

Most dominant carriers today are in fact two-headed beasts, one watching over the circuits, another minding the packets. Though these two heads rest on the same shoulders, there is often mistrust or outright animosity between them. The circuit-minder has history on his side – years and years of operation and the all-important 50 millisecond restoration. The packet-minder has the future on her side. The world, through her eyes, is being packetized, and the network will soon be carrying everything from emails to movies.

Because the carrier is of two minds, it should come as no surprise that today we are seeing two contrasting models for the multiservice network. Although it would seem safe to bet that the packet-centric version will prevail (it has the future on its side, after all) the challenge from the transport network is worth a close inspection. It’s smarter than the average packethead might think.

It’s the Packaging

Multiservice networking begins with packaging. One way or another, the various PDUs (protocol data units) coming from a customer need to be encapsulated in a common container, and then identified in some way so the network knows how to handle them. How this packaging occurs is the fundamental difference between the two prevailing multiservice models. In the packet-centric model, encapsulation into IP or MPLS is the way forward, leaving behind yesterday’s multiprotocol adaptation over ATM. How do we get there? There are many draft standards circulating through the Internet Engineering Task Force (IETF)’s Pseudo Wire Emulation Edge to Edge (PWE3) working group. The goal is to provide a broad enough range of encapsulation for MPLS and IP to create a pure-packet network capable of supporting nearly every protocol and service class imaginable, including circuits. The network, ultimately, can be transformed into one made purely of packets, with the role of the optical network limited to little more than plumbing, a way to get packets onto a fiber and across town.

Over in the transport network, it’s not as though engineers have been sleeping through the revolution. We now have GFP (generic framing procedure). Though it appeared on the scene at the end of 2001 as little more than a guide for adaptation of Ethernet and Fiber Channel to Sonet/SDH and OTN (optical transport network or “digital wrapper”) networks, it is showing signs of evolving into a true multiservice model.

I Want My GSMP

The latest proposal for the evolution of GFP and next-gen Sonet/SDH is GSMP (Generalized Service Multiplexing Procedure) being brought before the ANSI T1X1.5 subcommitee by Agere Systems (NYSE: AGR/A), Native Networks Ltd., and Applied Micro Circuits Corp. (AMCC) (Nasdaq: AMCC). With the standards for GFP, virtual concatenation, and LCAS (Link Capacity Adjustment Scheme) already in place, GSMP proposes to allow “multiple data services to statistically share this already deployed, underlying transport pipe. This will enable improved transport bandwidth efficiencies and will provide the basis for connectivity services with guaranteed QOS/SLAs per traffic flow.” In short, next-gen Sonet wouldn’t just be about circuits anymore, but about packets.

GFP can be looked at as a friendly, easy-to-use adaptation mechanism for putting Ethernet and Fibre Channel, among others, onto an optical network. But GSMP sounds more like a whole new networking layer with a full range of service possibilities. This isn’t far from the truth, and it is pushing Sonet and SDH into risky but promising territory. GFP already has something called the “linear header frame format” which allows multiple client signals to share the same GFP payload. This would allow many Ethernet customers at 10-Mbit/s each to ride together in an STS3, for example (can you think of anything more fun?). The separation and management of these customers is handled by GFP itself, not the Sonet layer, so GFP can be used to create virtual leased lines in point-to-point connections.

GSMP proposes to push this capability of GFP to a new level. According to Gilad Goren of Native Networks, one of the authors of the GSMP proposal, “GSMP extends GFP with the notion of labeling or tagging.”

GSMP’s own tag is called an Extended Linear Frame, which has the necessary header space to support unique addresses, priorities, and classes of service, along with extension header stacking for scaleability. Much as with ATM or MPLS, client frames are tagged, and once they are tagged the sky’s the limit as to how you can work with them, including multiplexing, oversubscription of services, and per-flow traffic management at the packet level. A single GFP connection could now hold various Ethernet subscribers, storage transport, and packet-ring services. These individual services can have their own restoration options, various levels of oversubscription, and a range of QOS. For the folks over on the transport side of the house, this is a multiservice network they can get a hold of and run with.

The big applications envisioned for GSMP are aggregation of a single customer’s multiple flows; delivery of data services to multiple customers collocated in one or more buildings in the metro area; aggregating traffic from multiple Ethernet-based DSLAM uplinks; and grooming data-over-Sonet traffic from multiple, partially populated, Sonet/SDH pipes.

Okay, so you can already hear the groaning: Do we really need another network layer that promises service unification? Isn’t MPLS enough? Or even ATM – which seems to have a second lease on life of late. But GSMP, using a GFP-based approach, is much more bandwidth efficient than ATM and will have much less expensive interfaces, since no process-intensive SAR (segmentation and reassembly) is required. It’s also truly protocol agnostic, supports any topology, has unique header protection mechanisms, and could ultimately employ a unified management system for all services – from Ethernet, to ATM and Frame Relay, storage, and even video distribution. And best of all, it’s based on Sonet/SDH, so the core of the transport network remains untouched: Only the edge needs upgrading, one service mux at a time.

Money Will Talk

The ongoing debate around GSMP comes down to whether to use MPLS as the tagging mechanism or not. The GSMP authors argued for a new tagging mechanism based on GFP’s linear extension header; others argue for MPLS.

“I have discussed the GSMP proposal with several other key industry folks and there is a bit of a backlash against it being inconsistent with MPLS,” says Jonathan Reeves, President and CEO of Mangrove Systems Inc. Reeves would rather see a direct mapping of an MPLS label into the GFP header. This would enable GFP to become an integral part of the MPLS control plane, or it could be provisioned by OSS systems in non-MPLS environments. The payoff here is that if and when carriers do deploy GMPLS-based networks, the GFP sub-level can be controlled using the same procedures as the circuit provisioning level.

So, is this a case of the transport network trying to assert its relevance in the face of “netheads” wresting control of the helm? And since we’ve already done so much work to make MPLS the true multiservice network solution for IP networks, why bother with Sonet/SDH, the OTN, and GFP? Well, the answer is simple: The transport network is making money; the data network isn’t. That gives the transport guys some credibility in standards bodies, and it gives big transport equipment vendors a chance to assert an alternative to the “all-IP” world of Cisco Systems Inc. (Nasdaq: CSCO) and Juniper Networks Inc. (Nasdaq: JNPR).

Ethernet and storage services are the first stabs at expanding the role of Sonet and SDH, and so far it appears to be working. Incumbent carriers are taking a hard look at GFP and are gingerly taking steps to roll out storage and Ethernet connectivity services this year. The big question is how they evolve these first, rather dull, point-to-point metro offerings to fully realized multipoint services with all the options of fast-packet services of old. The transport guys will bring GFP and something like GSMP to the table, while the IP folks will offer up PWE3. In this day and age, it will likely be the CFO who decides. Which means it’s really anybody’s guess who wins.

— Scott Clavenna, Director of Research, Light Reading

Disclosure: The author has no financial relationship with any of the companies mentioned in this column.
avri 12/5/2012 | 12:11:21 AM
re: Multiservice Nirvana I find it intersting that they are using this name for a new protocol.

GSMP (General Switch Management Protocol) is an
IETF proposed standard (RFC 3292-3295). This is the third version of the protocol. The first released version, RFC1987, was created by Peter Newman at Ipsilon in 1996.

GSMP is currently used for MPLS an GMPLS control of underlying switch fabrics, incliding ATM, Optical and TDM. It sounds somewhat similar in use to the GSMP mentioned in this article.

Avri Doria
co-chair GSMP WG in the IETF
avri 12/5/2012 | 12:11:19 AM
re: Multiservice Nirvana In my last message I forgot to mention that
GSMP (RFC3292) was also selected by the Multiservice Switching Forum (www.msforum.org) as its choice for the interface between the virtual switch function and the control function.

This interface is similar to the CC interface being defined in the ASON/ASTN architecutre in the ITU. GSMP (RFC 3292) will be recommended as a candidate for that interface when it comes time to define it.

a.
Scott Clavenna 12/5/2012 | 12:11:18 AM
re: Multiservice Nirvana That's a great point. The first time I called someone to ask them about GSMP they said, "Well, that's a doomed acronym. Don't they know about the IETF group?"

At the ITU it's been mentioned in the G.esm (Ethernet service multiplexing) work in Study Group 15, and also part of the larger G.eota (Ethernet over Transport Architecture).

We've officially run out of acronyms I'm afraid.

Scott
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE