Metro Networks reach an Optical Crossroad: Cross-connecting services or switching lambdas? - Optical Networking

Telecommunications, Feb, 2002 by Hagay Katz, Michael Mesh

The emergence of optical switching, be it OEO (optical-electrical-optical) or all optical, has changed the way service providers plan and operate long-haul networks. Some carriers have replaced the standard SONET model for capacity upgrade (from OC-12 to OC-48 to OC-192) and the typical DWDM capacity upgrade (from one lambda to many) with a new model. In the new model, a whole lambda (typically OC-48) is seen as a network resource and can be provisioned on an end-to-end basis using signaling techniques. When a lambda crosses the long-haul network, carriers want to minimize the need to manipulate this lambda electronically. They also want to minimize equipment requirements at the core by creating a transparent long-haul core. On the other hand, routing an entire lambda without electronic manipulation only makes sense when the lambda is fully utilized and when the network can still monitor performance and forward the lambda openly and flexibly. Carriers still do not have a clear and final answer to these chall enges. Nonetheless it seems that the trend has been set for lambda routing in the long haul.

This shift in the metro brings carriers a new challenge: They need to migrate smoothly from current SONET- and ATM/frame relay-based networks to interface with a transparent long-haul core. Moreover, service providers are asking themselves whether a similar transformation should be implemented in their metro networks. As the amount of traffic in the metro grows, some metro networks can be viewed as small-scale long haul.

The Lambda Explosion Epicenter

The edge of the core, where services are handed off from the metro to the long-haul network, is where the multiplexing and cross-connect action takes place. Currently most of the traffic is private line (DS-n, OC-n); traditional, SONET-based multiplexers and cross-connects manipulate this traffic toward the core network. This is the first place where metro network designers encounter the dilemma: to cross-connect a lambda or cross-connect a service.

Cross-connecting a lambda is sometimes a more efficient solution; it does not require any electric signal termination. The ability to switch a whole lambda to any fiber flexibly is not supported by the traditional MSPPs (multi-service provisioning platforms). OEO manipulation can be done by a wide bandwidth transponder (typically 100 Mbps to 2.5 Gbps), and therefore it allows a generic service interface card. Additionally it regenerates the signal. On the other hand, it burns a whole lambda--a very expensive resource. The optimal solution would be to aggregate lambdas that should be handed to the long-haul network. Current metro systems do not have the ability to aggregate synchronous traffic (SONET, PDH (plesiochronous digital heirarchy)) and asynchronous traffic (Gigabit Ethernet, Fibre Channel) on the same lambda. Mapping these services to different lambdas results in systems that require a large number of lambdas.

The metro is dynamic, and service providers do not know ahead of time when they need efficient service aggregation and when they need lambda switching. The situation depends on the traffic growth requirements of customers, new urban developments, and many other unknowns. Moreover service providers do not know ahead of time where to route these signals as new ISPs, ASPs, CLECs and utilities may need this traffic to be directed to them at any given time. So, what service providers need most of all is flexibility in both areas: the ability to cross-connect any service to any lambda on any fiber and cross-connect any lambda to any fiber.

Last, but not least, managing the current SONET-based cross-connects and multiplexers necessitate the management of thousands of hierarchical time slots. Each lambda is specified by a large, rigid table of time slots, and software wizards are not enough to handle service changes and rearrangements. The current need for time slot assignment at every node is comparable to the need to assign a specific seating ticket to every passenger hopping onto a metropolitan train. Imagine how long it would take to arrange people in their seats, how many people it would take to administer the seating, and how many trains would be needed since groups of people have rigid requirements to stay together.

Service providers need a unified, time-slot-free flat paradigm of multi-protocol operation, without the legacy SONET time slot problem. This would radically simplify service provisioning. Planners would not be bothered with the exact time slots occupied by a specific service on a specific lambda. Services would be assigned to lambdas based on a single parameter: available capacity.

Finding the Sweet Spot

Until now, no architecture offered the flexibility, on a single platform, to cross-connect any service to any lambda on any fiber, and cross-connect any lambda to any fiber. Separate lambda-switching, packet-switching STS- (synchronous transport signal) cross-connects were deployed in different boxes, using different management schemes. These workarounds were not scalable and did not offer an alternative to the anachronistic time-slot-rigid allocation of SONET service provisioning.