Many organizations today either use Voice over IP (VoIP) and are converting their WAN to Multiprotocol Label Switching (MPLS), or have an MPLS WAN and are rolling out IP telephony (IPT)/VoIP. If you are managing the telephony infrastructure at one of these companies, you'll need to be up to speed on MPLS.
First, the claim to fame of MPLS is "any-to-any" connectivity. This statement generally implies a comparison to permanent virtual circuit (PVC)-based technologies such as frame relay and ATM, where each site has a physical circuit connecting it to the "cloud." Logical circuits are then configured on the physical circuits to create virtual circuits connecting sites together.
Before VoIP came along few companies ever created a full mesh because there was a cost associated with each PVC. Instead, companies required traffic in a hub-and-spoke topology to pass from one remote office to another through the hub site, using both its inbound and outbound bandwidth. This was generally OK because one remote office never talked to another before VoIP.
However, packets don't fly directly between any two sites -- as a legacy voice person, you're more likely to understand this than many of your data counterparts. In reality, your packets are probably riding some good old-fashioned frame-relay or ATM network to get from your office to your carrier's closest MPLS POP. Yes, it's rather amusing, but don't laugh until after you review your latency and jitter reports.
As someone with a keen interest in low-latency, you'll want to ask some pointed questions about where the MPLS POP actually is and what the Layer 2 path to get there looks like, because your packets could be taking a scenic route that won't show up on traceroutes.
Another significant difference between PVCs and MPLS is that the technology really provides no mechanical equivalent of committed information rate (CIR), Committed Burst Size (BC) or Excess Burst Size (BE), etc. However, your WAN provider may like those concepts so much that it tries to replicate the functionality with some truly bizarre policing and remarking configurations. Make sure you understand how they've implemented QoS and exactly how they treat your packets that exceed the committed data rate (CDR) and what the thresholds are.
Finally, while it was possible for a provisioned PVC or SVC to change its path through the carrier's backbone, it's much more likely to actually happen with traffic-engineered paths in MPLS. You should keep track of how much delay your circuits have, and if you see this number suddenly and mysteriously change, there's a good chance your packets are taking a different path as a result of a failure or the availability of a better path.
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
Dig deeper on Unified Communications Resources