& cplSiteName &

Resilient Packet Ring Technology

Light Reading
8/15/2002
50%
50%

Packet rings have generated plenty of arcane controversy concerning the best ways to handle Ethernet and other packet protocols over the ubiquitous metro fiber-ring topology. But with the new IEEE 802.17 technical standard firmly on the horizon, it’s time for vendors to prove they can make packet rings appeal to the Sonet- and TDM-dominated world of the big incumbents. In short, packet rings are about to grow up.

Resilient Packet Ring (RPR) has been a metro buzzword for a two or three years now, but the noise got pretty deafening towards the end of last year as the Institute of Electrical and Electronics Engineers Inc. (IEEE)’s RPR standardization effort finally hammered competing approaches into a single base for a standard (see Cisco Rounds Up More RPR Support, RPR Divided, RPR: RIP?, RPR: Deadlock Ahead?, and RPR Moves Forward).

The frantic fuss is because RPR promises to be a very smart metro technology, geared to bringing legacy TDM (time-division multiplexing) and newer packet-data services together at high efficiencies onto the metro fiber ring. But there is no chance of the dominant incumbents taking to it in a big way without an agreed-upon standard – and other technologies like next-generation Sonet and switched metro Ethernet are already up and running (see Next-Gen Sonet and Metro Ethernet).

Actually, that technology comparison is a little unfair, as RPR is just a tiny slice of a Layer 2 data-link protocol to provide media access control (MAC) for packets being transported over a ring topology. As developed by the IEEE’s 802.17 RPR Working Group (WG), RPR will run happily over any Layer 1 transport, whether using Sonet/SDH framing or native Ethernet on the transmission links – and with any Layer 3 protocol, for that matter. But RPR still has to attract the attention of vendors and carriers as a potentially key part of a metro solution.

The figure below illustrates the point that RPR will be part of a complete solution and that it can be used with various higher- and lower-level protocols:

(a) Shows RPR running over an existing Sonet/SDH network, which provides the Layer 1 capability (e.g., as an OC12 RPR ring within an OC48 ring). In this example, the carrier uses RPR for its efficiency in supporting Ethernet (and other packet protocols), while continuing to run TDM Sonet/SDH-style services over the remaining Sonet/SDH capacity as normal. This approach might be deployed as a simple RPR blade in the existing Sonet equipment.

(b) Shows RPR running over just the Sonet/SDH PHY (or its 10-Gigabit Ethernet equivalent), which provides the Layer 1 capability. However, RPR now supports both Ethernet and TDM Sonet/SDH-style services. This approach gives RPR a more fundamental role than does (a) and is really a new network architecture.

In the form of earlier proprietary or prestandard versions, RPR has been gaining some ground. “We’ve seen very, very positive traction,” says Jeff Baher, senior marketing manager of the router technology group at Cisco Systems Inc. (Nasdaq: CSCO), referring to that company’s RPR-like Spatial Reuse Protocol (SRP), now an Internet Engineering Task Force (IETF) informational document. “We have just recently introduced OC192 [10 Gbit/s] RPR and are working with a number of customers that are adopting that technology. We also introduced OC48 [2.5 Gbit/s] last year, and we have pretty significant traction now in a number of different types of application – in cable, ISP internetworking, and ILEC and PTT applications.”

Raj Sharma, director of engineering for network architecture at Luminous Networks Inc., another vendor active in RPR, expresses a similar view: “There is a lot of traction in the carriers. We see that Luminous is involved with almost every carrier and cable operator that I can think of in the U.S. and internationally to try out the products, to explain how this technology works, and actually look at the deployment. We have shipped 30,000 ports so far.”

Made for the Metro

The thumbnail justification for this growing interest is that RPR may be a better way of using metro fiber rings in a multiservices environment than either Sonet or Ethernet alone. It promises to combine Sonet’s resilience and availability with the simpler equipment stacks and lower costs of Ethernet to handle multiservice traffic – voice, video, and data – with high efficiency and a range of QOS (quality of service) guarantees. So it would be cheaper on both the capital expenditure (capex) and operating expenditure (opex) sides, and still offer opportunities for enhancing revenues on the service side. Sounds tempting, doesn’t it?

RPR does all this by creating a new packet MAC layer that is optimized for carrier metro ring topologies and conditions. Although RPR is not Ethernet (despite the IEEE’s involvement), everyone is working very hard to ensure that RPR will work efficiently and seamlessly with the existing Ethernet 802 series. So RPR can also appear in enterprise campus networks and in data centers as well as carrier Gigabit and 10-Gigabit Ethernet implementations. Overall, RPR beefs up Ethernet’s rather limited MAC capabilities and allows them to support ring topologies, something Ethernet was not designed to handle.

