Cisco's Resilient Ring Gets a Boost

There was a time when standards had to be agreed upon before semiconductor vendors could implement them, but those days are long gone, to judge from today’s announcement by Mindspeed Technologies, a division of Conexant Systems Inc. (Nasdaq: CNXT)

Mindspeed says that it’s developed the first chip to support the proposed IEEE 802.17 Resilient Packet Ring (RPR) standard (see Mindspeed Offers Packet Ring Solution), a technology that aims to give low-cost Ethernet networks some of Sonet’s self-healing capabilities (see IEEE Tunes Ethernet for Telcos).

But guess what? The Institute of Electrical and Electronics Engineers (IEEE) hasn’t even started discussing the proposed RPR standard. The first meeting is planned for March.

In fact, Mindspeed’s chip, the CX29950 RingMaker, implements technology called the spacial reuse protocol (SRP) that Cisco Systems Inc. (Nasdaq: CSCO) has been trying to get standardized for a couple of years. It forms the basis of Cisco’s Dynamic Packet Transport (DPT) equipment that’s already in use in Internet service providers’ points of presence, cable networks, and (oddly enough) some metropolitan area networks in China (see Cisco's Second String).

So, how can Mindspeed wave a magic wand and turn its SRP chip into an RPR one? And is this some sinister Cisco standards plot in the making?

Mindspeed says it’s nothing of the sort. It acknowledges that it might need to tinker with its chip to bring it into line with whatever standard comes out of the IEEE. “We will make any modifications required,” says Lauren Schlicht, product line manager for Mindspeed’s broadband internetworking systems unit.

However, Schlicht isn’t expecting major changes, because the IEEE is likely to limit the scope of the RPR standard to bridging between rings. The upshot is that proprietary technologies, such as Cisco's SRP, will continue to be used within rings. Carriers accept that they won't be able to mix equipment from different vendors on the same ring, according to Schlicht. Cisco’s biggest competitor in this field, Nortel Networks Corp. (NYSE/Toronto: NT), has its own ring technology called Optera Packet Edge (see http://www.nortelnetworks.com/products/01/optera/packet_edge/doclib.html for details). Right now, Nortel has embedded its ring technology in some of its products but hasn’t encouraged other vendors to adopt it in the way Cisco has with SRP.

Schlicht says that Mindspeed is already working with nine vendors (in addition to Cisco) that are using its CX29950 RingMaker to develop equipment. So far, only one of them -- Riverstone Networks -- has announced an SRP-based product.

All the same, nine vendors developing SRP-based products equate to a fair amount of support for whatever Cisco submits to the IEEE working group developing the RPR standard.

One fly in the ointment could be that the current version of Cisco's DPT has a fundamental problem -- that it won't support DiffServ (differentiated services), a crucial standard for enabling service providers to offer different grades of service at different prices, according to Juha Heinanen, the CTO of Telia Finland (a subsidiary of Sweden's Telia AB) and an Internet infrastructure guru.

The problem stems from the fact that DPT only supports two traffic classes that have a strict priority relationship, according to Heinanen. "DiffServ requires more than two traffic classes, each with its own configurable buffer space and scheduling weight," he says. "Also, within each class, it should be possible to assign packets a different level of drop precedence." This isn't possible with DPT.

Heinanen also points to problems with the way in which DPT ensures that attached equipment doesn't hog access. "DPT's FDDI-like, node-based fairness concept would need to be redesigned in order to make RPR DiffServ compatible," he says. -- Peter Heywood, international editor, Light Reading http://www.lightreading.com

Page 1 / 6   >   >>
Peter Heywood 12/4/2012 | 8:56:45 PM
re: Cisco's Resilient Ring Gets a Boost The last time I wrote a story on DPT, I got some interesting feedback on its shortcomings.

Anybody care to remind me what they were?
bcdma 12/4/2012 | 8:56:39 PM
re: Cisco's Resilient Ring Gets a Boost I strongly oppose providing ring solutions to carriers any more. Provisioning and management is complex and it is a hack.

Both at L3 layer and at physical layer (SONET or WDM) we should view the network as mesh. A ring with 4 nodes is a mesh network with a degree of 2.

We should move up protection from physical layer to l3 and use IGP fast convergence with pre-setup backup LSPs in the absense of fast IGP convergence to provide resiliency. Not all traffic needs protection any more. Voice traffic is 0 sum game and who cares for SONET rings in all packet networks of the future. The underlying physical transport may still be sonet. But we can move away from its BLSRs and UPSRs if effective L3 restoration strategy is worked out.
Peter Heywood 12/4/2012 | 8:56:38 PM
re: Cisco's Resilient Ring Gets a Boost I've updated the story with some information from Juha Heinanen on why the current version of DPT won't support Diff Serv, which sounds like a significant shortcoming.

The additional material is in the last few paragraphs.

FiberFan 12/4/2012 | 8:56:32 PM
re: Cisco's Resilient Ring Gets a Boost I agree with both points below. Why, after all of this time are we still reliant on "dumb" protection? The question I would pose is could the protection be both layer 2 and 3 (and perhaps L4 or higher) based on the type of traffic carried? Although voice isn't growing, it's not going away either. The RPR standard should take into account all types of traffic, voice, data and let's not forget video. With proper QOS mechanisms (like DiffServ) and perhaps syncronization there could really be one, standard platform for carrying all 3 traffic types. Not one for data and one for voice & video. Isn't that just about what we have now? I think RPR is our only hope of service providers not being forced to "bolt boxes" together. I would encourage all of the SP's out there to take a look at the RPR and get them to work for you.
Your thought?
Peter Heywood 12/4/2012 | 8:56:31 PM
re: Cisco's Resilient Ring Gets a Boost I asked Cisco whether it had got anywhere with encouraging other semiconductor vendors to develop SRP chips. Here's the reply:

"We'll be announcing several test, system as well as silicon partnerships in the next few months."

I also asked Cisco to comment on Juha's point about DPT's lack of support for Diff Serv. It's hoping to find someone to respond tomorrow.


FiberFan 12/4/2012 | 8:56:29 PM
re: Cisco's Resilient Ring Gets a Boost Peter,
It might be nice to hear about their potential support for latency and jitter sensitive traffic as well. DiffServ is very important but not being able to carry multiple traffic types (to replace all of those aging OC3-12 SONET rings) would be a backbreaker for RPR. The folks I have spoken to says DPT isn't really meant for voice traffic. We already have a single dimension solution. I don't think we need another.
Your thoughts?
Peter Heywood 12/4/2012 | 8:56:28 PM
re: Cisco's Resilient Ring Gets a Boost Fiberfan, I'm talking to Cisco today so I'll ask your question.
Prime 12/4/2012 | 8:56:27 PM
re: Cisco's Resilient Ring Gets a Boost The rumor is the Urban Media lost its $54 million of funding, and is closing shop. Is this true? What have you heard?
bcdma 12/4/2012 | 8:56:26 PM
re: Cisco's Resilient Ring Gets a Boost You seem to agree, yet suggest people use RPR. My point is we should not encourage RPR and standardization of yet another ring protocol, albeit at packet layer. What happened to Token ring?.

Any ring specific application of routing alogrithm can always be equated to a mesh network of degree 2 and IGP can find best routes .
Pilen 12/4/2012 | 8:56:23 PM
re: Cisco's Resilient Ring Gets a Boost I think you should take a look at the other Alliance members as well. From my point of view Dynarcs (CRS) Channelized Reserved Services, seems to solve the problem in a extraordinary way. Info on homepage, dynarc.com
Page 1 / 6   >   >>
Sign In