Blank

The base SONET frame is called STS-1 (Synchronous Transport Signal 1), which is the SONET standard for transmission over OC-1 optical fiber at 51.84 Mbps. For many applications that rate works just fine. But quite often other data rates are desired, such as:

VT (Virtual Tributary) – compared to traditional telecom circuits such as the DS0, and T1, an STS-1 is a very high speed. In many cases, the end user does not need such a high data rate, but they still want to purchase an STS-1 because they have multiple channels at lower data rates. For these cases it is desired to break up the STS-1 into multiple “sub STS-1” channels. The VT is a sub-STS-1 rate - similar to the channels, or time slots in a channelized circuit such as 28 DS1’s within 1 DS3. They are “tributaries”, like small streams that eventually combine to form the river, which is the STS-1.

*** other than the base SONET data rates (STS-1 on an OC-1 carrier), almost ALL SONET (STS-3, OC-3 and up) and SDH (STM-1 and up) data rate streams are concatenated !!!

Channelized Data Streams (STS-n, or OC-n – see NOTE) – “non-concatenated” - this is the default configuration, by the nomenclature – although it is rarely used (the vast majority of STS-n signals are actually STS-nc, concantenated). But for multiple STS-1 where it is desired that they remain separate, distinct streams of data - an STS-3 can be used, which is three STS-1 channelized signals (similar to the way a channelized DS3 is 28 DS1 signals). The receiving station then de-multiplexes them.

Concatenated Data Strems (STS-nc, or OC-nc - see NOTE) – “unchannelized” - for a higher data rate using an unchannelized signal, an STS-1c (STS-1 concatenated) signal can be used, which is also three STS-1 signals, but they are viewed at the endpoints as a single stream of data at a rate of OC3.

NOTE: the naming of SONET speeds is very confusing for many people. By default, the SONET acronyms without a “c”, such as STS-3, refers to a “non-concatenated” signal. Only when the “c” is present is the signal concatenated. The majority of the telecom customers purchase concatenated services, yet they rarely know that they should specify “c” at the end of the acronym. The vast majority of customers that order an OC3 want a simple, single stream of data at 155.52 Mbps. But they enter “OC3” on the order form, which is actually three OC1 streams !!! They should enter “OC3c” on the order form. Fortunately, the telecom providers are aware of this and give them a concatenated OC3 anyway. Unfortunately this causes the reverse problem for the more educated customers that actuall want an OC3 (non-concatenated, or “channelized”). They correctly enter “OC3” on the order form and are given an OC3c !!!

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.

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.

Virtual Tributary Type	Data Rate (Mega-bits per sec)	Columns used in the 90-column STS-1	Commonly Used for
VT1.5	1.728	3	T1 (1.536 M)
VT2	2.304	4	E1 (2.048 M)
VT3	3.456	6	DS1c (3.152 M)
VT6	6.912	12	DS2 (6.312 M)

The different size tributary options are provided to maximize available bandwidth in an STS-1 channel. Note: lower-rate end user services must first be mapped into the appropriate virtual tributary container to handle rate and format discrepancies prior to insertion into the Sonet frame.

The path overhead and payload data together form what is called the VT SPE (synchronous payload envelope).

With a standard STS-1, the SPE is used in it’s entirety. But whenever any VT’s are used, the SPE is subdivided into seven, 12 column groups for a total of 84 columns. This means that of the 86 user data columns, 2 columns are not used – these are columns 30 and 59 and are called “fixed stuff” (odd name – but they really have no function), or just “stuff” since they are analogous to “stuff bits” (a term from the T-carrier system).

As shown below, the payload columns are physically divided into 3 groups of 28, even though functionally they are used as seven groups of 12 columns. It is important to note that the stuff columns are columns 29 and 59 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.

NOTE: this diagram has columns that are numbered using SPE as a base structure. However, the STS-1 frames have their own numbering for their own columns, which the SPE is a part of – and the STS-1 column for the first byte of the SPE will rarely be column 1 !!! Remember that the SPE has an offset within the STS-1 frame which is starts at the byte just to the right of the H3 pointer byte.

The groups of 12 columns can be broken down further. For example, “VT 1.5” uses 3 columns, which will give you a data rate of 3/90 * 51.85 = 1.728 Mbps. This data rate fits a T1 into it quite nicely, with just a bit of leftover capacity.

Here it gets very complex, and for most people the only thing you need to know is that the VT’s are structured as byte-interleaved groups each with it’s own pointer.

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.

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

