This section looks at the configuration tasks for enabling the Frame Relay PIPQ feature on Cisco routers. Take note that Frame Relay Traffic Shaping or FRF.12 is not required for Frame Relay PIPQ to work. Frame Relay PIPQ can work with or without these features. However, recall that when Frame Relay Traffic Shaping is enabled on a Frame Relay interface, the two-level queuing hierarchy is created on the interface. With Frame Relay Traffic Shaping and the two-level queuing structure, the interface-level queue is a FIFO queue, whereas the PVC-level queue can support other queuing methods, such as WFQ. Enabling Frame Relay Traffic Shaping with FRF.12 converts the interface-level FIFO queue to a Dual-FIFO queue, whereby unfragmented voice packets go into the high-priority FIFO queue, and fragmented data packets are queued in the low-priority FIFO queue.

With Frame Relay PIPQ, the four-queue interface-level PQ system replaces the FIFO queue or the Dual-FIFO queue created at the interface when Frame Relay Traffic Shaping and Frame Relay FRF.12 Fragmentation are enabled concurrently. In the Dual-FIFO queue system, depending on whether packets carried on the PVC are fragmented, FRF.12 prioritizes and separates the unfragmented voice packets and fragmented data packets into the high-priority and the low-priority interface queues, respectively. When assigning priority, in contrast with FRF.12, Frame Relay PIPQ does not take into consideration whether packets are fragmented or not. When FRF.12 is configured together with Frame Relay PIPQ, both voice packets and fragmented data packets carried by the same Frame Relay PVC go into an interface-level priority queue preassigned to that PVC by Frame Relay PIPQ. Although the Frame Relay PIPQ feature is independent of Frame Relay FRF.12 Fragmentation, it is always useful to enable FRF.12 on the Frame Relay PVC carrying voice traffic to prevent an unexpected large packet from causing latency or jitters for the mainstream voice packets.

Table 17-1 summarizes the various interface-level queuing mechanisms that result from enabling certain Frame Relay features.

Table 17-1. Interface Queuing Strategy for Frame Relay
Frame Relay Features	Interface Queuing Strategy
Frame Relay encapsulation without any features	If the interface speed is lower than E1, default is WFQ queuing. If the interface speed is greater than E1, default is FIFO queuing.
Frame Relay Traffic Shaping	FIFO queuing.
Frame Relay FRF.12 with FRTS	Dual-FIFO queuing.
Frame Relay PIPQ (with or without FRTS or FRF.12)	Interface PQ.

To configure the Frame Relay PIPQ feature on a Cisco router, perform the following configuration steps, beginning from the global configuration mode:

Step 1.     In the global configuration mode, first set up the PVC priority within a Frame Relay map class. Specify the map-class name with the map-class frame-relay map-class-name command. This enters you into the map-class configuration mode.

Step 2.     In the map-class configuration mode, assign a PVC priority level to a Frame Relay map class with the frame-relay interface-queue priority {high | medium | normal | low} map-class configuration command. When the map class is subsequently assigned to a Frame Relay DLCI, the configured priority level in the map class determines the PVC priority level for the traffic transported on that DLCI.

Step 3.     Enable Frame Relay PIPQ at the interface level with the frame-relay interface-queue priority [high-limit medium-limit normal-limit low-limit] interface configuration command. The queue limit of the four priority queues can be adjusted with this command. Otherwise, the default queue limits for the high, medium, normal, and low queues are 20, 40, 60, and 80, respectively. If frame-relay interface-queue priority is not enabled at the interface level, configuring PVC priority within a map class is not effective.

Step 4.     The final step is to assign the configured Frame Relay map class to the individual Frame Relay PVC. The class map-class-name configuration command can be used to assign a Frame Relay map class directly to an individual Frame Relay PVC. Additionally, the frame-relay class map-class-name interface configuration command can be used to assign a Frame Relay map class to all Frame Relay PVCs created on a main interface or subinterface.

Figure 17-5 depicts the network diagram used to verify Frame Relay PIPQ. Example 17-7 shows the configuration commands of the routers in the diagram.

Example 17-7. Configuration Commands of the Routers Used for Demonstrating Frame Relay PIPQ in Figure 17-5
! Router R1:

<output omitted>

interface FastEthernet0/0
 ip address 10.0.0.3 255.255.255.0
 ip policy route-map WEB_TRAFFIC
 !
interface Serial4/0
 no ip address
 encapsulation frame-relay
 frame-relay interface-queue priority
!
interface Serial4/0.102 point-to-point
 ip address 172.16.1.1 255.255.255.252
 frame-relay interface-dlci 102
  class HIGH
!
interface Serial4/0.103 point-to-point
 ip address 172.16.2.1 255.255.255.252
 frame-relay interface-dlci 103
  class MEDIUM
!
interface Serial4/0.104 point-to-point
 ip address 172.16.1.5 255.255.255.252
 frame-relay interface-dlci 104
  class LOW
!
interface Serial4/0.105 point-to-point
 ip address 172.16.2.5 255.255.255.252
 frame-relay interface-dlci 105
class NORMAL
!
router ospf 1
 area 1 stub
 passive-interface FastEthernet0/0
 network 10.0.0.0 0.0.0.255 area 1
 network 172.16.1.4 0.0.0.3 area 0
 network 172.16.2.0 0.0.0.3 area 0
 network 172.16.2.4 0.0.0.3 area 0
 !
