News Stay informed about the latest enterprise technology news and product updates.

Traffic Engineering with MPLS: Quality of service

This chapter excerpt focuses on quality of service (QoS) in traffic engineering, specifically covering the DiffServ architecture and interaction, EXP for packet forwarding, the Modular QoS CLI, and the emerging DiffServ-Aware Traffic Engineering devices. Learn how these can be used to further optimize your network performance.

Traffic Engineering with MPLS


Quality of service with MPLS TE

This excerpt is reprinted with permission from Cisco Press. For more information or to order the book, visit the Cisco Press Web site.

Quality of service (QoS) and MPLS are, at a political level, similar. They're both technologies that have been gaining popularity in recent years. They both seem to be technologies that you either love or hate -- some people are huge QoS fans, and others can't stand it. The same is true of MPLS -- some people like it, and others don't.

At a technical level, though, QoS and MPLS are very different.

QoS is an umbrella term that covers network performance characteristics. As discussed in Chapter 1 of this book, "Understanding Traffic Engineering with MPLS," QoS has two parts:

  • Finding a path through your network that can provide the service you offer
  • Enforcing that service

The acronym QoS in respect to IP first showed up in RFC 1006, "ISO Transport Service on Top of the TCP: Version 3," published in 1987. The term QoS has been around for even longer, because it is a general term used to describe performance characteristics in networks. In the IP and MPLS worlds, the term QoS is most often used to describe a set of techniques to manage packet loss, latency, and jitter. QoS has been rather appropriately described as "managed unfairness": If you have contention for system resources, who are you unfair to, and why?

Two QoS architectures are in use today:

  • Integrated Services (IntServ)
  • Differentiated Services (DiffServ)

For various reasons, IntServ never scaled to the level it needed to get to for Internet-size networks. IntServ is fine for small- to medium-sized networks, but its need to make end-to-end, host-to-host, per-application microflows across a network means it can't grow to the level that large service provider networks need.

DiffServ, on the other hand, has proven quite scalable. Its use of classification on the edge and per-hop queuing and discard behaviors in the core means that most of the work is done at the edge, and you don't need to keep any microflow state in the core.

This chapter assumes that you understand QoS on an IP network. It concentrates on the integration of MPLS into the IP QoS spectrum of services. This means that you should be comfortable with acronyms such as CAR, LLQ, MDRR, MQC, SLA, and WRED in order to get the most out of this chapter. This chapter briefly reviews both the DiffServ architecture and the Modular QoS CLI (MQC), but see Appendix B, "CCO and Other References," if you want to learn more about the portfolio of Cisco QoS tools.

QoS, as used in casual conversation and in the context of IP and MPLS networks, is a method of packet treatment: How do you decide which packets get what service? MPLS, on the other hand, is a switching method used to get packets from one place to another by going through a series of hops. Which hops a packet goes through can be determined by your IGP routing or by MPLS TE.

So there you have it -- MPLS is about getting packets from one hop to another, and QoS (as the term is commonly used) is what happens to packets at each hop. As you can imagine, between two complex devices such as QoS and MPLS, a lot can be done.

This chapter covers five topics:

  • The DiffServ architecture
  • DiffServ's interaction with IP Precedence and MPLS EXP bits
  • The treatment of EXP values in a label stack as packets are forwarded throughout a network
  • A quick review of the Modular QoS CLI (MQC), which is how most QoS features on most platforms are configured
  • Where DiffServ and MPLS TE intersect -- the emerging DiffServ-Aware Traffic Engineering (DS-TE) devices and how they can be used to further optimize your network performance

    This chapter is posted in full as a pdf file. To continue reading, click here.

Dig Deeper on Network protocols and standards

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchUnifiedCommunications

SearchMobileComputing

SearchDataCenter

SearchITChannel

Close