Creating dynamic bandwidth channels for data by bonding multiple SONET VT1.5s into a single virtual data channel. This second technique is actually a combination of Layer 1 and 2. ML-PPP (Multilink Point-to-Point Protocol) or IMA (inverse multiplexing) is used to virtually bond SONET VT1.5s in integer multiples to create virtual pipes that lay inside larger SONET STS-1 pipes in the transport network. The net effect is that bandwidth can be allocated dynamically and efficiently to map incoming packet traffic onto SONET transport. Figure 2 shows a 10-Mb Ethernet stream mapped into a virtual 7 VT1.5 ML-PPP bundle that will eventually get mapped onto a part of a SONET STS-1 with other traffic bundles. Because ML-PPP and IMA are industry standard bonding techniques, you don't need the same edge device at the other end of the network to reassemble the traffic. This feature effectively solves the SONET bandwidth granularity problem, making SONET efficient for data as well as voice.

Most of today's high-margin, packet-based services rely on Layer 2 protocols and switching. To illustrate some of the Layer 2 features found on the data sheets of these emerging edge platforms, consider a typical frame relay network utilizing fractional T1 leased lines for local access.

A basic frame relay network is illustrated in Figure 3. In this network, 12 users access the frame network using on-site FRADs (frame relay access devices), which connect to leased lines. These terminate onto a metro access device, such as a SONET ADM, which grooms traffic onto the metro transport network. On the other side of the metro transport network, the circuits terminate on another ADM (typically in a CO), which finally terminates on a frame relay switch. There are two major problems with this scenario in Layer 1 alone. Both can be addressed with the enhanced switching intelligence described in the previous section. First, when an individual fractional T1 is transported from the FRAD to the CO through the metro transport network, it occupies an entire SONET VT1.5 because the ADM doesn't have visibility into the actual payload coming into the T1 port. In this example, 128 kbps out of a potential 1.5 Mbps is actually being utilized, wasting a significant amount of bandwidth. If this were an OC-3 ring, the ring would already be 100 percent utilized by just these 12 low-bandwidth users. The second issue is that each fractional T1 circuit occupies an entire physical T1 port on the core frame relay switch, as well as an entire T1 port on both SONET ADMs. This is a tremendous waste of resources.

Figure 4 depicts the same network using an intelligent metro edge device. The 12 128-kb fractional T1s originating from the user have now been groomed into a single VT1.5 as they are transported through the metro transport network. As a result, the number of T1 frame relay switch ports and ADM switch ports required at the CO has decreased to one. In this example, the service provider has increased bandwidth utilization from roughly 8 percent to well over 90 percent, in addition to saving physical switch ports.

If the edge device has Layer 2 frame relay switching capability, the need for on-site FRADs disappears. The service provider can now provision either fractional T1s or native Ethernet connections to the users. This reduces complexity and cost, eases provisioning and simplifies network management. For the competitive carrier that needs to provision services rapidly, this is an ideal feature because it need not rely on the incumbent service provider to provision local access circuits.

Additionally, if the edge device can oversubscribe traffic at Layer 2 or 3, the carrier can offer differentiated classes of service, all controlled from the metro edge rather than the metro core. This saves a tremendous amount of transport bandwidth, especially for services with high over-subscription ratios, such as 4:1 and 8:1.

Many emerging metro platforms support various Layer 3 switching features. Generally speaking, the features fall into three camps: support of interior routing protocols, support of exterior routing protocols, and support of advanced IP services, such as NAT (network address translation) and VPN tunneling.

Platforms that support interior routing protocols such as RIP (Routing Information Protocol) and OSPF (open shortest path first), allow the edge device to be used in place of a classic enterprise router. The device can sit in the basement of a building and the service provider can offer fully managed IP services without having to physically manage each customer's router on-site. Alternatively, customers that don't want a fully managed service can still communicate with the edge device at Layer 3.

Platforms that support exterior routing protocols such as BGP4 (Border Gateway Protocol), which essentially allows exchange of information between networks, allow the service provider to extend its routing model beyond serving the enterprise. This is an especially important feature for service providers that conduct a fair amount of POP-to-POP communication.

Finally, many platforms boast enhanced IP-based services, which can be of tremendous value to service providers searching for ways to differentiate themselves from the competition. Examples of enhanced IP-based features include:

 NAT, which allows basic firewall functionality by hiding customers' private IP addresses from the outside world.

 Tunneling protocols, such as IPSec, which allow the service provider to offer encrypted VPN services.

 Usage-based billing, which allows the service provider to meter and charge for bandwidth.

 Support for MPLS (multiprotocol label switching), which is a front-runner in the race to optimize IP for latency and jitter-sensitive applications. While arguably a Layer 2 link control protocol, MPLS boasts the ability to perform many of the same traffic-shaping functions as ATM, but without the ATM cell tax.

