Next-generation framer/mappers

Next-generation framer/mapper devices are driving network transport efficiencies, says Deepak Sharma, Marketing Manager at Cypress Semiconductor.

Every day, we asked to do more with less by our bosses, our companies and our customers.

This requirement is particularly evident in the task of moving data across a transport infrastructure in an optimal, cost-efficient manner.

The original transport network was based on a simple "configure and forget" rule.

It relied on Sonet/SDH TDM (time division multiplexing) capabilities.

But the shift to packet-based transport requirements has forced the industry to develop new standards and architectures.

This, in turn, has resulted in the evolution of framer/mapper chips at the physical-layer level to provide a way to use the existing transport network more efficiently for data services.

Today, the transport network must work efficiently with both voice and data.

But the unpredictable or "bursty" nature of data traffic is not ideally suited for transport over an existing TDM channel.

If a designer creates a TDM channel that can handle the maximum data rate coming in, the link is underused most of the time.

On the other hand, if they create a TDM channel based on average rate, then packets might be dropped when a critical burst comes through.

Another wrinkle is the proliferation of data transport protocols, such as Ethernet, Fibre Channel (FC), Escon, DVB and Ficon along with the need to move them transparently across the WAN.

For example, if a corporation with headquarters in Los Angeles wants to back up its data in Texas and transport it across the network via FC, from a deployment perspective, it needs: a flexible-bandwidth mechanism to adapt the Sonet/SDH channels to the data being transported over them; a mechanism to flexibly and, ideally, dynamically change the bandwidth of the Sonet/SDH channels configured across the network; and an efficient means of mapping multiprotocol data onto Sonet/SDH channels.

Although there are some new and exciting technologies such as 10GbE over fibre with the potential to meet these requirements, most vendors remain focused on increasing the efficiency and flexibility of the existing infrastructure.

(There is more than $200 billion of Sonet/SDH equipment deployed to date).

We will look at three key standards that achieve this goal.

Virtual concatenation [1][2] is an inverse multiplexing technique that enables an arbitrary number of Sonet/SDH channels to be combined into a single, byte-synchronous stream.

In other words, it allows an arbitrary number of either low-order (VC-12 or VC-3 in SDH, or VT1.5 in Sonet) or high-order (VC-4 in SDH or STS1/STS3c/STS12c in Sonet) channels to be "logically" combined into a single channel.

This channel can be routed independently through the network.

This implies that only the source and the destination nodes need to be VC-capable, the protocol itself is transparent to intermediate nodes.

A single OC48/STM-16 frame can be used to transport one GbE, one FC, one DVB and one Fast Ethernet packet, all at the same time.

As the constituent STS channels of a virtually concatenated group (VCG) can traverse different routes in a network, arriving at the destination node at different times (differential delay), the standard has a mechanism to account for this delay at the receiving node, using the standard path overhead (POH) bytes in Sonet/SDH frames.

Ultimately, virtual concatenation allows for efficient bandwidth allocation of multiple protocols, per their requirements.

A carrier can now provide value-added services, such as lower-rate Ethernet transport services, in a cost-efficient manner and without adding capacity.

In addition, it allows a carrier to recover "stranded" bandwidth from the network.

Small groups of STS channels between two nodes that could not otherwise be used can now be virtually concatenated to carry high-bandwidth data.

In fact, virtual concatenation enables carriers to provide customers with "bandwidth on demand".

For example, in Ethernet services, SLAs are often written with explicit CIR (committed information rate) and PIR (peak information rate) instructions.

Let's say a customer has a CIR of 300Mbit/s with a PIR of 1Gbit/s (GbE).

A carrier could set up a VCG using STS1-6v/VC3-6v or VC4-2v in an OC-48 stream.

The remaining bandwidth could be used for other traffic (low-priority in this example).

If the system needed to handle a burst of 1Gbit/s, the carrier would be required to bump up the 300Mbit/s to 1Gbit/s - or to "dynamically" change from STS1-6v/VC3-6v or VC4-2v to STS1-21v/VC3-21v or VC4-7v.

Today, this would require bringing down the whole node, reconfiguring the channels and bringing it up again.

In some cases, it might even require a technician to go out to the field to reconfigure other elements in the network.

The LCAS link capacity adjustment scheme [4] standard will solve this problem in the future.

LCAS is a dynamic, end-to-end "handshake" mechanism that allows the source and destination framers to coordinate the addition or deletion of a channel from a group of virtually concatenated channels.

LCAS assumes that the required additional channels - and the construction of an end-to-end path - are done either by a management- or distributed-control plane, or that the path already exists in the network.

Using LCAS intelligently, carriers can allow incremental bandwidth increases to match the abilities of native Ethernet service providers.

With VC and LCAS, we can use bandwidth efficiently and change it dynamically.

The last step is finding a way to efficiently map multiple protocols into a Sonet/SDH frame.

Although PoS and ATM have been used for transporting data over Sonet/SDH, neither is considered to be best for packet data in terms of bandwidth efficiency and high-speed processing capability.

PoS uses HDLC, which suffers from bandwidth expansion based on data patterns, and ATM has a "cell tax" that consumes at minimum an extra 10% of the bandwidth.

Further, single-bit errors in HDLC often cause the misidentification of frame boundaries; corrupt frames cannot be mended at the receiver and all corrupted frames are dropped.

Lastly, ATM is more than just a client-adaptation solution - it supports QoS, traffic engineering and a host of switching, multiplexing and networking functions.

As such, ATM may be overkill for a simple point-to-point traffic transport.

The answer is the GFP generic framing procedure [4].

GFP enables mapping of any data type to a Sonet/SDH byte synchronous channel.

It provides a highly flexible encapsulation that supports both fixed and variable length frames.

There are two types of GFP modes - framed GFP (a PDU-oriented adaptation mode for variable-length packets, such as Ethernet, IP, RPR) and transparent GFP (a block-code-oriented adaptation mode for storage protocols such as Ficon, Fibre Channel and Escon).

In transparent GFP, block-coded client characters that are decoded and mapped into a GFP frame may be transmitted at once without waiting for the entire client data packet.

This is useful for low-latency protocols in the LAN and SAN space.

So how do GFP, virtual concatenation and LCAS fit together? GFP allows a designer to create a flexible and versatile transport infrastructure, while virtual concatenation and LCAS add elasticity to it.

By enabling a common mechanism to efficiently map multiple protocols into Sonet/SDH streams, GFP and VC enable carriers to differentiate their services and extract more revenue.

At the same time, LCAS optimises the existing infrastructure, resulting in reduced capital and operational expenditures.

The development of these new standards has led to a new breed of framer/mapper products in the marketplace.

The first framers to hit the market were straightforward TDM framers.

They came in either concatenated or channelised versions.

As data services grew, the next step was higher speeds and PoS functionalities.

This led to encapsulation protocols such as HDLC/PPP, LAPS, and even to ATM cell delineation.

Today's framer/mapper products need to support GFP, VC, and LCAS.

In other words, next-generation Sonet/SDH framers and mappers are trying to connect the Sonet/SDH world to the data world in a transparent and efficient manner.

The functions required can be broken down into two major blocks: network interface and client interface.

The network-interface block implements new standards (GFP, VC, LCAS), whereas the client-interface block manages data traffic and implements CoS and QoS features to provide a Layer 2 networking solution.

The client block will also handle the specific requirements of different protocols, such as providing buffer-to-buffer credit management for Fibre Channel or oversubscription capabilities for Ethernet services.

In response to these new requirements, vendors are launching a variety of framer/mapper products.

Each vendor has its own solution.

Some follow a flexible/modular chipset approach.

In this case, the network interface block is a backplane data mapper supporting GFP, VC and LCAS, whereas the client interface block is a protocol-specific IC, such as an FPGA or ASSP.

This concept is ideal for multiservice provisioning platforms (MSPPs).

Framer/mappers are used on the backplane of the tributary cards to hook up with a crossconnect.

The tributary cards provide specific services, such as Ethernet, storage and video.

Each of the tributary cards will have a framer/mapper that supports GFP, VC and LCAS.

They encapsulate the incoming data stream into GFP and create a "right sized" channel using VC.

The channel is transported across the backplane to a crossconnect that will then send the physical channels to a line interface card.

The trick in this architecture is to use a common network interface chip across all the tributary cards and a different client-interface chip based on the protocol.

The advantage is to provide a way to create scalable multifunction linecards with reduced design cycle time and complexity.

Furthermore, a chipset approach allows OEMs to differentiate their solution with custom or proprietary technology.

Yet another approach is protocol integration.

In this case, the client and network interface blocks are integrated into one chip to implement a particular protocol, such as Ethernet.

This is useful for platforms that deal with one protocol only, such as Ethernet aggregation boxes.

Protocol integration often provides big cost savings, but the downside is a lack of flexibility in supporting multiple protocols and the inability to use a common chipset architecture across the platform.

The last approach is very-high-scale integration.

Here, the idea is to integrate in a single chip multiple PHYs, next-generation framer/mappers, and Sonet/SDH PHYs.

The concept seeks to create a linecard on a chip.

This approach is best suited for DWDM boxes where space is at a premium and the task is limited to packing data on a wavelength.

What's the best solution? The answer lies in the architecture of the box and where it will sit in the network.

Take into account the services the box will provide, the client protocols, the network interface (OC-3/OC-12/OC-48) and the CoS/QoS requirements (eg Layer 2 transparent services for Ethernet, subrate Fibre Channel transport).

The evolution of framer/mapper devices to support new standards (GFP, VC, LCAS) has expanded their utility and moved them up in the value chain for system design.

They are now a critical aspect of the box and linecard architecture of new ADMs, MSPPs and DWDM platforms.

Linecard architectures will continue to evolve.

For DWDM platforms, the focus will shift to higher speeds and extended distances (using FEC).

MSPPs and next-generation ADMs, will provide transparent services both at Layer 2 and Layer 3.

Emerging standards like RPR will require more linecard sophistication.

We will see the integration of RPR MACs with next-generation framer/mappers.

There will be a movement to increase the QoS capabilities of transport services.

This will result in framer/mapper chips working with NPUs and Network Search Engines (NSEs) to provide a complete solution for Layer 2 and even Layer 3 services, such as Ethernet, transparent storage and video.

NPUs will provide the necessary horsepower to analyse and modify packets, and to create and maintain flows; NSEs will enable efficient search solutions (packet look up, tagging), while framers/mappers will provide the final step of encapsulation (GFP) and channel-transport (using VC, LCAS).

The name of the game will be to provide scalable, flexible, cost-effective Layer 2 managed solutions for the end customer.

[1]ANSI T1.105: "Synchronous optical network (Sonet) - Basic description including multiplex structure, rates and formats", 2001.

[2]ITU-T G.707/Y.1322: "Network node interface for the synchronous digital hierarchy (SDH)".

[3]ITU-T G.7042/Y.1305: "Link capacity adjustment scheme (LCAS) for virtual concatenated signals", 2001.

[4]ITU-T G.7041/Y.1303 "Generic framing procedure".

ITU-T documents are available from www.itu.int.

ANSI T1X1.5 documents are available from www.t1.org.

Back to top