x
Optical/IP

RPR Moves Forward

The Institute of Electrical and Electronics Engineers Inc. (IEEE) Resilient Packet Ring 802.17 working group has agreed on a preliminary draft of a standard, according to sources at the working groups meeting in Orlando, Fla.

Today roughly 80 percent of the group, consisting of about 100 individuals from system vendors, chip makers, service providers, and academia, accepted the joint proposal from Cisco Systems Inc. (Nasdaq: CSCO) and Nortel Networks Corp. (NYSE/Toronto: NT) known as “Darwin”.

"After long debates on the principles of the standard, we're finally at a stage where we can continue to the next and final phase -- writing down the actual standard," says Gady Rosenfeld, director of strategic marketing for Corrigent Systems.

This meeting is particularly important because for months observers have questioned whether or not the group would be able to achieve its goal of having a single draft by the end of the January meeting. Back in November it looked as though the two main groups -- “Gandalf” led by Cisco and “Alladin” led by Nortel -- were at a standstill (see RPR: Deadlock Ahead?). But now the two have come together and submitted a joint proposal: Darwin (see The Darwin Approach: Evolution of Resilient Packet Ring).

While Darwin has been marketed as a joint effort between the Gandalf and Alladin supporters, Fredric Thepot, an independent consultant attending the meeting, says that the new proposal is simply a redrafted version of Cisco’s Gandalf proposal.

“If you take the two texts, what you see is the Gandalf proposal with a few things thrown in from Nortel,” he says.

First, consider bandwidth management. Darwin, like Gandalf, doesn’t mention virtual output queuing, which controls congestion by limiting the number of packets entering the ring. But it was mentioned in the Alladin proposal. John Hawkins, senior manager of marketing for optical Ethernet at Nortel downplays this omission and explains that since queuing is not part of the MAC (media access control) layer, which the group is trying to define, it was left out of the standard.

“You can still do virtual output queuing using Darwin,” he says. “Even in the Alladin proposal it was an option.”

Hawkins also points out that in terms of bandwidth management, both Gandalf's congestion management and Alladin's congestion avoidance schemes are included in the proposal.

“Each group was espousing the virtues of their own approach," he says. "But there are networks that can use either method depending on the service provider's requirements. We decided we ought not preclude one or the other.”

“It’s like the difference between driving a car with an automatic transmission or one with a manual transmission,” adds Jeff Baher, director of marketing, Metro IP Access Business Unit for Cisco.

The Alladin group also seems to have made big concessions when it comes to packet formatting. Hawkins agrees that the Darwin packet format has the same look and feel as Cisco’s originally proposed spatial reuse protocol (SRP), but he says that additional fields have been added, like a header error checking field, which is required for more carrier-class applications. He also admits that more work is needed in this area.

“There are some complications in bridging between rings," he says. "And there will likely be other complications that come up that we haven’t even thought of yet. But this is a starting point.”

One area where Cisco seems to have compromised is in the protection scheme. The Gandalf proposal recommends "packet wrapping" as the default, with "packet steering" as an option. Packet wrapping is a scheme that calls for packets to simply turn around and go the other way around the ring when they hit a disconnection. Steering calls for all nodes to be notified of a failure and would direct traffic away from the fiber break. Alladin supporters proposed that the standard include steering only. In the end, the Darwin proposal uses packet steering as the default with wrapping as the option.

“The most important thing is to meet the 50 millisecond restoration time requirement,” says Cisco’s Baher.

In the end, members of the working group are satisfied that there will be a single draft to work on from here on out. But Thepot suggests that it has come at a particularly high cost to Nortel's installed base of customers. He believes that Cisco, which also has a large installed base, will have an easier time adapting its technology to the Darwin proposal than Nortel.

“To me it looks like Nortel lost in all of this,” he says. “Yes, it’s true that Cisco isn’t exactly compatible to Darwin, but it will be an easier migration. Nortel will have to go back and implement a lot more things, and I don’t see it being easy.”

Now that a preliminary draft has been accepted, editors will work on drafting a formal document. The edited draft will then be ratified at the next meeting in March and voted on again in July. A final version of the standard won't be ratified until early 2003, says Hawkins.

— Marguerite Reardon, Senior Editor, Light Reading
http://www.lightreading.com
<<   <   Page 2 / 3   >   >>
FiberFan 12/4/2012 | 11:01:22 PM
re: RPR Moves Forward hebbelyv,

