Using MPLS Traffic Engineering to avoid core network congestion

If you’ve ever tried to design QoS in a large Service Provider network, you’ve probably realized that QoS is a zero-sum game: you can give some traffic preferential treatment only if you decide to drop or delay some other traffic. Furthermore, QoS is not linked to IP routing; interface queues cannot apply backpressure to IP routing tables or influence load sharing ratios.

The only technology that can shift the excess traffic in high-speed IP-only networks from congested links to underutilized alternate paths is MPLS traffic engineering. The “Using MPLS TE to avoid core network congestion” article I’ve written for SearchTelecom describes the basic interactions of MPLS TE and QoS and introduces autotunnel and autobandwidth concepts.

Read the article on SearchTelecom

You can find the list of all articles I wrote for SearchTelecom in the CT3 wiki.

1 comment:

  1. i agree something is needed to extend routing based on performance measurements..

    We (IP) is never going to be serious unless we are able to route around link degradation rather then up/down.

    We have OER (PfR) for the edge, and similar on phone switches, so people are clearly thinking about it.

    Also there is this http://www.faqs.org/rfcs/rfc2676.html.

    Although (not having read it) i guess it would need to signal latency > xms = link down or something like that.

    I dont think it is possible to use Diffserv TE to setup a path based on jitter/pkt loss... iirc only constraints such as bandwidth, colour are possible etc.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.