The previous two chapters showed that you can deploy MPLS using different modes of operation. Chapter 2, "Frame-mode MPLS Operation," details how MPLS operates across framed interfaces, and Chapter 3, "Cell-mode MPLS Operation," shows how MPLS operates natively across ATM media.
The Layer 2 infrastructure, which provides the media over which Frame-mode MPLS can operate, often can be supplied through the use of switched WAN technology, such as Frame Relay or ATM. You can run MPLS in Cell-mode across ATM but not when using Frame Relay or when the ATM structure is built using traditional ATM Forum PVCs. This means that it must be possible to run Frame-mode MPLS across these types of interfaces so you can deploy MPLS end-to-end across the network.
This chapter considers the deployment of MPLS across Frame Relay interfaces and ATM PVCs. It also considers the use of Frame-mode and Cell-mode MPLS across the same physical interface; this functionality can be useful during a migration to the MPLS architecture, as you'll learn in Chapter 6, "MPLS Migration and Configuration Example."
Frame-mode MPLS Operation Across Frame Relay
Frame Relay is a widely deployed switched WAN technology that provides, in its basic form, a connection-oriented protocol between a service provider switch port and a customer premises equipment (CPE) device. This means basically that a session, or virtual circuit (VC), must be established before any data flow can commence across the Frame Relay network. The VC acts as a point-to-point link for purposes of data forwarding between connected CPE devices.
Using these VCs, you can establish MPLS forwarding and label distribution between two endpoint devices in exactly the same way as over any other type of interface that operates in Frame-mode. This means that the label distribution across the interface is unsolicited downstream with independent label control. Figure 4-1 provides an example of this type of connectivity.
Figure 4-1 MPLS Connectivity Across Frame Relay PVCs
Figure 4-1 illustrates two routers connected across a Frame Relay network. If you
concentrate on the San Jose router, you can see that it addresses the VC using a Data Link Connection Identifier (DLCI) of 164 and uses this VC to exchange routing protocol
information and to learn and distribute MPLS label forwarding information. From this router's perspective, any routes learned from its routing protocol neighbor across this VC (Paris in this case) have a next-hop forwarding address pointing to the Paris router.
When the San Jose router builds its LFIB, it uses the labels that it received across its TDP/LDP session with the Paris router to forward traffic to any FECs that it determines are reachable via the Paris router. You can see the relevant configuration of the San Jose router in Example 4-1.
Example 4-1 MPLS Across Frame Relay Router Configuration
hostname San Jose
!
interface serial 1/0
description ** interface to Paris no ip address
encapsulation frame-relay
!
interface Serial0/1.1 point-to-point ip address 146.4.1.18 255.255.255.252 tag-switching ip
frame-relay interface-dlci 164
To confirm the TDP relationship between the two routers, use the show tag-switching tdp neighbor command, as shown in Example 4-2. This command confirms that your TDP session is established across the Frame Relay interface and that unsolicited downstream label distribution is in effect.
Example 4-2 Confirmation of TDP Relationship Between Two LSRs Across Frame Relay
San Jose# show tag-switching tdp neighbor
Peer TDP Ident: 194.22.15.1:0; Local TDP Ident 194.22.15.2:0 TCP connection: 194.22.15.1.711 – 194.22.15.2.11363
State: Oper; PIEs sent/rcvd: 124/123; ; Downstream Up time: 01:43:37
TDP discovery sources:
Serial0/1.1
Addresses bound to peer TDP Ident:
146.4.1.17 196.7.25.1 194.22.15.1 10.2.1.13 There are two ways to encapsulate IP packets across a Cisco Systems, Inc.,
implementation of Frame Relay. The first is to use Cisco encapsulation (the default) and the second is to use RFC 1490 (IETF) encapsulation. MPLS forwarding and control functions across either encapsulation. Figure 4-2 shows the two encapsulation methods and how the MPLS information is added to the frame.
Figure 4-2 MPLS Encapsulation Across Frame Relay
Frame-mode MPLS Operation Across ATM PVCs
In certain circumstances, such as during a transition to a full IP+ATM MPLS environment, or if transit ATM switches do not support MPLS, it might be desirable to run MPLS in Frame- mode across ATM PVCs. This is a perfectly valid configuration although it suffers from the same scaling issues (due to the high number of VCs) as running IP over ATM in an overlay mode.
This type of connectivity, from an MPLS perspective, is essentially the same as described within the previous Frame Relay section. The label allocation scheme uses independent mode, and the distribution of labels uses unsolicited downstream. Figure 4-3 shows an example of this type of connectivity.
Figure 4-3 MPLS Connectivity Across ATM PVCs
You can see from Figure 4-3 that the San Jose and Paris routers are connected across a point-to-point ATM PVC. Again, using the show tag-switching tdp neighbor command confirms that unsolicited downstream label distribution is in effect across the interface and, therefore, MPLS is operating in Frame-mode. You can see this output in Example 4-3 and you can see the relevant configuration of the San Jose router in Example 4-4.
Example 4-3 Confirmation of TDP Relationship Between Two LSRs Across an ATM PVC
San Jose# show tag-switching tdp neighbor
Peer TDP Ident: 194.22.15.1:0; Local TDP Ident 194.22.15.2:0 TCP connection: 194.22.15.1.711 – 194.22.15.2.11064 State: Oper; PIEs sent/rcvd: 6557/6559; ; Downstream Up time: 3d23h
TDP discovery sources:
ATM0/0/0.1
Addresses bound to peer TDP Ident:
146.4.1.17 196.7.25.1 194.22.15.1 10.2.1.13
Example 4-4 MPLS Across ATM PVC Router Configuration
interface ATM0/0/0 no ip address
!
interface ATM0/0/0.1 point-to-point description ** interface to Paris ip address 146.4.1.18 255.255.255.252 pvc 0/36
encapsulation aal5snap !
tag-switching ip Note
Running MPLS across an ATM Forum PVC requires AAL5SNAP encapsulation on that PVC. AAL5MUX encapsulation does not work because packets of two different protocols
(pure IP control packets and labeled data packets) are exchanged over the same VC.
Chapter 2 details the specific encapsulation across ATM.
Frame-mode and Cell-mode MPLS Across the Same ATM Interface
It might be desirable in some deployments of the MPLS architecture to run both Frame- mode and Cell-mode MPLS across the same physical ATM interface, for example when linking two private MPLS-enabled ATM networks across a public ATM network that offers only ATM Forum PVC services. You can see how this feature can be used in the migration of an ATM network toward MPLS in the migration example in Chapter 6.
This type of connectivity is possible through the use of sub-interfaces with different sub- interface types on the router's ATM interface configuration. These sub-interfaces can be configured to run Cell-mode MPLS (sub-interface type tag-switching), or they can be configured to run Frame-mode (sub-interface type point-to-point). Figure 4-4 illustrates this technique.
Figure 4-4 Frame-mode and Cell-mode MPLS Across the Same ATM Interface
The example topology in Figure 4-4 shows that the San Jose and Paris routers have a point-to-point PVC connection between them but they also run Cell-mode MPLS directly with the MPLS ATM switch. This is achieved through the use of two separate ATM sub- interfaces. Example 4-5 shows the configuration of the San Jose router in this
environment.
Example 4-5 Configuration of Frame-mode and Cell-mode MPLS on the Same ATM Interface
interface ATM0/0/0 no ip address
!
interface ATM0/0/0.1 point-to-point
description ** ATM PVC interface to Paris
ip address 146.4.1.18 255.255.255.252 pvc 0/36
encapsulation aal5snap !
tag-switching ip
!
interface ATM0/0/0.2 tag-switching
description ** cell-mode interface to adjacent ATM-LSR ip unnumbered Loopback0
tag-switching ip
Summary
In this chapter, you see how you can run MPLS across traditional WAN media, be it a Frame Relay network or an ATM network supporting only ATM Forum permanent VCs. In both cases, MPLS runs directly between routers connected to the WAN network and the WAN switches are not aware of MPLS being transported across the WAN network.
MPLS over a Frame Relay network or an ATM Forum PVC is configured as Frame-mode MPLS and the LDP/TDP session is established directly between routers connected to the WAN network. The routers use standard Frame-mode label allocation and distribution procedures and forward labeled packets as frames with the standard label header (like any other datagrams, these frames obviously are transported as cells across the ATM network).
There are several benefits gained by running MPLS in Frame-mode across a WAN network:
• You can use the existing WAN infrastructure for transporting labeled packets.
• You can run MPLS across ATM networks that are not yet MPLS-enabled or across public ATM networks that do not support MPLS services.
• The migration of ATM networks toward MPLS becomes simple as the Frame-mode MPLS between routers offers a very convenient first transitional step.
The drawback of running MPLS across a WAN network in Frame-mode is also obvious—
you're again faced with the scalability issues of the large WAN networks discussed in Chapter 1, "Multiprotocol Label Switching (MPLS) Architecture Overview."