Optical/IP Networks

How About a Dry Martini?

At our recent Light Reading Live event, “The Future of Sonet,” we posed the question: “What is the next gen of next-gen Sonet?”

It seems one or two gens weren’t enough, and vendors and carriers alike are busy defining a third and fourth. While ops folks within service providers are just getting their hands on boxes with features such as virtual concatenation and GFP (generic framing procedure), the network planners in these organizations have been looking out three to five years to something better: a lasting, loving marriage of Sonet and MPLS. This marriage will be toasted not with champagne, but with a “Dry Martini.”

After sometime in mid-2001, the word Martini, when spoken to a nethead, no longer conjured the image of gin with a splash of vermouth in a dew-dappled conical glass. Instead, a rather difficult image was forced to mind: Frame Relay or Ethernet connections carried across an IP/MPLS network in “tunnels.”

The mouth didn’t really water at the thought of it, but Martini-based VPNs (virtual private networks) have proved immensely important to the ongoing evolution of the packet network – from one based on multiple control and data layers specific to every service, to one in which an MPLS core was capable of transporting many legacy services (Frame Relay, ATM, PPP, and Ethernet) as long as it had the proper shim. This was, by most accounts, the first real step towards convergence.

But convergence, it appears, doesn’t begin and end within the packet layer. Talking with a number of incumbent operators and a handful of transmission vendors recently, I kept hearing the term Dry Martini. This one is not tied to Luca Martini himself, but is derived from the concepts he created around “pseudowires,” or the emulation of Layers 1 and 2 services across an IP/MPLS network. Some call it Transport MPLS (TMPLS, a new acronym!), but Dry Martini just has an easier ring to it.

Up to now, the pseudowire concept was linked almost exclusively with IP gurus in the IETF. Those companies building Sonet boxes watched from a distance, but didn’t think pseudowires had much to do with their world. The closest they came to MPLS was GMPLS (Generalized MPLS), which dealt only with the IP/optical control plane – namely, resource and topology discovery, provisioning, and protection. Progress with GMPLS has been steady (though without much in the way of sex appeal lately) and continued at Supercomm this year, with seven large carriers and numerous vendors demonstrating optical services initiated via an interoperable control plane.

But where Generalized MPLS focused its efforts on managing the optical layer, the Transport MPLS concept is about what’s inside those optical connections – namely, VPNs – and how to dramatically improve the way in which the transport network carries them.

According to Jonathan Reeves, CEO of Mangrove Systems, “Pseudowire technology picks up where ATM left off. We now have a networking tool that enables all packet services including Frame Relay, ATM, Metro Ethernet, and IP to be carried in a consistent format, with unified OAM and QOS. To date, the technology has been focused on edge router applications; the next step is for PWE3 to move into the metro and access networks, which are today based on Sonet/SDH. This is where it gets interesting! Transporting pseudowires over GFP/VCAT allows us to unify the networks producing a new transport network that will be both data-efficient and fully packet-aware.”

The service providers, particularly IXCs, have forced the issue recently, insisting on further consolidation of transport and packet layers to reduce their capex and opex associated with Layer 2 services. ILECs may soon follow suit, now that they are rolling out Ethernet services in earnest while continuing to support legacy Frame Relay and ATM. They may turn to the pseudowire as a means of carrying both legacy and emerging services over their newly deployed IP/MPLS networks – and if they include support for pseudowires within their transport gear, then they will be drinking the same Dry Martini as the IXCs.

The distinction between next-gen Sonet and Dry Martini, though subtle, is everything. Next-gen Sonet is based on a set of standards that allow data services to be mapped to Sonet more efficiently and deterministically. Dry Martini adds a much richer dimension to the transport network: the ability to see inside those connections and provision pseudowires and manage packet services within transport gear.

“The boundaries between IP and optical networks are blurring with the deployment of Ethernet interfaces on transport equipment, coupled with carrier-grade requirements for next-generation services” says Arpit Joshipura, Vice President for Portfolio Solutions Marketing at Ciena. “Pseudowires, or Dry Martini, is the next logical evolution beyond next-gen Sonet.”

Thus, where next-gen Sonet addressed the need for efficient transport by carving up bandwidth into right-sized chunks to match customer or data interface requirements more closely, Dry Martini takes a step further by terminating the data traffic and repackaging it as a pseudowire. This doesn’t necessarily require full-blown switching of data traffic, just termination, stripping out of idle frames so that only real customer data gets transported, and encapsulating that good data into specific pseudowires, bound for wherever the MPLS network takes them. This process gives next-gen Sonet boxes true packet awareness, so they can better treat traffic of different classes and priorities.

This quickly elicits groans of “yet another God Box” from skeptics, but IXCs have a good reason for wanting packet-aware transport: access charges.

Whenever an IXC has to lease a circuit from an ILEC to get to a customer, its margins take a hit. The fewer of these leased circuits, the better. The goal, therefore is to get as much traffic onto a circuit as possible, which you accomplish with new forms of customer-located equipment (CLE) based on next-gen Sonet. Back at the IXC’s metro POP, they are looking for another level of efficient aggregation, this time with the goal of reducing the number of ports in use on digital crossconnects, ATM and Ethernet switches, and big IP routers. AT&T and MCI are the strongest advocates of this application today, and others are beginning to take notice, particularly some big PTTs in Europe.

