A primer on the technology that could prove key to metro networks * What it is * How it works * Why it’s important

August 15, 2002

50 Min Read
Resilient Packet Ring Technology

Could Resilient Packet Ring be the Jesse Ventura of emerging metro technologies?

It's a disturbing thought, we admit. But the RPR technology can be likened to a novice, independent politician running in a two-party world. The straight-shooting candidate brings a sense of optimism to the packet rings dominating the metro networks, along with a whole new bag of promises that are causing traditional party-line carriers to turn and take notice.

Many on the campaign trail like the way RPR approaches the problem of delivering voice and data traffic over metro rings with a clean slate. It doesn't come across as adversarial to either Sonet or Ethernet, and it promises bandwidth utilization and efficiencies never before accomplished.

RPR also has a dedicated and growing following made of two groups that, once upon a time, fought each other fiercely before compromising and moving on. But RPR believers are about to go through their biggest test yet.

Charming as RPR's feather boa and fishnet stockings are, some think the whole thing is just flash and trash. Incumbent carriers will never buy into something so… so new. Or so they say. The thing is, carriers might be ambivalent enough about RPR to provide an opening to equipment vendors that can put just the right spin on their product pitches. (Just ask the chilblained citizens of Minnesota.)

RPR has come a long way, but it still has some tough road ahead. And if and when it gets all the way into the office, its job will be just beginning.

It's been a while since a technology so small has caused a ruckus so big. To that end, Light Reading is proud to present a pre-election special, if you will. The following report will examine Resilient Packet Ring: how it works, what it's really all about, who's supporting it, where it's going… and how it will ultimately affect vendors and carriers.

Here’s a hyperlinked summary:

  • Why Rings?

  • How It Began

  • RPR Details

  • From Standards to Products

  • Using RPR

  • What's Next?

  • System Vendors and Products



This report is part of a series of articles on metro technologies written by Tim Hills, an independent analyst. The series started with an overview (see Metro Multiservices Evolution) and then went on to survey developments in next-generation Sonet/SDH (see Next-Gen Sonet ) and Ethernet (see Metro Ethernet). A further article on metro DWDM developments is planned.

Some of this report digs quite deeply into technological issues. To get the most out of it, why not start by listening to our archived Web-enabled preview? Just click here.

Here's some background reading that might also help:

  • Beginner's Guide: Protocol Basics

  • Beginner's Guide: Sonet (Synchronous Optical NETwork) and SDH (Synchronous Digital Hierarchy)

  • Beginner's Guide: Ethernet

  • Report: Metro Multiservices Evolution

  • Report: Next-Gen Sonet

  • Report: Next-Gen Sonet Silicon

  • Report: Metro Ethernet

Introduction by Phil Harvey, Senior Editor, Light Reading
http://www.lightreading.com

About the author: Tim Hills is a freelance technical writer. He may be reached at: [email protected].

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:

