Leveraging MPLS To Enhance Network Transport Capabilities
In the Service Provider and Enterprise Environments
Also Available in PDF format (1.06MB)

Overview
As global internetworking infrastructures continue to evolve to support higher usage levels and the convergence of disparate types of service, network architects must increasingly wrestle with the challenges of efficiently routing/switching heterogeneous traffic across complex network structures.Service providers and enterprise network administrators both need maximum flexibility to de fine Virtual Private Network (VPN) links, to merge multiple classes of service and to optimize traffic engineering across multi-faceted internetworking environments.

Recently, a large part of the networking industry's focus has turned to the use of Multiprotocol Label Switching (MPLS) as providing an attractive opportunity for streamlining the implementation of VPNs, service convergence and traffic engineering capabilities, while minimizing the complexity and overhead associated with earlier methodologies.

In this white paper, we will provide an overview of MPLS and the market forces driving its development as well as reviewing the current state of the MPLS standards and industry adoption status. Then we will compare the key differences between deploying MPLS at the WAN and MAN levels and will explore the near-term opportunities for both service providers and enterprises to leverage MPLS to their maximum advantage. Finally, we will look at the specific MPLS solutions available from Extreme Networks® to smooth the cost-effective and performance-optimized implementation of label switching applications in real-world scenarios.

What is MPLS?
As its name implies, MPLS is essentially a labeling system designed to accommodate multiple protocols. Put another way, the use of MPLS labels enables routers to avoid the processing overhead of delving deeply into each packet and performing complex route lookup operations based upon destination IP addresses.

In an MPLS environment,incoming packets are initially assigned labels by a Label Edge Router (LER), as shown in Figure 1, which then enables the packets to be more efficiently handled by MPLS capable routers at each point along the forwarding path. An MPLS label essentially consists of a short fixed-length value carried within each packet's header and identifying a Forwarding Equivalence Class (FEC), which tells the router how to handle the packet. A FEC is defined to be a group of packets that are forwarded in the same manner Examples of FECs include an IP prefix, a host address,or a VLAN ID. The label concept in MPLS is analogous to other connection identifiers, such as an ATM VPI/VCI or a Frame Relay DLCI.

By mapping to a specific FEC, the MPLS label efficiently provides the router with all of the local link information needed for immediate forwarding to the next hop. In effect, the use of MPLS creates a Label Switch Path (LSP) along which each Label Switch Router (LSR) can make forwarding decisions based solely upon the contents of the labels. At each hop, the LSR simply strips off the existing label and applies a new one that tells the next LSR how to forward the packet.

As will be demonstrated in the following sections, the intelligent deployment of MPLS technologies can significantly enhance the performance of packet-based networks by providing a relatively simple mechanism for instilling more deterministic flow control and flexibly creating dedicated virtual circuits. In effect, MPLS is helping lay the foundation for next-generation internetworking by combining the best characteristics of flexible, ubiquitous packet-oriented IP networks with the circuit-oriented advantages of traditional telecom networks.

Market Drivers for MPLS

Originally, the primary motivations for MPLS included:

The price and performance advantages of ATM switches relative to routers available in the early-to-mid 1990's were significant factors in the first three motivations listed above. ATM's price/performance advantages, combined with its traffic engineering capabilities, resulted in large parts of the Internet being built with ATM switches that provided layer-2 connectivity between surrounding lower-speed routers. However, mapping IP services onto ATM networks proved problematic in terms of both complexity and scalability issues. These problems led to the notion of defining protocols that would enable ATM switches to operate at layer-3; thereby, creating faster/cheaper routers.

Originally the driving force for MPLS development was focused solely on the improvement of performance, which was envisioned to be achieved by cleanly separating the forwarding control functions (embodied in the label) from the payload data, thereby leveraging the speed of Layer 2 switching into Layer 3. However, the emergence of a new generation of very high-speed, ASIC-based, Layer2/Layer3 switch/router systems, such as Extreme Networks BlackDiamond® family, has now overcome the speed advantages of conventional Layer 2 switching solutions and has obviated the original focus of MPLS on speed issues. Nonetheless, MPLS protocols are still quite important as enablers of new routing functionality. VPNs, traffic engineering, fast reroute, and Quality of Service (QoS) routing are among the functions enabled/enhanced by MPLS.Furthermore,new functions may be added without requiring changes to the label swapping forwarding paradigm (i.e., without requiring hardware upgrades). In some ways, MPLS can be viewed as a new and improved ATM, since it often positioned as a unifying technology that enables a single networking infrastructure to support a wide variety of services.

