lutions was that the ATM switch fabrics (and sometimes cell formats) were maintained while the fully featured (but IP-incompatible) ATM signaling system was replaced by a new system that integrated with IP. It soon became clear that rather than having competing solutions, a better approach would be to merge the work into a new The MPLS Architecture standard and terminology. Thus, the term MPLS was decided on and the IETF started the MPLS working group in 1997 to coordinate development. As MPLS evolved it moved far beyond a better approach to transporting IP over ATM. In fact, it is more common to use Ethernet as the underlying layer-2 protocol for newly deployed networks. At the embryonic start of MPLS, one of the key reasons for using switch- ing to support IP connectivity was that it was cheaper to perform label switching than the more complex IP forwarding function that had to be implemented in software. However, with the use of improved hardware (such as ASICs and CAMs) the IP forwarding function can now be provided directly in hardware at a cost that almost matches the simpler switch fabric. The reader might then ask why MPLS is still needed. The answer is that, because IP has become the dominant protocol, a core network that provides IP functionality is needed. However, the IP control plane has difficulties with providing carrier-grade VPNs suitable for replacing legacy leased-line services, and it cannot provide satisfactory traffic engineering. Both of these applications are well supported in MPLS. However, before these key applica- tions of MPLS can be described, MPLS architecture and signaling need to be introduced. The MPLS Architecture The MPLS network architecture is defined by the IETF in RFC 3031. This chapter makes frequent use of the IETF standards called Requests for Comments (RFCs), and these can be obtained from http://www.ietf.org. Where possible, the RFCs referred to are chosen for their clear descriptions of the technology, and the reader is encouraged to read portions of them for more info