Cisco MGX 8200 Series Edge Concentrators

Building a Multiservice Platform for the Future

White Paper

Building a Multiservice Platform

for the Future

The communications market in the networking and telecommunications arena is undergoing tremendous change. Intense competition and consolidation are driving down margins, forcing network operators and service providers alike to cut costs wherever possible. At the same time, customers are pressuring operators and providers to add new services in order to keep pace with the explosion in demand for Internet and data services. Adding to the confusion is the confluence of voice and data services. As data traffic overtakes voice traffic on most networks, operators and providers are compelled to grapple with a hybrid blend of services, placing an incredible strain on their existing infrastructure.

The Multiservice Challenge

The dilemma is how to add services while keeping costs under control. Historically, operators and providers have implemented networks that offer multiple services, but in practice built separate networks for each service. As cost pressures increase, network operators and service providers can simply no longer afford to build a separate network per service. However, with today's monolithic switching equipment that tightly bundles logic control and forwarding functions into one physical unit, it is the only alternative.

The proliferation of multiple overlay networks for forwarding and control, and in some cases, multiple networks for each service, creates operational inefficiencies. What's more, the support for multiple protocol versions from multiple vendors makes interworking and upgrades a daunting challenge. Consequently, most network operators and providers purchase equipment from a single vendor to minimize management problems. That puts them in the unenviable position of making their successes directly dependent on the decisions and capabilities of a single equipment vendor.

Due to economic pressures today, service providers and network operators are now focusing their resources on a smaller number of collapsed networks that support a greater number of services. Essentially, they seek a more flexible way to provision multiple services. One approach is to develop a modular system architecture similar to the standardization work of intelligent networking (IN) for telephone switches, which minimizes the risk of scaling a network. With the flexibility afforded by such a method, network operators can mix and match best-of-breed components to achieve the optimal system that suits their needs, rather than relying on vendors to implement specific technologies before making crucial business decisions. A modular paradigm will also accelerate the development of innovative solutions for communications networking, more rapidly leading to the cost-effective introduction of new services and features.

Making the Vision a Reality: the Multiservice Switching Forum

The Multiservice Switching Forum (MSF)—founded in 1998 by Cisco, Bellcore and MCI WorldCom—is developing standards and architectures to directly address the rising need for modular networking. The forum has grown through broad support in the industry and now has representation from major network vendors and service providers. The MSF's mission is to develop an open, standards-based network environment that supports multiple services on a common networking infrastructure. To achieve this goal, the forum focuses on the development of industry agreements and standards to establish an architecture and framework that can be easily extended to support new technologies, functions, and services. The MSF architecture currently in development applies to both connection-oriented voice services and connectionless data services (for example, telephone switches, as well as Frame Relay, Asynchronous Transfer Mode [ATM], and Multiprotocol Label Switching [MPLS]) and can easily be extended to connectionless IP routing-based networks.

The proposed architecture is based on four cornerstones that exploit the structural similarities between IP routers, Frame Relay devices, and ATM switches. First, it logically separates the functions of a switch into four levels or planes-transport, control, management, and applications (Figure 1). Then, the MSF architecture defines standard interfaces and management for communication between these components. It also logically partitions resources to allow for the execution of several controlling software instances in parallel. And finally, the architecture defines a coordinated, hierarchical management of physical and virtual network elements.

The value of the MSF approach is its recognition that while networking functions are typically standard, they are exercised in various ways by different services. One resource might be partitioned to support a Frame Relay permanent virtual circuit (PVC), an ATM virtual path, and an IP router, but each of these three functions are requested and managed differently. By distinguishing how resources are allocated and dispensed from how they are requested, the MSF architecture makes the handling of information flows service-independent.

Figure 1
High-Level Multiservice Switching Forum Architecture