Current State of MPLS Standards Efforts
The underlying concepts for label switching technologies originally evolved out of various proprietary approaches put forth by individual equipment manufacturers. However,the current momentum and ultimate success of MPLS would not be possible without the involvement and leadership of industry-wide efforts from key standards-setting organizations. Currently the development of MPLS technological standards and real-world deployment opportunities revolve around inter-related collaboration between the IETF and the MPLS Forum.

Internet Engineering Task Force (IETF)
In 1997 the Internet Engineering Task Force (IETF) established a formal MPLS Working Group to address many of the wide-ranging issues involved with the development of label switching standards. Since its inception, the IETF MPLS Working Group has helped to identify and flesh out the myriad of technical issues that must be addressed to create a vendor-independent foundation for implementing interoperable MPLS methodologies. Other related IETF Working Groups, such as the IP-Over-Optical (IPO) WG, have also been established to focus on coordinating and developing MPLS-related technologies. In addition, other standards-setting bodies such as the International Telecommunications Union (ITU) and the ATM Forum are addressing MPLS-related issues, which must be coordinated within the context of the IETF process.

However, to date the sheer breadth of the challenges facing the IETF, ITU and ATM Forum have relegated their primary efforts to coordinating development of technical definitions and standardized guidelines for using MPLS. Currently, over 112 drafts relating to MPLS are in various states of review and refinement within the formal IETF processes. In many cases, working drafts are contingent upon information contained in other related drafts. While this broad-reaching approach has been very beneficial in identifying the full range of issues relating to MPLS and pushing forward a number of technology alternatives, from a network implementers' perspective, it has not yet created a firm basis for deploying interoperable real-world solutions. Essentially, the IETF 'owns' MPLS from a standards viewpoint, however the IETF's primary focus is on defining protocols rather than implementable architectures.

As of today MPLS networks has not yet generated any substantial revenue since most of the MPLS deployments have targeted the MPLS traffic engineering application in the WAN while the WAN VPN implementations have not scaled to address mass markets.

MPLS Forum
In March 2000, the MPLS Forum was established as "an industry-wide association of networking and telecommunications companies focused on advancing the deployment of multi-vendor MPLS networks and associated applications."The MPLS Forum views its role as entirely complementary to that of the existing standards bodies such as IETF, the ITU and the ATM Forum, with a focus on collaboratively developing "implementation agreements" to further real--world practical deployments of interoperable MPLS solutions.

During its first nine months of existence, the MPLS Forum has rapidly gained widespread industry participation, going from an initial membership of 16 companies to a current level of 79 members. With active participation from a diverse range of equipment vendors, component suppliers, test/interoperability companies and service providers/carriers, the MPLS Forum provides a unique opportunity for in depth, hands-on multi-vendor interaction, focused on creating practical MPLS implementation criteria. Extreme Networks currently has a seat on the board of the MPLS Forum and has been an active member of forum since its inception.

MPLS Basics
MPLS may be thought of as a shim-layer between layers 2 and 3 of the protocol stack. As such, MPLS provides connection services to layer-3 functions while making use of link-layer services from layer-2. To achieve this, MPLS defines a shim header that is inserted between the link-layer header and the network-layer header of transmitted frames. The format of a 32-bit MPLS shim header is illustrated in Figure 2 below.

The MPLS shim header is also referred to as a label stack, since it may contain multiple entries. Each entry contains a 20-bit label, a 3-bit experimental (EXP) field, a 1-bit End of Stack flag, and an 8-bit Time-To-Live (TTL) field. As previously mentioned, the EXP field may be used to identify different traffic classes in support of the DiffServ QoS model.The TTL field is used for loop mitigation in a manner similar to the TTL field carried in IP headers. The End of Stack bit is set to 1 to indicate the last stack entry. The format of a MPLS label stack containing two entries is shown in Figure 3 below.