It looks like RPT (Luminous' flavour of RPR) WILL be able to support CES class services and the like. I was not able to attend the latest 802.17 meetings but many of my colleauges have come back back with favorable reports on multiple classes of service being supported by this draft.
It surprises me that Gandalf had only two classes of service, Hi and Low. (My god, my ceiling fan has three classes!) I believe multiple classes of service will help carriers support their SLAs and enable more types of services.

Youe comments?

FiberFan
FiberFan 12/4/2012 | 11:01:22 PM
re: RPR Moves Forward hebbelyv,
You asked-
"What does the future RPR standard means for the survival of DPT?"

DPT died when Cisco wrote Gandalf. Cisco admitted that Gandalf would NOT be backwards compatible with DPT. They'll also have to re-spin ASICs (per Cisco) so it looks like Cisco's "15,000 ports of DPT dployed" customers are screwed. Very unfortunate for them.

Your comments?
FiberFan
prefer_to_lurk 12/4/2012 | 11:01:21 PM
re: RPR Moves Forward fundamental_guy wrote:

"Cisco retains leadership"
"Nortel's OPE/IPT is dead"

You forgot to mention that Cisco's SRP/DPT is dead too.

An earlier post indicated that Darwin draws just as heavily -- if not more so -- on Alladin than Gandalf.

Yet you claim that Cisco retained leadership ??? I must be missing something here, can you elaborate ?

ptl
michael007007 12/4/2012 | 11:01:19 PM
re: RPR Moves Forward O.k. it seems like everyone lost and the ASIC should be redrawn.
How long will it take to develop a new ASIC?
When will the first products be available?
etherguy 12/4/2012 | 11:01:16 PM
re: RPR Moves Forward hard to say. generally an asic re-spin is a year-plus but recently i've seen 6 month turnarounds. don't know how yet. asic companies including the fabs like tsmc have been working on shortening development cycles for custom asics to combat the benefits of increasingly complex and functional fpgas with much shorter cycles and more flexibility (by definition, programmable). one interesting development is where asic companies are embedding fpgas into the core. that could be a factor.

this is a setback for everyone but in some ways it could be a blessing in disguise because who wants to have to try and bring something to market, in this market? better to hammer out a bullet proof product designed to the new standard than to try and force anything with a half-ass product. if you can buy the time, so to speak. imho. luminous looks like the winner and of course cisco will find a way to win here so i don't see "eveyone losing."
fthepot 12/4/2012 | 11:01:10 PM
re: RPR Moves Forward Things are not black or white:

I don't like the losers/winners approach. It is clear that standard process is complex and painfull but competitors are always here more motivated to make a successfull standard for all the industry and not a standard for them !
The RPR group announced one year ago that a draft will be ready by the beginning of 2002 and the job has been done ... we don't care how.
For me it is a success for the industry and I thanks all the participants including Cisco, Nortel, and others for the intelligence and efforts they have devoted.
One again some vendors will have more difficulties to implement the standard in their existing platform but they will work hard now !
FT.
fundamental_guy 12/4/2012 | 11:00:47 PM
re: RPR Moves Forward FT,

We all like shades of gray rather black or white
because it permits us to spin it one way or
the other.

Truly, think of what happened here. Lantern
developed an ASIC for RPR that uses CID to track
and adjust BW, etc. for each users. In a way, this
is an incredible accomplishment because the folks
at Lantern made their dream, at their previous
employer, come true at Lantern - by implementing
Explicit Rate Controlled ABR scheme in ASIC.
But this macho thing screwed them up. CID
and their individual rate policed scheme get
thrown out like a dead rat. Clearly, they will
have a difficult time convincing the customers
they can continue now - anyway Global Xing just
filled for chapter 11 so it may be moot anyway !!

fundoo guy
fundamental_guy 12/4/2012 | 11:00:46 PM
re: RPR Moves Forward This is a response to "prefer_to_lurk" on
why I think Cisco is still the leader.

Except frame format of SRP, Cisco's SRP is
compatible to Darwin. Transit path does not
have to change for Cisco to be compliant.
Protection does not have to change for Cisco
to be compliant - that takes care of the digestive
and nervous system of the ASIC. Now frame format
is big a hoppla that everyone things is a breaker
but relatively easy to modify in silicon. In
fact all the SRP farme fields are still present.
The new ones can be taken care easily.

Cisco, made concessions that never hurt them.
Nortel changed religion.
Lantern lost their clothes.
fundamental_guy 12/4/2012 | 11:00:46 PM
re: RPR Moves Forward Cisco claim of Darwin not being compatible to
SRP is like the when the opposition claims
colateral damage after bombing to invoke sympathy.
Let us not be so gulible.
x_luminous_guy 12/4/2012 | 11:00:27 PM
re: RPR Moves Forward Let's clarify things here fundamental_guy (Jay Shuler - VP Marketing for Luminous)

As an ex-luminous employee and someone who is very familiar with the product (RPT), we both know what your implemention is -- and it ain't RPR.

Since RPR defines a MAC and RPT has no MAC implementation, Luminous' claims of being RPR is marketing hype for starters. Your continual rantings sounds more like fear of competition than evangelizing a technology.

<<   <   Page 2 / 3   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE