Subscriber Network QoS Design

Designing the subscriber MPLS VPN usually starts with understanding the fundamental characteristics of the existing subscriber network. Baselining the current network provides a starting point for requirements for migrating to Layer 3 VPN. Baselining the network and applications is discussed in the next few sections.

Baselining involves measuring and profiling the volume and type of traffic on the network. Network traffic is divided into classes based on a number of characteristics:

• Real-time traffic Traffic highly sensitive to delay and delay variation, such as IP telephony and VoIP.

• Delay-sensitive business traffic Interactive and transactional traffic highly sensitive to delays. Transactional traffic may involve several request-response round trips in a single transaction. A small increase in delay is multiplied several times in each transaction. Applications using transactional databases frequently are included in this category.

• Non-delay-sensitive business traffic Critical applications that tolerate variations in delay and occasional packet loss. This is the normal class for most business applications.

• Bulk background traffic Traffic with a higher tolerance of delay and packet loss and non-business-critical traffic. E-mail, FTP, and similar traffic are frequently included in this category.

Some network baselines provide finer resolution (more categories) of traffic. At a minimum, traffic should be profiled based on the preceding categories. The traffic profile should then be further analyzed to find the volume based on source and destination for each class. Any areas of the network with excessive delay, packet loss, or high utilization should also be noted.

Baseline New Applications

In most cases, completing the migration of existing applications to the MPLS VPN before implementing new applications is recommended.

In some situations, adding new applications during the migration is unavoidable. Baselines should be established for new applications comparable to the baseline for the existing network applications.

Develop the Network

The information previously gathered provides the starting point for the network design.

Some traffic patterns are apparent immediately. For example, e-mail host locations and hosts with other business applications that are frequently accessed present clear patterns.

Comparing the traffic matrix with bandwidth utilization between locations highlights problem areas and anomalies in routing and other areas of the network.

In developing the subscriber network design, the critical information to recognize is the peak traffic per class for each source and destination pair, and the relationship between the peak hours for the various traffic classes.

The CE-to-PE link bandwidth for a given location is based on the peak traffic and the subscriber policy for noncritical traffic classes. In some locations, multiple applications reach individual peaks concurrently. For example, many people check voice mail and e-mail in the morning. IP telephony is a real-time CoS, whereas e-mail is frequently considered batch traffic. CE-to-PE link bandwidth may also be affected by the underlying technology used for the access link.

After you determine the bandwidth for the subscriber CE-to-PE link, the QoS policy for managing traffic on the link needs to be determined. The QoS policy determines the allocation of traffic to classes, and the treatment of the traffic in each of the classes, under congested conditions. QoS policy has no effect in uncongested conditions. The QoS policy involves marking, policing, fragmentation, interleaving, and compression functions (to name a few), all of which are active policies with or without congestion.

The four classes described for profiling the existing network are frequently defined as classes for the QoS policy. Networks without VoIP or IP telephony may define as few as three traffic classes. If the enterprise has the business objective of supporting VoIP, only then is a three-class model sufficient. However, if an enterprise has many applications with unique service-level requirements, applying unique classes of service (up to 11, for example) may be appropriate. Ultimately, business requirements dictate the CoS implementation model.

After determining the required traffic classes, handling of each class is defined based on the traffic characteristics. If either VoIP or IP telephony traffic is supported, low-latency queuing (LLQ) is recommended. LLQ provides a priority queue that is serviced exhaustively before other queues are serviced. A bandwidth limit can be configured for the LLQ to prevent starvation of other queues. A bandwidth limit (enforced via an implicit policer) is always present with LLQ. Other queues are serviced based on the CBWFQ policy defined. Unless otherwise specified, taildrop is used to discard packets in excess of the bandwidth assigned to the class under congested conditions.

If VoIP or IP telephony traffic is not supported, modular QoS CLI (MQC)-based LLQ is recommended for defining QoS policy for the allocation and treatment of traffic classes under congested conditions.

Each traffic class is marked based on the QoS policy. DSCP specifies how traffic is handled in the service provider network.

Most service provider networks recognize four levels of service at a minimum. The levels are usually divided along the lines of the traffic classes recommended for baselining the network. The premium CoS is usually reserved for LLQ ToS and is recommended for voice applications. The larger packet sizes associated with video applications generally are better suited to the second CoS.

The IP Precedence or DSCP bits are mapped to the experimental field of the MPLS label at the PE router. The experimental field is a 3-bit field, allowing a maximum of eight levels of service to be supported in an MPLS VPN core network. Although the field is 3 bits, most service providers support a maximum of four levels of service.

Note

Three bits (offering eight levels) lets EXP bits indicate whether traffic for a class is within or out of contract (two states per class equals eight values).

QoS has a significant role in the enterprise network when it comes to offering network services. With the advent of applications, such as videoconferencing and VoIP, it becomes essential to ensure that the network can offer services such as end-to-end bounded delay and guaranteed bandwidth to end-user applications. Without these sorts of QoS features, it can't meet the requirements of these applications without compromising the quality of the video or the voice services.

With QoS in place, the enterprise network can assure its users that its network can meet the requirements of the user applications. This also helps the enterprise distinguish between different types of users: one set of users who require services with a certain guarantee (such as end-to-end delay or bandwidth), and others who are satisfied with best-effort services. This distinction between types of users also helps the enterprise charge these users (for network services) based on their requirements.