Advertisement
Articles
Advertisement

One network - All services

Sun, 06/01/2008 - 8:35am
Ben Legault,Director of Marketing, Ciena

Comparing SONET, ATM, RPR and OTN for network convergence.

There’s good news for all network architects: life is about to get very simple. Why? Services are all migrating to IP/Ethernet, and Ethernet transport technologies are being specified, developed and tested as we speak. So before we know it, our job will be as easy as building one big QoS-enabled all-Ethernet network with PBB-TE or MPLS-based technologies that will carry nothing but Ethernet-based services. Right?

Video requirements
Table 1: Video requirements.

Yes...but not anytime soon, unfortunately, because the migration of services to Ethernet will take quite some time. Any MSO developing a business services portfolio in addition to its residential triple play offering will need to build networks capable of handling circuit-switched services, video transport, storage area networking (SAN), and so on, for quite some time.

PARALLEL NETWORKS: EXPENSIVE
To date, practically no one has built a true converged network capable of handling all services. Sure, networks have been built over traditional DWDM systems where each service runs on a dedicated lambda, but we all know that’s not efficient.

So why build parallel networks? To answer this question, we first need to identify what should be expected from a converged infrastructure.

VIDEO TRANSPORT REQUIREMENTS
Because broadcast video traffic is sent as a complete digital channel line-up from a central site to all hubs, the perfect transport solution must provide unidirectional paths – to save unused upstream capacity – with drop and continue capabilities.

Separately, on-demand video content is transmitted as unicast streams that require an asymmetric transport solution with a relatively low bit-rate upstream path to transport signaling messages.

HSD and VoIP requirements
Table 2: HSD and VoIP requirements.

Finally, all video applications require strict QoS, and the option for protected paths for high-availability in both ring and mesh topologies.

These requirements are also important for VoIP and business services.

HSD AND VOIP REQUIREMENTS
Low latency, low jitter, low packet loss, protection, QoS, etc. are the usual suspects that we all know about (particularly for VoIP). In addition, these services drive the growing necessity for transport technology speeds to align with LAN technology speeds.

If the VoIP and Internet traffic is aggregated by high-performance edge devices based on 1 Gbps, 10 Gbps or 100 Gbps LAN interfaces, deploying a transport system capable of handling up to a full 1 Gig, 10 Gig or 100 Gig LAN PHY saves you an additional potential QoS problem. It allows you to shape and rate-limit at the edge and to maximize investments made in edge network elements.

BUSINESS SERVICES REQUIREMENTS
With the advent of circuit emulation, SONET infrastructure used for legacy TDM applications will eventually be replaced, but certainly not overnight. In addition, some large businesses own and operate SONET networks and expect their service provider to offer SONET as a service.Then comes what some identify as “high-end business services.” For the most part, the cable industry is currently focused on delivering high-speed Ethernets and T1s. This is what we know best, and it is without question a smart business strategy to start with these services. But do we really expect it will stop there? Unlikely.

Business needs
Table 3: Business needs.

Businesses of all sorts currently pay the telco incumbents hefty sums on a monthly basis for FICON, ESCON, Fibre Channel, ASI, SD-SDI, and HD-SDI services.

Clearly, we are not going to ignore this market forever, as the opportunity is there to leapfrog the incumbents’ service portfolio while mobilizing less capital.

MANAGEMENT REQUIREMENTS
Finally come the service management requirements. A common infrastructure carrying multiple services must not only offer QoS on a per service basis, but also the capability to manage and report on services individually.

Based on this basic set of requirements, which should be completed with additional requirements specific to your needs, we propose to compare the transport technologies at our disposal to identify if one can indeed support network convergence.

COMPARING TRANSPORT TECHNOLOGIES
Over the years, network architects have had a relatively limited set of transport technology options to build networks.
The short list can be summarized as: ATM, SONET/SDH, RPR and OTN. Table 5 summarizes how they compare in terms of the requirements we have identified. The comparisons are done strictly at the transport level and exclude the packet forwarding layers of transported services because they are identical across all four technologies.

SONET/SDH
SONET offers many great features in areas such as protection, availability, and its native support for circuit-switched services, but falls short on a few important fronts as an enabler for network convergence.

Service management
Table 4: Service management.

First – and ironically – it cannot carry SONET as a service because of incompatibilities in the communication channel and the fact that the entire digital hierarchy is processed at every hop.

In addition, SONET’s inability to transport a full 10 Gig LAN PHY, combined with its cumbersome multiplexing hierarchy, makes it an inefficient packet transport solution – not to mention that SONET’s evolution to 100 Gig is non-existent.

Finally, although uncompressed video, storage area networking and mainframe extension applications can be supported by SONET through GFP mappings, the solution faces cost challenges associated with the inefficient use of SONET bandwidth.

ATM
ATM’s cell-based transport system was specifically designed to enable the convergence of video, data and voice networks. Yet, very few MSOs have adopted this technology due to complexity, cost, and most of all, a misalignment with the long term trend of migration to packet switched networks.

Specifically related to the requirements identified above, ATM implementations suffer from the absence of credible “drop and continue” features. In addition, because it runs over SONET, it cannot transport SONET as a service, nor do its speeds align with LAN technologies. Finally, because implementations above 600 Mbps are impractical for cost reasons, ATM is not suitable for certain video transport, SAN and mainframe extension services.

RPR
RPR is interesting, as many SONET vendors have implemented RPR modules to allow MSOs to converge TDM and IP traffic onto a common infrastructure. In fact, RPR is an attractive option for MSOs in this regard.

On the other hand, being a packet-based transport technology, RPR cannot handle uncompressed video, SAN and mainframe extension applications. It also fails to provide support for mesh topologies and does not offer per-service management and reporting capabilities. In addition, although its QoS feature set offers a high-priority service class, all high-priority services are treated equal, failing to provide mechanisms to prevent high-priority services from stepping over each other.

comparison of transport technologies
Table 5: A comparison of transport technologies.

OTN
Also known as G.709 or “digital wrapper,” OTN is an ITU-T standard defined in 2001 as the next-generation SONET. OTN’s hierarchy is similar to SONET’s, but at a coarser granularity and with a simpler communication channel, effectively reducing complexity and cost. The OTN line speeds follow LAN technologies.

OTN can efficiently carry SONET/SDH, Ethernet, video, SAN and mainframe extension services, all multiplexed into a single lambda. It provides SONET-like protection in both ring and mesh topologies, and allows the creation of unidirectional, asymmetrical and symmetrical paths that support insert, drop and continue functions at each node, on a per service basis.

Each service is provided with strict QoS through the bandwidth hierarchy.

Finally, service management and reporting is offered on a per service basis, and OTN provides SONET-like OAM&P capabilities.

CONCLUSION
The road to a QoS-enabled, all-Ethernet network is clear, but will take time. Yet MSOs have an incentive to immediately converge their network infrastructure to reduce network costs and improve fiber usage efficiency. Network convergence for video, voice and data applications was not practical through traditional transport technologies such as SONET, ATM and RPR, because of their inability to support the requirements of existing services while also enabling the full suite of business services.

On the other hand, a relative newcomer, OTN, offers a rich feature set that can finally allow true network convergence. It provides cost-competitive advantages to its adopters, mainly in terms of fiber consumption and investments in network elements, while creating a transition path to an all-Ethernet infrastructure for any MSO wishing to build and operate a single infrastructure today.

E-mail: tsalman@ciena.com

Topics

Advertisement

Share This Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading