Sliced architectures extend Sonet/SDH for high- speed data

Initially deployed for voice traffic, Sonet/SDH has played a major role in today's service provider networks, combining voice, video, and data on a single robust transport mechanism. However, many existing equipment architectures will not scale sufficiently to meet the increasing data demands of the future. Furthermore, as the number of network nodes expands, provisioning and managing these networks is becoming increasingly complicated.

In today's frugal service provider environment, carriers looking for ways to cut capital and operational expenses will need their existing Sonet/SDH infrastructure to scale while maintaining both new and legacy services. New switching technologies employing sliced memory architectures could help here, allowing service providers to tune and scale existing Sonet/SDH infrastructure to a data-centric world while preserving their voice revenues.

Sonet/SDH switching systems utilize either single-stage or multistage switching architectures. Smaller grooming fabrics are often created using single-stage architectures, but for a given technology generation, a single-stage architecture is typically fixed in bandwidth and cannot be scaled without moving to a multistage architecture. However, the system is simple to implement, as there is only a single switching element.

A multistage approach addresses the bandwidth scalability requirements, but at the expense of increased device count, power, and software complexity. As an example, to scale a single-fabric-element, 160 Gbit/second Sonet/SDH system to 640 Gbit/s, 12 switching elements would be required (four devices in three columns). The resulting system cost and power attributable to the switch fabric increases twelve-fold for a modest four-fold increase in aggregate capacity. Further, the system may not be able to support the additional software complexity.

An alternate approach is to use a sliced architecture. Sliced architectures scale linearly from a single-element architecture, reducing the number of devices required to construct large fabrics compared to their multistage counterparts. Essentially, sliced architectures distribute the data path across multiple, parallel switching elements in a single stage, with each element grooming traffic at a sub-granular level.

Take an example where the aggregate capacity of a sliced architecture switch fabric is increased from 160 Gbit/s to 640 Gbit/s. In a sliced architecture, each byte of data from the line card is spread across four data links, so that the first link carries bits 1 and 2, the second link carries bits 3 and 4, and so on. Subsequent bytes from subsequent time slots are similarly distributed. This is termed "di-bit slicing," since two bits of each byte are placed on each link. The four fabric elements then switch the data two bits at a time for reassembly at the egress line card. Using this slicing technique, the architecture scales linearly to 640 Gbit/s using only four fabric elements.

There are a few important observations that arise from this architecture. First, each fabric element is switching data to and from a common port or time slot. Each fabric element thus performs the same task and may share a common matrix configuration. Second, the fabric element itself must be capable of addressing and switching at the sub-granular level. This does add complexity to the design of the element itself, but the overall throughput is the same as a byte-addressable element: Only the switching granularity is increased. The physical characteristics of a di-bit sliced element (power and size) are similar to a byte-addressable element. Finally, there is no fundamental architectural change during the upgrade: Because data is handled in parallel, the group of elements acts as a single device.

Blocking issues

A sliced architecture also avoids some of the complexity that multistage fabrics experience in the area of "blocking," one of the most difficult design problems switching architectures must solve. Blocking occurs when an input port or time slot may not be connected to the required output port or time slot, despite that port being available. This problem is made worse in Sonet/SDH systems, where bidirectional traffic is very common, as in ring applications. Increased demand for multicast services, such as video, further exacerbates the problem.

Switch fabric blocking performance falls into three categories: blocking, rearrangeably non-blocking, and strictly non-blocking. In a strictly non-blocking fabric, all connections may be made, regardless of the order in which the connections are configured. In a rearrangeably non-blocking fabric, some connections may be blocked, but it is always possible to rearrange existing connections to make switching resources available.

In blocking fabrics, rearrangement may alleviate some blocking, but it is not possible to resolve all connection requests. For each of the above categories, the blocking behavior is specific to a particular type of traffic. For instance, a fabric may be rearrangeably non-blocking for bidirectional traffic, but blocking for multicast.

In single-element fabrics, blocking is easily resolved by using a shared core-memory element. In a memory element, each output port or time slot has simultaneous access to all the input ports or time slots and is therefore strictly non-blocking for all traffic forms. Shared memory elements are also very simple to configure: you need only configure the source port or time slot for each output port or time slot. This greatly reduces the software complexity.

In multistage fabrics, blocking or non-blocking performance is difficult to prove in practice. Even if the individual fabric elements are strictly non-blocking, this does not necessarily extend to the fabric as a whole. Until now, Sonet/SDH system designers have created usable implementations of multistage fabrics through a combination of port-placement restrictions, multicast limitations, connection rearrangement, and internal fabric speedup. As the number of possible connections increases, data-enabled Sonet/SDH systems need to eliminate such restrictions.

Sliced architectures are able to extend the benefits of single chip memory elements to higher-capacity multichip architectures while maintaining the ease of configuration and arbitrary multicast capabilities of single element designs. The result is the elimination of complex rearrangement algorithms, as well as faster, deterministic provisioning times.