Figure 1 illustrates the multiplanar approach proposed by the MSF. From the bottom:

  • The adaptation plane supports the physical interface to a user or another network element.

  • The switching plane supports the actual switching fabric by which physical interfaces are connected.

  • The control plane provides the generic capability to manage network service events and provides control over both the adaptation and switching planes. Standard protocols are used in communicating between the control plane and the switching and adaptation planes.

  • The application plane provides services that use the capabilities of the control plane, while also providing enhancements to the services realized within the control plane.

System integration with components from various vendors, who each specialize in different component types, is made possible through the introduction of open intrasystem interfaces. An intrasystem interface defines the information exchange between the forwarding and control components within a network element, whereas intersystem interfaces handle the interaction across the network between components of the same plane. The MSF approach specifies the interfaces between the planes, distinguishing between intrasystem and intersystem interfaces, to allow the critical technologies of forwarding and control to evolve independently from each other.

Thanks to these interfaces, functions in the control plane can allocate the resources of the switching and adaptation planes, partitioning the resources to create multiple virtual switches. Communication between the planes is strictly limited to the defined protocol between the planes. Each plane exclusively manages its own resources. These resources can include port resources such as bandwidth and buffer space, as well as switch resources such as forwarding table space. It is possible to combine virtual switches, enabling them to interact with each other in a predictable and controlled manner. This sharing of resources between virtual switches may be either deterministic or statistical.

Partitioning the functionality naturally lends itself to the support of multiple services for separate groups of users. The MSF architecture supports deterministic partitioning for strict isolation between services even as they share resources in common. And the control logic allows the use of statistical allocation principles for the resources within its partition.

An independent controller manages each virtual switch as though it were a physical switch. Similarly, a separate network manager can control each virtual network as though it were a physical network. The management hierarchy within the MSF architecture enables tremendous flexibility in configuring networks. It allows components to be mixed and matched, defining how resources are partitioned to support virtual switches. By using standardized management interfaces and information, management functions operate on two levels:

  • Superordinate management that regulates the physical resources and allows virtual entities to be created, modified, and deleted

  • Subordinate management of the virtual entities

Benefits All Around

The flexible architecture proposed by the MSF benefits both equipment suppliers and network operators. It is very likely that a modular approach will drive innovation in the networking arena, creating a new market of third-party suppliers to develop, with each vendor concentrating on the portion of the system they know best. And the architecture's open interfaces will enable greater participation in the development of future products, lowering the threshold for introduction of new types of network control. The result will be a much more dynamic, innovative marketplace for next-generation switching solutions.

By using systems based on this architecture, operators can buy the solutions that best fit their needs, mixing and matching capabilities to meet specific requirements. It also frees network operators from making all-or-nothing decisions when upgrading their networks. Instead, they can thoughtfully evolve their networks, replacing or upgrading vendors and products without rebuilding the entire whole network. Moreover, it allows for easy management of heterogeneous networks that incorporate solutions from multiple vendors.

Separating switching hardware from control software enables independent scaling of hardware and software, giving network providers the flexibility they need to quickly and cost-effectively expand their services. Provisioning multiple services on virtual switches that share physical layer resources frees providers from vendor constraints when developing services. Providers can now smoothly migrate to new standards, evolving their networks to accommodate protocols as they emerge and mature. All this leads to lower provisioning costs, simplified management, and higher availability within networks.

Changes in Service Mix

Because the MSF architecture is "core agnostic," it is extremely attractive for providers considering a move from one IP traffic standard to another. For example, there is intense interest in the emerging MPLS standard because it enables new, high-margin services to be provisioned and managed in a simpler, more scalable way compared to ATM and Frame Relay. By streamlining the service provisioning, operators and providers can add customers and new network sites in a meshed configuration, without having to set up Layer 2 addresses for each pair of communicating sites.

Providers or network operators considering adoption of an emerging standard face an interesting situation. When using traditional monolithic switching equipment, they can either completely replace their existing network with the new standard, or they can create an entire, secondary parallel network to support the emerging standard. Faced with uncertain economic times and intense competition, either way represents an extremely risky economic proposition.

