The key features provided by RPR are data services, efficient bandwidth, robustness, and OAM (operation, administration, and management) capabilities. Enhanced bridging (IEEE 802.17b) is an extension to RPR's simple bridging (IEEE 802.17a) that ensures seamless integration with Ethernet bridges, providing a simple, cost-effective way to connect access and metro networks. RPR can efficiently provide Ethernet services over existing infrastructure, and it provides a clear roadmap for future transport systems.

Ethernet services
From the user's perspective, Ethernet service can be defined as:

• Ethernet line service (ELS): a point-to-point interface from the user to the network
• Ethernet LAN service (E-LAN): a multi-point to multi-point (MP2MP) interface providing LAN service

• Physical interface: the type of medium (e.g. fiber, copper, etc.) and maximum speed
• Bandwidth profile: usually specified as a committed access rate and an excess or burst access rate
• Performance guarantees: performance measures such as availability, delay, jitter, and packet loss
• Classes of service: different priorities assigned to various applications
• High-level services: other services such as firewall

Ethernet service delivery
There are several ways to provide Ethernet services, such as transport-, Layer 2-, and IP/MPLS-based. Ethernet over SONET/SDH has been used as a data transport mechanism for a number of years. It's mainly based on point-to-point connections. SONET/SDH provides the underlying transport with protection and fast restoration. This service delivery is robust, but the cost is high. To reduce the cost, some vendors use virtual concatenation (i.e., bundling SONET/SDH to provide the right-sized bandwidth link).

Other solutions include providing an Ethernet switch to aggregate the Ethernet traffic. However, this method suffers from a higher delivery cost due to inefficient bandwidth use as well as the necessity to manage and provision the point-to-point connections.

Layer 2 solutions are based strictly on Ethernet switching. Data-based solutions have the advantage of cost-effectiveness, because Ethernet transport equipment is less expensive than SONET/SDH equipment. However, they work only in metro networks when the underlying physical network is Ethernet.

Another drawback is that Layer 2 data protection is done by a spanning tree, an algorithm designed to provide a unique path from one point to another, blocking any redundant paths. Thus, it's hard to guarantee carrier-grade restoration times below 50 ms. This approach also lacks latency and jitter guarantees to support different service classes for applications like VoIP. While existing systems could provide jitter and latency guarantees, these are vendor-specific and aren't built into the Ethernet MAC. One final drawback to Layer 2 data transport is its lack of native management features.

The IP/MPLS approach has the broadest applications, because it can be implemented using Ethernet PHY or SONET/SDH. However, the cost of these solutions is fairly high, and it's been difficult for them to achieve protection times below 50 ms.

RPR at a glance
RPR addresses the drawbacks of standard Ethernet service delivery mechanisms. It's a Layer 2 technology based on dual rings called ringlets. The dual-ringlet design provides protection in the event that one ringlet is cut. RPR supports up to 255 nodes per ring. One of the major features of RPR is automatic (dynamic) bandwidth management.

RPR also provides several choices in terms of applications (Fig. 1). In this configuration, part of the ring is carved out for Ethernet services. The user sees an Ethernet connection, and RPR provides bandwidth management and oversubscription. In this case, an OC-12 circuit can be dedicated to carry all Ethernet traffic from several customers. Each customer can have different SLAs with burst capability. There are several applications:

• SONET- or Ethernet-based PHY: rings can be based either on Ethernet PHY (1G, or 10G), or SONET/SDH (155 or 622 Mbits/s, 2.5 or 10 Gbits/s, or other rates).
• Switch/router or ADM rings: RPR is deployed for next-generation SONET/SDH ADMs (add-drop muxes) and switches and routers.
• Layer 2 or 3: As an 802 technology, RPR provides a way to bridge Ethernet to RPR (Layer 2). Both the 802.17a (simple bridging) and upcoming 802.17b (enhanced bridging) protocols specify the bridging function for RPR. RPR also supports IP and MPLS routing (Layer 3).

One major contribution of RPR is that the service class guarantees (bandwidth, jitter, latency, etc.) are provided by the MAC itself (Table 1). Ethernet can carry service class information (using a VLAN tag, for example), but the MAC layer doesn't process packets differently for various service classes. RPR supports both unicast and broadcast/multicast. Multicast is done by sending a packet around and removing it by the sender.

Bandwidth efficiency
RPR provides bandwidth guarantees, because the RPR MAC has built-in rate shapers to ensure that allocated high-priority traffic gets access to the ring. RPR also improves bandwidth efficiency because, unlike SONET (where one ring is reserved for redundancy only), both ringlets carry traffic at all times.

