e provider is forwarding packets, your IP routing table doesn't really matter. This entire WAN, BGP and all, is contained within a virtual network within the provider's MPLS network. Remember, the provider only cares about labels, and our network has no labels. The provider receives our packet, attaches a label to the packet, and forwards it through the cloud using that label. The contents of the packet are irrelevant. Only the label matters. Figure 24-3 shows how this is possible. There are two customers using MPLS service from the same provider. Each customer is using the same IP space (10.0.0.0/16). Each customer also connects to the same MPLS environment, but neither customer can con- nect to the other's routers. Why? They each have their own labels. This is similar to a VPN in that each customer can only see its own equipment, even though they share the network beneath. You may hear people refer to MPLS networks as VPNs, but be careful with terminology, because with MPLS, there is usually no encryption involved. Branch 010 Branch 020 Branch 030 Customer A 10.0.0.0/16 Virtual Network Branch 040 Customer B 10.0.0.0/16 Virtual Network Branch 010 Branch 020 Provider MPLS Cloud Branch 030 Branch 040 Figure 24-3. MPLS virtual networks What matters to the customer is that all of this is transparent. There is no indication to the customer that there are any labels or virtual networks involved. The fact that the MPLS is involved is also (usually) completely transparent. For the most part, the only Chapter 24: MPLS thing that appears to be different to most engineers turning up provider-supplied MPLS is that BGP is usually involved. We'll get to that in a moment. One of the other big selling points for MPLS is the inherent support for QoS. Since one of the labels in the MPLS label stack is a traffic-class field, MPLS networks can be built to support true classes of service. The number of classes varies by provider, and each provider will generally offer different schemes for classification. The capability to sup- port