| MPLS: Breaking Through, A Status Report By <a href="mailto:bmichael@cmp.com">Bill Michael</a>
Service providers demonstrate a curious attitude when it comes to Multi-Protocol Label Switching (MPLS). Almost all agree they need it, yet almost none are actually using it, yet.
Part of the problem has to do with the fact that it's hard to identify precisely what MPLS can and should be used for. To some, it's primarily a way of achieving quality of service in an all-IP network. To others, it's a way of easing the transition from ATM to IP in the network backbone. Still others see it as the most efficient way of building virtual private network applications. The truth is, MPLS can do all of these, and more, which is why it's arguably the most important protocol being considered in the public network today. But unless carriers, service providers, and even enterprise users can gain a clear understanding of its capabilities, and develop concrete plans for its implementation, it risks becoming ineffectual.
Of course, as with almost any new technology at the network core, change doesn't happen overnight. While MPLS has been a part of the IETF in draft form since 1997, and has existed in proprietary implementations (notably, Cisco's "tag switching") for even longer, it is only now beginning to see the light of day in actual network deployments.
A recent Infonetics Research study showed that only two of nine (or around 22%) tier-one U.S. carriers interviewed have so far deployed MPLS in their networks, though half are planning deployments within a year (see figure 1). Of tier-two carriers surveyed, around 65% (15 of 23) said they planned to implement MPLS by next year. Kevin Mitchell, directing analyst of Service Provider Networks for Infonetics, notes that these numbers, while showing a clear trend toward greater adoption, still only reflect partial deployments in limited segments of the network. "Obviously, these carriers are not implementing MPLS throughout their networks," Mitchell said. "What we'll see is a staged rollout, spread out over multiple years. ... For the next year or year-and-a-half, the implementations will take place only in islands of the network."
This reticence can be traced in part to the inevitably drawn-out process of standards making. Indeed, most agree that MPLS standardization and interoperability has proceeded more slowly than vendors and carriers would have liked. Some have even suggested that the standard was over-engineered, and has become more complex than it was originally intended to be. But the biggest factor that seems to be keeping service providers from deploying MPLS more rapidly is related to what's in their networks already, not to what the advocates of MPLS propose to introduce there. At this point, MPLS has no direct rivals. Protocols like RSVP and DiffServ are, by and large, seen as complementary, not competitive. What MPLS must contend with, however, is the status quo: For most major carriers in this country, this means an installed base of ATM in the backbone of their networks, along with frame relay as a means of establishing connections to subscribers.
Though this could suggest that MPLS is incompatible with ATM or frame relay transport, that isn't true. While generally associated with an IP network, MPLS was, in fact, designed to be protocol agnostic at both layer 2 and layer 3, where IP resides: hence the name, multi-protocol. The "labels" that form the core of MPLS can be applied to the front-end of an IP packet header (forming what the standard calls a "shim header") just as easily as they can map onto the VPI/VCI field of an ATM cell header or the DLCI field of a frame relay address. Generally, MPLS is viewed as a merger of layer 2 and layer 3 technologies, or often as a way of introducing a "connection-oriented" switching paradigm into the fundamentally "connection-less" world of IP routing. While not inaccurate, these descriptions tell only part of the story. In reality, MPLS can serve a number of different purposes, each depending on the type of network in which it is deployed, as well as the applications that are to be carried over that network.
Between, or Beyond, Two Networks
For those who want to characterize MPLS as somewhere "between" switching and routing, the two most useful points of reference are ATM virtual circuits on the one hand, and OSPF on the other. OSPF stands for Open Shortest Path First, and describes the way IP routers determine the next hop for packets along the network, comparing the packets' destination IP addresses against large-scale forwarding tables. As the name indicates, OSPF gives priority to the shortest available path for getting a packet from point A to point B. Each router hop that a packet takes as it traverses the network will replicate this process of table lookups and forwarding. Of course, this model raises some fundamental scalability issues as the size of routing tables increases, though ASIC-based routing technology is more capable than legacy software of maintaining routing tables while still performing at wire-speed. What OSPF lacks, however, is any deterministic method for establishing routes or distinguishing between packet flows.
An ATM VC, by contrast, entails a simpler, intrinsically faster routing mechanism that reduces table sizes, eliminates complex route decision-making, and is even easier to translate to silicon. Virtual circuits are pre-determined and pre-provisioned routes, linking multiple network elements. Deciding on the path a virtual circuit should take requires more up-front network engineering than connectionless approaches, and, in many cases, some manual intervention with equipment. But once a VC is established, it's arguably less taxing on the network elements (primarily switches) involved.
MPLS draws from both approaches, and has applications in both pure ATM and pure IP environments. In each case, it offers a direct response to the network's shortcomings. When MPLS is used under IP, it can eliminate the overhead of packet-by-packet route processing in portions of the network where dynamically assigned, connection-by-connection routing or deliberate path engineering produces better results. Under ATM, it can produce better scalability and more efficient provisioning mechanisms than the more static, permanent virtual circuit configurations. It can also be used to provide a "VC aware" integration plane between IP edge networks and pure ATM cores.
The latter application - MPLS in hybrid transport and multi-protocol networks: networks comprising elements that speak pure IP, frame relay, ATM, or layered combinations of same - is what carriers are looking forward to in the immediate future. Sure, the general (or at least the most visible) trend is toward end-to-end IP; but in the meantime, and it could be a very long one, packets will be swirled around with a mixture of circuits, frames, and cells, and the network will have to negotiate between them. To avoid reduction to a "least common denominator" scenario, or a network that takes on the worst qualities of each of these elements - IP-over-ATM, though widely used, is a good example - it would be nice to have a protocol that creates some consistency and adds some efficiency into the mix. Enter MPLS. MPLS defines two major network elements, a Label Edge Router (LER) and a Label Switch Router (LSR). What's important to note about these entities is that they are functional descriptions, not system-level definitions. The types of products or systems that can fulfill the LER or LSR functions are not inherently limited, and, while generally separate, a single box could also act as either or both, depending on the application. Nonetheless, the simplest way of thinking about an LER and an LSR is to use a topographical distinction - the LER sits at the network edge (typically contained within an edge router) and the LSR resides in the core (typically within a backbone router).
The Label Edge Router often takes on a somewhat more complex responsibility than the LSR, since it is at the network edge that labels are actually applied to incoming traffic. The LER, in an MPLS network, becomes the only node performing a full routing operation, and serves as the originating and terminating point in a Label Switched Path (LSP). Unlike OSPF paths, an LSP can take into account information about class of service (which may be set by a TOS bit or DiffServ field, or using ATM QoS mechanisms), as well as the over- or under-utilization of bandwidth on certain routes. Along the LSP are several Label Switch Routers, which may themselves be layer 3 IP routers, but assume the more limited duties of a switch in forwarding MPLS traffic. One of the central tasks performed by the LSR is label "swapping" - examining only the information contained in the label itself (as opposed doing a full address lookup), and assigning a new label based on the flow's next destination along the path.
This model is not unique, and its roots in both IP routing and ATM switching are clear. But it does achieve at least two distinct benefits. First, it offers a significant improvement in both efficiency and control over conventional IP routing mechanisms, by confining the layer 3 function to isolated points in the network. Second, it serves as a generalized method for carrying traffic of all sorts across the network, since MPLS labels can be affixed to virtually any type of transport protocol, and the traffic is brought back to its native format only when it enters or leaves the MPLS domain.
Primary Advantages
As a way to converge otherwise parallel IP and ATM networks without requiring essential changes to the characteristics of one or the other, MPLS holds out a significant value proposition to major carriers. Maintaining two separate networks (IP and ATM) has obvious disadvantages in terms of cost, whereas running IP over ATM cannot (or so most savants now agree) continue to scale over time. Both of these issues, however - network scalability and the expense of operating parallel networks - are very general ones, and could also be given simply as reasons why carriers would want to converge all their traffic over an all-IP backbone. Where MPLS really shows its strengths as a long-term solution, not just a transitional fix, is in how it supplements IP. This boils down to two key concepts: quality of service (QoS) and traffic engineering.
While some might characterize MPLS broadly as a "QoS protocol," on its own the standard lacks a concrete means of quality assurance or traffic differentiation. What it does provide is an opportunity for mapping DiffServ fields (an 8-bit segment of the IP packet header) onto an MPLS label (as a 3-bit field in its new incarnation), and for conveying this information through the core of the network in a way that's both more efficient and more friendly to other protocols than a pure IP/DiffServ implementation would be. (The same idea of mapping external information onto the MPLS label applies to other forms of traffic identification/ classification, as well - including type-of-service bits, port numbers, and source or destination addresses.)
Even more important, MPLS lets you not only recognize and prioritize different types of applications, but also reserve network resources in support of them and define explicit routes over which they can be carried. Again, the standard relies on other protocols to achieve this end, defining only a generic need for a Label Distribution Protocol (LDP) to communicate between label router nodes. But the two main options that have been suggested for the role of LDP - CR-LDP (Constraint-based Routing) and RSVP-TE (an extended version of the Resource ReSerVation Protocol) - both describe methods for allocating bandwidth and establishing dedicated virtual routes based on QoS rules or application-specific constraints (see MPLS structure here).
End-to-end QoS in an IP network has been something of a holy grail for service providers, and it could be the area where MPLS makes its biggest impact. Certainly, the promise of highly differentiated and guarantee-able IP QoS is something that both enterprise users and service providers would like to emerge from MPLS deployment. But to be realistic, we're not likely to see a full realization of this aim anytime very soon. Technical issues still need to be addressed in integrating MPLS with DiffServ, and it will undoubtedly take some time to make these resources ubiquitous within the network. What is becoming a short-term reality for carriers, however, is traffic engineering.
Traffic engineering is not altogether distinct from QoS: In fact, from a broad perspective, the ability of MPLS to do traffic engineering effectively lays the groundwork for its QoS potential. Looking at the issue somewhat more narrowly, though, carriers see immediate benefit from traffic engineering in the internal operation of their network, rather than in their customer-facing service offerings. The hope, of course, is that the infrastructure they are investing in today will enable revenue-generating services tomorrow. But for the moment, MPLS offers a relatively straightforward way of solving traffic management problems like network bottlenecks, caused by congestion on certain router paths. Here, the flexibility of MPLS with regard to choosing the "best" path for a certain traffic flow can be leveraged to more evenly distribute traffic throughout the network.
Again, it isn't much of a leap to see how basic traffic engineering can extend into a more sophisticated QoS implementation. At the end of the day, a service provider's choice to focus on one or the other will depend more on the type of applications they are offering than on the core capabilities of MPLS. In fact, both vendors and service providers alike are already starting to look at MPLS from a more application-oriented perspective - the first item on their lists being Virtual Private Networks (VPNs).
A Quality Alternative for VPNs - and Voice?
A lot of talk has circulated around IP VPNs over the past couple of years, but if you look closely enough at what most carriers are offering as Virtual Private Network service today, you'll almost always find legacy technologies like frame relay or ATM doing the actual work in the core. The basic problem with a frame relay VPN is that it's point-to-point: Virtual circuit connections run from routers at every node in the VPN to similar hardware at every other node, to ensure dedicated, secure connections. That works fine if your network configuration is static, but not so well if (like most enterprises) the layout of your network changes. Each time you want to add a new site to a frame-based VPN, new virtual circuits need to be provisioned not just from the service provider's network to that particular site, but between the new site and every existing site in the VPN. The resulting mesh of circuits is inevitably complex, and too often leads to long waits and hassle on the customer's end, and added cost and consumption of network resources on the service provider's. IP, of course, resolves this problem by eliminating permanent virtual circuits. But on its own it doesn't provide any currently viable alternative for securely segmenting the traffic of one subscriber from another (though IPSec is a proposed solution), nor does it have any way of guaranteeing an agreed-upon level of bandwidth and performance or quality to the customer. Label Switched Paths, on the other hand, meet both sets of needs. They are secure, because MPLS VPNs take advantage of BGP (the Border Gateway Protocol) to exchange information only to and from authenticated users on designated routing paths. And because LSPs are constraint-based and deterministic, they can essentially be configured to meet any level of service and bandwidth requirements deemed necessary by the provider, based on service level agreements (SLAs) made with the VPN subscriber.
Much of the work being done around MPLS VPNs is focused on the edge of the network, since that's where services are defined and labels applied, though both edge and core label routers need to be aware of the service. Cisco Systems (San Jose, CA - 408-526-7208) has been among the earliest of vendors to target this application directly, and includes VPNs as part of the core MPLS functionality contained within its IOS software, which runs on most Cisco routers. Azhar Sayeed, senior product manager of the IOS Technologies division, suggests that the advantages of building MPLS-based VPNs in terms of scalability, ease of provisioning, and network efficiency are significant and clear.
"With MPLS, you're confining the VPN information to the network, so that users don't have to establish the tunnels themselves," Sayeed says. "Instead, you can configure the VPN once in the core of the network, and you don't have to re-provision any connections to the users when you want to add another site." Users on a common VPN are recognized based on VPN identifiers in the MPLS label. Users can have either standard IP addresses or non-unique private IP addresses within their VPN or domain, since the information between VPNs is kept separate in the edge router in a virtual routing and forwarding table. Routers in the core of the network make routing decisions based on labels as opposed to the IP addresses.
Where the MPLS VPN application gets even more interesting, Sayeed points out, is in combining the basic capability to dynamically provision endpoints from the network with the QoS and traffic-differentiation possibilities that MPLS makes available. A carrier might offer multi-service VPNs, for instance, where a service level agreement doesn't just specify a certain standard of performance for a subscriber's traffic in general, but can distinguish and prioritize traffic flows down to the level of individual users or applications. Here it becomes crucial that MPLS work closely with other QoS mechanisms such as DiffServ - one of the particular aspects of traffic engineering that Cisco is cultivating. "We have extended MPLS Traffic Engineering to make it more DiffServ-aware," explains Sayeed, "so that routers have an understanding not only of how much bandwidth is available over a particular link, but how much of a certain class of traffic can be admitted on that link. What you want is a distributed accounting of resources for each different class of traffic on the network, so that you can start to develop more fine-grained SLAs."
Cisco's most formidable competitor in the core of the network, Juniper Networks (Sunnyvale, CA - 408-745-2000), is placing a similar emphasis on the MPLS-based VPN application with both its backbone routers and its newer line of edge routers - though more basic traffic engineering at the core is likely to be where carriers first begin to implement their MPLS capabilities. Both Cisco and Juniper have tested interoperability of their MPLS-enabled core routers, performing the Label Switch Router function, on public test beds at George Mason University and the University of New Hampshire. At the same time, a newer group of companies is emerging to concentrate specifically on the network edge, and is implementing MPLS in a more diverse group of products.
Unisphere Networks (Westford, MA - 978-589-5800) offers a relatively straightforward example with its ERX edge routing platform, which includes the functionality of an MPLS Label Edge Router. To account for service providers' interest in MPLS-based VPN applications, Bill Glynn, Unisphere's senior project manager, points to many of the same advantages as Sayeed, with regard to both deterministic routing and differentiated QoS. Unisphere, in fact, has already begun on one deployment of MPLS-based VPNs with European carrier Portugal Telecom. It's at the provider's edge, Glynn emphasizes, that the application-based features of MPLS are really brought to bear, and in the Label Edge Router that QoS initiatives must be focused.
"Quality of service starts at the edge," says Glynn. "If you blow it there, it doesn't matter what you do at the core." Edge routers, he explains, carry a greater responsibility with regard to higher-order functions like QoS because even in an MPLS implementation, they take on not just the basic label and signaling functionality, but also include a full set of IP routing protocols to terminate IP traffic in its native format. Unisphere has implemented full LER as well as LSR functionality on its platform, including all of the major Label Distribution Protocol standards proposed, and is currently in the process of testing interoperability with core routers (see Intelligent MPLS Access).
Glynn agrees that, to date, carriers have focused much more of their attention on using MPLS for traffic engineering at the core of the network than on building QoS-enabled applications at the edge. But he suggests that that tide could begin to shift quickly. "At some point," he says, "which we're right now rapidly approaching, service providers will no longer be able to afford to run parallel networks. They realize the world is going IP ... and it's already common that they want to cap their investments in legacy technology. What they're looking for is a way to maintain the services they have now, and to begin adding on new IP services at the same time."
VPNs are just the first of these, where MPLS can provide a bridge from the legacy past and present to the IP future. But almost anyone involved in deploying MPLS agrees that VPNs are not the only, or even the most lucrative, killer app. Increasingly, forward-thinking service providers and equipment vendors are starting to ask, what about voice?
Voice-over-MPLS is far from being a standardized or widely deployed application, even within the limited context of existing packet telephony deployments. But given the fundamental capabilities of MPLS to do traffic engineering and quality of service, it seems like only a matter of time before it starts to be seen as a way of addressing the concerns people have traditionally held with regard to voice-over-IP. Perhaps the biggest reason why this application hasn't received as much attention as it would seem to merit, however, is that many of the specific traffic management and QoS issues that face VoIP are tied to the local loop or access portion of the network, where bandwidth is at present significantly more constrained than at the core. The focus of the standard and its main proponents, despite these constraints, has until quite recently been strictly on the core, extending only to the edge of the service provider's network but not all the way out to the customer premise. Whether or not MPLS should be so extended is still a matter of some debate. A few vendors, though, along with some next-gen carriers and service providers, see a good deal of potential in MPLS for the access network, and are beginning to shift the balance. MPLS: At the Edge and in the Core
One of the earliest advocates of voice-over-MPLS in the vendor community, and probably the best-known proponent of using MPLS for access networks, is a young company called Integral Access (Chelmsford, MA - 978-256-8833) that builds IADs and edge termination platforms to carry different types of IP traffic. From a high level, the Integral Access PurePacket system looks not unlike a multi-service DSL architecture: Both have CPE that collects and unifies a customer's voice and data traffic, and communicates with a box that aggregates and terminates this traffic at the service provider's edge. Where Integral Access differs is that its products (as their name suggests) are purely packet-based; so instead of employing ATM transport and its related QoS mechanisms and standards (e.g., AAL2 for VoATM), they looked for a way to accomplish similar functionality within the scope of IP. From the company's perspective, MPLS was a natural choice.
The efficiency and bandwidth utilization advantages of IP over ATM are by now well known. For Integral Access, MPLS provides a way to reap these benefits without having to sacrifice quality assurance. By implementing Label Switched Paths between their CPE and their network equipment, they can recognize different types of traffic (based on factors like IP and MAC addresses, originating port numbers, etc.) and group it into any of four classes of service categories, allocating different flows to particular paths accordingly. Since the LSPs are unique, performance can be monitored on a per-flow basis, and related back to individual applications, which enables a provider to offer several different classes of SLAs.
With respect to voice, the company has also been able to leverage a somewhat less obvious advantage of MPLS. Both the CPE and the edge device in this model serve as media gateways, to packetize and unpacketize voice that originates and terminates as standard TDM. Rather than using standard IP packet headers, however, Integral Access has done something unique: They actually replace the header with an MPLS label, instead of simply adding to it, thereby cutting down on overhead. While this isn't much of a concern in the core network, where bandwidth is abundant enough to make such distinctions unimportant, it can have a real impact in the access, especially where subscribers are running at sub-T1 rates. It also lets the edge and CPE devices avoid doing header compression, which can take up time. If the packets need to continue on over an IP connection past the edge device, Integral Access can add the header back on at that point, and send it along its way with MPLS labels still intact.
So far, the company's implementation of voice-over-MPLS has been proprietary, but they are currently working to reach interoperability with MPLS routers in the core, and plan to standardize their access interfaces as well, using the MPLS Forum as a foundation.
Also working on specific ways to optimize MPLS for deployment in the access network, though with a rather different spin on the topic, is LiquidLight (Duluth, GA - 678-812-2000), a startup focusing on bandwidth management for Optical Service Providers. As such, LiquidLight actually combines two envelope-pushing applications for MPLS - use in the access or metro area network, and integration of IP and optical technologies. The company calls its implementation "MPLS Lite," since it attempts to limit the number of labels required and the frequency with which they are exchanged to achieve greater efficiency in a bandwidth-constrained environment. It also takes advantage of features provided within the standard itself, like "fast re-route" to offer a solution better suited to the access environment. LiquidLight's aim, by using MPLS in conjunction with a variety of QoS mechanisms, is to offer a way of better controlling performance, quality, and bandwidth allocation in both the local loop and metro area optical networks. One of the key implications of this type of model is that service providers are moving quickly toward extending optical networks closer to their subscribers, and bringing IP all the way to the customer to enable next-gen applications.
At the provider edge, the market for MPLS-enabled products is growing even more rapidly, and a very diverse group of vendors are getting involved in the standard, where once only IP router makers were concerned. One notable example is Celox Networks (Southborough, MA -508-305-7000), one of the newest companies to enter the subscriber aggregation segment, alongside vendors like Redback and Shasta (now a part of Nortel Networks). Celox is seeking to bring MPLS into a developing part of the network it terms the "services POP," situated in between the metro area and the core. Its own product, the SCx 192, which the company describes as a service creation platform, can act as a Label Edge Router. The primary function of the SCx is to aggregate high volumes of subscriber traffic, segment and classify it, and apply service logic before forwarding it on at wire speed into the core.
One of the key initial applications Celox enables is VPNs - making its tie-in with MPLS a natural one. An implicit debate arises, however, over whether the LER functionality and VPN provisioning should be located in an IP router or in the type of platform that Celox proposes. While positioning the company as complementary, not competitive, with IP routers, Hugh Kelly, senior v.p. of marketing and business development, notes that one of the primary values MPLS offers is "a scalable means for service providers to accommodate the requirements of different kinds of traffic flows. It's a way of dealing with IP packets more efficiently than doing a full routing lookup on them."
At the core, IP routers acting as LSRs simply examine the MPLS labels that have been applied by the Celox platform, and forward packets accordingly. This model suggests that IP routers at the edge should remain similarly focused and simplified, leaving QoS and application-related decisions to a more specialized system. Celox is testing its MPLS implementation with those of major core routers, but can also support native ATM QoS, emphasizing that a number of carriers are planning to retain ATM in their networks for some time to come.
While the movement of MPLS in terms of product development, interoperability, and application scenarios is clearly extending outward from the network core, there's still no doubt that the core is where most carriers are looking to begin their MPLS deployments. Both from a technical and a market perspective, MPLS is significantly easier to comprehend and define at the core than it is at the edge. This is where the bulk of the standardization process has been focused over time, it's where the most consensus has been reached on required functions and applications, and it's also where interoperability is closest to becoming a reality. Part of what makes MPLS core-related initiatives simpler is that, at least when it comes to IP routers, there just aren't as many vendors in competition as there are in the edge market. As this article goes to press, both the University of New Hampshire's InterOperability Lab and George Mason University's Advanced Internet Lab are wrapping up their latest rounds of MPLS interoperability testing. The UNH test included eleven publicly announced vendors, but of those only three - Cisco, Juniper, and Avici - hold a major presence at the gigabit/terabit network core. These same three have essentially been participants since the first independent interoperability took place, and are seen by most edge vendors as the initial standard against which interoperability can be measured.
Both Cisco and Juniper offer their own products for the network edge, but Avici (Billerica, MA - 978-964-2000) has at least thus far focused exclusively on the core, with its Terabit Switch Router (TSR). Esmeralda Swartz, Avici's director of strategic marketing, says that while most carriers are still proceeding slowly with actual deployments of MPLS, support for the standard has become a must-have feature for core routers in the service provider marketplace. Equally crucial at this level, Swartz emphasizes, is the issue of interoperability. "One of the key values that MPLS offers to carriers," she says, "is the ability to build converged networks, where a standards-based application can cross multiple vendors' routers and switches, yet still maintain consistent quality of service."
Avici touts the TSR as the most scalable MPLS switch on the market, having demonstrated the ability to support up to 15,000 tunnels on the platform. The company also points out that it can carry up to eight different classes of service within a tunnel, whereas most competitors support only four. In terms of applications, however, Avici is targeting essentially the same initial areas as others focused on the core - bandwidth management, quality of service, and MPLS-based VPNs.
Reaching for the Light
One factor that still needs to be considered, and could potentially shake things up a bit at the network core, is integrating MPLS with the optical network. The basic problem carriers are trying to address is how to achieve tighter integration between layer 2 and 3 devices in the "electrical" backbone of the network (primarily IP routers and ATM switches) and the generally less intelligent devices (switches, cross-connects, multiplexers) that make up the optical core. Several competing interfaces have been proposed for this purpose, but among the leaders are a set of extensions to the basic MPLS standard, which have now taken on lives of their own as Generalized MPLS (GMPLS) and MP-lambda-S (MPlS). The basic idea behind this initiative, which has been taken up in the IETF, is to use MPLS as the foundation for a common control plane across multiple different types of networks, not just IP and ATM. MP-lambda-S concentrates on IP-over-optical applications, mapping intelligent packet flows onto optical wavelengths, while GMPLS extends the idea of a common control plane to include things like TDM and SONET networks, as well.
Since these standards are much more recent than basic MPLS, and enjoy less industry-wide consensus, there has been little if any interoperability achieved, though vendors in both the IP routing and optical networking environments are working increasingly hard on implementation. Tenor Networks (Acton, MA - 978-264-4900), for example, builds what it describes as a "core MPLS switch," designed to mediate between backbone routers and optical transport gear. The TN250G includes both MPLS and DiffServ functionality for traffic engineering and quality of service, but also offers the ability to communicate directly with DWDM and optical cross-connect equipment. Traffic going into the Tenor switch could come from any variety of networks, including IP, ATM, TDM, and frame relay, and could be carrying many different types of applications, from data to voice to VPNs. The goal is to maintain QoS classifications put on this traffic as it travels not only into the IP or ATM backbone, but also across the optical core, and to extend traffic engineering and bandwidth management policies across the entire network as a whole.
Tenor aims at end-to-end service provisioning, based on applications and business rules. With its current implementation of MPLS it is possible to start achieving this within the IP environment, where it has never really existed before. Generalized MPLS will make it possible to apply the same sorts of rules governing requests for bandwidth and guaranteed paths across the optical network, where today's solution for QoS is essentially abundant bandwidth.
Serving a relatively similar role within the network, though taking a different approach is Equipe Communications (Acton, MA - 978-635-1999), a company that just last month came out of stealth mode with a product it refers to as a "multi-layer optical on-ramp." This integrates a core MPLS switch as part of its functionality.
The Equipe 3200, currently in alpha trials and set to enter beta in June, can switch ATM and frame relay traffic in their native formats - distinguishing it from most other MPLS switches, which concentrate primarily on IP - and also includes a built-in SONET STS-1 cross-connect to enable private line services. The E3200's service interfaces reflect its target market - large, incumbent carriers who are transitioning to IP, but have a significant installed base of ATM, frame relay, and SONET in their networks from which they are drawing revenue today. MPLS lets Equipe provide a way for these carriers to start to build next-gen IP applications, like VPNs, with guaranteed quality of service, while merging them with existing services over a common platform.
On the back-end, Equipe grooms traffic directly onto optical wavelengths via wave division multiplexers or other optical transport gear. Here the company is currently working with two signaling standards proposed as alternatives to MPLS, the Optical Internetworking Forum's (OIF) UNI and the Optical Domain Service Interconnect (ODSI) protocol suite. Each has similar goals of enabling switches and routers to request bandwidth and extend traffic-engineering mechanisms across the optical core. The E3200 includes a 200 Gbps ATM switch fabric, with an optical throughput of up to 320 Gbps, and supports up to 128 OC-48 interfaces or up to 32 OC-192 in a single rack.
The Multiple Multi-Protocol
The remarkable breadth of products implementing MPLS in one form or another suggests, above all, that it's difficult to pin down the standard to just one role in the network. It's also hard to apply just one set of devices to form its infrastructure. As initiatives like Generalized MPLS and MPLS for the access network gather force, we can only expect this complexity to deepen. Going forward, interoperability will be an increasingly significant, though perhaps more difficult, objective. It's important to recognize, however, that simply by diversifying, MPLS isn't necessarily spreading itself too thin. The work being done in optical networking, for example, has been separated from the original IETF working group, and vendors are for the most part keeping the two implementations distinct, even if they are working on both simultaneously. Also, with regard to all its various traffic engineering and QoS applications, MPLS provides the ability to build up services incrementally - so a carrier can start with the practical and relatively simpler applications like bandwidth management today, and work up to more sophisticated QoS as the network and other service offerings demand it.
One of the key value propositions that MPLS offers to service providers is not having to make wholesale changes to the architecture of their networks today, while developing new services and new infrastructure that takes advantage of what's already there. Soon enough, business customers will likely begin to see the effects of MPLS in the network, as well - first, through simple-to-provision and secure IP VPNs; later, through end-to-end IP services with flexible, dynamic, and guaranteed performance levels.
|
