Optical/IP Networks

Cisco Clarifies Ring Strategy

It’s tough not to think of fairy tales when looking at the two schemes being put forward for the proposed resilient packet ring (RPR) standard for metro networks. Their names -- Aladdin and Gandalf -- are part of the problem, but the way in which Cisco Systems Inc. (Nasdaq: CSCO) explains its position doesn’t make things any easier.

Cisco started out by proposing its own spacial reuse protocol (SRP) technology as the basis of the RPR standard, but that didn’t go down too well with others in the 802.17 working group of the Institute of Electrical and Electronics Engineers Inc. (IEEE).

The main reason was that Cisco has already deployed a lot of SRP equipment (it now has 190 customers and has shipped 14,000 ports), so making SRP a standard would have given it a big competitive advantage.

At one stage, it looked as though things were getting deadlocked (see RPR: RIP? and RPR Divided). Cisco couldn’t get its SRP idea accepted, but it had persuaded a fair number of other vendors to develop SRP equipment and chips or to back its ideas. As a result, it had enough support to block adoption of Aladdin, an alternative proposal for the RPR standard from a group of vendors including Alcatel SA (NYSE: ALA; Paris: CGEP:PA) and Nortel Networks Corp. (NYSE/Toronto: NT).

To Cisco’s credit, it's got the standards process going again by dumping SRP and coming up with an alternative scheme, Gandalf. Last week, the concept was presented to the IEEE 802.17 working group in a paper from Cisco and its followers. Much emphasis was placed on Gandalf not being compatible with SRP and SRP silicon having to be respun -- the message being that Cisco wouldn’t gain an advantage by its adoption (see Cisco in U-Turn on RPR).

Here's where things get slightly strange. Cisco says this isn't a U-turn. Gandalf is merely “an evolution of SRP,” says Jeff Baher, director of marketing for Cisco’s metro IP access business unit. “Gandalf is by no means a departure from our SRP strategy,” he says. “We stand by the architectures we’ve already delivered. And we stand by our customers.”

Baher also refutes suggestions by competitors in the Aladdin camp -- notably Lantern Communications Inc. and Luminous Networks Inc. -- that Cisco’s introduction of Gandalf is an admission that there's something amiss with SRP.

Lantern and Luminous point to the main thing they think is amiss. They say that SRP only gives carriers a way of offering two types of service -- one in which bandwidth is dedicated to individual connections, or best effort. It doesn’t support a third service type required by the RPR standard -- one where customers benefit from lower costs by sharing bandwidth but still get performance guarantees, in the form of service-level agreements (SLAs).

Baher says this is a misconception. Both SRP and Gandalf can support SLAs and are the same in this respect, he says. “Our ability to offer SLAs hasn’t changed.”

Cisco plans to offer products based on SRP and whatever the RPR standard turns out to be, side by side, according to Baher.

Cisco has adopted a similar strategy in other fields in the past. It did this with routing protocols, offering its own proprietary IGRP (interior gateway routing protocol) or the standard OSPF (open shortest path first). It’s also done it with its proprietary Tag Switching or standardized Multiprotocol Label Switching (MPLS). In each case, customers have had a strong incentive to use Cisco’s proprietary version because the standardized version was slow to arrive (and in the case of OSPF, didn't work too well to start with).

While vendors in the Resilient Packet Ring Alliance still have some differences to sort out, they all agree on one thing: RPR complements rather than competes with the two technologies likely to be used in metro networks -- Sonet/SDH and Ethernet. The idea is that RPR can be used with either technology to support the types of service previously mentioned: connections with dedicated bandwidth, connections running over shared bandwidth, with SLAs, and best-effort.

To understand this, some context is necessary. Right now, most carriers make nearly all their revenues from services provided over TDM (time-division multiplex) channels, partly because telephony is still a big money spinner and partly because most data services are provided over TDM channels. These TDM channels are carried over access lines into add/drop multiplexers, where they’re aggregated and carried over Sonet/SDH rings in metro networks.

Sooner or later, this arrangement is likely to run into scaleability problems because data services are still growing at a fast rate. As a result, the task of setting up individual TDM channels for each customer will become unmanageable, as well as highly inefficient. “In the long term, the carriers are looking at building a data-centric architecture, “ says Kanaiya Vasani, director of marketing at Lantern.

The idea is that RPR can help them do this, in three ways. First, it gives them a way of offering different grades of service at different prices. Second, it gives them a simple way of carving up bandwidth to handle these different types of service. Third, it gives them a free choice of the underlying protocol in metro networks -- which comes down to Sonet/SDH or Ethernet.

This last point explains why the RPR Alliance’s membership -- and the backers of both Aladdin and Gandalf -- include established vendors of Sonet/SDH equipment as well as startups that make a big thing out of offering Ethernet solutions for metro networks.

The existing Sonet/SDH equipment vendors are planning to develop RPR blades for their existing add/drop multiplexers, a solution that’ll be attractive to incumbents with existing Sonet/SDH metro infrastructure. In some cases, the established vendors are likely to also incorporate DWDM functionality so that they can use RPR to aggregate large volumes of different types of traffic from thousands of users and then feed this onto multiple wavelengths.

Startups like Lantern and Luminous are planning to tinker with their existing boxes to offer RPR over Ethernet, a solution that’s more likely to find favor with startup carriers.

Cisco’s SRP is also physical media independent, according to Baher. In theory, it could run over Ethernet or Sonet/SDH, although Cisco’s current SRP boxes only operate over OC48 (2.5 Gbit/s) Sonet/SDH connections, for a couple of reasons. First, 2.5 Gbit/s is considerably faster than gigabit Ethernet. Second, Ethernet doesn’t incorporate a lot of the administration and management features found in Sonet, on which a lot of carriers rely. “Ethernet as a physical layer isn’t there yet,” says Baher. Those arguments might disappear when 10-gigabit Ethernet emerges, he adds.

— Peter Heywood, Founding Editor, Light Reading
PhilMorrison99 12/4/2012 | 7:31:57 PM
re: Cisco Clarifies Ring Strategy I think Jeff Baher makes some very valid points. That said, simply stating that one supports SLAs doesn't say very much. You can do traffic classification (via TOS), and you can rate limit using CAR, but what real world problem does this really allow you to solve? What guarrantees do I have that low priortity traffic that is already on the ring is re-prioritized once High priority traffic needs access to the ring, such as Voice or Video? Also how do you guarrantee that x-data traffic doesn't consume more ring bandwitdh then x% (is that something that needs to be configured on every node, seperately). You can classify on ring Ingress, but what happens to traffic that circles the ring like say multicast? I'm sure there is an excellent white paper that explains all this, so a pointer will suffice, thanks.

mu-law 12/4/2012 | 7:31:27 PM
re: Cisco Clarifies Ring Strategy And thus it is assured that both will be executed to half the extent (or, say 60/40) that one would be. A brilliant strategy of perpetuating mediocre products, while constructing barriers to entry, and creating a potential intertial booby-trap for SRP non-implementors.

Its unfortunate that this genius is not directed at the furtherance of the technology / industry, but I guess that's business.
Sign In