Understanding Sonet VTs: A Tutorial

Virtual tributaries (VTs) are commonly used for grooming applications where sub STS-1 level signals are generated from a number of sources operating at various rates and combined into a higher-speed, channelized data pipe. Some end users, for example, may demand T1 rate services of 1.544-Mbit/s mapped into VT1.5 virtual tributary types while others may require an E1 rate service of 2.048 Mbit/s mapped into a VT2 virtual tributary type.

This article will look inside Sonet and focus on VT management and processing during transport through the network. Operations such as interleaving, pointer processing, tributary alignment for switching, overhead processing, and support for protection mechanisms including unidirectional path switched rings (UPSR) will be discussed. Finally, a virtual tributary switch application will be provided to tie in all the concepts discussed.

What is a Virtual Tributary?
A virtual tributary is a structure used for the transport of low rate sub-STS-1 synchronous signals. Virtual tributary information is organized inside an STS-1 channel of Sonet frames and routed through the network to a specified destination from a given source location.

There are four types (VT1.5, VT2, VT3, VT6) or sizes of virtual tributaries defined for Sonet. A VT1.5 has the lowest payload capacity with a data rate of 1.728 Mbit/s. Progressing in size, a VT2 has a data rate of 2.304 Mbit/s, a VT3 operates at 3.456 Mbit/s, and a VT6 offers a data rate of 6.912 Mbit/s.

The different size tributary options are provided to maximize available bandwidth in an STS-1 channel. For example, if the end user requires the transport of DS-1C signals requiring 3.152 Mbit/s, a virtual tributary VT3 size would be the ideal solution as opposed to a VT6 size that provides much more bandwidth than what is needed. Other common low rate signals such as DS1, E1, and DS2 fit into virtual tributary types VT1.5, VT2, and VT6, respectively. As a note, lower-rate end user services must be mapped into the appropriate virtual tributary container to handle rate and format discrepancies prior to insertion into the Sonet frame.

The virtual tributary structure contains three main components consisting of the payload pointer (VT payload pointer), path overhead (VT POH), and payload data bytes. The path overhead and payload data together form what is called the VT synchronous payload envelope (SPE).

Each virtual tributary type has a unique VT SPE size. Although the number of payload bytes in the VT SPE differs for each virtual tributary size, the number of VT POH bytes and functionality of each is the same regardless of the VT type.

As shown in Figure 1, there are four VT POH bytes contained in any VT structure separated by a fixed number of payload bytes. The first byte of the VT SPE is always the V5 VT POH byte. V5 is used to provide tributary BIP-2 parity (provides error performance monitoring through bit interleaved parity over previous VT SPE odd and even bits), REI-V (remote error indication used to indicate BIP-2 errors at originating equipment), RFI-V (remote failure indication), signal label (indicates content of VT SPE), and RDI-V (remote defect indication) information.

The J2 VT POH byte is a VT path trace identifier used to transmit a repetitive fixed length message (typically 16 or 64 bytes in sequence length). In order to transmit the complete J2 message specified, a number of VTs equal to the trace message length must be sequentially transmitted since each VT SPE is only capable of transmitting a single byte of the required J2 message. Support for low-order tandem connection monitoring is provided through the use of the Z6 VT POH byte. The Z7 VT POH byte is used to enable APS signaling and extended RDI (ERDI) capability.

A VT payload pointer for each individual virtual tributary in the frame is provided to locate the start of the VT SPE, or tributary path overhead V5 byte. The VT payload pointer allows for movement of tributaries in the VT SPE cavity by providing pointer increment, decrement, and NDF functionality similar to the operation of Sonet H1/H2/H3 pointer bytes. There are four VT pointer bytes (V1, V2, V3, and V4) allocated for each tributary type. A more detailed discussion of VT pointer bytes is provided below.

Assembly of VTs
A Sonet STS-1 rate frame contains nine rows and 90 columns or 810 bytes of information as shown in Figure 2. The first 3 columns in the frame are made up of transport overhead, which includes a channel level pointer (H1/H2 bytes) that indicates where the STS-1 SPE begins (denoted by J1 byte of path overhead).

