SONET/SDH, ATM, IP
New concatenation techniques help SONET/SDH networks handle high-bandwidth data traffic.
FRANK KUHN, Siemens Information and Communications Networks
When bandwidth demand leapfrogs the capacity of an existing network infrastructure, finding a graceful solution is not always easy-especially without spending a fortune. It's a challenge that providers of SONET/SDH networks can appreciate. High-bandwidth Internet Protocol (IP) communication is testing SONET/SDH networks' ability to cope with data traffic.
Today's IP core routers and ATM core switches typically use "fat pipes" to deliver clear channel signals with a capacity of OC-12/STM-4 (622 Mbits/ sec), OC-48/STM-16 (2.5 Gbits/sec), or OC-192/STM-64 (10 Gbits/sec). These interfaces are found in server farms or Internet service providers' points of presence. SONET/SDH networks offer line and switching capacity to accommodate this high-bandwidth traffic. The weakness lies in the internal granularity of SONET/SDH networks.
Traffic is carried through the SONET/SDH network using virtual containers (VCs). A VC-4 has a client capacity of approximately 140 Mbits/sec. While a fat pipe may support traffic in the gigabit range, the traffic has to be converted into multiple VC-4 channels to be transported through the network infrastructure. As such, an STM-4/OC-12 clear channel is divided into 4xVC-4 signals, while an STM-16/OC-48 clear channel is converted to 16xVC-4 signals.
Today, the demand for high bandwidth transport regularly exceeds the VC-4 limit. Obviously, carriers in the SONET/SDH space can't just walk away from high-bandwidth business. Carriers have to find ways to get high bandwidth signals across their networks while working within the restrictions of their transport technology, which requires a mapping scheme that multiplexes the VC-4 signals together to accommodate the higher bandwidth provided by the fat pipes. There are several techniques for doing that-some more efficient and cost-effective than others.
One way to transport these high bit rates is to use channelized interfaces, an approach offered by many IP and ATM vendors. Channelized transport allows routing through a network via different paths of independent VC-4 channels that are logically bundled together but reach the final destination on their own.
The large data stream (STM-N/OC-3N) emerging from a router is divided into multiple smaller streams of independent VC-4 channels that can be readily transported by the SONET/SDH network. These individual VC-4 signals can get to their destination by different routes. Weaving their way across possibly hundreds of domains, the signals are then reassembled at the destination router in the correct order.
Since channelized transport allows traffic through any established SONET/SDH network, this approach provides easy transport across multiple domains and simplifies transport planning. However, channelized transport also has disadvantages, notably degraded performance and higher equipment cost in the router. Total throughput is reduced because the IP routers must perform substantial number crunching in order to process the multiple data streams. The performance loss due to this internal processing is about 50%. Another issue is cost; the price for a channelized router interface is about three times higher than for a clear channel interface.
Channelized transport requires additional administration effort in the SONET/SDH network, because the channels have to be individually configured. Individual crossconnections also have to be established, with separate monitoring and management of the SONET/SDH signals. Thus, to achieve 4xVC-4, the SONET/SDH carrier has to configure and supervise four individual paths through the network (see Figure 1).
Multiple formats of contiguously concatenated VCs are defined in Inter national Telecommunications Union-Telecommunications (ITU-T) recommendation G.707 (eg., VC-4-4c, VC-4-l6c, VC-4-64c).
Contiguous concatenation aggregates multiple virtual containers within a high bandwidth clear channel. Four VC-4s contiguously concatenated would have a data rate of VC-4-4c. A concatenation indicator in the pointer associated with each concatenated frame indicates that the virtual container with which the pointers are associated is concatenated.
Unfortunately, contiguous concatenation is difficult to impossible in multicarrier topologies, because most of the installed base does not provide the clear channel transport required to support it. For a contiguously concatenated payload to pass through a network, a clear channel must be supported across all intermediate nodes.
Contiguous concatenation can only be used between operators with SONET/ SDH equipment supporting this technique (see Figure 2). Most carriers today lack the infrastructure to support clear channel traffic and use equipment limited to processing individual VC-4 signals. The installed base of crossconnects, add/drop multiplexers, and other SONET/SDH equipment stops at the VC-4 border. To implement contiguous concatenation in such networks would require extensive hardware upgrades-prohibitively expensive for most carriers.
Virtual concatenation offers a way to overcome this problem. This concatenation technique provides the SONET/SDH network elements at both ends of the signal path with the ability to send and receive individual VC-4s that are associated in a concatenated group. The cost of transporting the concatenated signal is confined to the upgrade costs at each end of the path, rather than upgrading the entire network to handle contiguously concatenated signals.
According to the ITU-T G.707 standard, virtual concatenation is equivalent to contiguous concatenation, but the intermediate transport is done using separate VC-4 channels. Virtual concatenation converts the clear channel signal into separate VC-4 channels for transport through the SONET/SDH network and vice versa on the receiving end. Upon reaching the destination, the channels are realigned and buffered inside special hardware, forming the clear channel again. Virtual concatenation maintains byte-level integrity identical to contiguous concatenation.
At the sending end, each virtual container is provided with information about its concatenated group identity and its position/sequence within the group, as well as destination information for processing in the intermediate nodes in the network. At the receiving end, the equipment identifies a VC-4 as belonging to a particular concatenated group and identifies its position/sequence within that group. Because of the likelihood of different propagation and processing delays for each of the individual VC-4s, the receiving end equipment provides buffers to store the incoming data until the latest VC-4 arrives, when realignment can be performed (see Figure 3).
New concatenation technology will allow SONET/SDH carriers to offer contiguous concatenation service using their current network equipment. The process involves conversion from contiguous concatenation to virtual concatenation to carry the traffic through the network and back again. The concatenation conversion occurs at the border of the network element.
The conversion is performed using a pair of interface cards, one at each end of the path where the service is needed. By providing virtual concatenation to route individual VC-4 data streams, carriers can support high bandwidth traffic while leaving their core hardware alone (see Figure 4).
Carriers with equipment that does not support contiguous concatenation can use this technique to allow their network to support the service. For a network operator or communications carrier, there is a dramatic price difference between upgrading for virtual concatenation at the borders and upgrading the entire SONET/SDH network to support contiguous concatenation. The latter would require buying all network equipment needed to support clear channel signals.
Virtual concatenation and concatenation conversion enable established SONET/SDH networks to offer clear channel service without paying for major infrastructure upgrades, allowing carriers to provide the type of high bandwidth transport service that their customers want.
Frank Kuhn is head of systems engineering for synchronous network solutions at Siemens Information and Communication Networks (ICN), located in Munich, Germany.