ENABLING PACKET-BASED SERVICES WITH RESILIENT PACKET RING TECHNOLOGY
As businesses deploy more sophisticated network applications, their need for customized, high-bandwidth services is increasing. To deliver the value-added services these customers demand, service providers are rapidly integrating packet-based technologies into their metropolitan-area networks. Packet-based forwarding and multiplexing allow providers to use their infrastructure bandwidth much more efficiently. At the same time, packet technologies make it easier for providers to provision and support profitable differentiated services.
Many providers are discovering that Resilient Packet Ring (RPR) is an effective technology for optimizing metro networks. RPR is a Layer 2 ring technology designed specifically to meet the requirements of metro networks with multipoint service requirements. Furthermore, it gives providers the ability to apply packet classification and queuing that helps guarantee the level of performance that paying customers expect. RPR also lets service providers use their infrastructure more efficiently by sidestepping the bandwidth restrictions associated with traditional TDM technology. And it delivers the same resiliency and rapid failover offered by traditional transport ring topologies.
RPR supports bidirectional communication around both sides of the ring, using redundant paths simultaneously for data transport. Unlike SONET/SDH, RPR does not rigidly reserve bandwidth, so service providers can deliver line-rate Gigabit Ethernet using only STS-12c/VC-4-4c circuit sizes.
Figure 1
Cisco ONS 15454 MSPP and ML-Series Cards
CISCO MULTISERVICE OPTICAL RPR SOLUTION
Cisco Systems® has long been an industry leader in RPR technology, and is deeply involved in the IEEE 802.17 working group, which is focused on this standard. In fact, the first major technical proposal for an RPR protocol was submitted by Cisco®, based on its Dynamic Packet Transport (DPT) technology. Cisco has been deploying RPR architectures with DPT in service provider networks for more than five years.
Using its industry-leading Cisco IOS® Software, the Cisco ONS Family now supports RPR. Using the Cisco Multilayer ML-Series of Ethernet cards, providers can smoothly integrate packet functions into the Cisco ONS 15454 Multiservice Provisioning Platform (MSPP), shown in Figure 1. ML cards feature full Cisco IOS Software-based management, Layer 2 and Layer 3 switching, RPR aggregation, and enhanced quality of service (QoS) for bandwidth reservation. With Cisco ML-Series Ethernet cards, service providers can deliver an RPR solution that gives customers a wide range of benefits, including:
• Improved SONET/SDH bandwidth utilization, compared to traditional Spanning Tree Protocol ring topologies
• A non-SONET/SDH failover mechanism with less than 50-ms convergence for fiber cuts, restores, node failures, and node insertion
• The ability to perform ubiquitous QoS assurance on all data traffic-transit, drop, and add
The comprehensive Cisco RPR solution enables service providers to take advantage of the competitive benefits of this innovative technology today and can help secure market share and maximize profits in the future.
Although the 802.17 draft was used as reference for the Cisco ML-Series RPR implementation, the current ML RPR protocol does not comply with all clauses of IEEE 802.17. In this paper, we'll illustrate some of the technical features that RPR provides and discuss how Cisco enables service providers to immediately deliver the advantages of RPR over SONET/SDH technology to customers. And we'll discuss some of the differences between the Cisco Multilayer RPR solution and the IEEE 802.17 standard.
SPATIAL REUSE
Spatial reuse enables networks to efficiently utilize bandwidth and to simultaneously support multiple data streams over that same network bandwidth. Traditional ring-based data protocols such as Token Ring or Fiber Distributed Data Interface (FDDI) use arbitration to place a single conversation at a time over the network. These protocols use a technique called "source stripping," in which every data packet traverses the entire ring before returning to the original sender, who pulls the packets off of the ring, finally releasing that bandwidth for other services.
Multilayer RPR, a feature supported by Cisco ML-Series solutions, uses a technique called "destination stripping" to support spatial reuse for both bridged and routed applications. With destination stripping, the destination node of a unicast flow removes packets from the ring, instead of continuing to forward them over the entire ring. By removing packets before they make a complete circuit, Multilayer RPR conserves network bandwidth.
The IEEE 802.17 RPR standard also performs destination stripping for routed IP traffic, but, unlike the Cisco Multilayer RPR, does not use this technique for bridged services. For bridged applications in a 802.17 RPR network, all frames flood around the ring, and the source node strips each one (Figure 2). As such, the IEEE 802.17 RPR implementation only offers spatial reuse benefits for routed traffic, and yields no spatial reuse benefits when sending bridged traffic.
Figure 2
Spatial Reuse and Bridging
RING SOURCING
RPR technologies also use ring sourcing techniques to maximize available bandwidth, including destination routing and flow-based load sharing (Figure 3). These mechanisms determine the most efficient direction for transmitting packets onto a ring.
The IEEE 802.17 standard employs shortest path first (SPF) destination routing, which uses metrics such as hop count to calculate the least expensive direction for a packet to travel to reach its destination. In contrast, Multilayer RPR uses a technique called flow-based load sharing, which attempts to transmit packets equally in both directions, regardless of the intended endpoint. Each technique offers advantages.
Destination routing can substantially increase bandwidth, especially for distributed, any-to-any traffic patterns. For example, in situations where source-to-destination flows only occur between adjacent nodes, the total aggregate bandwidth of an 802.17 ring will be equal to the circuit bandwidth, multiplied by the number of connecting segments. A meshed traffic pattern can provide even more available bandwidth. However, destination routing is less advantageous for hub-and-spoke applications.
Figure 3
Per-Flow Load Balancing Versus SPF Destination-Based Sourcing
Flow-based load sharing, which is used by the Cisco Multilayer RPR implementation, offers benefits as well, especially in situations where bandwidth requirements are not symmetric around a ring. For example, consider a three-node configuration, A-B-C, with traffic between A and B at 100 Mbps, and traffic between A and C at 1 Gbps. Using destination routing, the link A-C would have 1-Gbps utilization, forcing the provider to use STS-24c/VC4-8c ring circuits. However, using flow-based load sharing, links A-B and A-C would both have only 550 Mbps, and can fit into an STS-12c/VC4-4c ring.
In situations where only two nodes exist on a ring, flow-based load sharing enables service providers to use both paths on the ring. Destination routing would be a less efficient mechanism in a ring with only two nodes. Because destination routing uses hop counts to make its decisions, it would arbitrarily choose a single preferred link for all packet transmissions. Because of the necessity for load sharing to occur per flow instead of per packet, however, perfect load balancing still is not guaranteed.
The Cisco Multilayer RPR also uses both the source and destination addresses of a packet to choose a ring direction. Flow-based load sharing helps ensure that all packets populated with equal source- and destination-address pairs will be sent in the same direction, and arrive at their destination in the correct order.
In short, destination routing localizes traffic and reduces latency for IP routing, but flow-based load sharing can provide more consistent bandwidth distribution, regardless of traffic type and pattern.
TOPOLOGY DISCOVERY
Topology discovery is important for network management and for calculating metrics that are used by destination routing. The IEEE 802.17 standard uses in-band internodal communications to enable network elements to announce themselves and determine their positions on the ring. On an IEEE 802.17 network, each device must maintain an accurate map of the ring topology to source packets in the least expensive direction.
The Cisco Multilayer RPR does not source packets based on link metrics, but it does use topology discovery for network management. On a Cisco network, the Cisco ONS 15454 performs automatic topology discovery using SONET/SDH Data Communications Channel (DCC) communications, so there's no need for the Multilayer RPR protocol to perform this function.
RAPID RECOVERY
Network resiliency is another important feature provided by RPR technology. The IEEE 802.17 standard offers two recovery methods that can restore connectivity in the event of a node or circuit failure: steering and wrapping. Steering reverses the direction that traffic flows from the source node if a failure is detected between the source node and its destination (Figure 4). To do this, each and every node needs to be aware of any failure, and therefore, must be continuously kept updated on the network status. When a network failure is recognized, each node is updated and all ensuing packets are steered away from that failed area. While the steering approach maintains sub-50-ms network resiliency, it follows a more complicated methodology and yields longer converge times as networks get larger.
Figure 4
Wrapping and Steering Recovery
The wrapping technique is much simpler, and does not make changes at the source node. Packets on a wrapped ring are simply redirected if they reach a failure point. Therefore, only the nodes adjacent to the failure need to be aware of the issue and will initiate the wrap. Wrapping also offers sub-50-ms resiliency and maintains the same network convergence times, regardless of the network size.
The Cisco Multilayer RPR currently performs wrap resiliency, while the IEEE 802.17 standard has defined support for both steering and wrapping.
FAIRNESS AND QUEUING
RPR provides robust support for fairness and queuing, which are important because they enable service providers to offer differentiated services to their customers. The Cisco Multilayer RPR and IEEE 802.17 each enable a variety of fairness and queuing techniques.
As a packet transits around a ring, it may hop through several intermediate nodes. At each transit point, a packet may compete with other packets sourced onto the ring at that location. Fairness mechanisms are designed to maintain a similar quality of service for equally classed flows, regardless of the number of hops. Multilayer RPR uses local fairness, while 802.17 uses ring-based fairness.
Local fairness prioritizes both transit traffic moving through the network and transmit packets that are inserted onto the network. Transit traffic usually receives preference, and administrators can fine-tune the output queuing ratio at each node.
Ring-based fairness uses internodal communication to announce buffer threshold events and to signal queue priority changes. The IEEE 802.17 standard uses ring-based fairness with this dynamic queuing technique to adapt to network congestion.
The Cisco Multilayer RPR can also be tailored to simulate 802.17 using Cisco IOS Software. With the Cisco Multilayer RPR, each device makes static, autonomous queuing decisions. The weighted queuing is provided with Weighted Deficit Round Robin (WDRR) with Low-Latency Queuing (LLQ) scheduling. All transit and local traffic priorities on each packet-over-SONET (POS) interface may be based on RPR class of service (CoS) marking and remarking.
Service classification can be based on IP differentiated services code point (DSCP), IP Precedence, or Ethernet CoS with the Cisco Multilayer RPR implementation. These Layer 2 and Layer 3 priorities are mapped into eight classes because this RPR CoS uses three bits, just like the Ethernet CoS scheme. Any number of queues may be built at egress POS ports on the ring to support these classes with relative weighting. Administrators can implement the same type of queuing strategy on egress of Ethernet ports to provide consistent, end-to-end QoS. Furthermore, the Multilayer RPR solution offers committed information rate (CIR) and peak information rate (PIR) support, allowing the provider to offer strict service-level agreements (SLAs) based on bandwidth requirements.
The 802.17 RPR implementation also provides classification for advanced services support. However, only three major classes-real time, non-real time, and best effort-are currently defined by the IEEE. Subclasses are defined for more granular breakdown of service types, but no CIR/PIR mechanism has been defined by the IEEE.
DUAL RPR INTERCONNECT
The IEEE 802.17 standard focuses on packet switching within an RPR ring, but it does not address communication between rings. Under the 802.17 standard, ring-to-ring traffic must exit one RPR domain and enter another using standard User-Network Interface (UNI) ports. To manage these UNI interconnections, administrators must use control protocols in the middle of the network that are normally used only at network endpoints. To provide 802.17 RPR interconnection with redundant Ethernet interfaces, administrators must use customer routing protocols for IP services and introduce Spanning Tree for loop avoidance of Layer 2 services.
The Cisco Multilayer RPR technology offers an alternative that enables providers to interconnect RPR domains without using traditional Layer 2 control protocols or disrupting customer routing schemes. The Dual RPR Interconnect (DRPRI) protocol provides support for redundant pairs of back-to-back Ethernet connections between different RPR networks (Figure 5). With DRPRI, inter-ring bridging recovery occurs in less than 100 ms. Customer routing protocols and Spanning Tree instances are not touched, regardless of DRPRI hops.
Figure 5
DRPRI Interconnection
DRPRI is flexible enough to accommodate a variety of network equipment, routing schemes, and site topologies. In fact, redundant connecting nodes do not need to be adjacent or even near each other. This unique protocol enables providers to pair working and standby facilities however they wish, in any infrastructure design.
CONCLUSION
The Cisco bridging-optimized Multilayer RPR lets providers deliver efficient packet transport over their traditional SONET/SDH architecture. Cisco Multilayer RPR supports RPR's most important features, including bidirectional ring transport, per-flow load balancing of both rotations, spatial reuse by destination-stripping unicast flows to conserve bandwidth, and rapid link recovery.
Cisco will continue to demonstrate its commitment to standards-based RPR solutions by providing IEEE 802.17-compliant products in future Multilayer Cisco ONS releases. These new solutions will be compatible with the existing Cisco Multilayer RPR protocol, enabling service providers to quickly take steps to deliver the value-added services to meet customer demand, while protecting their investment in the years to come.