Figure 4 below illustrates the format of a unicast MPLS frame on an Ethernet link. The MAC addresses are those of the adjacent MPLS router interfaces. The x8847 Ethertype value indicates that the frame contains a MPLS Unicast packet. A different Ethertype value (x8848) is used to identify MPLS Multicast packets. If the frame contained an 802.1Q VLAN tag, the format would change to that depicted in Figure 5 below. In both cases, the Ethertype values no longer identify the network-layer protocol type, which implies that, generally, the protocol type must be inferable from the MPLS label value(s) For example, when only one type of protocol is carried on a given LSP.

The approach is similar for Packet over SONET interfaces running PPP. In that case, the MPLS shim header follows the PPP Protocol ID (PID) field. A PID of x0281 is used to indicate MPLS Unicast, while a PID of x0283 identifies MPLS Multicast. MPLS can also take advantage of technologies that can carry labels in the link-layer header. For example, MPLS labels may be carried in the VPI/VCI fields of ATM cell headers. Frame relay provides another example, where a MPLS label may be carried in the DLCI field. More detailed information on MPLS encapsulations can be found in the RFC 3032, MPLS Label Stack Encoding.

MPLS Label Distribution Protocols
MPLS LSPs may be established via multiple protocols. The Label Distribution Protocol (LDP) was defined by the IETF specifically for this purpose. Additionally, RSVP has been enhanced to support LSP establishment, and label distribution may also be piggybacked onto BGP route exchanges. Each of these protocols will be discussed in this section, starting with LDP.

LDP
LDP includes a neighbor discovery protocol that runs over UDP. In the basic discovery mechanism, each LSR periodically multicasts a HELLO message to a well-known UDP port that all LSRs listen on. These HELLOs are transmitted to the all routers on this subnet multicast group. When a neighbor is discovered, a hello-adjacency is formed and the LSR with the numerically greater IP address is denoted as the active LSR.

Targeted LDP Sessions between non-directly connected LSRs are also supported via an extended discovery mechanism. In this case, Targeted HELLO messages are periodically sent to a specific IP address.

LDP can operate in Downstream-on-demand mode or Downstream Unsolicited mode. In the Downstream-on-Demand mode, label bindings are only distributed in response to explicit requests. Conversely, in the Downstream Unsolicited mode, an LSR may distribute label bindings to LSRs that have not specifically requested them. Architecturally, the difference between the two different LDP modes is significant, since the Downstream Unsolicited mode is often associated with a topology-driven strategy, where labels are routinely assigned to entries as they are inserted into the routing database. In either case, an LSR only uses a label binding to switch traffic if the binding was received from the current next hop for the associated FEC.

Both label advertisement disciplines may be concurrently deployed in the same network. However, for a given adjacency, the two LSRs must agree on the discipline.Negotiation procedures specify that Downstream Unsolicited mode be used when a conflict exists on Ethernet or PoS links.

Two other label distribution modes that merit discussion are Liberal versus Conservative Label Retention, and Ordered versus Independent LSP Control. In conservative label retention mode, an LSR retains only the label-to-FEC mappings that it currently needs (i.e., mappings received from the current next hop for the FEC). Conversely, LSRs keep all the mappings that have been advertised to them when operating in liberal label retention mode. The tradeoff is memory resources saved by conservative mode versus the potential of responding more quickly to routing changes that is made possible by liberal retention (e.g., when the label binding for a new next hop is already resident in memory).

With Independent LSP Control, each LSR makes independent decisions to bind labels to FECs. By contrast, in Ordered LSP Control, the initial label for a LSP is always assigned by the egress LSR for the associated FEC. More specifically, with Ordered LSP Control, an LSR only binds a label to a particular FEC if it is the egress LSR for the FEC, or if it has already received a label binding for the FEC from its next hop for the FEC. True to its name,the ordered mode provides a more controlled environment that yields benefits in regard to loop prevention and ensuring utilization of consistent FECs throughout the network.