The H1/H2 pointer value used in Figure 2 is 522 (row 1, column 4). The STS-1 frame SPE contains 87 columns (90 columns minus three columns of transport overhead). A single column of STS-1 Path Overhead is subtracted from the SPE resulting in an STS-1 SPE payload capacity of 86 columns.

The VT structure shown in Figure 2 is transported in the Sonet STS-1 frame SPE payload region. Prior to insertion into the Sonet frame, virtual tributaries are arranged into seven virtual tributary groups (VTGs) and interleaved using an alternating tributary/group sequence. As shown in Figure 2, the seven VTG's are all a fixed size of 432 bytes.

An important point to remember is that each VTG must be configured for a single virtual tributary type. Applying the size of the various tributary structures shown in Figure 1 with the addition of the four VT pointer bytes for each tributary, it is easy to see that a single VTG can contain a single VT6, two VT3s, three VT2s, or four VT1.5s. A VTG configured for a single VT6 type, for example, would contain 428 bytes of VT SPE and 4 bytes of VT pointer. Likewise, a VTG configured for VT1.5s would contain four VT1.5 virtual tributary types each containing 104 bytes of VT SPE and 4 bytes of VT pointer overhead.

A VTG configured for VT1.5, VT2, or VT3 tributaries are interleaved in turn to form the VTG. For example, a VTG configured for VT1.5s would be constructed by following the repetitive sequence of taking a byte from VT1.5 tributary #1, then a byte from VT1.5 tributary #2, then a byte from VT1.5 tributary #3, and finally a byte from VT1.5 tributary #4. Once all the seven independent VTGs are constructed, they are alternately inserted into the Sonet frame payload area (see Figure 2) in a similar way the tributaries are built in the VTG. The repeating sequence of taking a single byte each from VTG#1-VTG#2-VTG#3-VTG#4-VTG#5-VTG#6-VTG#7 in turn is used until the entire 432 byte sequence for each VTG is transmitted.

The payload capacity required to transmit the entire seven VTG sequence described above is four Sonet frames (see Figure 2). This four-frame sequence is often referred to as a VT superframe or multiframe.

The Sonet STS-1 SPE path overhead (POH) H4 byte least significant 2 bits are used as a multiframe indicator to identify the number of the next SONET frame in the multiframe sequence. The H4 multiframe sequence indicator continuously cycles from "00" (identifies first SONET frame in multiframe sequence) to "11" (identifies last SONET frame in multiframe sequence). In Figure 2 above, the first Sonet STS-1 frame shown has the least significant 2 bits of the H4 byte set to a value of "01" indicating that the next Sonet frame is the second frame of the multiframe sequence.

