The Multi-service Switching Forum (MSF) promises to transcend the many ‘languages’ of a multi-vendor public network. But is this too good to be true? Tom Nolle finds out

You’re probably familiar with the story of the Tower of Babel, and how a proud plan to build a tower to the sky was foiled by making all the workers speak different languages. Co-operation collapsed, and with it the plan-and the tower.

Multi-service networking, the creation of a public network that anticipates the need for advanced services and fulfils it with minimal incremental investment or delay, is another proud scheme. But it’s also risking collapse because of language differences-protocol and behaviour differences-among network devices.

In this version of the Tower story, however, there just might be a hero. An organisation that met in 1998 is developing an architecture that will guide how the network of the future will work, and how each carrier and user can get to that future, regardless of their starting point or their business or technology drivers. This organisation is the Multi-service Switching Forum.

The MSF was born out of need. In the late 1990s, British Telecom (BT) and MCI were discussing a merger that would’ve created a global monster with arguably at least one installed version of every network device ever sold. Both carriers’ planners were wrestling with how this kind of network-with its diversity of technology and requirements-could converge on a single infrastructure that offered a competitive, diverse set of services. They launched discussions on this with some key vendors, but the initiative lost momentum when the merger deal fell apart.

But the goals were too attractive, too logical, to be set aside. In 1998, the MSF was launched at a meeting in Orlando, where they kicked off possibly the most significant technology forum of our age. MSF committed itself to developing a multi-service architecture that didn’t demand IP convergence, or any ‘convergence’ on a specific technology, vendor, or service concept. They wanted truly universal networking.

They think they may have found it. The first public picture of MSF’s work emerged this year, and the forum hopes its influence will be visible in the marketplace in 2002.

What exactly is the MSF architecture? Will it work? Who wins with MSF, and who might lose? This article will explore these questions.

MSF: The problem and the opportunity

While the optics hype of the past few years has obscured this fact, networking is more than pushing bits around. Users pay for services, which are created by combining information movement with a context for consumption that enables users to deploy that information-moving capability to support their needs. This is reflected in our terminology: Voice communications is ‘calling’, which describes not the information movement process, but the process by which we signal the voice network for the service of connection.

If service signalling is important in the concept of user-level services, it’s critical in the context of network behaviour. A network is a mesh of nodes and trunks in which any useful movement of information will likely require the co-operation of many devices and the arbitration of resources on many paths. In single-service applications, this problem is manageable. A phone network does phone calls, and every device in the network speaks the language of telephony: Signalling System 7 (SS7). What language would a multi-service network speak? Would status information conveyed in one service ‘language’ be different from that conveyed in another, thus causing false problem indications? Could the same resources be assigned to different service customers because one service didn’t ‘see’ the other? Signalling is networking’s ‘Tower of Babel’: Almost every class of device, from phone switch to router, has its own set of signalling protocols.

One possible answer, explored in depth over the last four years, is to create ‘convergence’ on a single network architecture. IP is usually the target architecture here because of the Internet’s cachet, but IP convergence isn’t economically viable. First, there’s the problem of justifying the rebuilding of existing networks along IP lines. Then there are the technological issues involved in cramming non-IP services into an IP network. The ‘convergence argument’ is beyond the scope of this article. Suffice it to say that Wall Street seems no longer interested in it, so other approaches are required.

A multi-service network can be viewed as a series of virtual network structures overlaid on a physical network based on a multi-service hardware device set. From this goal, it was logical to visualise each such ‘network’ as a service framework, and as an application of hardware capabilities. This ‘application layer’ could then be mapped to real networks at two levels-the information transport or switching level, and the control protocol level. That created three layers-application, control, and information switching. Add a fourth ‘management plane’ for operations functions, and you’ve got the basis of the MSF approach.

MSF’s goal was to make the information-handling portion of the network as generic as possible, and then combine it with a series of parallel service control planes to create a mixture of services. The service-specific part of the current hodgepodge of technology would be separated from network hardware and reside in a unique ‘layer’ or plane. Each layer would be made up of independent devices, inter-operating according to standard protocol rules. That would enable the creation of a given service in a single way, regardless of the underlying hardware. Many vendors, technologies, and business models, but one architecture for all.

The new architecture could provide many benefits. First, it could reduce network costs by making a network equipment investment more service-agile, so it could earn more revenue and remain useful for a longer period. Second, it could reduce operations costs by standardising on one set of equipment. Third, it could enable faster introduction of new services-a benefit to providers and users. Finally, it could improve network reliability and reduce service outages by facilitating a ‘network-wide’ policy set to address various problems, including the potential impact of terrorist acts on a network.