The value of pseudowires in a packet-aware transport network doesn’t stop there. Efficiency is nice, but only part of the story. The “Dry Martini” has a few more values to offer. According to Gady Rosenfeld, Director of Strategic Marketing for Corrigent Systems, “The pseudowire scheme brings to the transport network the ability to provision services end-to-end in a way that is decoupled from the process of allocating physical facilities. In addition, it allows the transport network to distinguish between best-efforts and premium services, regardless of their protocol.”

In short, the transmission folks are no longer stuck being plumbers, fitting pipes together from point A to point B and leaving it at that. With the advent of pseudowires, the packet-switched network now may pass directly through transmission network elements. Thus, a pseudowire-based service (VPLS, for example) may begin on an MSPP, traverse a “packet-aware” core optical switch, tunnel through a few core routers, then terminate on an edge router.

The operator’s packet-switched network will now include these transport network elements, and it can provision these services from a single console using a language common to both those that lay the pipes and those that fill them. In this light, Dry Martini is a bridge built to span the transport and packet services networks, something talked about for over a decade but extremely difficult to achieve.

What does this all add up to? that depends on whom you ask. The IXCs certainly are intrigued, and are beginning to test these concepts in labs. At our Live event, Bob Doverspike of AT&T Labs spoke at length about the values of packet-aware transport, saying he had it all working in the lab, not just on Power Point. ILECs and CLECs are just starting to examine this concept, and will likely lag a bit because they are not driven by quite the same forces as the IXCs and tend to be more resistant to anything that would substantially disrupt their operations procedures.

For vendors, Dry Martini or TMPLS is an opportunity to stand out in a very crowded market for next-gen Sonet systems. The nice thing about Dry Martini is that it extends from core to access, creating opportunities for Dry Martini devices that sit at the customer premises, in metro COs and core POPs. Here’s a rundown of how products may evolve based on these concepts:
  • Core STS switch vendors will be adding “data-awareness” to their products – first via VLAN awareness, next via pseudowires – and positioning them more at the edge as a service gateway. The market in the core is rather dead, and these vendors see that the action is at the edge of the core.

  • Metro Core Aggregation Switches (Mahi's Vx7, Lucent's Lambda Unite, Cisco's 15600, etc.) primarily perform metro ring aggregation today, but will be adding Layer 2 data aggregation as well. This will first be centered on Ethernet and employ VLANs, but eventually will migrate to pseudowires so that all Layer 2 services will be treated with a common language and MPLS toolkit.

  • MSPP vendors will also be moving from Ethernet services support via VLANs to the use of pseudowires for all Layer 2 services.

  • “Micro MSPPs” and other CLE will become pseudowire access devices, converting customer traffic into pseudowires and transporting that traffic via Ethernet or Sonet/SDH, depending on the legacy network. This is an interesting one to watch, as it brings MPLS all the way to the customer premises, completing the end-to-end story of MPLS as a real service solution, not just a traffic engineering tool.
For now, sit back and enjoy another drink. This is the best-named service concept we’ve ever had.

— Scott Clavenna, Chief Analyst, Heavy Reading

To learn more about next-generation Sonet, check out Scott’s recent Heavy Reading Report: The Future of Sonet/SDH. His next Report, coming in September, will be an in-depth exploration of “Pseudowires.”

For more on this topic, check out:

For further education, visit the archives of related Light Reading Webinars:

pingpan 12/5/2012 | 1:29:31 AM
re: How About a Dry Martini? Here is the pointer to the draft:


There are a number of issues yet to be resolved, such as the support of QoS and the translation/interface of OAM etc.

- Ping
dadofamunky 12/5/2012 | 1:29:29 AM
re: How About a Dry Martini? Yep, he's right. MPLS doesn't have clearly defined OAM (a big historical objection). There is also probably no less unified vendor feature out there than QoS, because of the inconsistency of the chip vendors. We have WRR and WRED standards but everyone does it differently.... How is MPLS going to solve that issue? At least, within a timespan short enough for us to see the result in our stock portfolios before we die?

I also don't see how MPLS can terminate on the customer premises when the whole point of MPLS VPNs and PWE3 is to eliminate as much CPE foolishness as possible. The benefit of PWE3 is to enable widely spread campuses and sites to unify their broadcast domains and simplify their WAN topology. Who needs MPLS on an Extreme switch?

Still, it's nice to see someone talking about future solutions and developments instead of what we CAN'T do.... Guess that's my job....
optodoofus 12/5/2012 | 1:29:04 AM
re: How About a Dry Martini? I downloaded and read the Dry Martini spec, and I don't see why this is a big dal at all. Essentially, it is a proposal to tunnel PWs over non-MPLS tunnels such as ATM VCs, SONET paths or optical waves. If you put a black box around the solution, yopu can deliver exactly the same thing with a pair of routers and a transport network in-between. UUNET did this a decade ago by using an ATM core between their routers. Cisco took this a step further by developing an RPM blade directly in the MGX switch years ago.

It's true that Martini PWs didn't exist back, but they do now. So why exactly is this proposal innovative and new? Even without this, anyone could develop a router/switch blade for their ADM/optical switch/ATM switch, and many have. If I'm missing something, please speak up.

A more interesting development would be to explore the implications of this solution for an access solution as opposed to an end-to-end solution as described in the draft. Since most service providers have TDM-based access networks, this would be a useful solution for extending MPLS access out to the customer prem (or at least a lot closer than it currently goes). The point where the access network meets the core packet network would be an interesting point, and understanding how this transition works will be the key to knowing whether this technology offers real benefit to service providers. A bookend solution would probably be much less interesting to service providers than a solution that hands off PWs from the access to the core.
pingpan 12/5/2012 | 1:28:58 AM
re: How About a Dry Martini? Did I claim it was a new innovation? Simply asking to extend PW's over all media, beyond the current design of over MPLS LSP's or GRE tunnels.

As you have pointed out, many carriers have SONET/ATM switch networks, and they may stay there for a long while. And the carriers want to be able to aggregate customer flows toward the core through those networks. One mechanism would be to setup PW's, but PW's are defined for MPLS LSR's so far. I was just pointing out here that the carriers may use draft-martini over those over(well)-engineered cross-connects and circuits without dealing with MPLS LSP's. I believe this would be a cost-effective solution if exercised well.

Further, draft-martini is providing a nice packet encapsulation mechanism for aggregation. What is wrong by using it beyond SONET/ATM? Try WiMax? With it's 30-mile range, and designed toward wireless private-leased line. Run draft-martini over it straight to aggregate mini-flows.

As for your router-on-a-blade solution, try this: support 20G (for 40G in Cisco math) throughout per linecard on a traditional ADM/SONET switch, without killing the power budget (here goes your NPU solution), and disturbing the existing features (APS, UPSR...), and keeping it cheap (cheaper than per-router-port). Not sure it is that easy.

Thank you for reading my draft!

- Ping
Scott Clavenna 12/5/2012 | 1:28:57 AM
re: How About a Dry Martini? http://dl.comsoc.org/cocoon/co...
Say_Yes_2_MPLS 12/5/2012 | 1:28:43 AM
re: How About a Dry Martini? Ping, as you say, the draft describes tunnelling PWs (using MPLS labels) over a L1/L2 connection/flow. Optodoofus points out that this could be done by sticking an IP/MPLS router at each end of the connection/flow or by putting an IP/MPLS blade on an ADM/L2 switch. However, you state that the router on a blade idea is more complex/expensive than your proposal. This raises the question - How exactly do you foresee this being deployed in the real world? To support PWs, at each end of the connection/flow there must be a device that:

i) has an IP address and understands IP packets
ii) supports LDP signalling (so needs to support UDP/TCP)
iii) can understand MPLS packets and push/pop MPLS labels
iv) can forward packets out of an outbound interface/VC based on an MPLS label, i.e. has a label information/forwarding table.
v) can be managed, i.e. needs MIBs, ICMP, SNMP

