MPLS VPN Topologies

 < Day Day Up > 



As MPLS developed, it became apparent that MPLS VPNs could provide a flexible VPN solution to service providers and ISPs alike. In order to meet these needs, the Layer-3 MPLS VPN was developed.

MPLS VPN topology and design has developed rapidly. Over the past few years, MPLS VPNs have grown from Layer-3 VPNs into variety of options, including any-to-any protocols, such as Cisco’s AToM (Any Transport over MPLS). The proliferation of VPNs at both Layer-2 and Layer-3 has led to much confusion. Figure 7.16 represents a top-layer drawing of the VPN tree showing the relationship of Layer-2 and Layer-3 VPNs. The drawing shows current relationships at the time of printing; however, it should continue to serve as a top-level view of MPLS VPNs.

click to expand
Figure 7.16: The Layers of VPNs (The VPN Tree)

As you can see from the drawing, there are many VPN solutions. We will work our way through this chart to discover how MPLS developed historically, define its concepts, and identify the benefits and challenges of each of the various MPLS VPN solutions.

Layer 3 MPLS VPNs

Before we talk about the details of MPLS Layer-3 VPNs, we need to introduce a model of VPN called the Peer Model. In the Peer Model, the PE and CE are peers, i.e., they exchange IP routing information in a peer-to-peer relationship. The VPN tunnels are established in the core of the MPLS network.

In Figure 7.15, we saw that the CE communicates to the PE using standard routing protocols, which could be static or dynamic IGP protocols. Within the core of the network, tunnels are established between PEs. At the egress end, we see the PE and CE again communicate as peers. For the time being, we will not cover the particular method of tunnel building inside the core of the network since this method can vary depending upon the customer’s needs and which vendor’s system is selected.

Referring again the MPLS VPN tree (Figure 7.16), we see the MPLS Layer-3 VPNs on the left of the drawing with two modes under it: RFC 2547 and Virtual Routing.

RFC 2547

RFC 2547 has a simple data flow as shown. Figure 7.17 and Fig 7.18 show the flow of data across a Layer- RFC 2547 VPN. Native IP data is sent to PE1. PE1 adds the VPN label mapping to the interface and customer. PE1 then assigns an LSP and an MPLS label for that path.

click to expand
Figure 7.17: RFC 2547 Data Flow, Steps 1 and 2

click to expand
Figure 7.18: RFC 2547 Data Flow, Steps 3 and 4

A virtual fully meshed network is established across the core network using extensions to the BGP protocol. This allows for simplification of the core routing exchange and service providers are able to use a protocol with which they are familiar.

In Figure 7.19 and 7.20, we see that the routing scheme works as follows: The CE is connected to a PE and exchanges routing tables using any one of a number of interior routing protocols (IRP), including RIP, OSPF, IBGP, EIRGP. The routing tables are sent to the far-end PEs via a BGP. At the far end, the PE routers send the forwarding tables to the CE routers.

click to expand
Figure 7.19: RFC 2547 Routing Exchange, Steps 1 and 2

click to expand
Figure 7.20: RFC 2547 Routing Exchange, Steps 3 and 4

A challenge arises when sites have internal IP addresses (as permitted by RFC 1918). In order to keep these sites separate, the PEs add a route designator to the IP address as illustrated in Figure 7.21

click to expand
Figure 7.21: Independent IP Address

click to expand
Figure 7.22: Independent IP Address with Router Designator

RFC 2547 has gained significant community acceptance. However, there are two shortfalls to this procedure (see Table 7.2):

Table 7.2: RFC 2547 Summary

click to expand

  1. The customer’s routing tables are exposed to the service provider.

  2. Since all connections are advertised using one instance of BGP across the core, a misconfiguration could result in exposure of competitors’ information and data.

Virtual Routing

An alternative to RFC 2547 is the Virtual Router (VR) architecture (Figure 7.23). In this architecture, each PE maintains a virtual router for each VPN forwarding table. Fully meshed tunnels are advertised across the core using VR protocols.

click to expand
Figure 7.23: Virtual Routing Network Drawing

Table 7.3 illustrates how the VR approach establishes tunnels between each site. The core of the MPLS network does not combine data from several sites. Since the data is kept separate, this design has the added benefit of additional security in that a misconfiguration will not impact security of the data. The downside of this design could prove to be one of scalability and the need for complex configuration.

Table 7.3: Virtual Routing Summary

click to expand

In summary, Virtual Routing has some of the advantages of RFC 2547 and it provides security against accidental misrouting in the core network. The tradeoff is that the configuration is more complex.

Layer-2 VPNS

Businesses in the marketplace found that Layer-3 VPNs met only part of the end users’ requirements. Back in the early days of MPLS implementation, early adopters of the technology discovered that there was a market demand for Layer-2 VPNs as well.

Layer-3 VPNs worked well for a number of customers; however, there was a significant percentage of the marketplace using legacy systems and networks for whom a Layer-2 VPN solution would be better suited. As these needs were identified, different architectures were suggested for MPLS Layer-2 VPNs, including Virtual Private Wire Service (VPWS) and Virtual Private LAN Services (VPLS).

Referring to the VPN Tree (Figure 7.24), we can see that there are several types of Layer-2 VPNs. We will first address VPWS, VPLS, and IPLS followed by the supportive technology under each category.

click to expand
Figure 7.24: VPN Tree

Virtual Private Wire Service (VPWS)

VPWS is a strong market alternative to FR and ATM services. In VPWS, the service providers provide a pseudo-wire across the network. This overlay model provides circuit emulation from customer to customer. It provides services similar to ATM and FR; however, significant cost savings can be realized using MPLS VPWS over these alternative methods. A functional top level view of VPWS is provided in Figure 7.25.

click to expand
Figure 7.25: VPWS Network Design

For MPLS carriers wishing to capture the FR and ATM market place, VPWS offers rapid service conversion. Customers will be able to maintain their FR or ATM connection with the same equipment. The difference is that traffic will now be carried encapsulated in an MPLS header and run over an MPLS network.

In the summary of VPLS (see Table 7.4), we find that VPWS provides substantial Layer-2 traffic compatibility. It interfaces well with FR, ATM, HDLC, and PPP. There remain some questions regarding scalability.

Table 7.4: VPWS Summary

click to expand

Virtual Private LAN Service (VPLS)

In this version of MPLS VPN solutions, we find a great use for metro and extended campus applications. Ethernet LANs interface to the CE, which provides a core that acts like a Layer-2 Bridge. In a VPLS, the MPLS core can connect sites on a point-to-multipoint basis. The CE at the ingress side simply reviews Layer-2 addresses and forwards information to the CE on the egress side based upon Layer-2 switching or bridging tables as seen in Figure 7.26.

click to expand
Figure 7.26: VPLS Network

In Table 7.5, we see that VPLS acts like a big bridge. In this type of network design, we must consider the scalability of extended LAN services and the disadvantages of flat networks. However, VPLS offers advantages to switched campus environments.

Table 7.5: VPLS Summary

click to expand

IP LAN Services (IPLS)

What if the customer site does not have a Layer-2 switch, but instead has a router? The simple VPLS solution will not work in that case. Thus creating a place for additional VPN service called IP LAN Service (IPLS). In this network design, the CE devices are routers, but instead of using the IP address at the ingress of the network, forwarding decisions are based upon the MAC or Layer-2 address (Figure 7.27).

click to expand
Figure 7.27: IPLS Network

Table 7.6: IPLS Summary

click to expand

IPLS operates in a very similar manner to VPLS, but it is reserved for IP traffic only. The customer’s equipment are routers, but the PEs evaluate Layer-2 addresses making IPLS a Layer-2 VPN technology. Several different groups have predicted the marketplace for this service. These predictions vary from a acquiring a significant market share to meeting the needs of less than 1% of the marketplace. Only time will tell.

Martini

When we talk about the different offerings for MPLS VPNs, the discussion of Martini versus Kompella always comes up. How can we compare apples to oranges? The Martini draft protocols are really two sets of protocols: a transport set and an encapsulation set. These protocols combine together to form the Martini suite. This suite is designed primarily for point-to-point operations offering a viable alternative to non-meshed FR and ATM networks.

A block diagram of Martini is shown in Figure 7.28. The incoming traffic is configured into an assigned VC and a control word as shown in Figures 7.29 and 7.30. The unique feature of Martini is not the VC word, but the control word. The control word allows MPLS to carry the L2 control bits as would be carried in FR or ATM.

click to expand
Figure 7.28: Martini Block Diagram

click to expand
Figure 7.29: Martini Header

click to expand
Figure 7.30: Martini Header (Detailed)

In Figure 7.30, we see the data flow across an MPLS Martini network. Notice in the Martini header details of Figure 7.29 and 7.28 that there is a portion reserved for signaling protocols. This allows the MPLS network to carry standard ATM and FR signals across the core. Martini supports and preserves FR markings and tags, including FECN, BECN, and DE. It also allows for QoS marking.

As shown in Figure 7.31, the LDPs make paths that are akin to multi-lane highways or tunnels. The VPNs travel down lanes, or virtual channels (VCs), within the highways.

click to expand
Figure 7.31: Martini Tunnels

This methodology requires an MPLS label for the LDP, another label for the VC, and an optional control word.

For a Layer-2 protocol, the use of tunnel-method routing is not required. Martini L2 VPNs are scalable, and do not involve complex routing issues; however, they do involve relatively complex configurations especially for fully meshed networks. Martini is best suited for point-to-point operations as shown in Martini summary chart (see Table 7.7).

Table 7.7: Martini Summary

click to expand

Kompella

Kompella’s Draft RFCs support the following Layer-2 protocols: ATM, HDLC, Ethernet, Ethernet VLANs, Frame Relay, and PPP.

The core network must first establish routing and switching and full mesh network of connections must be made with extended BGP as shown in Figure 7.28. The PEs communicate with other PEs using BGP to exchange routing and switching tables.

In Kompella’s protocol suite, the flow of data across the network looks like most MPLS tunneling protocols. In this case (Figures 7.32 and 7.33), the flow starts from the PE-1, where a packet is received on a sub-interface and is mapped to both an LSP and the egress PE (PE-2). PE-2 learns the routers of CE-2 via BGP.

click to expand
Figure 7.32: Kompella Routing and Forwarding Exchange

click to expand
Figure 7.33: Kompella Data Flow, Steps 1 and 2

click to expand
Figure 7.34: Kompella Data Flow, Steps 3 and 4

Kompella’s battle cry is “keep it simple.” Among all the offerings, Kompella’s is the simplest to establish. In the table in Table 7.8, we see that this protocol offers good features with less complexity than other protocols.

Table 7.8: Kompella Summary

click to expand

AToM

The IETF defined Architecture for Layer-2 VPNs, and Cisco developed a product to meet those requirements in “Any Transport over MPLS (AToM).” When a “datacommer” first hears of AToM, the acronym may be confusing because the OSI model has a Transport layer at Layer 4. However, AToM has nothing to do with OSI layer 4. It is designed to carry any Layer-2 traffic across the network and connect with any other Layer-2 traffic.

AToM uses a pseudo-wire concept to link Layer-2 protocols across the MPLS core. It can link TDM circuits, Frame Relay, ATM and Ethernet. Currently, AToM supports the following protocols:

ATM AAL5 over MPLS (AAL5oMPLS)

ATM Cell Relay over MPLS (CRoMPLS)

VLAN over MPLS (EoMPLS)

PPP/HDLC over MPLS (PPP/HDLCoMPLS)

In the near future, with the release of Phase Two, AToM will support any-to-any connections that will allow dissimilar protocols to cross over. For example, Frame Relay will be able to talk to ATM. This service will be provided by using emulation.

Figure 7.35 provides a block diagram of an AToM network. The data is carried in packets called protocol data units (PDUs). These PDUs are encapsulated at the ingress PE and forwarded to the egress PE. The pseudo-wire carries all the data and supervisory information needed to provide Layer-2 services.

click to expand
Figure 7.35: AToM Network

Point-to-point emulation is the focus of the pseudo-wire standards and the key to AToM services. With a basic understanding of the Martini standards, we can see how AToM works.

In the summary chart provided in Table 7.9, we can see that the major advantage of AToM is that it is a point-to-point, any-to-any protocol that will be able to accommodate service providers needs in years to come. The major disadvantage is that is a vendor proprietary.

Table 7.9: AToM Summary

click to expand



 < Day Day Up > 



Rick Gallagher's MPLS Training Guide. Building Multi-Protocol Label Switching Networks
Rick Gallahers MPLS Training Guide: Building Multi Protocol Label Switching Networks
ISBN: 1932266003
EAN: 2147483647
Year: 2003
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net