The major bandwidth management feature in RPR is fairness. For opportunistic traffic (such as ClassB1 or ClassC) the algorithm makes sure that if there's unused, reclaimable bandwidth in the ring from other service classes (like classB0 or classA1) or from other nodes (classA1, classB0, classB1, or classC), it's used by active stations. This ensures maximum bandwidth utilization. Because unused bandwidth can be reclaimed, RPR enables a high level of oversubscription, such as having customer Ethernet ports with an aggregate bandwidth far larger than the ring capacity. This is particularly important given Ethernet traffic's bursty nature.

The RPR standard defines two major fairness algorithms, aggressive and conservative. Aggressive is where full bandwidth utilization is of the essence. In this mode, RPR nodes "aggressively" reclaim unused bandwidth and maximize utilization. Conservative is where the stability of traffic flows is of the essence. Nodes ramp up and down when reclaiming unused bandwidth.

RPR ensures robustness by providing either steering or wrapping around faulty links or nodes. The protection is accomplished in less than 50 ms with an algorithm that uses TP frames, which are broadcast by every node. TP frames carry status information that's used to determine if the ring has any faulty links or nodes. These frames also provide a quick snapshot of the ring's topology.

RPR provides several mechanisms to help operators manage the ring. These mechanisms include measuring the ring's health and performance (e.g., link round trip time, echo and reply), topology discovery (name of station, management address, etc.), and a flexible OAM packet for vendor-specific needs.

Ethernet services with RPR enhanced bridging
RPR offers an alternate way to deliver Ethernet services with lower costs, and without giving up quality of service guarantees. By using Layer 2 technology and enhanced bridging, we can reduce the complexity of the RPR nodes. While simple bridging (802.17a) doesn't take advantage of spatial re-use and instead uses flooding, enhanced bridging (802.17b) enables Ethernet traffic to be reliably mapped onto an RPR node at Layer 2 while still making full use of the fairness algorithm.

Given a set of Ethernet stations (or customers) connected using Layer 2 switches (S1 through S6), the "Ethernet clouds" can be connected using an RPR ring (Fig. 2). This ring can be implemented using different underlying physical media, including GigE PHY, a 10GE PHY, and SONET/SDH (either concatenated or using virtual concatenation).

The challenge is to provide a mechanism by which Ethernet bridges and RPR nodes (A through E) can interoperate. With a different nature of learning in RPR enhanced bridging, for each Ethernet address (a MAC address and optional VLAN tag), we need to learn the RPR location (which node it is attached to).

This information is affected by failure in the ring (because protection changes the way we reach a given Ethernet address). While initially some criteria help choose which ringlet to use (ringlet selection), this choice will be affected by failure. For example, from Fig. 3, A can reach D through ringlet 0 in three hops or ringlet 1 in two hops. We can select ringlet 0 for B and C, and ringlet 1 for D and E. Most of the tasks performed by an RPR bridge are similar to those in an Ethernet bridge.

The other task is to convert Ethernet packets to RPR and vise-versa by taking advantage of an RPR data frame called extended frame (Fig. 4). This frame lets a user carry Ethernet frames as is, and then simply appending an RPR-specific header when going into the ring, and removing it when getting out of the ring. The header addition relies on lookup of the destination address, the nature of the address (multicast or unicast), and the local topology and protection status. The service class also needs to be mapped from the Ethernet domain (802.1p) to the RPR domain (class A, B, C).

When comparing data transport methods, RPR is the only method that guarantees support for bursty traffic, supports both SONET and Ethernet PHYs, and offers the protection, QoS, and management features carriers expect (Table 2). In addition, RPR can be implemented at a lower cost than SONET/SDH or MPLS.

RPR has so far been considered a technical curiosity due to lack of vendor implementation, but its outstanding data-handling characteristics, combined with the low cost and simplicity of deployment, promise a bright future for this protocol.

References

1. IEEE Std 802.17-2004: Resilient packet ring (RPR) access method and physical layer specification
2. "IEEE 802.17 Resilient Packet Ring Tutorial," F. Davik, IEEE Communications Magazine, March 2004, Vol. 43, No. 3, pp. 112-118
3. "Metro Ethernet," Sam Halabi, 2003, Cisco Press
4. Initial Implementations of Point-to-Point Ethernet over SONET/SDH Transport," V. Ramamurti, Communications Magazine, March 2004, Vol. 43 No. 3, pp 64-70
5. User Network Interface (UNI) requirements and Framework," Metro Ethernet Forum, Technical Specification MEF 11, 2005