The MSF modular architecture offers a much more attractive alternative, providing a multiservice migration path that enables operators and providers to move to a new network infrastructure in stages. The architecture can easily support multiple standards simultaneously, allowing for a gradual, controlled evolution of the service mix at a pace set individually by each service provider. This gradual move allows operators and providers to prepare for new standards-based networks within their existing infrastructures.

Going back to the ATM and MPLS example, the switching plane could be ATM- or MPLS-based, with separate controllers for a virtual ATM and MPLS switch (Figures 2 and 3). A third-party application could also be installed, with all three services provisioned as virtual switches sharing common hardware and software resources. Over time, the provider could gradually shift more resources to the MPLS virtual switch. A carefully planned strategy like this enables "core transparency," offering the least disruption and expense for a migration to MPLS.

Figure 2
Multiservice ATM-based switch

Figure 3
Multiservice MPLS-based switch

Foundation for Myriad of Applications

Besides helping operators minimize the costs and risks of adopting new standards, the MSF architecture is extremely attractive in a whole portfolio of other applications because the partitioned architecture allows the use of separate technologies for access and core. Here are just a few examples that illustrate the flexibility of the architecture:

  • Telephony Gateway (MGC/MG): In an MSF-standard system, a telephony gateway that converts information carried on telephone circuits to the data packets carried over a packet network can be logically separated into two components—a media gateway (MG) and a media gateway controller (MGC). The MGC component can be responsible for protocol interactions with the service logic leading to the establishment of a call, while the MG component can adapt the media streams packaged at the network boundaries. Separating the control from the forwarding process in this way not only increases the speed and lowers the cost of introducing new services and features, but also gives network operators the freedom to independently provision the MG and MGC components for optimal network performance.

  • Partitioned Access Router: Along with partitioning network nodes, the MSF architecture also supports partitioning network access from customer equipment. Existing techniques like asymmetric digital subscriber line (ADSL) and virtual local area network (VLAN)/Ethernet can be used to partition the access. As shown, A, B and C represent different customers connected via dedicated lines to a concentrating function, or alternatively, stand for different network services that one customer is using. The ADSL serving customers A, B, and C would be multiplexed by a DSL Access Multiplexer (DSLAM) into a single ATM port on an ATM switch. Either the virtual channel or virtual path level of ATM would be employed to perform this multiplexing. ATM port resources, such as buffers and shapers, would be partitioned among these virtual channels (or paths).

  • Classical IP Router: The MSF architecture can also be easily applied to a router application. The most straightforward approach is to split the router into distinct "boxes" connected over an interface, traversing one or more MSF-defined reference points as shown in Figure 4. For example, the IP-routing control component could be separated from the IP-forwarding component to enable natural specialization and independent scaling of each component. The upper control part maximizes reliability while maintaining stability. With the volume of traffic in the Internet growing exponentially, this configuration could easily be scaled to forward an ever-increasing volume of traffic.

Figure 4
Physical model of a classical IP router

In addition to basic IP-level forwarding, the separation of control from forwarding enables the development of value-added IP services. These include differentiated services based on fields within the packet, enforcement of sophisticated policies, and the implementation of value-added routing algorithms specifically tailored to user applications.

Separate control plane and forwarding planes also help provide different redundancy techniques for each function. Each plane can have its own redundancy, making the entire system more reliable. Each plane can also be upgraded separately. For example, the control module can be upgraded without affecting the forwarding plane.

Future Applications

Besides enhancing established switching functions, the MSF architecture easily fuels the development of exciting, new opportunities that are simply not feasible with traditional monolithic networking systems.

  • Network hotel: Virtual private networks (VPNs) can be provided according to the Web-hotel model. That is, a bigger operator sells partitions of its infrastructure, and as in ordinary hotels, operations and maintenance are provided as a part of the service.

  • Customer-controlled VPN: The customer may himself organize control and management of his own VPN. This may be an attractive alternative for bigger customers that already have their own professional IT staff and want to include and possibly integrate management of their VPNs within their own supervision environments.

  • Third-party management of VPN: While the customer or the provider may not handle the management of the VPN, some other third party could.

  • Instant networks: The increased flexibility offered by the MSF architecture could invite creation of "instant networks," where networks are established (and released) within the same amount of time it takes today to establish a connection.

