t's to help you deploy MPLS as handed to you from a provider. As a result, you will not see a lot of jargon like penultimate hop pop- ping (possibly my favorite tech term ever) used here. Really, you don't need to know this to make an MPLS WAN work for you. My goal, as always, is to help you get your job done. In a nutshell, packets in an MPLS network are prefixed with an MPLS header (called a label stack). This header contains one or more labels, each of which contains a label value, a traffic-class field (used for quality of service [QoS]), a bottom-of-stack flag, and an 8-bit time-to-live (TTL) field. Sounds exciting, doesn't it? For most people using MPLS, none of this matters. Bear with me, though, because you need to understand some history. The label stack is the only thing examined by the MPLS switches. Therefore, no tradi- tional routing table lookups are required, which in theory makes this a much faster solution than more traditional IP-based solutions. In the time since MPLS was designed, hardware has evolved considerably, and one might argue that the speed gained from the more efficient protocol is only a small part of what makes MPLS successful. When MPLS was being devised, the prevalent WAN technologies in use were ATM and Frame Relay, both of which suffered from some drawbacks. ATM especially suf- fered from severe overhead requirements that made it pretty unattractive. MPLS offered something more than simple speed and efficiency, though. Because entire packets are prefixed with an MPLS header, the MPLS network can serve multiple networks as virtual networks within the MPLS cloud. Furthermore, there are no obvious virtual circuits in an MPLS network as seen from the customer device. An MPLS network, as seen from a customer's perspective, is like having a private Internet, with only the customer's desired endpoints being visible. So let's cut to the chase. Why use MPLS over Frame Relay or ATM? I'll be honest with you-the number one reason that most companies deploy MPLS has nothing to do with techn