Layer 4 switching utilizes information in the Layer 3 and Layer 4 packet headers to make forwarding decisions based on session and application-layer information. In essence, Layer 4 switching allows a more sophisticated way of differentiating and prioritizing traffic flows. While service providers are creating their own ways to use Layer 4 switching to create service types, Layer 4 switching is commonly used to perform server load-balancing functions in large corporate data centers, or by ISPs and content providers. The technology is also useful where replication across many physical servers is required, for example in data mirroring. This functionality will become an increasingly important feature in edge platforms, as the need to control traffic closer to the user grows more and more acute.

The profile and dynamics of traffic at the edge of metropolitan networks have experienced radical change in the past few years. But while data traffic is eclipsing voice in quantity, voice still provides a majority of revenues. This phenomenon presents one of the most significant challenges facing service providers today: how to capitalize on emerging packet-based services, while continuing to support high-margin TDM voice as well. A new class of metro on-ramp, the multiservice provisioning platform, is allowing service providers to make this transition by pushing switching intelligence from the core straight to the edge of the metropolitan network. Through an array of Layer 1, 2, 3 and 4 switching technologies, service providers can now utilize their existing metro networks to handle multiprotocol data, as well as TDM voice, and evolve these networks with confidence toward the IP-based future. *

In OC3c and OC12c, the "c" means concatenated. A lot of people mistake this for channelized. The opposite is true:

*** an OC3 is channelized – it consists of three STS1 channels. So, Just as a DS1 = 24 DS0’s and a DS3 = 28 DS1’s, an OC3 = 3 OC-1’s = 3 STS-1’s

Optical Carrier	Data Rate	SONET	SDH
OC-1	51.84 Mbit/s	STS-1	--
OC-3, OC3c	155.52 Mbit/s	STS-3	STM-1

DS1 and DS3 are ALWAYS TRANSMITTED IN CHANNELIZED FORM. They do not have a “c” (concatenated) version. They are always transmitted in the T-carrier format, which is channelized. But there is such a thing as “unchannelized” DS1 and DS3. The method used for unchannelized DS3 is for the equipment at the endpoints to combine the channelized, transmitted, 28 DS1’s together into one data stream.

However, OC3 does have a “c” (concatenated) version. Therefore is can be transmitted in either channelized (OC3) or unchannelized (OC3c - concatenated) form.

Can’t we combine the 3 OC1 channels in an OC3 ? Yes, but unless you plan on using the OC1’s separately, or have existing equipment that will only work with standard OC3 (and you don’t want to pay to upgrade), then use OC3c. The OC3, which contains 3 byte-interleaved OC1 TDM channels, can have all 3 channels combined into one data stream at the receiving end. But in the vast majority of cases, there is no need to transmit 3 separate OC1’s – in other-words, use OC3c !!!

This differs for the lower, DS3 speed. For DS3 it is necessary to combine channels at the endpoints for an unchannelized stream of data, since no DS3c exists. For DS3 the data can be unchannelized at the endpoints, but is always transmitted as channelized data through the transmission path. But with OC3 there is a concatenated version available, OC3c - so you may as well use that instead of having to use three separate data channels and then combining them at the endpoint.

Remember, OC3c (OC3 concatenated) is unchannelized !!! With an OC3c the entire payload is a single channel. OC-3 is a byte interleaved (3 x OC-1) Frame Structure, but OC-3c has Big One Frame(Frame Structure is similar to STM-1).

Usually, most customers use OC3c – and the few true OC3 circuits are are the telcos – for mux/demuxing on DACS' and OC switches.

Why people leave off the “c” - when dealing with ATM switches and other data equipment, most people forget to include the "c" as they should, even though almost all data equipment uses concatenated fiber interfaces. In fact, it has almost become convention to forget about the "c". However, it is still incorrect to not use the "c" if you are not dealing with channelized fiber interfaces. In fact, many people have been working with *OC3c* for years and still call them OC3.

In the ATM world people often leave off the "c" that should be there. Almost certainly, whatever goes into your ATM port is a single channel, not anything muxed. (Yes, it could be, but it very rarely is; channelized ATM NICs are rare at best.) So the correct way to talk about your 155 Mb/s ATM port is "OC-3c" but most of the time the "c" will just get you blank stares and the inaccurate term "OC-3" is used instead.

NOTE: if a customer really has a true OC3 (not "c") interface, they could configure up to 3 separate logical interfaces, just like they could with channelized T-carrier links.

Can you Mix OC3 and OC3c ?? No, you cannot connect together an OC3 with an OC3c, any more than you can connect a channelized DS3 interface to a non-channelized DS3 interface. Both ends need to agree on the framing structure of the physical link. You will probably get the link "up" but not much more than that (no data).