More detailed descriptions of LDP operations can be found in RFC 3036, LDP Specification.

CR-LDP
Constrained base Routing –LDP (CR-LDP) is a set of extensions to LDP designed to support constraint-based LSP setup. The most significant extensions add support for specifying explicit routes and traffic parameters. Other extensions include support for resource classes, LSP preemption through setup/holding priorities, and route pinning.

An explicit route is a list of abstract nodes that a LSP must traverse, where an abstract node may be one node (identified by an IP address) or a group of nodes (sharing the same IP prefix or autonomous system number). CR-LDP supports both strict and loose explicit routes. If an abstract node is marked as strict, then it must be topologically adjacent to the preceding node in the explicit route. Conversely, if an abstract node is marked as loose, then any next hop that is along the path to that node may be taken. Thus, strict routes enable complete control of the nodes traversed by a LSP, while loose routes provide significant local flexibility in selecting the nodes that comprise selected portions of the path (which is useful when the originating node has imperfect knowledge of the entire path topology).

Traffic parameters identify resources that must be reserved for a LSP. The traffic characteristics of a LSP may be specified in terms of peak data rate/burst size, committed data rate/burst size, and service granularity. The data rates describe bandwidth requirements for the path, while the service granularity can be used to specify delay variation constraints. Support is provided for negotiation of the data rates at LSP establishment.

Preemption refers to the tearing down of one LSP in order to free the associated resources so that they can be used to establish another, higher priority, LSP. LSP preemption is supported through the setup and holding priority parameters. The holding priority of an existing LSP is compared against the setup priority of a newly requested LSP to determine if the new path can preempt the existing path. More detailed descriptions of CR-LDP operations can be found in the Internet Draft draft-ietf-mpls-cr-ldp-04.txt.

RSVP-TE
RSVP-TE is a set of extensions to the Resource reSerVation Protocol (RSVP).

RSVP defines procedures for signaling QoS requirements and reserving the resources necessary to provide the requested service. Basic RSVP is similar to LDP in the sense that requests follow the normal routed path in a hop-by-hop manner (i.e., reservation requests for a flow follow the same path through the network as the data comprising the flow, which is actually quite handy). RSVP reservations are unidirectional in nature,and the source initiates the reservation procedure by transmitting a PATH message containing a Traffic Specification (Tspec) object.The Tspec describes the source traffic characteristics in terms of peak data rate, average data rate, burst size, and minimum/maximum packet sizes.The PATH message may also contain an optional AdSpec object that is updated by network elements along the path to indicate information such as the availability of particular QoS services, the maximum bandwidth available along the path, the minimum path latency, and the path MTU. State is
installed at each device traversed by the PATH message, but no resources are reserved. Among other things, this state identifies the adjacent RSVP nodes,which pins down the path for the reservation. Resources are not actually reserved until the receiver responds to the PATH message with a RESV message.

Upon receiving a PATH message, a destination may examine the Sender’s Tspec and the AdSpec in conjunction with local status/policy information to determine the actual QoS specification that is to be included in the RESV message. The RESV message simply follows the reverse of the path established by the PATH message, and the appropriate resources are reserved at each node.

The RSVP-TE extensions enable RSVP to be used for traffic engineering in MPLS environments. The primary extensions add support for assigning MPLS labels and specifying explicit paths as a sequence of loose and strict routes. These extensions are supported by including Label Request and Explicit Route objects in the PATH message. A destination responds to a Label Request by including a Label object in its RESV message.Labels are then subsequently assigned at each node the RESV message traverses. Thus, RSVP-TE operates in Downstream-on-Demand Label Advertisement mode with Ordered LSP Control.

Other RSVP-TE extensions include support for resource affinities, LSP preemption through setup/holding priorities, record route/loop detection options, and rerouting/bandwidth-increase operations.

We have seen that RSVP-TE and CR-LDP are both evolving protocols, which now offer very similar functionality. At this point, it appears that RSVP-TE is winning in the marketplace, as it is currently much more widely deployed.

