Multiprotocol label switching was designed to enhance the performance of the traffic-forwarding mechanism and to provide a traffic-engineering capability in IP networks. Generalized MPLS evolved from MPLS to provide a "general purpose" control plane for such other types of switching media as time-division multiplexing, wavelength switching, (lambdas) and spatial switching.

Several challenges remain and are being addressed in industry forums and standards bodies. Ultimately, the carriers, service providers and network operators will decide the direction of the set of solutions for each issue. Meanwhile, deployment of MPLS- and GMPLS-based networks will continue, and the growing amount of field experience will help drive standards to cover some of the question-mark areas.

It is well-understood that the traffic-forwarding efficiency of MPLS is superior to that of traditional IP networks. The table lookup operation in traditional IP routing is inefficient, since it is performed for every packet received at each hop. Nevertheless, it does provide "hooks" for establishing security for both the end user and the network itself. That is possible because the information necessary for the construction of a sophisticated firewall is present in an IP packet header, and, most important, the source and the destination IP addresses are network-wide and globally unique.

By contrast, MPLS labels and other data fields carried by the MPLS shim header are simply used to speed up the forwarding decision at each routing hop and generally have local significance. Therefore, they are inappropriate for use in access control or for network security.

The data-forwarding behavior in MPLS networks is, in fact, similar to that in connection-oriented, legacy networks-such as ATM, frame relay and X.25-where security has not been an issue and access control is enforced during the end-to-end connection setup.

The MPLS/GMPLS architecture specifies the use of IP routing protocols (OSPF and IS-IS) with traffic-engineering enhancements. Both protocols use link state algorithms that have been used in the Internet for many years. Just like an IP OSPF network, an MPLS/GMPLS-based OSPF network may be segmented into areas or administrative domains for scaling purposes.

In a single area, all of the nodes in an OSPF network are aware of the exact topology (nodes and links) of the network in that particular area. With the traffic-engineering enhancement for MPLS/GMPLS, all nodes in an area are aware of the traffic parameters that are associated with the nodes and the links in that area. As a result, all of the necessary information regarding "reachability," topology and traffic-engineering parameters are available during route calculation so as to achieve an optimized routing path for any label switched path (LSP) within that area.

However, in a multiarea OSPF network, the traditional OSPF protocol only passes the address reachability information among areas, not the topology. In addition, there is a lack of an effective mechanism to pass traffic-engineering information from one area to the other. That makes the routing path calculation difficult or suboptimal for an LSP that crosses a multiarea OSPF network.

Similarly, in interdomain IP networks, network administrative domains can only exchange information regarding reachability. The IS-IS network is also similar to the OSPF network, where a Level 1 IS-IS network is equivalent to a single OSPF network, and a multilevel IS-IS network is equivalent to a multiarea OSPF network.

The hierarchical infrastructure defined for OSPF and IS-IS in the past was intended to scale to large networks, and with today's powerful processors and relatively inexpensive memory, a router or a switch can process and retain far more topological information than was possible a few years ago. A single area or level is sufficient for the initial deployment of MPLS and GMPLS networks today. But with the continuous growth of Internet traffic, an effective mechanism and additional enhancements to the OSPF and IS-IS will still be necessary to handle traffic-engineering in multiarea and interdomain MPLS/GMPLS networks.

Multicast traffic allows a source to send data to multiple, predefined destinations. The connections between the source and the destinations form a tree-like structure: The source is the root, and the destinations are the branches.

The MPLS architecture supports data forwarding for both unicast and multicast traffic, but the widespread deployment of MPLS-based multicast applications must address a number of issues.

Several IP multicast routing protocols are currently used to forward IP multicast traffic in a non-MPLS environment. Since the operational behavior for traditional IP forwarding is quite different from an MPLS network, a number of issues and trade-offs must be considered in selecting a protocol to carry multicast traffic in an MPLS network:

• The ability to aggregate multicast trees with different multicast destination addresses on one LSP to create an efficient network operation;
  
• The establishment of shared multicast trees in connection-oriented networks (such as ATM or frame relay), an approach that's more economical than several equivalent "source" trees. This poses a challenge for MPLS networks, since merging LSPs is still problematic;
  
• The efficiency of mapping a Layer 3 point-to-multipoint tree to a Layer 2 point-to-multipoint tree in a dynamic network environment; and
  
• Creation of many merging points for bidirectional shared trees.

For unicast traffic forwarding, either the Layer 2 or the Layer 3 forwarding engine is used in MPLS networks. For multicast traffic forwarding, both may have to be used on a single label switch router. That would complicate both the software and hardware architectures, because several items are not yet well-defined for multicast traffic, specifically the label distribution mechanism, the mechanism to specify "explicit routing," and the mechanism to build a QoS-based multicast distribution tree.

In GMPLS networks, the data can be packet-based (MPLS networks only), TDM-based, wavelength-based, waveband-based or fiber-based. There are quite a few combinations in the data plane interworking context between GMPLS networks and ATM or frame relay networks, which carry data in cells or frames, respectively. To maintain end-to-end quality-of-service, the QoS associated for a given connection must be taken into account when interworking.

At present, the MPLS Forum, ATM Forum and Frame Relay Forum are working on the specifications for interworking between MPLS and ATM/frame relay. Practical solutions to satisfy carriers that manage both MPLS networks and legacy networks remain to be defined.