Just when you thought that MPLS has peaked, that the pace of innovation has slowed, and that MPLS is getting boring, two promising new developments--namely "MPLS in the access" and "seamless MPLS"--bring fresh excitement to service provider networks. MPLS in the access is evolutionary, but a necessary prerequisite to seamless MPLS, which has the potential to revolutionize the life cycle of service offerings.
It is hard to overstate the impact that MPLS has had on service provider networks. In half a decade (1999-2004), MPLS transformed the WAN portion of most service providers. MPLS's fast-paced deployment can be attributed to two key qualities: its excellent synergy with IP (an almost universally deployed technology) and its versatility. This versatility was evidenced by the wide variety of reasons that MPLS was introduced into networks: for traffic engineering and enhanced quality-of-service (QoS) features; for fast restoration on network failures; for convergence of multiple networks to a single infrastructure; and for a new service, "BGP/MPLS IP VPNs," which serves both as a technology for service provider-based VPNs for enterprise clients and as a technique for compartmentalization of network elements (see RFC3209, RFC4090, RFC4364, and MPLS Apps).
Over the past half decade, MPLS has made inroads both to the rest of the service provider world as well as to other parts of service provider networks, such as the metro area network (MAN) and access networks. The timing is fortuitous, supporting another sweeping change: the migration of TDM-based infrastructure to Ethernet. Ethernet, while an extremely successful LAN technology, needed help to meet the stringent requirements of service provider networks--MPLS filled in nicely. MPLS has also progressed functionally, with the emulation of point-to-point and multipoint-to-multipoint Layer 2 services (RFC4447, RFC4761, and RFC4762), and the addition of multicast capabilities, both natively in MPLS (RFC4875) and within VPNs (mVPN). These developments are of interest from two points of view: (a) a carrier-grade infrastructure for the metro network, and (b) a vehicle for offering new services.
This expansion outward from the core, however, has been opportunistic and somewhat haphazard. "MPLS in the access" asks the question: Why shouldn't MPLS be used in all access networks in a systematic fashion? This has several benefits and several challenges. Juniper considers the benefits significant and the challenges solvable. The following sections contain a high-level architecture for MPLS in the access. "seamless MPLS" takes this one step further to an analysis that asks what fundamental change would occur if the entire network were based on MPLS. The result is startling, and offers a new view of MPLS--not just as a network technology, not as a service in itself, or as a service enabler--but also as a vehicle for flexible service delivery. This last aspect has the potential to dramatically change the nature of service offering.
Download Paper
(Webtorials registration required for downloads. Click here if you forgot your username/password.)
It is hard to overstate the impact that MPLS has had on service provider networks. In half a decade (1999-2004), MPLS transformed the WAN portion of most service providers. MPLS's fast-paced deployment can be attributed to two key qualities: its excellent synergy with IP (an almost universally deployed technology) and its versatility. This versatility was evidenced by the wide variety of reasons that MPLS was introduced into networks: for traffic engineering and enhanced quality-of-service (QoS) features; for fast restoration on network failures; for convergence of multiple networks to a single infrastructure; and for a new service, "BGP/MPLS IP VPNs," which serves both as a technology for service provider-based VPNs for enterprise clients and as a technique for compartmentalization of network elements (see RFC3209, RFC4090, RFC4364, and MPLS Apps).
Over the past half decade, MPLS has made inroads both to the rest of the service provider world as well as to other parts of service provider networks, such as the metro area network (MAN) and access networks. The timing is fortuitous, supporting another sweeping change: the migration of TDM-based infrastructure to Ethernet. Ethernet, while an extremely successful LAN technology, needed help to meet the stringent requirements of service provider networks--MPLS filled in nicely. MPLS has also progressed functionally, with the emulation of point-to-point and multipoint-to-multipoint Layer 2 services (RFC4447, RFC4761, and RFC4762), and the addition of multicast capabilities, both natively in MPLS (RFC4875) and within VPNs (mVPN). These developments are of interest from two points of view: (a) a carrier-grade infrastructure for the metro network, and (b) a vehicle for offering new services.
This expansion outward from the core, however, has been opportunistic and somewhat haphazard. "MPLS in the access" asks the question: Why shouldn't MPLS be used in all access networks in a systematic fashion? This has several benefits and several challenges. Juniper considers the benefits significant and the challenges solvable. The following sections contain a high-level architecture for MPLS in the access. "seamless MPLS" takes this one step further to an analysis that asks what fundamental change would occur if the entire network were based on MPLS. The result is startling, and offers a new view of MPLS--not just as a network technology, not as a service in itself, or as a service enabler--but also as a vehicle for flexible service delivery. This last aspect has the potential to dramatically change the nature of service offering.
Download Paper
(Webtorials registration required for downloads. Click here if you forgot your username/password.)
This is a great paper on the status and future of MPLS.
Even though the Internet has become broadly proposed as the ultimate solution for networks - including corporate networks - the fact remains that the Internet is still basically a "best effort" network. If you want guaranteed performance, you'll have to look elsewhere.
Recent events have highlighted the fragility of the Internet, and the move to could-based services must have - at least as an option - an access method that is more reliable.
I highly recommend this in-depth, technical paper.