IP/VPN QoS Strategy
Layer 3 VPN technology, such as MPLS VPN, introduces several challenges. One of those challenges is the QoS treatment and handling of traffic across the service provider's IP network, which would likely have a different type and number of QoS CoSs. Given that traffic would be routed by the provider across the IP network, it is imperative that the internal QoS classes of service be handled correctly to ensure that service levels are being met.
In some cases, there may not be a direct one-to-one mapping of enterprise CoSs to those offered by the service providers. In that case, it is necessary at the WAN edge to merge or remap the internal classes so that they may align. To ensure that important and high-priority classes are given the same level of service as if they were traversing the internal private WAN, care must be taken when such actions are carried out.
Enterprises implement more classes of service, because they want to separate applications. However, in the provider's IP core, they aggregate classes based on the service-level agreement (SLA) type. That is, they have priority queuing (PQ) for controlled latency and CBWFQ for guaranteed-bandwidth and best-effort. All CBWFQ applications that are separated at the edge are lumped together. However, as long as the aggregate meets the needs of the sum of the individual guarantees at the edge, it is fine for the service provider core and is of no concern.
Service providers may have different strategies for enforcing QoS classes. Although it may be a common practice for one provider to discard excess traffic marked with higher drop precedence within a class selector, others may elect to drop traffic from lower-priority classes instead. This aspect of the provider's QoS offering must be fully understood and assessed so that the correct merging and/or remapping of an enterprise's internal classes are performed.
For example, if the service provider is offering four levels of QoS—EF, AF1, AF2, and best-effort (BE)—it is not recommended that more than one internal customer class share a common service provider class selector. That is, if traffic belonging to Class 2 is mapped to AF2, only packets that exceed the maximum bandwidth for this class should be marked down to AF22 or AF23, because these represent higher drop preference values within this particular class selector. In this case, no other traffic should be marked as AF22 or AF23, except excess traffic belonging to Class 2.
IP values 6 and 7 are also used for network control traffic (routing protocols). Most of this traffic is link-local, so an individual class of traffic can be set up for this traffic on a WAN port, with minimum bandwidth. On the CE side of the CE-to-PE links, it is recommended that a separate class be used for management traffic. On the PE side of the CE-to-PE link, this tends to vary per provider. This traffic must, at a minimum, be mapped into a high-priority data CoS in the service provider cloud.
Approaches for QoS Transparency Requirements for the Service Provider Network
Any L3 IP/VPN solution implemented in an enterprise network must support QoS trans-parency. QoS transparency is defined as the ability to recover your original discrete CoSs at the remote end of the IP/VPN network. It is unacceptable for multiple CoSs to be combined into one service provider class such that, at the remote end, the traffic cannot be recovered into the separate CoSs. This transparency can be achieved in one of two ways.
With the first option, the enterprise CE can convert the IP DSCP values to those expected by your service provider's PE, as long as a minimum of five discrete values across the service provider's network preserve the independence of the five CoSs. At the remote CE, traffic can be re-marked back to the appropriate levels for the enterprise network. It is unacceptable for traffic from one class to be re-marked by the network into another class such that it would end up in a different CoS when it was converted back to the enterprise's expected values.
The second option, available in MPLS VPN only, is to leave the IP DSCP markings untouched and use those values to set the MPLS Experimental (EXP) QoS bits to an appropriate level of service based on the markings defined by the enterprise.
RFC 3270 discusses more of the operational aspects with the transport of differing DiffServ implementations. It also classifies these into three effective modes. The Uniform, Pipe, and Short-Pipe modes provide the solution for service providers' flexibility in selecting how DiffServ CoSs are routed or traffic-engineered within their domain.
DiffServ tunneling modes introduce a new Per-Hop Behavior (PHB) that allows differ-entiated QoS in a provider's network. The tunneling mode is defined at the edge of the network, normally in the PE label switch routers (LSRs) (both ingress and egress). You may need to make changes in the P routers, and you must also consider what occurs when the topmost label is removed from a packet due to Penultimate Hop Popping (PHP). It may be necessary to copy the MPLS EXP value from the top label that is being popped to the newly exposed label; this does not always apply to all tunneling modes.
In some cases (for example, a plain non-VPN MPLS network), the PHP action on the final P router can expose a plain IP packet when a packet with only one label is received. When this IP packet is received by the egress LSR (PE), it is not possible to classify the packet based on the MPLS EXP bits because there is no label now. In these situations, you must configure the egress PE router to advertise an explicit-null label. When the PHP action is performed on the P router, a label with a value of 0 is sent. With this special label, you can mark the EXP bits as normally labeled packets, allowing the correct classification on the egress PE router.
MPLS network support of DiffServ specification defines the following tunneling modes:
- Uniform
- Pipe
- Short-Pipe
The next sections examine each tunneling mode and provide examples that show how you can configure each one. The examples include a full mapping of IPP to MPLS EXP bits. It is possible to have a number of different QoS parameters and tunneling modes for each customer.
Uniform Mode
DiffServ tunneling Uniform mode has only one layer of QoS, which reaches end to end. The ingress PE router (PE1) copies the DSCP from the incoming IP packet into the MPLS EXP bits of the imposed labels. As the EXP bits travel through the core, they may or may not be modified by intermediate P routers. In this example, the P router modifies the EXP bits of the top label. At the egress P router, you can copy the EXP bits to the EXP bits of the newly exposed label after the PHP. Finally, at the egress PE router, you can copy the EXP bits to the DSCP bits of the newly exposed IP packet.
Pipe Mode
DiffServ tunneling Pipe mode uses two layers of QoS:
- An underlying QoS for the data, which remains unchanged when traversing the core.
- A per-core QoS, which is separate from that of the underlying IP packets. This per-core QoS PHB remains transparent to end users.
When a packet reaches the edge of the MPLS core, the egress PE router classifies the newly exposed IP packets for outbound queuing based on the MPLS PHB from the EXP bits of the recently removed label.
Short-Pipe Mode
DiffServ tunneling Short-Pipe mode uses the same rules and techniques across the core. The difference is that, at the egress PE router, you classify the newly exposed IP packets for outbound queuing based on the IP PHB from the DSCP value of this IP packet.
QoS CoS Requirements for the SP Network
The service provider's network must support a minimum of three classes at all interfaces with speeds of OC-12/STM-4 (622 Mbps) and less. These classes must include a real-time class using LLQ, a high-priority data class with CBWFQ "minimum bandwidth," and a best-effort class.
Four or five classes are preferred (with the minimum requirements for an LLQ class and all but one of the remaining classes supporting minimum bandwidth), such that the enterprise classes can map directly to the service provider's network.
WRED Implementations
Whereas QoS and LFI are techniques for congestion management, WRED is a technique used for congestion avoidance. WRED, when implemented, allows for the early detection of network congestion and provides the means for the selective discard of packets based on the IPP or DSCP values. When the average queue depth exceeds a user-defined minimum threshold, WRED begins discarding lower-priority packets (both TCP and UDP) based on the QoS information. The intent is to allow TCP applications to decrease their transmission rate and allow the network utilization to level out. Should the average queue depth increase above the user-defined maximum threshold, WRED reverts to "tail-drop" operation. This means that all packets entering the queue at that point are dropped until the traffic utilization is reduced to below the maximum threshold.
Because all traffic is classified and marked at the LAN edge, it is more useful for WRED to be implemented at the WAN edge routers. This way, when the core of the network experiences congestion, packets can be intelligently discarded. In most cases, WRED is recommended only for WAN edge routers that directly connect to IP/VPN providers that explicitly indicate that they support this feature. Packets that exceed threshold values can have their priority marked down or selectively discarded. An important point to keep in mind is that WRED should not be applied to queues that support voice traffic, due to the potential impact that packet loss can have on voice quality.
Additionally, Explicit Congestion Notification (ECN) is an extension to WRED in that ECN marks packets instead of dropping them when the average queue length exceeds a specific threshold value. When configured with WRED's ECN feature, routers and end hosts use this marking as a signal that the network is congested and slow down sending of packets.
As stated in RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP, implementing ECN requires an ECN-specific field that has 2 bits: the ECN-capable Transport (ECT) bit and the CE (Congestion Experienced) bit in the IP header. The ECT bit and the CE bit can be used to make four ECN field combinations of 00 to 11. The first number is the ECT bit, and the second number is the CE bit. Figure 5-11 gives an overview of ECN application.
)
Figure 5-11 ECN Application
ECN is being adopted in a lot of enterprise and service provider networks, which complements WRED. The benefits can be summarized as follows:
- Improved method for congestion avoidance—This feature provides an improved method for congestion avoidance by allowing the network to mark packets for later transmission, rather than dropping them from the queue. Marking the packets for later transmission accommodates applications that are sensitive to delay or packet loss and provides improved throughput and application performance.
- Enhanced queue management—Currently, dropped packets indicate that a queue is full and that the network is experiencing congestion. When a network experiences congestion, this feature allows networks to mark a packet's IP header with a CE bit. This marking, in turn, triggers the appropriate congestion-avoidance mechanism and allows the network to better manage the data queues. With this feature, ECN-capable routers and end hosts can respond to congestion before a queue overflows and packets are dropped, providing enhanced queue management.
For more information on the benefits associated with ECN, refer to RFC 2309, Internet Performance Recommendations.