The MSF framework

Figure 1 shows a diagram of the MSF framework, an architecture for creating multi-service, multi-vendor, multi-technology networks. The MSF approach creates layers such as OSI, but the relationship between the layers is less that of a fixed stack than of an interconnected partnership. (Note that the MSF uses the term ‘plane’ to refer to a level or layer of structure.)

One relatively new MSF architecture layer is the ‘management plane,’ where network operations functions are controlled. This plane co-ordinates network management. This includes the devices in the switching plane and hardware used to create the other planes of functionality, and the services being sold to customers. The need to separate services from networks is an intuitive requirement in a multi-service network, but few standards activities to date have addressed it. The details of this layer must still be provided, and they’ll be important to service providers.

At the framework’s core is the concept of an independent switching plane, which can be any information-handler (switch, router, forwarder, and so on) that has multi-service potential. The features of the hardware that would support its operation, allocation of resources, movement of information, and so on, are defined in an abstract ‘virtual device’ in this plane. The hardware’s behaviour is controlled by modifying the policies or parameters that govern this virtual device, so presumably there’s a virtual device type for each type of hardware, or for each service mission. Virtual device concepts are pretty common in networking; SNMP uses ‘virtual device’ MIBs to provide multi-vendor management, for example. The MSF is simply extending the paradigm.

The virtual device is linked by a control connection to another MSF plane, the control plane. This plane of functionality is composed of a series of ‘controllers’ that are linked to specific service protocol sets, such as voice/SS7, ATM/Private Network-to-Network Interface (PNNI), or IP/Multi-protocol Label Switching (MPLS). The controller manipulates the features of the virtual device within each piece of hardware, and thus the behaviour of the network’s equipment. This virtual-device-to-controller link lets controllers operate on different equipment from different vendors in a common way. Again, it’s a concept similar to network management with SNMP: One MIB may be defined for a series of devices and each MIB is used the same way, but the implementation of the MIB on the device is specialised to the device.

Users would connect to the network through a somewhat non-intuitive layer, the adaptation plane. Here, hardware/software would match user service signalling and information interfaces with the network’s hardware and software. From the adaptation plane, end-to-end information would generally go to the switching plane and control/signalling information to the control plane (and to a controller). The adaptation plane creates a universal adapter framework to which user interfaces are matched, and from which standard information and signalling elements are diverted into (or converted for use by) real network elements.

An application plane that contains a model of the service logic controls this process. This might prove to be the defining concept for MSF. In today’s networks, connecting users to network features creates services. Services are therefore just features of networks. But that model doesn’t work well for multi-service environments, or for ‘service-independent’ technologies such as optics. In the MSF approach, service intelligence resides in a high controlling layer of functionality; this intelligence guides how service requests are interpreted, and how device and network resources are allocated. An example of ‘enveloping’ service intelligence lies in today’s phone network, where the Advanced Intelligent Network (AIN) architecture defines ‘Service Control Points’ to add service logic. In softswitch networks under development, this new application logic is created using APIs such as the Java AIN (JAIN) APIs developed with the support of Sun Microsystems.

Figure 2 shows models of how the framework would operate in the real world. These models are an ATM service network and Voice over Packet (VoP) (including IP). An MSF Implementation Agreement, a full interoperability standard, supports the latter application while the former is still in a more conceptual stage. The figure also illustrates the generic model of the control/device relationship that is the basis of the MSF architecture. (For simplification, management and adaptation plane details aren’t shown.)

The VoP/Voice over IP (VoIP) example contains the most familiar concepts. A gateway controller product (part of the control plane) is linked via an established standard (MEGACO, or Media Gateway Control Protocol [MGCP]) to a voice/media gateway product (a switching plane device). This provides a translation between standard SS7 signalling for PSTN users and the IP network environment. The gateway controller reads the SS7 signals and commands the gateway to create cross-connects between incoming PSTN calls (from a ‘real’ Class 5 switch, for example) and Session Initiation Protocol (SIP) IP calls over the IP network. A similar conversion would occur at the other end. All of this could be controlled by signalling standards operated ‘above’ the control plane in the application plane.