A basic idea of RPR is to start with a Layer 2 packet technology that supports ring topologies and integrates a packet-switching capability, and to add the necessary QOS definitions within the protocol to bound jitter and delay for time-sensitive traffic like TDM or MPEG streams. The QOS also allows oversubscription of the network for end data services. Thus a base is established from which to start migrating new data services while continuing to offer bread-and-butter legacy TDM and voice services.

Fabulous Features

By cleverly controlling the way that packets access and traverse a metro ring, RPR can offer some very desirable features:

  • Bandwidth multiplication by reusing ring bandwidth for different traffic streams on separate parts of the ring (spatial reuse)

  • Statistical multiplexing of traffic within a single large optical ring channel to increase bandwidth-utilization efficiency even further – there is no fixed bandwidth partitioning between services, and traffic aggregation at the ring level gives higher multiplexing gains than at the node level

  • A range of QOS guarantees

  • Fair sharing of bandwidth among QOS traffic categories

  • Sonet-style sub-50ms protection switching for resiliency to ring or node failures

  • Simple LAN-like service provisioning

One RPR feature that’s exciting the industry is its ability to maximize use of a ring’s total bandwidth (summed among all nodes) through both spatial reuse and statistical multiplexing. Gains from spatial reuse (including that of protection capacity) depend greatly on traffic patterns but could be as much as eight times that of a simple Sonet ring for randomly distributed traffic. All in all, it is perfectly possible to run an RPR-type ring at around 95 percent utilization of all the internodal bandwidth while maintaining all the SLAs (service-level agreements).

“If you have a collector ring, where naturally all the traffic is running to the hub, then spatial reuse is irrelevant,” says Gady Rosenfeld, director of strategic marketing at Corrigent Systems Inc. “But other factors are the ability to use the protection bandwidth that, in Sonet’s case, is just sitting idle, and – more importantly – the ability to do efficient statistical multiplexing over a shared medium. This kind of statistical multiplexing efficiency can be achieved only when you have a large number of input sources. When you have a medium shared by all of the sources – in RPR’s case, all of the nodes on the ring – you can achieve a much more efficient statistical multiplexing.”

RPR’s characteristics thus fit very well with today’s combinations of committed-information-rate (CIR) and best-effort traffic. Carriers can have a committed rate reserved on the ring, and statistically multiplex the excess rates running on the ring very efficiently – working wonders for their ability to oversell capacity.

Add Sonet-style resilience and management tools, and a provisioning system that is largely decentralized and automatic, and it is easy to see why RPR is attracting attention.

 
(30)  | 
Comment  | 
Print  | 
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
Page 1 / 3   >   >>
mohamoud
50%
50%
mohamoud,
User Rank: Light Beer
4/21/2013 | 8:34:21 AM
re: Resilient Packet Ring Technology
I guess standardization is nowadays hindering efficient development and premises, somehow, I once thought proprietary was much of "too many for the same" but it is rather offering alternatives which is always welcomed by the many not so powerful but yet productive of good ideas
data_guy
50%
50%
data_guy,
User Rank: Light Beer
12/4/2012 | 9:56:20 PM
re: Resilient Packet Ring Technology

Cisco has caused extreme harm to the usefulness of this standard, and has subverted the IEEE standardization process.
One of the requirements of 802.17 is that it provide for IEEE 802.1D bridging, that is, it needs to be able to act as a switch. The draft standard is at this time flawed because bridging is accomplished by having the frames travel all the way around the ring- no spatial re-use when used as a bridge! Since Spatial Reuse is part of the basic premise behind the standard, I would contend that bridging has not been met. I can't say so, though, since Takefman (Cisco), the chair of the group, has restricted access to the email reflector where all discussions take place.
The Cisco/ Nortel/ Luminous camp is only concerened with routing, not switching, so they have pushed for layer-3 capabilities only from the very beginning. So, congratulations, on designing a brand new, big, fat, slow router!

How can all this happen in the IEEE? Well, I guess they lost in trying to fight big corporate influences. All future standards from that group will only benefit the few and the powerful from now on, I guess.
fundamental_guy
50%
50%
fundamental_guy,
User Rank: Light Beer
12/4/2012 | 9:56:08 PM
re: Resilient Packet Ring Technology
Although, 802 is generally known as the
LAN/MAN/WAN standards it has an over zealous toll
booth attendant, supported by a local mafia of
Ethernet switch vendors, known as 802.1. It is
ridiculous to force all future 802 standard
to conform to spanning tree based bridging
rules. WAN and MANs are not dimunitive networks
like LANs to consider bridging (a.k.a layer
2 routing with a flat address space)as a viable
solution.