More detailed descriptions of RSVP-TE operations can be found in the Internet Draft draft-ietf-mpls-rsvp-lsp-tunnel-07.txt.

BGP-4
When BGP is used to distribute a particular route, it can also be used to distribute a MPLS label that is mapped to that route. The label mapping information is piggybacked in the BGP UPDATE message that is used to distribute the route. The MPLS labels associated with a route are encoded in the BGP-4 Multiprotocol Extensions attribute (which is defined in RFC 2283). A BGP speaker will not send MPLS label mappings to a particular peer unless that peer has indicated support for the mappings via BGP Capability Negotiation.

One obvious use for this capability occurs when two adjacent LSRs are also BGP peers. In that case, label distribution can be handled solely by BGP, without the need for any other label distribution protocol. The capability is also quite useful in supporting scalable VPNs.

More detailed descriptions of the procedures used to carry MPLS labels in BGP-4 can be found in the
Internet Draft draft-ietf-mpls-bgp4-mpls-05.txt.

Traffic Engineering
At its fundamental level, traffic engineering consists of the ability to control traffic flows in a network coupled with the ability to move traffic away from the shortest path calculated by the IGP to take advantage of less congested paths. Traffic engineering with MPLS also can add a process whereby information can be routed through the network according to an overall management view of available resources and the current/expected traffic loads. Figure 6 below shows a simple scenario where traffic following traffic engineered LSP is taking a different path from traffic following the shortest path calculated by the IGPs.

Enhanced traffic engineering can also be accomplished via MPLS by configuring explicit paths for LSPs by using RSVP-TE. Specific levels of bandwidth then can be reserved along RSVP-established LSPs by setting parameters for requested and minimum bandwidth limits. MPLS support can allow for specification of both “loose” and strictly specified LSP hops. In addition, with options for pre-establishing backup paths, the ingress LER can provide for fast reroute over an explicitly configured backup LSP.

MPLS traffic engineering capabilities can also be used to support load-balancing functions by providing for routing IP traffic across multiple explicitly configured LSPs that are bundled into a given Forwarding Equivalence Class (FEC). MPLS’s ability to flexibly define explicit LSP criteria can also be used in conjunction with advanced switch/router architectures to support QoS management objectives by assigning specific classes of service to LSPs with pre-determined bandwidth provisions.

These relatively straightforward traffic-engineering applications offer the most attractive opportunities for leveraging MPLS to enable both service providers and enterprises to improve overall networkmanagement and to better utilize available bandwidth.

Dynamic traffic engineering relies on extensions to link-state routing protocols that report information about the current bandwidth utilization of each network link. Traffic engineering extensions have been defined for both the IS-IS and OSPF routing protocols. The IS-IS extensions are defined in the Internet Draft draft-ietf-isis-traffic-02.txt, and the OSPF extensions are defined in the Internet Draft draft-katz-yeung-ospf-traffic-03.txt. The extensions designed for these two protocols are essentially identical in terms of functionality.

The OSPF extensions make use of Opaque LSAs (which are defined in RFC 2370). One new Opaque LSA Type is defined, the Traffic Engineering LSA. Traffic Engineering LSAs contain parameters that convey link information such as link type, link ID, local interface IP address, remote interface IP address, traffic engineering metric, maximum bandwidth, maximum reservable bandwidth, unreserved bandwidth,and resource color/class.

Making this information available is only part of the story. MPLS routers may then use the information to dynamically calculate explicit paths for LSPs that satisfy configured policies using a Constrained Shortest Path First (CSPF) algorithm (e.g., guarantee a specified minimum bandwidth for traffic traversing a particular egress LSR). The required resources can then be reserved along the path when the LSP is established (using a protocol such as RSVP-TE or CR-LDP).

BGP/MPLS VPNs
MPLS drafts suggest proposals for building Layer3 point to multipoint VPNs. Building such VPNs is NOT a straightforward task and requires numerous protocols and protocol extensions working hand in hand to achieve the desired connectivity. The recipe for L3 VPNs consists of a mix of the following ingredients:

As of the writing of this document L3 MPLS VPNs continue to be in experimental stages due to the lack of interoperable standards and the lack of consistent MPLS VPN implementation agreements. The following subsection introduces the basic concepts of BGP/MPLS VPNs as described in the Internet Draft draft-rosen-rfc2547bis-02.txt (which obsoletes RFC 2547). Figure 7 below contains an example network configuration that provides a framework for our discussion of BGP/MPLS VPNs. The figure depicts two VPNs, VPN 1 and VPN2, each of which is comprised of two sites. Note that the VPNs utilize overlapping IP address spaces drawn from the private address space defined in RFC 1918 (i.e., both VPNs use the same set of IP addresses).

The CE boxes shown in Figure 7 represent Customer Edge switches or routers, while the PE boxes are Provider Edge routers, and the P boxes are Provider routers. If the CE box is a router, then it need only peer with the adjacent PE router(s) (i.e., a CE router doesn’t need to peer with other CE routers in the VPN, which is a scalability advantage). The PE and P routers form the core MPLS network. The P routers only need to maintain routing information for the core MPLS net work (i.e., they do not maintain routing information for any of the VPNs, which is another scalability advantage). Conversely, the PE routers maintain per-site routing information and use BGP to cause VPN routes to be advertised to each other. Fortunately, for scalability reasons, the PE routers need only maintain routing information for the VPNs they are supporting (i.e., for the directly attached VPNs). Collectively, the scalability attributes of the model ensure that no single router needs to maintain routing information for all the VPNs.

Since a PE router can support multiple VPNs that may have overlapping address spaces, each PE router must maintain multiple layer-3 forwarding tables. These tables are referred to as VPN Routing and Forwarding tables (VRFs). According to the draft RFC, each site supported by a PE router must be mapped to a VRF. For simplicity, let’s assume that each site is a member of one VPN, and that the PE router is configured to associate a particular VPN with each physical interface to a CE router. In this case, the PE router maintains one VRF for each VPN, and frames received from a particular physical interface are forwarded using the VRF for the VPN associated with that interface.

The VRF for a particular VPN is populated in two ways: (1) when the PE router learns routes from a directly attached CE router that is a member of the VPN, and (2) when the PE router receives routes for the VPN via BGP. The PE router may learn the routes that are reachable at a particular CE router’s site via configuration or by routing protocol exchanges with the CE router. The draft RFC discusses configurations where the PE and CE routers are RIP peers, OSPF peers, or BGP peers.

As mentioned previously, PE routers use BGP to distribute VPN routes to each other. VPN route distribution makes use of the BGP-4 Multiprotocol Extensions, which enable BGP to carry routes from multiple address families. The VPN-IPv4 address family is introduced to support BGP/MPLS VPNs. A VPN-IPv4 address is a 12-byte quantity,beginning with an 8-byte Route Distinguisher (RD)and ending with a 4-byte IPv4 address. Use of the RD makes it possible to create distinct routes to a common IPv4 address prefix, which is necessary when the same IPv4 address prefix is used in two different VPNs.

The RD is not used to convey information about the set of VPNs to which the route is to be distributed. Instead, for scalability reasons, Route Target attributes are used for this purpose. A Route Target attribute can be thought of as identifying a set of VRFs. Every VRF is associated with one or more Route Target attributes. Export Targets identify the set of Route Targets that a PE router attaches to a route learned from a particular CE site. Import Targets identify the set of Route Targets that are used to determine whether a route received from another PE router can be inserted in a particular VRF. A VPN-IPv4 route is only eligible for installation in a particular VRF if there is a Route Target that is both one of the route’s Route Targets and one of the VRF’s Import Targets. Thus, Route Targets are the mechanisms that enable each PE router to only maintain routing information for the VPNs it is supporting. The use of Import Targets and Exports Targets also provides considerable flexibility in constructing a variety of VPN topologies (such as a fully meshed closed user group, or a hub-and-spoke architecture). Route Targets are encoded as BGP Extended Communities attributes.

When distributing a VPN route via BGP, a PE router includes its own IP address as the BGP Next Hop.The PE router also always assigns and distributes a MPLS label for each VPN route. Use of the BGP-distributed MPLS labels requires that there be a label switched path between the PE router that installs the BGP-distributed route and the PE router that is the BGP Next Hop of that route. This is necessary because a two-level label stack is used to forward VPN packets across the MPLS backbone.

