Multiprotocol Label Switching, or MPLS, is a method of forwarding packets using labels. Providers can use it as part of private-network and traffic-engineering services. To evaluate an offering, separate the forwarding mechanism from its routing policy, security design and contractual performance commitments.
Follow a packet through a simplified path
The architecture in RFC 3031 groups packets into forwarding equivalence classes: packets that receive a common forwarding treatment. A label identifies that treatment in a local context. Routers use installed forwarding information to choose the next hop and label operation.
- Enter: an ingress router classifies the packet and applies the appropriate label information.
- Forward: a transit router uses the incoming label and its forwarding state to send the packet onward, commonly replacing the label.
- Leave: the label is removed at the appropriate stage, and the packet continues toward its destination. Some paths remove an outer label at the hop before the egress.
A label is a forwarding value, not a globally meaningful street address. Label stacks can support multiple functions. The illustration is a conceptual sequence rather than a complete protocol trace.
Understand the customer and provider roles
In the BGP/MPLS IP VPN model described by RFC 4364, customer-edge devices connect to provider-edge routers. Provider-edge routing contexts and route policies determine which customer sites can exchange routes. Core routers can carry the traffic without holding every customer’s individual VPN routes.
The model separates customer routing, while encryption is an additional design choice. RFC 4364 explicitly distinguishes its VPN architecture from cryptographic privacy and integrity. Ask where encryption terminates and which party manages it when your requirements call for protection of the data itself.
For a branch-office access plan and acceptance workflow, use the business VPN guide. Keep the network-service design and application authorisation aligned: reachability to a site does not determine what a user may do in an application.
Translate service terms into questions
| Term in an offer | Question to ask | Evidence to request |
|---|---|---|
| Private network | Which sites and external services can exchange routes? | Topology, route policy and responsibility boundaries. |
| Quality of service | Which traffic classes are supported and how is excess traffic handled? | Class definitions, marking policy and access-link limits. |
| Low latency | Between which endpoints, in which direction and by what method? | Measurement scope, thresholds and reporting interval. |
| High availability | Which failures are covered and how is recovery measured? | Redundancy design, exclusions and failover test results. |
| Service guarantee | What triggers a claim and what remedy applies? | The actual agreement, reporting process and exclusions. |
Classifying traffic changes how capacity is shared during contention. Plan enough capacity for the workload and investigate the complete access path. A provider-core metric may omit the local access circuit or the public-cloud destination where your application runs.
Check the access link before blaming the core
A fictional branch bottleneck
A branch has a 50 Mbps service handoff. Its planned simultaneous demand is 8 Mbps of real-time traffic plus 60 Mbps of file transfer: 68 Mbps in total. Even if the provider core has ample capacity, the 50 Mbps access service must constrain that offered load. A suitable policy can favour the real-time class, while the file transfer waits or slows.
This example is arithmetic about one bottleneck, not a prediction of application behavior. Measure actual demand, bursts, loss and latency under a representative workload. Check the provider’s policer, queue and class behavior for the purchased service.
Evaluate the service you can operate
Compare designs against the same sites, applications and recovery goals. MPLS describes forwarding technology; SD-WAN describes a broader approach to managing wide-area connectivity and can use different underlying transports. A decision needs the actual product architecture and terms, not a universal winner between labels.
Before acceptance, verify required routes, isolated sites, cloud access, representative performance and a planned failure scenario. Record who monitors the customer gateway, local circuit and provider network. Keep a baseline and a clear escalation path so later changes can be assessed against observable service behavior.
Explore the Internet library
Internet: Connections, Networks and Online Life brings together connection choices, network explanations, travel connectivity and practical online tasks.