The ATM example shows a service controller or switch controller using the Generic Switch Management Protocol (GSMP) to manage connections on an ATM switch. (GSMP is a protocol that facilitates ATM switch functions such as connection setup, switch port management, and link failure notification.) A network of these configurations could set up ATM virtual circuits from user port to user port across various vendors’ equipment, not relying on the single-vendor proprietary Permanent Virtual Circuit (PVC) set-up mechanisms now available from ATM vendors.

Of course, it’s possible to do ATM virtual circuit set-up and IP calling without MSF. That’s one of the challenges the MSF architecture faces; it’s not likely to add functionality to the network in the near term. MSF’s target is a multi-vendor, multi-service, multi-technology carrier network framework. In the near term that framework will duplicate in an ‘open’ environment what vendors already do in single-vendor networks.

The real utility of MSF’s framework will become visible when sufficient support for MSF exists to attract third-party developers of application-plane or control-plane platforms. Innovation in how network features and service features are interconnected will increase the value of networking by creating new service combinations. But we’ll have to wait until the MSF concept acquires critical market mass, meaning significant vendor support.

Transitioning to MSF

Because MSF’s framework and Implementation Agreements are based on established standards, compliance with MSF is simpler than it would be if new standards were involved. But MSF defines roles as well as protocols. For example, a device might support the MEGACO controller-to-gateway protocol as required by MSF, but support only one gateway per controller, which is contrary to the MSF Implementation Agreement. Since many vendors have developed support for standards in a fairly narrow (and largely self-serving) manner, many will have to adjust their products to meet MSF requirements, whose goal is vendor independence.

Getting vendors to make such adjustments may prove challenging. Vendors typically want to ‘lock in’ customers to their solution strategy, rather than to support open architectures where customers could choose equipment from various vendors. This barrier will be overcome only if the buyer community demands compliance with MSF’s Implementation Agreements as a condition of purchase. So far, we’ve been unable to find a carrier that has done that, but Implementation Agreements are only now being published.

Another challenge for compliance is the difficulty in transitioning existing networks to a new architecture. MSF isn’t necessary to create the voice, frame, cell, and IP networks that generate today’s provider profits. If networks evolve slowly and incumbent carriers dominate the market (both of which seem likely given the current state of the industry), changes to networks will be incremental. Can MSF generate value, or even work effectively, when a ‘new’ MSF-compliant greenfield network isn’t an option?

The answer is ‘maybe.’ Because MSF is based on established standards, the MSF can create Implementation Agreements that reflect current deployment practices.

Controlling a ‘network’ through an MSF approach would mean, to most carriers, controlling the network’s nodes-switches or routers. MSF has provided a reference approach for that mission (see Figure 2.) The approach is based on GSMP, which isn’t a popular protocol. We asked the major carrier ATM switch vendors whether they would support GSMP, and none offer it as a native product feature. The GSMP working group, in fact, has difficulty attracting interest, submissions, and even attendance at its meetings.

But that’s not the whole story. MSF member Cisco Systems has its own proprietary architecture for switch control: the Virtual Switch Interface (VSI). There’s some indication that Cisco’s VSI, which is already implemented by about 50 service providers for some applications, is influencing the GSMP efforts and the direction of the MSF’s switch control Implementation Agreement.

Another major ATM carrier player and MSF member, Marconi (www.marconi.com), also has an interesting approach. Marconi says it provides GSMP support using service management software from fellow MSF member CPLANE (www.cplane.com). Service management systems-software designed to support the operations functions of multi-service networks-can ‘translate’ between MSF control protocols such as GSMP and proprietary vendor switch and router management systems.

The ‘service-management-translate’ approach may also explain how MSF’s architecture could be applied to existing networks. While service management architectures pre-date MSF’s architecture, leading-edge players in the service management space have adopted architectures that strongly resemble the higher (application and control plane) levels of MSF.

Given that carriers are finding new merit in more conservative service approaches, though, the lack of a router control standard might not hurt much. Using a service management system as an element in an MSF-compliant architecture would enable that architecture to be applied to existing frame/cell networks, and to networks built by players such as the RBOCs as they expand their services to a national scope. In the early deployment, when MSF’s standards weren’t supported fully by vendors, the service management system would translate between these standards and the vendors’ management systems interfaces. As support for MSF control standards grows, this translating function would be used less frequently. Eventually, the translation elements would disappear, leaving the service management system to act as the application plane of the MSF architecture.