IEEE 802 needs a wake up call. Perhaps, the 802.17
working group has done it a favor by spending
less efforts on a dying protocol like spanning
tree algorithm based layer 2 routing - also
sold as 802.1D bridging. If the 802.17 ends up
spending time on this it would have further
exposed how broken and sad this protocol is and
how IEEE is very disallusioned IEEE in mandating
all furture networks to conform to this. For IEEE
the main focus should be to gain a
beach head in carrier networks. Since, most
carriers consider ITU to be the defacto standard
body. IEEE will win the local mafia war and
loose the over fight to perpetuate itself
as a standards body.

I think your note might confuse readers on
what the 802.17 decided to keep and what it
decided not to undertake to speed up the
availability of the standard. As a working
group member, I think it is my duty to clarify.


The working group is always reminded and
understands well that conformance (paying dues
to the local 802 union) to 802.1 is required.
There is a general distaste of bridging to many
RPR vendors who have leveraged MPLS and a IP
control plane to accomplish this.
Never the less, the 802.17 working group bit the
bullet and decided to show how the protocol they
are designing supports all the flooding rules
and learning rules required by 802.1 bridging.
However, a few over-zealous and lost-at-sea
vendors wanted to further optimize 802.17 to
ensure 802.17 would be very optimal for
bridged networks.
So, a poll was taken of the 5 major system vendors
whether this complication in the standard was
worth it. Cisco, Nortel, Luminous and Corrigent
declared that they never plan to shackle their
customers by bridging between RPR rings or
between RPR and Ethernet. Lantern was the only
one who wanted despite having no such product
plans. The reality was that Lantern having been
trounced soundly in the RPR standards was
attempting to use this as a Trojan horse to
get back their ATMish "flowid" field in the
header - which was one of the outcome if
802.17 workking group were to optimize RPR for
802.1 bridging. So, with 4 out 5 seeking not
to pursue this and having reviewed our orginal
project proposal the group deemed that such
optimization was a wate of the 802.17 working
group's time and they gave full permission for
such bridging zealots to go persue such
elaborate optimization with the 802.1 bridging
working group. After al, it is wiser to keep
the monkeys busy at something :)

I think this was fair and keeps
with current tide in the industry. Your
implication of unfairness sounds like sour
grapes to me !

Just so that the readers get a full story...
Now, there were others like Cypress and C-Cor
who have no skin in this game and who have
individuals at these meetings who are mainly
there to agrandize themselves. These inidviduals
made pursuit of optimizing 802.17 for 802.1
a very challenging research and also fell a prey
to ever needy Lantern guys on the sidelines.

Sorry chaps. Bridging had its days. Now, its
existence has become a pain in the neck.
In fact, to resolve some of the obscene
inadequacies of 802.1 bridging VLAN was invented.
Now, that has become inadequate and stacked-VLANs
are being proposed. And there is more...

IMHO, optimizing for bridging will create more problems.


lightgo
50%
50%
lightgo,
User Rank: Light Beer
12/4/2012 | 9:56:03 PM
re: Resilient Packet Ring Technology
Hi Lantern competitor (it's obvious who wrote it, even the person's name is easy to guess):

You should focus your time/energy on business rather than go after your competition this way.

It should not be forgotten that you didn't like anything about Cisco proposal for just about anything until just a few months ago. So what changed? Desperation, maybe? Or is it that suddenly your bridging concepts became ultra-clear when the business became tough? Pretty funny.

It's true IEEE spanning tree is old and hardly worth the compatibility pursuit. But 802.17 isn't doing IEEE any favor either. It's bringing an ancient and old proprietary protocol of one particular company to IEEE for stamping of approval and now the 802.17 folks wonder why not all members just sign on the dotted line. For a lot of people in 802.17, winning people by politics is same as improving the protocol. It's high time the blind followers try to fix stuff rather than rush it to make it a standard.
FiberFan
50%
50%
FiberFan,
User Rank: Light Beer
12/4/2012 | 9:56:03 PM
re: Resilient Packet Ring Technology
data_guy:
With all due respect, are you attending these meeting and discussions? I think you are WAY off base.
RPR is nearing finality and is rolling along quite well. I've even heard thru some carriers that many of the "Next Gen" SONET guys are looking at implementing RPR as a data plane.

If you want 802.1D bridging, buy an ethernet switch. If you want packet transport, use RPR.

