Latency, deskew in metro networks

A key factor in the success of metropolitan-area network (MAN) applications will be the use of virtual-concatenation (VCAT) technology to maximize bandwidth efficiency and provide optimal granularity for simultaneous transport of multiple protocols. Virtual concatenation allows equipment designers and network providers to effectively integrate advanced local-area network and storage-area network services, such as Gigabit Ethernet, Fibre Channel, Escon and others across heterogeneous MAN networks.

The effective deployment of VCAT, however, presents some important technical challenges. Among them is the critical need to tightly manage both deskew and latency across many traffic streams. deskew is a fundamental requirement because of the need to compensate for differential delay between the multiple received paths belonging to the same virtual-concatenation group (VCG). At the same time, minimizing latency for co-routed paths is a critical issue when latency-sensitive protocols such as Fibre Channel, Escon, digital video broadcasting or voice-over-Internet Protocol are mixed together within a VCAT environment along with other, less-latency-sensitive services, such as Gigabit Ethernet.

Achieving a balance between the management of deskew and latency is a "ground-level" challenge that has to be solved at the semiconductor level. No amount of design magic at the system level can compensate for inadequate chip-level VCAT mapping performance or can overcome inflexibility of the chip's feature set. Unfortunately, some system designers think this requires maximum "brute-force" deskew functionality at the component level. In truth, however, they may actually be paying extra for unneeded capabilities and potentially incurring a penalty in added latency for the extra processing and memory access cycles involved in some deskew approaches.

In the balance of this article, we will look more closely at evaluating the real-world requirements for deskew in MAN environments and will explore the key hardware characteristics necessary to meet those requirements.

For physically co-routed paths in a virtual-concatenation group, the differential delay between paths is primarily incurred in the pointer processors located at each intermediate synchronous optical network/synchronous digital hierarchy (Sonet/SDH) network element in the path, such as add/drop multiplexers (ADMs) or synchronous cross-connects. An analysis report, available from ITU-T, indicates a worst-case 10-byte delay occurs as a synchronous transport signal path traverses pointer processor actions within each network element. Across a relatively large ring, one can assume an equal distribution of positive, negative and nonaction pointer-processor adjustments, thereby resulting in a typical profile containing 5 bytes of skew incurred as differential delay between separate Sonet/SDH paths within each network element. In contrast, only a negligible amount of delay stems from all other factors, such as chromatic dispersion, temperature variations and the like.

Memory requirement

Based on the above analysis, all of the deskew requirements for a network with as many as 16 Sonet/SDH nodes between end points can be handled using efficient deskew memory blocks as small as 90 bytes each. The fiber itself is a minor factor in the overall delay equation. This means that deskew requirements in Sonet/SDH or dense wave-length-division multiplexing (DWDM) rings traversing many thousands of kilometers can be effectively managed with a small amount of internal deskew memory on the VCAT mapping chips used in each node.

For example, a 2,400-km ring consisting of eight ADMs spaced at 300-km distances could be handled with 90 bytes of on-chip deskew memory per VCAT mapper device. Sufficient redundancy would still remain to allow traffic to traverse the whole ring twice, if necessary, to compensate for a node failure.

In some applications, there is a large percentage of diversely routed (rather than co-routed) VCAT traffic or networks where tributaries are transmitted in opposite directions within a large unidirectional-path switched ring (UPSR). That may require handling additional delay times between member paths in a VCG.

Experience has shown, however, that these requirements can be met by adding high-speed external memory rather than including the cost of extra internal memory in every VCAT mapping device. For example, even a challenging scenario, such as diverse routing paths with as much as a 3,000-km difference in length, can be handled within 15 milliseconds of external deskew memory. That memory can be configured using a 128-bit wide bus supporting four x32 double-data-rate (DDR) SRAM memory devices (or eight x16).

For system designers, balancing deskew requirements, latency management, flexibility and overall system costs can be difficult. Equipment suppliers are continually challenged by the need to support many different protocols within their systems, at the right cost, while avoiding unnecessary configuration and operational costs for their customers. This means that variations in the component-level, card-level and system-level hardware should be avoided and that the baseline costs for hardware must be kept to a minimum.

System designers also need to include built-in flexibility, however, in order to allow adaptation to special requirements.

There are advantages to standardizing on intelligent multiprotocol VCAT mapper devices, which can support up to 10 separate 1-Gbit/second ports and provide virtual-concatenation granularity down to the STS-1 level. System designers are able to leverage a single technology solution across a range of network node requirements throughout metro Sonet/SDH rings as well as DWDM rings (see figure).

Delays dampened

By handling deskew within 90 bytes of internal RAM, such a device can cost-effectively address most VCAT delay conditions encountered in metro and long-haul networks, while minimizing power usage, latency and processing overhead. Optional access for 15 ms of external DDR SDRAM allows the same device to be easily expanded to address intertributary delays for diversely routed virtual-concatenation groups but doesn't impose either extra cost or processing overhead on most VCAT applications.

Using a standards-based ap-proach that conforms with Sonet and SDH provisions and also incorporates link capacity adjustment scheme mechanisms, the VCAT mapper solution enables device-level dynamic adaptation and rapid provisioning to track with network growth and meet changing user bandwidth requirements. This can ease the burden of operational expenses, which currently account for as much as 80 percent of most carriers' overall costs.

The bottom line for MAN service providers is the ability to smoothly adapt existing Sonet/SDH and DWDM network infrastructures to support more protocols and offer better service to their customers, while optimizing overall bandwidth utilization. For the customers of MAN services, virtual concatenation allows them to pay only for the amount of bandwidth that they actually need.

Armin Schulz is senior product-marketing manager and Bob Brand is senior solutions architect at Applied Micro Circuits Corp. (Andover, Mass.).

See related chart