19743_1.gif(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.

RPR is not completely new, and proprietary packet-ring technologies have been around for a few years. One of the earliest was Cisco’s SRP, which has been used in its Dynamic Packet Transport (DPT) products since 1999. The IETF subsequently documented SRP as RFC2892 – the Cisco SRP MAC Layer Protocol; and other vendors have used SRP in their own versions of packet rings. Cisco’s motive in developing DPT was essentially to transfer to metro rings the efficiencies of using POS (packet over Sonet) to connect high-end routers direct to long-haul networks by bypassing intermediate Sonet and ATM layers.

“In many regards we look at DPT as simply packet-over-Sonet for rings,” says Cisco’s Baher (see Cisco's Second String). “Customers said, ‘I need to do what you basically gave me in the long haul, but for my regional networks and my metro access network.’ We have added a couple of other functions within that to carry high-priority traffic – voice over IP, TDM over IP traffic types – in addition to general data traffic types.”

Other vendors’ packet-ring technologies include Appian Communications Inc.’s DSQ/ODP (Optical Data Protection), Lantern Communications Inc.’s Resilient Optical Packet Ring (ROPR), Luminous Networks’ Resilient Packet Transport (RPT), Nortel Networks Corp.’s (NYSE/Toronto: NT) OPTera Packet Edge System, and Riverstone Networks Inc.’s (Nasdaq: RSTN) RPR/SRP.

But the big focus now is the effort by the IEEE 802.17 Working Group, since 2000, to develop a standard version of packet ring – Resilient Packet Ring. 802.17 RPR gives carriers a lot more options for fine tuning their networks than do earlier technologies such as SRP, and its development has unsurprisingly generated a vast amount of discussion on such topics as packet access and transit buffering, QOS, packet loss, protection mechanisms, transparent bridging, and packet flooding.

After considering a series of proposals and counterproposals, the WG agreed on a basic draft standard (known as the .02 Draft) in January 2002, taking RPR significantly closer to finalization and conformant products (see RPR Moves Forward). The .02 Draft settles all the major technical issues surrounding RPR, and includes:

  • The MAC reference model

  • Description of the MAC – including access control protocol, data path, and frame formats for data and control frames

  • A protection-switching protocol for ring fault detection and service restoration within 50ms

  • A topology-discovery protocol

  • Network-management primitives for the RPR MAC



“All the vendors that have prestandard RPR implementations are basically committed to coming out with standards for conformance RPR when that standard is available,” says Bob Love, president of the Resilient Packet Ring Alliance (RPRA) and vice-chair of the IEEE 802.17 WG. “So everyone is behind the standardization effort. Everyone understands that one of the carrier requirements is that we have a standardized technology.”

Since January, the WG has been progressively refining the draft and filling in the details. Says Love: “We are at a stage where there are lots and lots of comments on it. There’s lots of discussion, lots of technical aspects that are still subject to some change – which is exactly what we would expect in this part of a standards process.”

He now expects some small slippage in the original timetable, which had called for a first ballot in July 2002 and a published standard in March 2003: “One of the things that we had not expected is the incredible interest in Resilient Packet Ring. We’ve had over 400 people from 100 different companies all contributing their ideas. You’ve got to look at each of these and see what are the implications. So there was a lot more input than we were expecting – which ultimately will lead to a better standard.”

The RPRA itself is planning to start running interoperability conformance tests on vendor products between late 2002 and mid-2003 (see RPR Gurus Set Fall Deadline). There are a lot of chip vendors involved in the WG work, and it is expected that there will be a range of off-the-shelf RPR MAC chips and support chips available by the end of 2002.

Chip vendors such as Applied Micro Circuits Corp. (AMCC) (Nasdaq: AMCC), Infineon Technologies AG (NYSE/Frankfurt: IFX), Mindspeed Technologies, and Vitesse Semiconductor Corp. (Nasdaq: VTSS) have all recently announced their support for some of the proprietary technologies, such as Cisco’s DPT and Nortel’s OPTera Packet Edge, as means of entry into the existing packet-ring market (see AMCC Unleashes Tiber, Infineon Intros RPR Chip, Nortel, Vitesse Join on Packet Ring, and Cisco's Resilient Ring Gets a Boost).

The basic form of RPR has been settled, contained in both the IEEE 802.17 Draft Standard Version 0.2, agreed to in January 2002, and in the subsequently somewhat expanded Version 1.0, produced in July 2002. The intention of the 802.17 WG is to make the September 2002 meeting the cutoff point for technical improvements to the standard; after that date the only technical changes accepted will be those to fix problems with the standard.

Like most of the 802-series of standards, 802.17 has a shared medium that serves all attached nodes. All networks based on a shared medium need a MAC to control access to the medium equitably and to prevent interference between users. MACs occupy the lower part of the OSI Data Link Layer (see Protocol Basics for more on the OSI model). 802.17 does not specify a physical layer but uses existing standardized physical layers. It is intended to work with other standards of the 802-series, including 802.1 Bridging and 802.2 Logical Link Control that lie in the upper part of the Data Link Layer above the MAC; but other upper layers can be used as well.

It’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. This is inevitable, given that the standard specifies only a very narrow protocol sublayer that has to support a range of different requirements and approaches. 802.17 generated a huge amount of discussion last year on the best way to build packet rings, and the current Draft Standard effectively brings several different ideas together. Flexibility is very much the order of the day with RPR.

So 802.17 recognizes a fair number of options, but it does so in such a way as to ensure interoperability at the basic level. It does mean, however, that once you start delving into the mechanics of RPR’s operation, you have to make a lot of distinctions to make sense of the options. Pedantic though this may seem, it’s essential to distinguishing between what RPR can support in principle and what it may do in any particular implementation. The two are not the same.

RPR is essentially neutral with respect to its payload, just adding a small 18-byte header to the traffic’s native payload data unit (PDU). The header includes a 2-byte field for RPR functions (such as time to live, ringlet identification, message type, and priority), the destination and source MAC addresses, a protocol-type field, and a header error-checking (HEC) field. (Check out this paper from the RPR Alliance for more details.)

Physical layer: Although it is not concerned with the physical layer itself, 802.17 does define how RPR is to be mapped (through so-called reconciliation sublayers) to two existing physical layers of high interest – Ethernet and Sonet/SDH. There are two varieties of each:

  • Gigabit Ethernet reconciliation sublayer (GERS) for the Gigabit Ethernet PHYs 1000Base-SX and 1000Base-LX

  • 10-Gigabit Ethernet reconciliation sublayer (XGERS) for the 10-Gigabit Ethernet PHYs 10GBase-SR, 10GBase-LR, 10GBase-ER, and 10GBase-LX4 (all LAN PHYs); and 10GBase-SW, 10GBase-LW, and 10GBase-EW (all WAN PHYs)

  • Sonet/SDH reconciliation sublayer (SRS) for Generic Framing Procedure (GFP) or HDLC-like framing adaptation sublayers (for more on GFP, see Next-Gen Sonet page 3)

  • GFP reconciliation sublayer (GRS) for GFP adaptation sublayer only



Topology and basic mechanism: The basic 802.17 physical topology is of two counter-rotating rings (each termed a ringlet, one inner, one outer). So packet traffic travels in a clockwise direction on one ringlet and in a counterclockwise direction on the other. Normally the rings use fiber, but other physical media are possible. Nodes effectively act as dual add/drop multiplexers (ADMs) – they can transmit on either ringlet and receive from each. Because a node can transmit to another node by using either ringlet, it has to make a choice between the two paths, and this is governed by an algorithm. Normally, the shorter path would be used, but congestion or fault conditions can cause the alternative path to be selected.

For each ringlet, as an ADM switch, a node has two inputs and two outputs:

  • Inputs – (a) from the ringlet’s upstream nodes and (b) from a local transmit queue

  • Outputs – (a) to the ringlet’s downstream nodes and (b) to a local receiver



Traffic reaching its destination node is sent to the local receiver and stripped from the ringlet; otherwise, traffic transits the node and continues on the downstream ringlet. Multicast and broadcast traffic are both copied to the local receiver and transmitted to the downstream nodes.

The stripping of traffic packets from the ring by the destination node is one of the crucial features of 802.17, distinguishing it from 802.5 Token Ring and FDDI, where packets continue round the ring and are removed by the source node. Should the destination node fail, 802.17 has a hop-count mechanism (called Time to Live or TTL) to prevent endlessly circulating packets.

Multicast and broadcast traffic packets, however, have to be treated differently and are removed by the source node.

It’s not hard to see that these arrangements can lead to fairly efficient use of the ring’s capacity through the potential for spatial reuse of bandwidth on different parts of the ring by different traffic flows. Stripping packets from the ring when they reach their destination means that a traffic flow occupies only part of the total length of fiber. Because two directions of transmission are available, no two nodes are separated by more that half the ring’s circumference. Further, if source and destination nodes are distributed at random (a big if, and not true for certain common traffic patterns, such as those to a POP on an access ring) the average traffic path length is one quarter of the ring’s circumference. So the dual ring should, on average, be able to support eight (2x4) times the traffic flow of a single fiber without spatial reuse.

In principle, 802.17 can be used with 2N fiber rings (and/or DWDM virtual rings to achieve the same effect of fiber multiplication), although the standard does not specify the selection algorithm in this case. However, nothing precludes the system level from aggregating multiple fiber rings, and this capability could well become part of the RPR standard in future iterations.

Statistical multiplexing and traffic types: After spatial reuse, the second key to RPR’s high bandwidth-utilization efficiency is its statistical multiplexing of traffic flows to take advantage of unused or temporarily idle ring bandwidth. The 802.17 MAC controls traffic access to four different logical services on the ring, three of which provide different QOS capabilities:

  • High priority – Provides indefeasible reserved bandwidth that cannot be reclaimed by active lower-priority traffic, even if there is idle bandwidth available on the channel. This channel is for traffic requiring fixed bandwidth guarantees and low delay and jitter, such as voice, video, and circuit-emulation services.

  • Medium priority – Provides reserved bandwidth that may be reclaimed by active equal- or lower-priority traffic if there is idle bandwidth available on the channel. This channel is for traffic that needs definite bandwidth commitment, but which is not highly sensitive to delay, such as CIR data services.

  • Low priority – Provides a share of any unused ring bandwidth. This channel is for best-effort services only.

  • Control – Provides a guaranteed internode communications channel to support the operation of the ring’s distributed control mechanisms and the carrier’s OA&M (operations, administration, and maintenance) system.



The big point of all this is to create a system that can handle both legacy TDM and data traffic well and efficiently. This is essential if RPR is to make headway in the legacy-dominated world of the big incumbents. To strengthen RPR’s appeal further, 802.17 supports implementation options for prioritizing the ingress and circulation of packets as they traverse the ring, as this gives flexibility in the allocation of ring resources to suit specific circumstances and vendor approaches.

Resource allocation and control: There is no master node on the ring; bandwidth management and congestion control are fully distributed over all nodes, which implement control algorithms collectively. This is potentially a nice feature, as it combines with the nodes’ abilities for topology discovery to aid the ‘plug-and-play’ nature of adding or removing nodes from the ring.

Each node processes three traffic streams: exit traffic destined for the node; ingress traffic entering the node locally and to be placed on the ring; and transit traffic destined for nodes further downstream. The basic issues are to ensure that ingress and transit traffic don’t interfere with each other’s QOS and to share the ring resources fairly and avoid congestion.

Both ingress and transit traffic are buffered, because the medium is shared and packet flows are stochastic (in other words, it’s possible that multiple bursts of data could coincide). 802.17’s treatment of buffering is fairly complicated. Being just a basic MAC, 802.17 leaves some aspects of buffering to higher protocols, while offering options on other aspects.

There is only a small ingress buffer per class of traffic. However, the MAC does provide information and functions that will allow vendors to implement various enhancements and options for ingress buffering into their MAC clients. One enhancement of great interest is Virtual Destination Queuing (VDQ). The idea is to form a separate packet queue for each destination node on the ring, so that packets are handled according to the path they take on the ring. This prevents packets that are delayed by a congested link on the ring from blocking packets that do not have to traverse that link to reach their destination. To support VDQ, the MAC has schedulers to limit the amount of traffic transmitted beyond a single congestion point. The VDQ buffering itself is left entirely to the client.

There are two options for the transit buffer, and these affect the handling of traffic priorities:

  • Single transit buffer – Transit traffic always has priority over ingress traffic.

  • Dual transit buffer – Transit traffic is separated according to type into two different buffers. Low- and medium-priority transit traffic go into one buffer (the low-priority buffer), while high-priority transit traffic goes into the second, thus forming two queues that are handled differently.

There has to be a least one transit buffer, because the node may have already started adding a packet to the ring from the ingress buffer when a ring packet arrives to transit the node. The ring packet then has to be delayed, otherwise both packets would interfere and be corrupted. A single buffer minimizes this transit delay for all packets already on the ring and can be small as it needs to be to hold a packet only until the transmission of the ingress packet is complete. The average delay is therefore half the transmission time of an average packet – say, less than 1µs for 1000-byte packet at a 10-Gbit/s ring rate. A single buffer is a simple solution that does not require any special processing.

Using dual buffers is more complicated but leads to greater refinement in priority handling and more flexibility in tailoring the total delay experienced by packets in accessing and transiting the ring. The potential weakness of the single buffer is that high-priority traffic trying to access the ring will be delayed by any medium- or low-priority traffic already transiting the node, which may not suit the carrier’s requirements for SLAs. Dual buffers allow high-priority ingress traffic to temporarily hold up traffic in the low-priority transit buffer and thus speed up access to the ring. Of course, high-priority transit traffic retains priority over both traffic in the low-priority buffer and all ingress traffic (like the single buffer); and traffic in the low-priority buffer has priority over low- and medium-priority ingress traffic.

By recognizing both approaches, and ensuring that they will interoperate, 802.17 leaves it to vendors to decide how to play the inevitable tradeoffs between complexity and performance - these decisions will inevitably be influenced by the requirements of each implementation. So in some situations it may be acceptable to run a ring at a slightly lower utilization and use a single buffer; in others, where maximum utilization is essential, it may be better to use dual buffers. Essentially, it is a matter of fine tuning, as both single- and dual-transit buffers work with another key RPR capability – the fairness algorithm – to ensure SLAs, and each can be tuned differently by tweaking the implementation of the fairness algorithm.

Fairness: The fairness mechanisms are a vital part of resource allocation and of making RPR work. They ensure that the different ingress traffic streams have fair access to the available ring resources as those change dynamically in response to continual changes to the ingress traffic streams themselves. In this context available refers to bandwidth not pre-allocated to high-priority traffic and not currently being used by medium- or low-priority traffic. So fairness controls the amount of medium- and low-priority traffic (termed fairness eligible) that each node can put on the ringlets. The goal, of course, is to cram as much traffic of this type onto the ring as possible without compromising QOS or congesting the ring.

This is done by each node implementing the RPR Fairness Algorithm. This is elaborate and allows nodes to be weighted, so that highly weighted nodes are allocated proportionately more of the available bandwidth than nodes with a low weighting. Carriers can use this feature to ensure that nodes that are large sources of traffic get more of the available bandwidth than do nodes that are only small sources.

Just to make things even more complicated, not all medium-priority traffic is fairness eligible, as medium-priority traffic is divided into guaranteed and excess traffic (a.k.a. in-profile and out-of-profile traffic). The guaranteed traffic has priority over low-priority traffic for express access to the ring and is not regulated by the Fairness Algorithm. The excess traffic, however, is treated as low-priority traffic, and is subject to the Fairness Algorithm.

The basic idea is that each node periodically monitors the current utilization of its immediate downlinks (one on each ringlet), and informs the neighboring upstream nodes of the available bandwidth – the fair rate. It does this by sending control messages via the opposite ringlet. The upstream neighbors calculate their share of this bandwidth by using their own fairness weighting. If congestion threatens, the fair rate falls, causing upstream nodes to throttle back the loading of their fairness-eligible ingress traffic onto the ringlet. In effect, nodes use the circulating hop-by-hop control messages to identify the current most congested link on each ringlet and set their fairness-eligible ingress traffic rates accordingly.

But there is an elaboration, as a second type of control message allows nodes to be periodically informed of their allocated share of the available bandwidth on every internodal link on the ringlets. This information is not used by the RPR MAC but is passed to the MAC client. It allows the client to avoid the restrictions of the fair rate if it has packets for destination nodes that lie before the most congested link and therefore do not need to traverse it. This relies, however, on the MAC client supporting a VDQ, which is optional as far as 802.17 is concerned.

Protection: A big attraction of RPR’s dual counter-rotating ringlets is that there are always two paths between any two nodes of the ring, one on each of the ringlets. So if a span fails on one ringlet, packets that would normally traverse the span can always be switched automatically onto the other ringlet and take the second path. 802.17 actually specifies two entirely different protection mechanisms to do this: wrapping and steering. Once again, both are entirely distributed, as there is no single node responsible for controlling the automatic protection switching.

Wrapping is really just one of the standard Sonet protection mechanisms (Bidirectional Line-Switched Ring – BLSR) adapted for packet rings. Under wrapping, the nodes at each end of the failed span automatically detect the failure and simply loop back (wrap) on the other ringlet direction all packets heading toward the failed span.

Steering relies instead on all nodes exchanging information on the status of their attached downstream spans. When informed of a span failure, nodes reroute their ingress traffic onto the appropriate ringlet to avoid the failed span. So steering protection requires the active participation of all nodes on the ring, whereas wrapping involves only the two at each end of the failed span.

Implementations can use either mechanism, but steering is mandated as the default mechanism in rings where nodes support both, so as to ensure interoperability. As with other aspects of 802.17, a variety of factors will influence vendors’ and carriers’ choice of mechanism. Both are fast and equal Sonet’s sub-50ms speed, but each have different pros and cons. Wrapping is transparent, simple and familiar, but less bandwidth efficient than steering, as packets tend to stay on the ring longer.

Topology discovery: Keeping everything working in 802.17 is the RPR Topology Discovery Protocol, which keeps nodes aware of the identity of all nodes on the ring and of their physical connectivity relationships. It is run by each node independently at initialization and thence periodically; it underlies key routing, protection, and OA&M capabilities. So new nodes automatically advertise their presence, and each node broadcasts any changes to its local topology and exchanges periodic “hello” messages to its neighbors to monitor its environment.

802.17 also includes various management primitives for RPR, including fault management, configuration management, and performance management, together with various alarm signals and fault-localization tools.

Two things should now be obvious about 802.17 RPR:

  • It is only part of a complete network protocol stack.

  • There are a lot of options within the protocol.



So RPR as a label on a product is not, in itself, very illuminating. Carriers are going to have to dig deeper to see just what each vendor is up to in their products. This, of course, will be strongly influenced by product application and market segment, as well as by the vendor’s historical approach to network architectures.

“The standard just defines the very thin MAC layer, so there is enormous flexibility for vendors to build products with vastly different feature sets based around that standard,” says Nigel Cole, VP for business development at Corrigent Systems.

One very straightforward approach is to add RPR blades to existing products. Sun Microsystems Inc. (Nasdaq: SUNW) is doing this with a recently released PCI network interface adapter card to connect Sun servers directly onto OC48 RPR networks using Cisco’s DPT/SRP. The point here is that RPR lets Sun put high-performance servers directly onto a fiber ring, with low latency and high bandwidth. This is attractive for big application or database servers, or those providing multimedia gateways for voice or video over IP, and provides a migration to OC48 speeds to companies reaching the limit of, say, FDDI rings.

One particular case where the logic of this type of approach shows is the use of RPR to interconnect routers within a POP. Typically, edge routers are connected to core routers with an OC48 mesh. But, as Cisco’s Baher points out, “There’s an opportunity now with OC192 RPR to adopt a ring technology, which will deliver greater capacity, and it will reduce the number of core-router ports. So there’s a significant capex saving as we move from a 2.5-Gbit/s POP to a 5-Gbit/s POP to a 10-Gbit/s POP.”

Similarly, since RPR can use Sonet at Layer 1, an equally obvious approach is to provide RPR blades for Sonet equipment, thereby running Ethernet services efficiently over RPR-over-Sonet capacity, while using Sonet to transport TDM traffic. Nortel Networks does this with its OPTera Metro 3500 next-gen Sonet product.

A more fundamental notion, however, is to center an entire product around RPR. The idea here is to support all carrier services and capabilities over RPR, including those of Sonet. Corrigent Systems is promoting this approach, which it terms Sonet-Grade RPR, the attraction being to obtain Sonet-style performance and availability with Ethernet-style economics.

“We believe that the major market opportunity is with the established carriers and incumbents,” says Corrigent’s Cole. “So you have to have a system that’s fully compatible with Sonet. That means Sonet framing sitting on a Sonet PHY, or using that Sonet framing to sit onto an existing Sonet circuit. And it means having the ability to provision it, which in our opinion means MPLS/GMPLS, and then wrapping the whole thing up into a TL1 Sonet look and feel. That’s our view of the world, because we believe that’s the only way incumbents will adopt this type of technology. That’s a very different product from an Ethernet-centric RPR packet ring for offering carrier-class Ethernet services only.”

A basic point is that Corrigent uses the Sonet frame and PHY for Layer 1, so it can either run this at 2.5 Gbit/s or 10 Gbit/s as a pure packet ring (the preferred option for new build); or it can run it into a standard channelized Sonet ring to obtain some of the advantages of RPR over an existing Sonet infrastructure. A further point of handling TDM traffic over RPR is that part of the traditional TDM equipment stack can be eliminated.

“It means that you can take advantage of some of the big economic improvements. For example, we implement crossconnect functionality on our TDM interfaces without needing any TDM switch fabric,” says Cole. “That’s a very big economic saving. Not only do you have the benefit of having the legacy TDM services over the packet ring, but you start to get some big economic savings on those, as well as the Ethernet services.”

Luminous Networks emphasizes RPR’s role as part of a carrier transport solution. “Our solutions have really been tiered into three different layers of complexity,” says Sharma. “Point-to-point transport is one paradigm, but we have also started to build more aggregation/deaggregation, so you can aggregate/deaggregate Ethernet-based traffic or TDM services over packet networks. Thirdly is the idea of multipoint networks, where you have things like transparent LAN services, where an enterprise could have multiple connectivity on the ring, or over several rings connected by an arbitrary network in between.”

To handle this focus on transport, the company has developed its own technology: RPT, which it characterizes as a superset of RPR, because it addresses the transport of services – including resilience – over a heterogeneous network, end-to-end. RPR itself is concerned solely with a single ring.

Says Sharma: “The ability to switch between one node and another node that is common between the two rings is not really defined as part of the RPR specs – that’s going to be something that people like us are going to be able to differentiate with.”

Beyond the question of the particular role that RPR will play in different vendors’ products lie the design and performance implications of some options within the 802.17 RPR standard. Pretty obviously, vendors will have to consider roles and options together. Two major options are the choice between single- or dual-transit buffers, and between supporting wrap protection and the default steering protection. A more exotic choice is whether to use RPR’s capabilities to support Virtual Destination Queuing.

Transit-buffer options: A typical point here is that RPR needs to scale across a range of applications, and the form of the transit buffer can affect this scaleability and its cost–efficiency. In an access ring – where overall traffic levels are relatively low, access devices relatively small, and squeezing every last drop of bandwidth out of the ring may not be an overriding priority – a single transit buffer can provide an economical solution, as it makes sense to keep the cost of access nodes as low as possible. In a metro core ring, on the other hand – where traffic levels are high and a lot of aggregation/deaggregation of traffic streams with different QOS is going on through big nodes – the more expensive and functional dual buffer has attractions for maintaining the highest levels of ring utilization.

But it would be wrong to rely on simple generalizations alone. The buffer options lead to highly complex tradeoffs in the finer points of jitter, delay, ring utilization, and control of traffic flows, and these need to be tailored to requirements. For example, dual-transit buffers can appeal to router vendors faced with the typical IP requirement of bursty any-to-any traffic flows. In contrast, Layer 2 Ethernet switch vendors supporting transparent LAN services, with traffic flows more like those of the TDM world, could find the single-transit buffer appropriate. The Fairness Algorithm here operates more conservatively by not sending huge swaths of bandwidth from one node to another, as may occur in a router application.

Protection options: Steering, the default protection option, builds directly on the continuing topology awareness of RPR nodes – one of the key features of the RPR protocol. It obviously operates only after a source node is informed of a failure. So the node may already have placed some packets on the ring that will never reach their destination, and these will be lost. Wrapping, however, because it takes place just before the downstream point of failure, ensures that on-ring packets are just wrapped back on the other ringlet and are not lost. So wrapping has attractions for SLAs where packet loss has to be minimized, and steering is more efficient in overall bandwidth utilization on the ring. Both options, however, provide SLAs for 50ms protection switching.

Virtual Destination Queuing (VDQ): VDQ is optional in RPR, but RPR does provide the necessary control mechanisms to support it. Vendors such as Luminous Networks see this kind of capability as crucial to the development of RPR products. The argument is that VDQ is important when a hub-and-spoke-based traffic pattern is combined with a point-to-point traffic pattern on the same ring. Without VDQ it is difficult to prevent interaction between these two patterns. Point-to-point traffic is important for Ethernet-based private lines, while a hub-and-spoke pattern is important for broadband Internet access.

“It’s a huge differentiation for vendors and a huge value proposition in RPR,” says Luminous’s Sharma. “Because most typical networks do not have a good indication at the node level of the locality of the congestion in the network. Whereas in RPR, if you do get a congestion backoff message from the network, you know exactly the locality of this congestion. As a consequence, you don’t need to stall the traffic that is going to the nodes between your node and the point of congestion. You can still be transporting traffic before the point of congestion.”

There are many other factors that will affect vendors’ treatment of RPR and how it will be included in a product’s protocol stack. For example, John Hawkins, senior marketing manager for optical Ethernet at Nortel Networks, points out that the RPR Draft recognizes a header bit specifying on which of the two ringlets a packet originated. This maps well to vendor-specific functions that choose to make use of the information. Other pieces of the Draft are also clearly leverageable by vendors.

“For example, Nortel’s implementation adds a transparent domain indicator (TDI) function that is not part of the standard but is similar in concept to stacked VLANs,” says Hawkins. “This provides scaleability to meet real customer requirements for support for over 4,000 customers, the standard VLAN limit. The TDI could be a simple extension to standard IEEE 802.3 Ethernet-over-fiber implementations.”

As the dust begins to settle around the shape of the RPR technology, the industry is turning its attention to selling the stuff to carriers. There are naturally two standard questions:

  • What’s the business argument for RPR?

  • Where and how should a carrier use RPR?

Why Use RPR?

The fundamental argument is that RPR is going to save carriers a lot of money. These savings are to come from three main directions:

  • maximizing the utilization of fiber bandwidth to minimize the total requirements for fiber and bandwidth

  • simplification of network architectures and a reduction in the amount of equipment needed

  • simpler OA&M (operation, administration, and maintenance)

A big part of the expected capex savings rests on the network simplification that RPR can bring and the lighter equipment and fiber requirements compared to Ethernet-over-Sonet (EOS) or meshed Ethernet. These savings, in turn, rest on:

  • A distributed switch architecture – There is no node acting as a hub, thus eliminating the hub electronics, optics, and associated backhaul costs compared to an EOS ring operating in a hub-and-spoke mode.

  • Rings rather than point-to-point meshes – These have half the number of optical ports as an Ethernet mesh and can also use cheaper shorter-range optics because transmission is daisy-chained from node to node around the ring, rather than being direct to distant nodes.

  • Efficient aggregation through shared medium – Each node provides statistical multiplexing of ingress traffic with the entire traffic on the ring. This gives higher multiplexing gain than would be obtained by just statistically multiplexing the ingress traffic itself; and it eliminates the need to obtain further multiplexing gain by backhauling to a hub.

Corrigent Systems estimates that the capacity gain from ringwide statistical multiplexing can lie between a factor of 2 and 8, thereby allowing a considerable overbooking of bandwidth by carriers. The effects of this on costs can be considerable.

Says Corrigent’s Cole: “We did a business-case analysis for one of the Tier-1 carriers in North America that looked at the comparison for using RPR technology for aggregating Ethernet onto existing Sonet versus using regular Ethernet switches. The saving is approximately 1:4 – it’s 75 percent less. Basically, RPR is a much more efficient means of aggregating traffic at the edge. It consumes only about a quarter as many STS1s as using regular Ethernet as a means of aggregating Ethernet onto existing capacity.”

For randomly distributed traffic, the spatial-reuse capability of RPR can lead to an increase in ring capacity of up to a factor of 4 compared to EOS. A further doubling of capacity gain compared to EOS is provided by a protection mechanism that does not use redundancy: There is no unused protection capacity in an RPR architecture.

A sample capex comparison, undertaken by Corrigent, for delivery of Gigabit Ethernet shows RPR as about 25 percent of the cost of EOS and 35 percent of the cost of mesh Ethernet. In this particular comparison, the EOS approach required 16 fiber pairs, the mesh Ethernet 24 pairs, and the RPR only one. EOS required 320 Gigabit Ethernet ports, mesh Ethernet 224, and RPR 128.

Ring topologies are very efficient at minimizing numbers of optical ports, Cole points out. “You can have half the number of ports, and sometimes those ports are a third of the price because they are shorter range. Yet those components make up the largest cost component in any metro system. That alone is a dramatic capex saving, without all the other factors.”

The potential operations savings from RPR come largely from the distributed and automatic operation of the protocol, as this simplifies certain OA&M tasks. Says Martin Green, DPT product manager at Cisco Systems: “It’s a lot easier to manage than Sonet circuits. One thing we have pretty much gone for in 802.17 – and in many of the proprietary solutions – is to make it more of a plug-and-play situation. So to add and remove nodes from the ring, you don’t have to do any active management to set that up. The nodes automatically discover each other and automatically protect and unprotect.”

Where to Use RPR?

The combination of attractive features and the ability to combine with other protocols and to simplify network architectures gives RPR a potentially wide range of carrier and enterprise applications. Examples include:

  • Services, such as virtual private LAN services (also referred to as transparent LAN services), TDM private lines, and metro Ethernet transport

  • Networks, such as ILEC MANs, ISP backbones, regional enterprise backbones, CMTS/xDSL aggregation and distribution networks, wireless aggregation and distribution networks, intra-POP networks, and campus SANs



“We find that cable operators and interexchange carriers are not only interested in SRP/RPR today but are also deploying it in their networks,” says Steve Garrison, director of corporate marketing at Riverstone Networks. Cable operators, for example, need streaming capabilities based on packet rather than voice technology, while interexchange carriers need simpler ways to provide transit circuits. He points out that the characteristics of SRP/RPR satisfy the network requirements of these types of carriers.

The aggregation layer of the metro network is seen as one natural home for RPR because of the technology’s good aggregation characteristics. A potential attraction for ILECs (incumbent local exchange carriers) is that RPR promises to support both new data services and traditional TDM services over a single interface.

“The really big application is where you are starting to hook up your existing Sonet network to LANs which are all Ethernet,” says the RPRA’s Bob Love. “All of a sudden you have a massive amount of Ethernet data that has to go across the metropolitan area network. This is probably the norm rather than the exception, which is why we see a tremendous market for Resilient Packet Ring.”

Although devised as a metro technology, RPR can scale to distances of thousands of kilometers, meaning RPR may be run over large regional networks.

Such a wide range of possibilities inevitably leads to mixing and matching to meet different types of carrier requirements and circumstances. However, three major lines of approach are:

  • RPR for simple, standalone Ethernet services – The point here is basically to exploit RPR’s cost savings over a meshed optical Ethernet, as well as its simplified OA&M.

  • RPR for multiservice access – This supports TDM and Ethernet services on a standalone RPR ring. The idea is a cheaper form of new build that does everything that Sonet does but has high packet efficiencies for Ethernet traffic and services.

  • Adding RPR to an existing Sonet capacity – This effectively builds a virtual RPR over existing Sonet STS1s, using this capacity more efficiently by aggregating Ethernet services onto it.

There are two options for combing Sonet and packet ring. One is to use Sonet to handle existing legacy TDM services and to use a packet ring for data. The other is to put all services over RPR, retaining Sonet as pure bulk managed capacity. As Nigel Cole puts it, “A carrier usually needs both options. For new build, it’s more economic to put everything over the packet ring, but where there is substantial Sonet deployment, you can deploy it over existing Sonet capacity. Corrigent supports both options.”

With such an intense bout of standards activity, it is scarcely surprising that vendors are preparing to migrate proprietary packet-ring products to 802.17 RPR. However, this may be a somewhat gradual process, obviously dependent on the final delivery of the 802.17 standard. Also, packet rings are still only a small part of the metro market, and metro equipment markets are unlikely to boom in the near future.

As Jeff Baher of Cisco notes, “The plan, which is still very much a future – hinging on the delivery of the standard from the 802.17 body – would be to introduce dual-mode silicon at some point in the future.”

This, he says, would allow existing networks to operate in SRP mode but give them the ability to migrate to 802.17. “An upgrade is relatively straightforward. What we are anticipating is that 802.17 will typically be coupled with a speed upgrade. In the discussions we are having with customers we are not hearing a strong need to simply upgrade from SRP to 802.17 at the same speed, such as OC48.”

Similarly, Riverstone Networks, which is developing its products from an SRP base, plans to migrate to a full 802.17 RPR standard implementation by late 2003 that will increase system speed from today’s 2.5-Gbit/s OC48c/STM16 to 10-Gbit/s OC192c/STM64.

Carrier interest in RPR is growing – it’s described as “very substantial” by the RPRA’s Love. There are about half a dozen carriers participating in the 802.17 standards process, and a number of carriers are performing prestandard RPR trials. This is in addition to commercially active proprietary packet-ring implementations in various countries worldwide. Publicly announced prestandard deployments include those by:

The RPR market may also be beginning to widen away from concentrating on data-centric CLECs (competitive local exchange carriers) to traditional ILECs, according to Corrigent’s Cole, who points to the financial difficulties that the data-centric CLECs have encountered in making their data-only business models work. And this has implications for vendors’ RPR products.

“If you offer a product that’s only a better way of offering new Ethernet services, that doesn’t cut it with the carriers today,” he says. “If you have a product that can dramatically slash capex for existing Sonet services, that’s a very different value proposition. We feel very comfortable with our solution, as it is focused very much around the incumbent. For example, it is TL1-managed and they can deploy that with their existing Sonet operational paradigm.”

The comfort factor of being able to run RPR over existing Sonet and use familiar OA&M tools is clearly a plus factor for ILECs – it makes the overlaying of RPR onto spare Sonet capacity an obvious line of network evolution for them.

Overall, RPR looks to be a significant addition to the armory of carrier network technologies. But it’s only part of a solution: It’s up to the vendors and carriers to devise implementations that make the best use of its capabilities.

Packet-ring technologies are still a fairly specialist interest among system vendors, in contrast to things like next-generation Sonet and 1/10-Gigabit Ethernet, so the number of vendors with products on the market remains pretty small, although the group is likely to grow as the 802.17 RPR standards mature. Because RPR is neutral with respect to Layer 1, it can be used with either Sonet or native-Ethernet transport, so vendors of these systems are all potential candidates for adding RPR capabilities to their systems in the longer term.

Vendors to watch immediately, however, include:

  • Appian Communications Inc.
    See: Appian Unveils 'Virtual Ethernet Rings', Appian Enhances Ethernet-over-Sonet, Appian Scores Deal With NTT

  • Cisco Systems Inc. (Nasdaq: CSCO)
    See: Schlumberger Picks Cisco VPN Gear, Rutgers, France Telecom Pick Cisco, Cisco's All Over China, Cisco in U-Turn on RPR, Cisco Storms the Metro Edge, Cisco Rounds Up More RPR Support, Cisco Acquisition Causes RPR Stink

  • Corrigent Systems Inc.
    See: Corrigent Touts Metro Management, Corrigent Comes Out, Corrigent Joins Metro Ethernet Mix

  • Lantern Communications Inc.
    See: Lantern Demos 10-Gig RPR, Lantern Intros Metro Packet Switch

  • Luminous Networks Inc.
    See: Luminous Intros RPR Platform, Luminous Cuts Away, Luminous Rounds Up $80M, Luminous Close to Qwest Deal

  • Nortel Networks Corp. (NYSE/Toronto: NT)
    See: Nortel's Sonet Wins in Manitoba, Nortel Pushes Ether Over SDM, Nortel to Run Rings Around Japan, Nortel Announces Contract Wins, Nortel, Vitesse Join on Packet Ring

  • Riverstone Networks Inc. (Nasdaq: RSTN)
    See: Riverstone at CeBIT, Riverstone Rings Rapidly, Riverstone Goes Dense

  • Sun Microsystems Inc. (Nasdaq: SUNW)

The RPR business has not escaped the grim market conditions that have afflicted the rest of the telecommunications industry. Dynarc AB, a prominent RPR startup, went bankrupt in May 2002 (see Dynarc in Trouble, Startups Stumble and Succumb, and Dynarc Files for Bankruptcy).

What's on offer?

The table below looks into some of these vendors and their products, aiming to give a flavor of where packet-ring technology is now and where its development is going.

Vendors have differing views on what packet ring is for, how it relates to other technologies and products, and how it should be implemented – so the table inevitably mixes different product categories. The table thus concentrates on the attributes carriers expect from packet-ring technology itself and does not get too involved in any supporting technologies the products may use – such as DWDM (the subject of a future report). The common theme is offering robust, economical, and scaleable services in the metro, with highly efficient network utilization and strong SLAs.

For each of the vendors covered, the table takes a sample packet-ring product (or product that has packet-ring capabilities) and lists some of the major characteristics under several broad headings:

  • Type: How the vendor describes the product

    • By RPR’s definition, all products incorporate Layer 2 multiservice packet switches acting as ring-packet ADMs. In some cases RPR serves as a straightforward blade to add capability to another class of product (such as Internet router, Sonet MSPP, server); in others it is integrated into the total product design, the product then being a form of multiservices switch/router. Products are available at the access, aggregation, and core levels of the metro.

  • Architecture: Protocols and technologies used in the product

    • All existing products use a prestandard version of RPR, often based on Cisco’s SRP (a.k.a. RFC2892). Because RPR acts only on a single ring, vendors have developed many proprietary higher-level capabilities to handle end-to-end traffic control and management.

      OC48 (2.5 Gbit/s) is the generally supported ring speed, but some vendors now offer OC192 (10 Gbit/s). Vendors differ in the lower-layer protocols they support - for example, Sonet PHY, Ethernet PHY and PPP – but Sonet PHY is becoming common. MPLS is, not surprisingly, widely used in the protocol stacks for its connection-oriented capabilities and QOS.

      Some vendors use RPR only for data services and rely on Sonet to support TDM services such as voice. Other vendors use RPR for both data and TDM services.

  • Interfaces: The main interfaces provided (network-side and client services)

    • Service interfaces vary between products and naturally depend on product application. The common carrier set is well covered – OC3/12/48, DS1/3, 10/100/1000-Ethernet, for example. More exotic interface cards, such as ASI DVB MPEG Digital Video, are available as well.

  • Service/functional capabilities: Main services and functions supported

    • Packet services typically span point-to-point, point-to-multipoint, and multipoint-to-multipoint Ethernet services (such as Ethernet private lines, transparent LAN services, and VPNs), with support for common IEEE capabilities such as 802.1q/p VLANs, 802.3x Ethernet flow control, 802.3ad link aggregation, and 802.1p prioritization.

      Systems are available that support Sonet functions via RPR – for example, Sonet grooming and crossconnect services in VT1.5 and STS1 granularities.

  • Scaleability: Indication of how client data services and/or systems can be scaled

    • System throughputs range from 80 to 320 Gbit/s. Typically, rings can support about 100 nodes. Packet bandwidths typically scale in 1-Mbit/s increments to 1 Gbit/s, but some systems offer much smaller increments.

  • Network protection: Main protection modes and capabilities

    • Most systems boast sub-50ms protection switching.

  • System reliability: Indication of overall system reliability

    • Generally, 99.999% carrier grade, with redundant and hot-swappable modules; typically, 1+1 protection on Sonet modules and 1:1 and 1:N on electrical and Ethernet modules (where relevant).

  • Physical/configuration: Indication of basic chassis size, ports per card, cards per chassis, and chassis per bay

    • Physically, for the carrier systems, there is a common approach of using a core chassis, shelf, or system into which interface and functional cards are slotted; generally, interface cards can be mixed and matched by type until the capacity limit of the chassis backplane is reached. Chassis sizes vary considerably, typically with four to eight fitting into a standard 7-foot bay (19 or 23in.), together with the necessary power-supply and ancillary units. There is a fairly wide variation in the number of ports of a specific type that can be supported. For example, the number of Gigabit Ethernet ports per 7-foot rack varies from about 60 to 300.

  • Power consumption: Typical or maximum system power consumptions

  • Standards: Major technology, environmental and other standards supported

    • Most of the products are aimed at the carrier market, so they almost inevitably are specified to such standards as NEBS Level 3, UL 1950, and so on.

  • Vendor approach/notes: Indication of design approach and emphases; other relevant points

    • It’s impossible in the space available to include all vendors’ complete packet-ring ranges, as these usually span several functional categories – access nodes, aggregation nodes, core nodes and so on.





    Dynamic Table: Multiservice RPR ADMs for Metro-Area Networks

    Select fields:
    Show All Fields
    VendorProductTypeArchitectureInterfacesService/functional capabilitiesScaleabilityNetwork protectionSystem reliabilityPhysical/configurationPower consumptionStandardsVendor approach/notes

    It’s important to recognize that packet ring is just a component in a metro product’s packet-handling architecture. This means that, while some vendors offer products with a range of technology options – one being packet ring – others base their products solely on packet-ring technology.

    The table cannot be read as a straight comparator of a sample of vendors’ products. But it does highlight some of the different outcomes that packet-ring technology is producing in product terms, and what you may expect to find on the market now and over the coming months.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like