Doesn't this sound like an IP/MPLS router? Admittedly it doesn't need to support BGP, OSPF, L2TP, IPsec, etc. etc., but it does still require a fair bit of IP/MPLS functionality. So at the end of the day, the end device must support IP/MPLS functionality, whether it is on a separate blade or built into the network facing linecards.
pingpan 12/5/2012 | 1:28:40 AM
re: How About a Dry Martini? Hi,

You are making a very good point. Router-on-a-blade has been brought up internally in the past. After painfully going through the implementation details on the product I was working on, I had to believe it was a pie-in-the-sky. As I had pointed out before, its problem was mainly due to hardware requirements (power, real-estate, cost, memory, compatibility...).

Looking at the five conditioned you have listed, most of the existing devices can implement them without too much trouble. In fact, any home PC can support all five with a minor Linux/BSD kernel modification for label push/pop. On hadrware, a FPGA (or gate array) implementation can do the job. However, it is not a IP/MPLS router. You have pointed out nicely. The complexity to deal with route import/export at control plane, and the hardware requirements to support per-packet route look-up can be avoided in this case. This is because our problem space is to transport (layer-2) data flows over existing ATM/SONET infrastructure, where there exists a non-IP operational control-plane already.

Yes, I say "yes" to MPLS all the time. :-) There is no doubt in my mind that the core will be based on IP/MPLS eventually. At the same time, the carriers need to be able to aggregate customer-flows from access before entering MPLS core. This is the space where I believe dry-martini can take the advantage of the existing networks.

I did look at the IEEE paper that Scott had posted when it came out in April. From other feedback from other customers, they all seem to point toward the same direction where dry-martini is trying to address.


- Ping
optical_optimist 12/5/2012 | 1:27:57 AM
re: How About a Dry Martini? Correction to your article Light Reading ...

Mahi's Metro Core Aggregation Switch is the Mi7.
The Vx7 is their ROADM box, formerly known as the Photuris V32000.
Sign In