Historically, tag switching ( now called Label) was first proposed as a way to move IP packets more qickly than was possible with conventional routing. But, soon after implementations, it became apparent that any increase in speed was very slight. What really allowed MPLS to grow as an infrastructure technology was that it could provide new IP based services such as VPN's, Traffic Engineering ( TE) etc.
MultiProtocol Label Switching architecture, as discussed in IETF RFC 3031, combines the benefits of the hardware packet switching approach of ATM and the Layer 3 approach of IP. In traditional IP routing, a packet is assigned in each router to a particular flow corresponding to a class of routing or a forward equivalence class (FEC). In contrast, in MPLS this assignment is performed once at the entry, or ingress, to the MPLS network. In an MPLS network, the FEC is identified by the network exit destination, or egress, and by the ingress label-switched router (LSR).
The MPLS architecture separates the control information for packets required for packet transfer itself; that is, it separates the control and data planes. The data plane is used for the transport of packets (or label swapping algorithm), and the control plane is analogous to routing information (for example, the location to which to send the packet). This capability is programmed into hardware by the control plane. This separation permits applications to be developed and deployed in a scalable and flexible manner. Examples of applications that are facilitated by MPLS technology include the following: MPLS QoS, BGP VPNs Border Gateway Protocol (BGP), Traffic engineering Traffic engineering ( enables one to control traffic routing via constraint-based routing), Multicast routing Protocol Independent Multicast (PIM), Pseudowires [These can be used to evolve legacy networks and services, such as Frame Relay, ATM, PPP, High-Level Data Link Control (HDLC), and Ethernet], Generalized MPLS (GMPLS).
Services offered by Service Providers ( SP's) running MPLS on their backbone may include the following:
Layer 2 VPNs
Layer 3 VPNs
Remote Access and IPSec
Integration with MPLS
Quality of Service
Multicast and NGNs
IPv6 over MPLS
The MPLS models adopted by service providers (SP) of broadband services depend on the services offered and also on the models adopted according to customer demands. The services provided have changed significantly through the last few years as techology has progressed. For example, many wholesale providers who offered ATM as access links now have moved on to Gigabit Ethernet.
For example, two of the most common broadband SP's would be the following:
1) Retail Provider: Any provider thats sells services to an end-user which can be business or residential. Usually they would lease bandwidth from a wholesale provider.
2) Wholesale Povider: Any operator that sells services to other network operators. In context of the current broadband world, the wholesaler is usually whoever owns the subscriber plant ( wires, cables etc.)
In between the subscriber and their "ISP" is the wholesale provider who owns actually owns and operates the access network, for e.g, DSL, Cable, Ethernet etc. Of course, for an IP network, these are just different types of access.
Several applications that are facilitated by the implementation of MPLS include:
1) MPLS QoS: Implements quality of service mechanisms, such as differentiated service, which enables the creation of LSPs with guaranteed bandwidth.
2) Layer 3 VPN: Uses BGP in the service provider's network with IP routing protocols or static routing between the service provider and the customer. The BGP protocol is used to exchange the FEC-label binding.
3) Traffic engineering: Uses extensions of IS-IS or OSPF to distribute attributes in the network. Control processes the FEC-binding through RSVP. Traffic engineering enables you to control traffic routing and thus optimize network utilization.
4)Multicast routing via PIM: The protocol used to create FEC tables; extensions of version 2 of the PIM protocol are used to exchange FEClabel binding.
5) Layer 2 VPN: Can be created via a Layer 2 circuit over MPLS, commonly referred to as Any Transport over MPLS. Layer 2 VPNs, therefore, use Layer 2 transport as a building block to construct a Layer 2 VPN service that includes auto
configuration, management, QoS, and so on.
Architectural Components and choices for SP's:
Scaling MPLS VPNs to Multi-AS, Multi-Provider, and Hierarchical Networks:
RFC 4364 discusses the ability to build MPLS VPNs across the autonomous system
boundaries. The three basic models discussed in RFC2547bis for Inter-AS
connectivity are as follows:
1) Back-to-back VPN connectivity between ASBRs
2) VPNv4 exchange of routes and peering between ASBRs
3) IPv4 exchange of routes and peering between
All three models focus on propagating VPN routes from one AS to the other AS. The first model is a simple one in which the ASBRs connect back to back via logical circuits or VLANs one per VRF. The back-to-back connections enable VPN connectivity and the exchange of routes between ASBRs on a per-VPN basis. For example, if ASBR1 and 2 need to exchange routes for 10 VPNs, 10 logical circuits exist between ASBR1 and ASBR2one for each VPN.
Carrier Supporting Carrier:
Another method of scaling MPLS VPNs is to create hierarchical VPNs. Consider a national or international carrier that is selling a VPN service to smaller stub carriers. The smaller stub carriers might in turn be selling another MPLS VPN service to end users (enterprises). By nesting stub carrier VPNs within the core or national carrier VPN, a hierarchical VPN can be built. With the CSC mode described in RFC 2547bis, the stub carrier VPNs and their routes do not show up in the core carrieronly the stub carrier IGP routes are part of the core carrier VPN. So, the core carrier does not need to learn or understand end user routes because the end user of the core carrier is the stub carrier. The core carrier needs only to provide VPN connectivity so that the core carrier's CEs (ironically, they are stub carrier PEs) are reachable. TheseDeployment Guideline considerations will involve the following summary guideline:
CEs are called CSCCEs, whereas the PE that connects to the stub carrier and has MPLS enabled on the PE-CE link is called the CSCPE.
- Centralizing address translation makes keeping track of address assignment easier. Multiple NAT PEs might be required for load balancing. If this is the case, make sure public address pools do not overlap. One of the possible disadvantages to centralizing is the amount of redundancy that can be achieved by replication. For example, in a noncentralized environment, one gateway/server failure can result in an outage of only that VPN's service. However, in a centralized environment, a single gateway/shared PE failure can affect multiple VPNs. This drawback can be easily overcome by having multiple PEs that serve as shared gateways, which provide services to the same VPNs. So, you can provide redundancy with shared gateways.
- If VPNs that use overlapping private address space need to access a shared services segment, make sure that private address space is translated somewhere in the path.
- NAT impacts CPU utilization to a degree. Some protocols are more CPU-intensive than others. Therefore, the type of translation being performed could have significant performance impact. The impact is less for newer particle-based routers and more powerful routers.
- As the number of translation entries increases, the throughput in terms of packets per second (PPS) decreases. The effect is negligible for less than 10,000 translation table entries.
- The rate at which a router can add a new translation table entry decreases as the number of entries in the translation table increases.
- As the number of translation entries in the translation table increases, the amount of memory used increases.
In addition to the above, there must be considerations regarding the following tools and policies:
- Management, Provisioning, and Troubleshooting
- Equipment Scalability Versus Network Scalability
Finally, the basic arichitecture and mode of service will probably depend on customer demand and SP's commitment to deliver. Here is a small list of some of the things that customers want:
More service selections
Ease of deployment
Ease of maintenance
Service Providers want all of the above, plus:
No loss of
A simpler, easier network to manage
Enterprise networks range in consistency from very stable to constantly changing.
Companies on growth trends are building new facilities and acquiring other businesses. They want ease of intermigration and implementation. Changes must be ably employed within their limited maintenance windows. Their data centers must run flawlessly.