Your thoughts?
FiberFan
lightgo
50%
50%
lightgo,
User Rank: Light Beer
12/4/2012 | 9:56:02 PM
re: Resilient Packet Ring Technology
Apologize for any confusions - my previous message was for fundamental_guy for the message where he criticized Lantern and others about their opinions.
optical_ring
50%
50%
optical_ring,
User Rank: Light Beer
12/4/2012 | 9:56:01 PM
re: Resilient Packet Ring Technology
RPR Semiconductor Inc, (www.rprsemi.com) is another RPR silicon vendor which is not to be ignored, having a range of silicon solutions for the emerging RPR Technology.
Peter Heywood
50%
50%
Peter Heywood,
User Rank: Light Beer
12/4/2012 | 9:55:59 PM
re: Resilient Packet Ring Technology
Who else makes RPR silicon? Can someone give me a list? I'm trying to see whether there are enough players to make it worthwhile doing a survey.

heywood@lightreading.com
Peter Heywood
50%
50%
Peter Heywood,
User Rank: Light Beer
12/4/2012 | 9:55:59 PM
re: Resilient Packet Ring Technology
Some questions:

1. How big a difference is there between Cisco's proprietary SRP and the upcoming RPR standard?

2. Isn't there a real likelihood that Cisco will continue selling SRP in the same way that it continued selling its proprietary routing protocols - ie "Here you go, Mr. Customer, this box supports SRP and RPR so you can make your own mind up which you want to use. You might like to know, however, that SRP is widely deployed so it's proven technology. We're still ironing some kinks out of our RPR implementation."
standardsarefun
50%
50%
standardsarefun,
User Rank: Light Beer
12/4/2012 | 9:55:56 PM
re: Resilient Packet Ring Technology
Statements like: "ItGΗΦs not easy to summarize 802.17 concisely, because in some respects it is like a framework on which vendors will add a wide variety of bits to build more complete metro systems" strike a good deal of fear in me.

Does anyone know to what degree 802.17 compliance will be tested so that we can imagine deploying multi-vendor rings (with full layer 1, 2 and 3 interop) or this is really only a "framework standard" that like vendors sell box and leave the problems to the operators?

Please no PR type answers - I am looking for interop specs and event dates.
Page 1 / 3   >   >>
Featured Video
From The Founder
Light Reading is spending much of this year digging into the details of how automation technology will impact the comms market, but let's take a moment to also look at how automation is set to overturn the current world order by the middle of the century.
Flash Poll
Upcoming Live Events
October 18, 2017, Colorado Convention Center - Denver, CO
November 1, 2017, The Royal Garden Hotel
November 1, 2017, The Montcalm Marble Arch
November 2, 2017, 8 Northumberland Avenue, London, UK
November 2, 2017, 8 Northumberland Avenue – London
November 10, 2017, The Westin Times Square, New York, NY
November 16, 2017, ExCel Centre, London
November 30, 2017, The Westin Times Square
May 14-17, 2018, Austin Convention Center
All Upcoming Live Events
Infographics
With the mobile ecosystem becoming increasingly vulnerable to security threats, AdaptiveMobile has laid out some of the key considerations for the wireless community.
Hot Topics
The Revolution Will Be Automated
Steve Saunders, CEO and founder, Light Reading, 10/10/2017
The Big Cable DAA Update
Mari Silbey, Senior Editor, Cable/Video, 10/11/2017
Is US Lurching Back to Monopoly Status?
Carol Wilson, Editor-at-large, 10/16/2017
Telecom Italia Covers 73% of Italy With NB-IoT
Iain Morris, News Editor, 10/13/2017
DT: Brutal Automation Is Only Way to Succeed
Iain Morris, News Editor, 10/10/2017
Animals with Phones
Hunt & Peck Click Here
Giving new meaning to hunt-and-peck typing!
Latest Comment
Live Digital Audio

Understanding the full experience of women in technology requires starting at the collegiate level (or sooner) and studying the technologies women are involved with, company cultures they're part of and personal experiences of individuals.

During this WiC radio show, we will talk with Nicole Engelbert, the director of Research & Analysis for Ovum Technology and a 23-year telecom industry veteran, about her experiences and perspectives on women in tech. Engelbert covers infrastructure, applications and industries for Ovum, but she is also involved in the research firm's higher education team and has helped colleges and universities globally leverage technology as a strategy for improving recruitment, retention and graduation performance.

She will share her unique insight into the collegiate level, where women pursuing engineering and STEM-related degrees is dwindling. Engelbert will also reveal new, original Ovum research on the topics of artificial intelligence, the Internet of Things, security and augmented reality, as well as discuss what each of those technologies might mean for women in our field. As always, we'll also leave plenty of time to answer all your questions live on the air and chat board.

Like Us on Facebook
Twitter Feed