Traffic Engineering

...(略)
To demonstrate how traffic engineering addresses the problem of underutilized links, we will take an example in Figure 3-18 by first defining the traffic engineer terminology:

• Head-End—A router on which a TE tunnel is configured (R1)
• Tail-End—The router on which the TE tunnel terminates (R3)
• Mid-point—A router through which the TE tunnel passes (R2)
• LSP—The label-switched path taken by the TE tunnel; here it's R1-R2-R3
• Downstream router—A router closer to the tunnel tail
• Upstream router—A router farther from the tunnel tail (so R2 is upstream to R3's downstream, and R1 is upstream from R2's downstream)

Continuing the traffic engineering building block, information distribution is done via a link state protocol, such as IS-IS or OSPF. The link state protocol is required only for traffic engineering, not for the implementation of Layer 3 VPNs. A link state protocol is required to ensure that information gets flooded and to build a topology of the entire network.

Information that is flooded includes link, bandwidth, and attributes. After available bandwidth information is flooded, a router can calculate a path from head to tail. The TE head-end performs a constrained SPF (CSPF) calculation to find the best path. CSPF is just like regular IGP SPF, except that it takes required bandwidth into account and looks for the best path from a head to a single tail, not to all devices.

Note that control capabilities offered by existing Internet Gateway Protocols (IGPs) are adequate for traffic engineering. This makes actualizing effective policies to address network performance problems difficult. IGPs that are based on shortest path algorithms contribute to congestion problems in autonomous systems within the Internet. SPF algorithms generally optimize based on a simple additive metric. These protocols are topology driven so bandwidth availability and traffic characteristics are not factors in routing decisions. (Refer to IETF RFC 2702, "Requirements for Traffic Engineering over MPLS.")

In practice, there has been zero impact from CSPF CPU utilization on even the largest networks. After the path is calculated, you need to signal it across the network.

To reserve any bandwidth so that other LSPs cannot overload the path and to establish an LSP for loop-free forwarding along an arbitrary path, a path setup is done via PATH messages from head to tail and is similar to "call setup." A PATH MESSAGE carries a LABEL_REQUEST, whereas RESV messages are done from tail to head and are analogous to "call ACK." RESV messages transport the LABEL.

Other RSVP message types exist for LSP teardown and error signaling. The principles behind path setup are that you can use MPLS-TE to forward traffic down a path other than that determined by your IGP cost and that you can determine these arbitrary paths per tunnel head-end.

…(略)