While many service providers are members of MSF, there’s no indication so far that they’re requiring MSF as a condition of equipment procurement. There’s also a question of U.S. carrier support. MCI/WorldCom was the carrier who helped launch MSF, and SBC Communications and Verizon are among the RBOCs that have joined. Others are still holding back as of press date. Given the size of the US market and its role in driving equipment design, broader US carrier support may be needed before the market forces vendors to offer MSF-compliant equipment.

Who and when?

If MSF is successful, service providers would be able to support today’s services as well as services that evolve over the installed life of carrier equipment. That would reduce networks’ capital costs by reducing network hardware ‘churn.’ The single-technology network base could also significantly reduce network operations cost. The result: lower-priced services to users and faster deployment of new services in response to market opportunities.

So when can we expect all of this to happen? That depends on what happens with the switching Implementation Agreement. If it continues progressing in the same way in the direction of Cisco’s VSI superset of the GSMP standard there would be 50 MSF-compliant carrier networks already. These early market plays would give MSF a quick credibility boost with carriers, and would ensure Cisco’s support. If the agreement goes in another direction, it may be a long while before MSF achieves critical mass.

Carrier support for Cisco’s approach isn’t exactly touching the masses, though. VSI isn’t implemented in the generalised networks we use for voice and data in the United States, though it is used in AT&T’s IP VPN network. US market success for VSI may depend on Cisco’s success with the RBOCs, or on the RBOCs’ willingness to demand MSF compliance as a condition of upcoming ATM purchases.

A possible MSF-related decision is in the works. Long distance service approval is imminent for at least one RBOC and MSF member Verizon. Verizon is expected to receive approval for long distance service in the last of its major population areas-New Jersey-in early 2002. This would provide Verizon enough in-region long distance opportunity to justify building out a regional network to carry voice and data services inter-Local Access and Transport Area (LATA). Based on current market intelligence, Verizon intends to use ATM for this, and the MSF architecture could be a factor in product selection.

The RBOC regional toll network procurements may be the critical market test for MSF. We’re in a period of suppressed network investment, which has seriously impacted equipment vendors’ profits. We’re also in the early phases of a government-sponsored investment incentive designed to help companies buy more infrastructure. Will these incentives, and regulatory actions such as RBOC release into long distance markets, spur investment in new networks before MSF can guide those investments with accepted Implementation Agreements? The RBOC long distance networks could showcase both the VoP and switch control aspects of MSF, and would illustrate the principles of multi-service networking very well. But we probably won’t know whether the RBOCs will move to MSF for another quarter or so.

The question of who wins, or loses, with MSF, is critical to MSF’s long-term relevance. For decades standards have been seen as favouring an open market with active competition, and limiting market innovation. If a superstandard such as MSF develops, might it limit vendors’ ability to differentiate their products? Might it validate start-up players as well as incumbents? The vendor membership of MFS reads like a ‘Who’s Who’ in the industry, including Alcatel, Cisco, Lucent Technologies, Marconi, and Nortel Networks, as well as new players like Calix, Mahi Networks, and General Bandwidth. Are these vendors supporting the forum because of its carrier sponsorship, trying to create opportunity for themselves and not real progress?

Perhaps, but Cisco and Marconi are working actively to support the MSF framework in broad applications of multi-service networking. Cisco has been particularly successful in deploying networks that may not explicitly support the MSF standards, but conform at the network architecture level. Their VSI success would make Cisco a likely winner if MSF standards gain real acceptance.

‘Gaining real acceptance’ is the challenge. Ultimately, the market will probably have to decide MSF’s fate. If carriers and their customers press for flexible, tactical, inexpensive services, the MSF framework is almost inevitable. If there’s little public and buyer pressure for this, vendor squabbling may derail MSF. This might happen, because the industry is still preoccupied with the now-failed vision of convergence and the awful events of September 2001. The carrier sector in 2002 will be moving to address new competition between Incumbent Local Exchange Carriers (ILECs) and Interexchange Carriers (IXCs). None of these stimuli are forcing consideration of MSF’s goals. Will these goals be lost in the shuffle?

We don’t think so. SONET was successful because of who backed it; MSF has the same backing. Also, whatever the fate of MSF as an organisation or of its standards, its architecture will probably prevail in the long run. The business forces and other factors that guide our marketplace demand more of networks than the old monolithic service-specific structures can provide. Service-independent optical technology will demand a rethinking of network-building principles as it’s deployed. MSF has proposed what’s probably the only logical way to do that. Eventually, carrier networks and even enterprise networks will reflect the MSF approach as much as optical networks were driven by SONET. It’s just a matter of time.

www.networkmagazine.com