The payload carrying capacity of an STS-1 SPE is 774 bytes (86 columns x 9 rows x 1 byte) per Sonet frame. This is slightly more than the 756 bytes (108 bytes/VTG * 7 VTG's) per frame required for the transport of the 7 VTGs carrying virtual tributaries. The difference in the STS-1 payload area and the tributary information per Sonet frame time is 18 bytes or 2 columns worth of data bytes.

The Sonet standard specifies that this difference of 18 bytes be allocated as stuff bytes (x00 hex) located in VT SPE columns 29 and 58. It is important to note that the stuff columns are located 29 and 58 columns from the start of the VT SPE and are not specified as fixed columns in the STS-1 frame structure. The start of the VT SPE in the Sonet STS-1 frame will vary depending on the VT pointer value chosen.

A virtual tributary data rate can be calculated as the number of tributary bytes transported for each Sonet frame multiplied by the STS-1 frame data rate. A total of 108 VT6 tributary bytes (432 bytes per multiframe/4), for example, are transmitted per Sonet frame (810 bytes). Using the SONET STS-1 frame data rate of 51.84 Mbit/s [(810 bytes*8 bits/byte)/125μs] the VT6 tributary data rate is calculated as 6.912 Mbit/s (108 VT6 tributary bytes/810 STS-1 bytes times 51.84 Mbit/s).

Pointer Processing
As stated previously, each virtual tributary contains four pointer overhead bytes that are referred to as V1, V2, V3, and V4. V1 and V2 are used to specify a 10-bit tributary pointer, 2-bit VT size (set to "00" for Sonet), and a 4-bit new data flag (NDF) field. The VT pointer range specified by V1 and V2 is defined according to the type of virtual tributary transported.

Pointer Range: 0-103 (VT1.5 type)
Pointer Range: 0-139 (VT2 type)
Pointer Range: 0-211 (VT3 type)
Pointer Range: 0-427 (VT6 type)

The V3 pointer overhead byte provides a negative justification opportunity and will be filled with VT SPE information for this condition only. V3 is assigned a value of x00 (hex) when a negative justification is not required. The final VT pointer overhead byte, V4, is reserved. The four VT pointer overhead bytes are not considered part of the VT SPE except for the special case of a negative justification when a byte of VT SPE is present in the pointer V3 location.

One VT pointer byte for each tributary will be transmitted in every Sonet STS-1 frame. As with the VT SPE, it takes the complete multiframe sequence to transmit all four VT pointer bytes. The multiframe identifier is an indicator of which VT pointer overhead byte will be present within the SONET frame. If the current multiframe sequence indicator is "00", V1 pointer overhead will be present in the SONET frame. Likewise the V2 byte will occur for multiframe indicator "01", V3 for "10", and finally V4 for multiframe sequence indicator "11".

The VT pointer overhead bytes are always located within the first 28 columns or byte locations immediately following the STS-1 path overhead J1 byte each frame. If all seven VTGs in the STS-1 frame are configured for VT1.5s (4 VT1.5's per VTG), a full 28 columns of VT pointer overhead is required each frame. If, however, all VTGs are configured for VT6s (1 VT6 per VTG), only seven columns of VT pointer overhead are required each SONET frame.

The case of all VTGs configured for VT6 tributaries is shown in Figure 3. In this case, the locations for all 428 (0 to 427) VT6 pointer locations are identified. A VT pointer value of 117 for each VT6 in all 7 VTGs (specified by V1/V2 bytes) is assumed which implies that the start of the VT SPE (V5 byte) for all VT6 tributaries will be located in the byte position identified. As shown in Figure 3, the byte following the V2 VT pointer overhead byte is always VT pointer location 0.

VT Switch Application
A typical application for virtual tributaries is a switch configuration used to route user services such as DS1, T1, and E1 signals to/from various locations in a system. In Figure 4, a series of line cards are plugged into a telecom bus backplane where lower level tributaries are routed through the use of a VT switch.

The OC-12 linecard accepts 622.08-Mbit/s optical data in the ingress direction and converts it into an electrical STS-12 signal. This signal enters the STS-12 framer where transport overhead processing occurs along with channelized (STS-1 level) pointer processing necessary to generate telecom bus signaling required for VT processor operations.

The VT processor has the primary function of aligning incoming virtual tributaries, monitoring error statistics, interpreting overhead bytes, and generating VT-level UPSR information required for switching. UPSR information generated is generally a code word indicating conditions such as virtual tributary alarm indication signal (AIS-V), loss of pointer (LOP-V), path signal label unequipped (UNEQ-V), trace identifier mismatch (TIM-V), path signal label mismatch (PLM-V), signal fail (SF), and signal degrade (SD).

In the egress direction, VT information comes off the switch telecom bus interface and enters the STS-12 framer where channelized pointers are generated along with transport overhead information prior to conversion into an optical OC-12 signal. STS-12 framer functions include the generation of section and line parity, trace message insertion, automatic protection switching (APS) coding, and scrambling.

Wrap Up
The use of virtual tributaries for transporting low rate sub STS-1 signals is widespread and not only deployed in existing network elements but is also planned for future use. Virtual tributary rates specified allow for the transport of data rates from 1.728 to 6.912 Mbit/s, allowing for maximum bandwidth utilization of user services ranging from T1 (VT1.5) to T2 (VT6) signals. Virtual tributaries are no doubt here to stay for quite some time.

About the Author
Doug Bush is the director of IP development at Xelic. Doug holds a Bachelor of Science degree in Electrical Engineering from Rochester Institute of Technology and a Master of Science from the University of Maine. He can be reached at bush@xelic-inc.com