The outer MPLS label gets the packet across the backbone. This label is obtained from the backbone IGP and is associated with the best route to the BGP Next Hop address of the PE Router that advertised the VPN route. The inner MPLS label is obtained from BGP and is associated with the best route to the VPN destination address. At a minimum, this label identifies the VRF that the egress PE Router will use to forward the packet to a CE device, and may indicate the outgoing interface that the packet should be forwarded over (along with the appropriate link layer header for that interface).

The above-described use of a two-level MPLS label stack is an important scalability attribute of the model, because it is the two-level label stack that enables the P routers to operate without containing routes for any of the VPNs.

Summarizing, key aspects of the BGP/MPLS VPN model include:

MPLS in Metropolitan Area Networks
MPLS has been primarily driven by the complexity of WAN backbones and until relatively recently, much of the evolution of MPLS has focused on implementing label switching as a WAN technology. This has been driven by a number of factors including:

The WAN has become a complex environment with too many physical paths to accommodate for redundancy and reroutes in case of failures. The complex physical connectivity coupled with the dynamic behavior of Internal Routing Protocols (IGP) has created networks that ha

ve a “mind on their own” with unpredictable traffic behavior and inefficient utilization of link resources.

MAN Environment
The MAN has traditionally been a “circuit ” based network built with Time Division Multiplexing ((TDM) technologies optimized toward transporting voice. The MAN consisted of Digital Cross Connects (DCS) and Add Drop Multiplexers (ADMs) connected in rings and offering leased line services.

In the last couple of years the MAN has been transforming to a “packet” based network offering high-speed broadband services over an optimized IP and Optical infrastructure. Figure 8 below shows a Next Generation MAN topology consisting of Extreme Networks BlackDiamond switch routers offering IP services over glass, i.e.over fiber optic infrastructure.

Migrating MPLS to the MAN: Balancing Simplicity vs. Complexity
As MPLS moves into Metropolitan Area Network environments, the situation is quite different from the WAN, thereby requiring a different focus in order to derive optimal benefits from MPLS. Although MPLS helps to overcome complexity in the WAN, attempting an across-the-board full-blown MPLS implementation in the MAN can actually add complexity by working against many of the performance and flexibility benefits already achieved via wire-speed L2/L3 switch router systems.

Effective migration of MPLS into MAN environments must focus on leveraging label switching technologies to complement existing high-speed switch router systems in order to add needed capabilities without adding unneeded layers of complexity.

The two main applications for the MAN have been Transparent LAN services (TLS)and Internet connectivity. With Ethernet emerging as a MAN technology, the simple VLAN mechanism used in a LAN environment are scaling to support the TLS and VPN requirements of the MAN. Extreme Networks has deployed numerous MAN TLS and point-to-multipoint VPNs and Internet connectivity services using the inherent Ethernet mechanisms such as 802.1Q tagging and 802.1Q tunneling as well as the ability to handle L2 TLS traffic AND L3 routed Internet traffic on the same physical network. If we take a deeper look at Ethernet we would realize that most of the schemes that MPLS is trying to achieve already exist in an Ethernet L2/L3 environment, for examples:

Extreme Networks offers mechanisms such as Virtual MANs (vMANs™) to scale Layer2 topologies and to allow end-user information hiding. vMANs aggregate end user VLANs into bigger trunks hiding the detailed end user information from the MAN operator, allowing for simpler and more manageable network deployments. Figure 9 below shows the vMAN concept offering point-to-multipoint VPNs for customers A and B who have multiple sites as well as Internet connectivity to ISPs A and B respectively.

Notice how the bigger vMAN trunks hide the end user information from the MAN operator.

Opportunities for Leveraging MPLS VPNs in the MAN
In practical terms for MAN network implementers, the most promising near-term opportunities for deriving benefits from MPLS lie in the ability to extend the MAN traffic across an MPLS WAN. Extreme Networks is leveraging its expertise in building MANs for the flexible creation and efficient management of IP-based Virtual Private Networks that can be transparently tunneled across the WAN. For MAN service providers, these applications offer the most immediate paths to developing enhanced revenue opportunities from deployment of MPLS.

Extreme offers a simple software and hardware upgrade towards MPLS to leverage the existing installed infrastructure and to offer a migration path toward full blown MPLS implementation once MAN environments catch up to the complexities of the WAN.

Tunneling MAN Traffic Across MPLS Clouds
MAN operators have found a special need to tunnel Layer 2 traffic across an MPLS backbone. Extreme Networks offers the first Switch Router implementation allowing the mapping between L2 VLANs and MPLS LSPs and maintaining QoS mappings between 802.1Q and MPLS COS parameters. Figure 10 below shows how L2 MANs can be tunneled over an MPLS Network. The L2 VLANs are tunneled into MPLS LSPs. In addition the ability to map 802.1p QOS into MPLS Class of Service bits can ensure service level agreements across the MPLS network.

MPLS Solutions from Extreme Networks
As an active participant in the MPLS Forum and IETF, as well as the foremost developer of advanced multi-layer IP switch/router solutions, Extreme Networks is currently at the forefront of implementing leading-edge real-world MPLS solutions. Fundamental components of the Extreme Networks MPLS initiative include:

Scalable and Extensible MPLS Hardware Architecture
Extreme Network’s approach to providing MPLS solutions begins with the use of flexible modular hardware solutions, which allow customers to smoothly migrate toward the robust deployment of MPLS functionality, while building upon their existing equipment investments and established network architectures.

The basic building block for implementing MPLS within the existing Extreme Networks BlackDiamond architecture is a new hardware module known as the MPLS module. The MPLS module plugs into the BlackDiamond chassis as any other switch module or line card. Optimized for handling MPLS labels,the MPLS module process MPLS traffic with special purpose programmable hardware engines combining the flexibility of deploying IP services with the performance of high-speed data optimized hardware engines. By decoupling the MPLS processing from other system functions, the MPLS module-based architecture preserves all existing Layer2 and Layer3 functionality, while providing dedicated high-speed MPLS throughput.

Because the MPLS module approach offers a modular, incremental solution for deploying MPLS, customers can tailor the implementation of label switching capabilities based upon their real-world requirements rather than having to make sweeping new system investments to get MPLS functionality. Overall MPLS forwarding throughput can be smoothly scaled up simply by adding multiple MPLS modules, with up to four modules per BlackDiamond system. This modular deployment flexibility can be
especially important in MAN-level environments, where service providers need to selectively introduce new capabilities such as MPLS, while simultaneously balancing their investments against the incremental revenue-generation opportunities.

Leveraging the inherent flexibility of the modular MPLS hardware architecture in combination with a rich software environment, Extreme’s switches can efficiently provide both LER and LSR capability on all ports. MPLS functionality can be enabled or disabled on a per VLAN basis. In addition, multiple MPLS-based L2 VLANs can be efficiently aggregated using Extreme’s proven VirtualMAN (VMAN) capabilities.

Charting an Extensible MPLS Roadmap
As a leader in developing advanced IP switch/router solutions for enabling both service providers and enterprises to optimize MAN-level and LAN-level environments, Extreme Networks has focused initial MPLS offerings on delivering flexible and robust solutions for implementing VPNs and instituting basic traffic engineering functions. Scalability, configurability, and cost-effectiveness have been the driving primary objectives embodied in the initial MPLS offerings for the BlackDiamond architecture.

However, at the same time,these initial Extreme Networks MPLS solutions are designed to provide a solid foundation and extensible architecture for expanding and enhancing MPLS capabilities as both the market requirements and the state of MPLS standards continue to evolve. By creating modular incrementally deployable MPLS solutions targeted squarely at the applications that can provide the greatest immediate payoff, Extreme is continuing our commitment to delivering real-world results. Furthermore, by continuing to play a key leadership role in the MPLS Forum, the IETF and in other standards-setting efforts, Extreme Networks is simultaneously helping to define and extend the opportunities for bringing into reality an expanded set of future MPLS benefits.