Home > Articles > Implementing Quality of Service Over Cisco MPLS VPNs

Implementing Quality of Service Over Cisco MPLS VPNs

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: May 26, 2006.

Chapter Description

This chapter covers the requirements for supporting the converged world of Multiprotocol Label Switching (MPLS) VPNs and how this maps to QoS policy applicable in the enterprise. The aim is to provide a deployable set of policies that the enterprise can use as guidelines. You'll also see how to address these policies to the service provider. Specifically, the QoS needs of Acme, Inc. are addressed in the case study.

From the Book

Selecting MPLS VPN Services

Selecting MPLS VPN Services

$65.00

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 11

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.

5. Identification of Traffic | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020