MSF Organization and Progress

The MSF is composed of a variety of technical committees and workgroups that are developing the details of the architecture and standards. One of the most prominent groups is the architecture working group, which is tasked with defining a functional architecture that separates the control and user/data plane. This group is responsible for producing framework documents, implementation agreements, and technical reports that:

  • Define the functional building blocks and each respective function performed

  • Define the functional requirements for each functional building block

  • Define the interfaces between the functional blocks supporting the MSF architecture

The architecture working group has completed work on Release 1.0 of the MSF architecture, which supports ATM and classical, best-effort, IP-based networks. It also supports deterministic partitioning of multiservice switches and provides open interfaces between physical switching controllers and switches (implemented via General Switch Management Protocol [GSMP]), as well as between media gateways and their controllers (implemented via MEGACO/H.248). In addition, the working group has provided a number of physical mappings that show how the functional architecture would be implemented and deployed to support multiservice networks.

The working group is currently working on Release 2.0 of the functional architecture. Release 2.0 will supply explicit support for IP, MPLS, and mobility, while also extending the functional architecture to the application plane and associated application program interfaces (APIs) including:

  • Release 2.0 functional architecture

  • Functional architecture expanded to include mobility

  • Technical report: MPLS-based VPNs

  • Technical report: Voice over IP on MPLS-based networks

  • Framework document: Application of the Release 2.0 functional architecture to mobile networks

Other work groups include the switch working group and the media working group. The management framework working group was formed in 2000 to address the need for a coherent multiservice system management strategy that eliminates the need for the current multiplicity of management standards and equipment required in today's networking environments. Achieving this task is vital to the successful deployment of the MSF vision.

The management framework has several objectives:

  • Work with the architecture group to establish an architectural framework for the management plane in a MSF environment.

  • Study the work being done in standards bodies and decide which solutions are appropriate for MSF implementation agreements.
    Where appropriate, work with the liaison committee to establish liaisons with these standards bodies.

  • Cooperate with the other MSF working groups to develop information and data models appropriate to established goals and in accordance with the MSF architecture. This cooperation currently applies specifically to efforts in the switch working group and in the media working group.

Cisco and MSF

As a founding member of MSF, Cisco is a very active participant in the MSF and strongly endorses and advocates the architecture and standards being developed. Cisco believes a modular architecture is the best answer for the emerging needs of networking communications.

For this reason, Cisco is building equipment that incorporates the MSF architecture within its third-generation multiservice switches. These solutions support both traditional and emerging services including Frame Relay, ATM, circuit emulation, IP, and packet voice over a single infrastructure comprised of multiple control planes with a shared operating system and modules. The switches are designed to provide the requirements of various services, including simplified quality of service (QoS) and traffic management, and 99.9999 percent (five 9s) reliability.

This comprehensive family of switches also allows for the carefully planned adoption of MPLS today, while retaining ATM-based services by offering a common networking and control plane with ATM and MPLS control.

Addressing Tomorrow's Needs

The MSF envisions a future of global connectivity in which network elements can be interconnected and intermixed with relative freedom. This next-generation network infrastructure will foster new markets for entrepreneurial developers of network elements, spurring competition and accelerating the creation of innovative solutions for all facets of global communication.

Both large and small providers of networking services and equipment, including Cisco, are aligned with this vision because it will enable rapid deployment of new and enhanced services-without requiring new investments in switching and transmission resources. Such an infrastructure will support deployment of innovative services, controlled by software that can be adapted to meet the new and evolving requirements of end users.