SONET/SDH, ATM, IP
How do new protocols for optimizing SONET affect and interoperate with existing network infrastructure-and which will survive?
MATT DREYER, MAYAN Networks
Standards make the world go 'round. We drive on the right side of the road. We signal before we turn. We stop for red lights. Adherence to standards allows us to get along in a very complex world. Tele- communications and data-networking standards have been taking shape for the past quarter-century and are now well defined and understood. These standards have allowed us to connect the entire planet to a communications infrastructure that hardly seemed possible just a decade ago.
SONET and SDH have been the traditional workhorse standards for shipping traffic across the metropolitan network for the past 15 years. While basic time-division multiplexing (TDM) services composed the majority of traffic volume in the metro five years ago, multiprotocol packet-based traffic now dominates.
Because of that, the most recent "holy grail" of metropolitan networking has been in optimizing legacy SONET and SDH transport networks to handle both voice and data traffic. As a result, equipment vendors have invented a slew of new technologies and protocols for optimizing SONET in the metro-all of which support varying degrees of interoperability with the existing network. SONET-lite, SONET-like, virtual-path (VP) ATM, passive optical networking (PON), and multilink point-to-point protocol are but a few of the new proposed technologies and protocols being promoted by vendors.
The standard Layer 1 protocol domestically in optical networking is SONET, and SDH is the overseas standard. Deployed in the 1990s and today at speeds of OC-3 (155 Mbits/sec), OC-12 (622 Mbits/sec), OC-48 (2.5 Gbits/sec), and OC-192 (10 Gbits/sec), SONET has become the de facto standard for metro optical networking.
SONET's original design was optimized for voice traffic and fundamentally based on DS-0 (64-kbit/sec) data channels. By aggregating DS-0 channels, DS-1 (24xDS-0) and DS-3 (28xDS-1) channels are created. These data rates correspond directly to end-user services of plain old telephone service, T-1, and T-3 lines. The DS-3 channel is converted to the optical STS-1 (52-Mbit/sec) carrier. Multiple STS-1s are aggregated into OC-3, OC-12, OC-48, and OC-192 channels, providing up to 10 Gbits/sec of transport bandwidth.Ring topologies with inherent redundancy and, in the event of a failure, 50-msec restoration time, are standard fare in SONET networks. That allows SONET networks to achieve "five-nines" reliability, translating to less than 5 minutes of downtime per year. Other features of SONET include defined bandwidth channels, in-band operations, administration, maintenance, and provisioning (OAM&P) via digital communications channel (DCC), and a common set of command-line interface commands collectively known as transcription language one (TL1). SONET has been so widely accepted in telecommunications that it is now an $8-billion industry.
All is well with SONET until we diverge from TDM voice and add data traffic into the mix. Ethernet, the most widely deployed data transport protocol, is available in increments of 10, 100, and 1,000 Mbits/sec and does not interface well with SONET (which is provisioned in increments of 1.5 and 51.84 Mbits/sec (see Figure 1). In fact, over 80% of potential transport bandwidth is wasted when mapping a 10-Mbit/sec Ethernet stream to an STS-1-the minimum required in traditional SONET deployments when data transfers of more than 1.5 Mbits/sec are necessary.
Because the volume of data traffic is deluging traditional SONET edge networks, many vendors have derived technologies to overcome the inherent mismatch between Ethernet and SONET in an effort to optimize SONET for data. Dozens of startup companies have been created, all with the singular goal of transporting data efficiently over fiber in the metro. Fantastic schemes have been fashioned to overcome the limitations of SONET as a data transport. Unfortunately, most include the fundamental flaw of failing to support the existing SONET infrastructure that has been deployed for the last decade.
SONET is very well defined, widely deployed in over 150,000 rings in North America alone, and well understood. Optimizing SONET for data transport is a major undertaking with a wide variety of solutions. These solutions range from modifying the SONET header to stripping out channel headers to concatenating virtual tributaries (VTs), and finally, to doing away with the format all together. To understand the obstacles in deploying next-generation SONET, it is necessary to take a close look at the alternatives.
"SONET-lite" implementations take various approaches to optimizing through reducing overhead in the SONET STS-1 frame (ANSI T1.105 standard) or reducing timing rigidity and jitter tolerance. The SONET frame overhead occupies 2.34 Mbits/sec or 4.5% of the bandwidth available in an STS-1. A large portion of this overhead is dedicated to bytes designated as DCC. The DCC bytes can be thought of as a control network within the network. DCC is used primarily for OAM&P functions, necessary to manage the services and equipment on the network.
Other header bytes are dedicated to uses such as framing, error detection, protection, and line quality. By eliminating portions of the ANSI-defined SONET header, additional bandwidth is made available for data transport at the cost of interoperability and manageability. Table 1 shows the framing format for various implementations of SONET.
The biggest shortcoming of SONET-lite is the lack of a widely supported standard. Ciena, Fujitsu, and others have all submitted competing contributions to the standards bodies. Each contribution varies widely in the modifications made to the ANSI T1.105 standard, and most modifications are so radical that they are disruptive to existing SONET deployments.
If a service provider were to add new SONET-lite nodes to an existing SONET ring, the DCC channel would be destroyed and the ability to remotely manage and provision other nodes would be lost. That would require salable time slots on the ring to be dedicated solely to management functions, or worse, external management networks would need to be built. External management networks create additional complexity and cost. Even deploying the same vendor's SONET-lite equipment into a SONET ring can disrupt DCC communications (see Figure 2). While suitable for greenfield installations, interoperability issues with existing infrastructure will exclude SONET-lite as a viable migration path for existing rings.
Adding further confusion is the term "SONET-like." Often referenced in terms of SONET-like restoration, there is no defined standard. Some implementations suggest that SONET-like restoration matches the 50 msec defined by the SONET standard. Others reduce restoration times to 5 msec and below. Some convolutions of SONET-like include ring architectures, framing bytes, and even optical wavelengths implementing the network.
VP ATM is another proposed solution for optimizing SONET for data transport. In VP ATM, the SONET header is left intact, but the VT paths that make up the internal structure of the SONET payload envelope are removed. This optimization yields a single channel that offers an STS-3c (155 Mbits/sec) worth of bandwidth for transporting ATM cells.
The downside of this approach is that the smallest unit of bandwidth that can be provisioned on the ring is an entire 155 Mbits/sec. A side effect is that by stripping out the VT structure, VP ATM cannot natively support T-carriers such as T1 and T3. Although that can be accomplished by circuit emulation service, it adds unnecessary complexity to the network.
An additional limitation of VP ATM is the relatively small ATM cell. With average Internet Protocol (IP) packet sizes climbing beyond the 48-byte payload capacity of an ATM cell, it becomes necessary to span packets across multiple cells. Cell spanning introduces more overhead, wasted bandwidth, and jitter into the network-all of which are undesirable.
PON was originally developed as a means to deliver fiber to end-user locations. There are a number of proprietary formats available, and the architecture, being end-user based, is almost always point-to-point. Vendors base their PON solutions on Ethernet, ATM, or a proprietary format. Lack of a widely adopted standard requires that a single vendor's equipment be deployed at every node on the network. Deficiencies of built-in redundancy and standards-based signaling make PON unsuitable as a migration platform for SONET.
Of the proposed optimizations to the SONET standard, virtual concatenation (VC) provides a robust solution for optimizing data transport. Utilizing multilink point-to-point protocol (ML-PPP), as defined in the ITU-T G.707 standard, VC specifies a method by which 1.5-Mbit/sec VT channels can be combined to yield aggregate bandwidth channels for transporting data (see Figure 3).
By increasing the granularity by which bandwidth can be provisioned, service providers can right-size the transport for the data traffic. This technique bonds SONET VTs in integer multiples (e.g., nx1.5 Mbits/sec) to create dynamically allocated bandwidth channels for transporting data. By doing so, SONET data transport efficiencies can reach more than 90%, compared to roughly 20% by SONET alone. VC with ML-PPP is already widely adopted and deployed for optimizing SONET for data. Enterprise class routers from Cisco Systems and others support ML-PPP, making interoperability and compatibility with Layer 3 data possible throughout the network.
Unlike other SONET derivatives, VC retains the full ANSI T1.105 feature set, including DCC channels for OAM&P and support for existing T-carrier services such as T1 and T3. Thus, mixed-vendor SONET rings are not only workable, but also desirable because a clean migration from TDM to IP can be done over time without having to upgrade the entire ring all at once. If a vendor also puts forth the effort to interoperate with legacy OAM&P functionality provided by several major vendors, a seamless migration path can be formed from TDM to IP.
It is clear that service providers have a wide range of choices in migrating their networks to support data. A number of solutions provide remarkable increases in efficiency, yet few are based on industry-approved standards.
Many intricate details must be considered carefully while designing a migration strategy. Is a single vendor's proprietary technology a viable solution? Will the technology scale as network demands change? Will the technology interoperate with both existing and future network standards? A look to the developing 10-Gigabit Ethernet standards offers a hint-it's based on SONET.
Matt Dreyer is market development manager at MAYAN Networks (San Jose, CA). He can be reached at [email protected].
SONET (ANSI T1.105)
Section overhead
A1 framing
A2 framing
B1 section BIP-8
D1-D3 section DCC
E1 orderwire
F1 section user channel
J0 section trace
Z0 section trace
Line overhead
B2 line BIP-8
D4-D12 line DCC
E2 orderwire
H1-H2 pointer
H3 pointer action byte
K1, K2 APS channel
M0 STS-1 line REI
M1 STS-N line REI
S1 synchronize messaging
Z1 growth
Z2 growth
STS path overhead
B3 path BIP-8
C2 STS path signal label
F2 path user channel
G1 path status
H4 multiframe indicator
J1 STS path trace
N1 tandem connection
Z3-Z4 growth
VT path overhead
J2 VT path trace
V5
Z6 VT path growth
Z7 VT path growth
VT line overhead
M1 line quality
S1 synchronization message
SONET-lite Metro (Fujitsu)
J1 trace
B3 BIP-8
C2 signal label
G1 path status
F2 user channel
H4 indicator
Z3 growth
Z4 growth
Z5 tandem connection
SONET-lite (Ciena)
J0 protocol
B1 parity byte
B2 parity byte