map-class frame-relay MEDIUM
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority medium
!
map-class frame-relay NORMAL
 no frame-relay adaptive-shaping
!
map-class frame-relay LOW
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority low
!
map-class frame-relay HIGH
 no frame-relay adaptive-shaping
 frame-relay interface-queue priority high
!
access-list 101 permit tcp any any eq www
!
route-map WEB_TRAFFIC permit 10
 match ip address 101
 set ip next-hop 172.16.2.2
!
route-map WEB_TRAFFIC permit 20
!
!
!
dial-peer voice 1 pots
 destination-pattern 4001
 port1/0
!
dial-peer voice 2 voip
 destination-pattern 4002
 session target ipv4:172.16.1.2
________________________________________________________________
! Router R2:

<output omitted>

interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 !
interface Serial2/1
 no ip address
 encapsulation frame-relay
 !
interface Serial2/1.201 point-to-point
 ip address 172.16.1.2 255.255.255.252
 frame-relay interface-dlci 201
!
interface Serial2/1.401 point-to-point
 ip address 172.16.1.6 255.255.255.252
 frame-relay interface-dlci 401
 !
router ospf 1
 network 172.16.1.4 0.0.0.3 area 0
 network 192.168.1.0 0.0.0.255 area 0
 !
dial-peer voice 1 pots
 destination-pattern 4002
 port 1/0
 !
dial-peer voice 2 voip
 destination-pattern 4001
 session target ipv4:172.16.1.1
________________________________________________________________
! Router R3:

<output omitted>

interface FastEthernet0/0/0
 ip address 172.16.3.1 255.255.255.0
 !
interface Serial3/0/1
 no ip address
 encapsulation frame-relay
!
interface Serial3/0/1.301 point-to-point
 ip address 172.16.2.2 255.255.255.252
 frame-relay interface-dlci 301
!
interface Serial3/0/1.501 point-to-point
 ip address 172.16.2.6 255.255.255.252
 frame-relay interface-dlci 501
 !
router ospf 1
 network 172.16.2.0 0.0.0.3 area 0
 network 172.16.2.4 0.0.0.3 area 0
 network 172.16.3.0 0.0.0.255 area 2

Figure 17-5. Verifying the Frame Relay PIPQ Feature
[View full size image]
 

The configuration examples for Figure 17-5 portray a simple remote-central office setup connected over a hub-and-spoke Frame Relay network. The company needs to transport several different classes of user traffic with varying QoS requirements over the Frame Relay network with limited available bandwidth. The company has decided to use Frame Relay PIPQ at the central site router to prioritize the different classes of traffic sent into the Frame Relay network.

To fully utilize the benefits of Frame Relay PIPQ, you must separate the different types of traffic onto separate Frame Relay PVCs. In this example, four Frame Relay PVCs are provisioned between the central site, and its remote office sites to carry the different classes of traffic. The central site plans to make Voice over IP (VoIP) calls with one of its connected remote sites. A dedicated Frame Relay PVC is provisioned to transport the delay-sensitive VoIP traffic on DLCI 102. To minimize network latency for the VoIP traffic, traffic carried on DLCI 102 is given preferential treatment over other classes of traffic. Therefore, Frame Relay PIPQ is configured at the interface level. All traffic carried on DLCI 102 is sent into the high-priority interface queue at central router R1.

A small team of account managers at a branch site uploads sales proposals to a group of servers on a network connected to router R2. The manager at the central site needs to download this data for analysis. For this purpose, a low-bandwidth Frame Relay PVC is provisioned between routers R1 and R2 to facilitate this file transfer process between the central and remote sites. On the central router R1 and the remote router R2, OSPF is configured on the 172.16.1.4/30 subnet to provide connectivity between the central and remote sites. This helps to isolate routing updates from Frame Relay DLCI 102 and DLCI 201 serving the VoIP users. Furthermore, because the file transfer between routers R1 and R2 over 172.16.1.4/30 subnet are not considered mission-critical and the file transfer can be scheduled or performed manually during off-peak hours, traffic carried on DLCI 104 at the central router is sent into the low-priority interface queue.

Intranet Web traffic between clients connected to router R1 and the Web server attached to router R3 is given the next highest priority. All traffic carried on DLCI 103 is assigned to the medium-priority interface queue at router R1. Additionally, a route map is configured on router R1 to enable policy routing so that all incoming Web traffic from its clients is directed to router R3 over DLCI 103. All other traffic between routers R1 and R3 are routed with OSPF. Finally, at central router R1, the remaining traffic classes between routers R1 and R3 transported on DLCI 105 are assigned to the normal-priority interface queue.

It is important to understand that the scenario presented in this section serves only as an example to reflect the different classes of traffic likely to be seen on an actual production Frame Relay network. Each class of traffic can be transported on individual Frame Relay PVCs, and Frame Relay PIPQ can then be used to effectively provide traffic prioritization between the DLCIs.

NOTE

Notice in Example 17-7 that the configurations do not show the frame-relay interface-queue priority normal command for the normal priority queue under the Frame Relay map class. The default behavior for Frame Relay PIPQ in a map class is to assign packets to the normal queue. Hence, if you enable Frame Relay PIPQ at the interface but do not differentiate the classes of traffic in Frame Relay map classes, all traffic goes into the normal priority queue. This has the same exact behavior as FIFO queuing at the interface level. The configurations in Example 17-7 are verified in the next section. The commands for monitoring and troubleshooting Frame Relay PIPQ on a Cisco router are also introduced in the next section.