traffic engineering is a source routing mechanism achieved at mpls forwarding
controlled by upper layer protocols. the headend pe where traffic originates
places the traffic to a different lsp and that's how the specific traffic gets
the special threatment compared to normal traffic. the lsp could be explicitly
built by rsvp to the tailend, or computed from the isis
or ospf topology at the headend from sr attributes.
in the rsvp case, headend computes/verifies the path and signals it by rsvp.
the next hop p (called midpoint) assigns a label
for the lsp, only this label is need to be
used as outer label in order to use the specific path.
in sr case, the headend computes the path but uses the sr
info flooeded by isis or ospf which contains pre-assigned
labels of links in the core so the headend router could build a label
stack which if applied as outer label, the packet will take the computed path in the core.
with the capability to steer traffic to different te tunnels at the headend, a bunch of features could be
achieved. you can build a te tunnel over a path that differs from the best one and push some traffic to it.
you can build two te tunnels over different paths (probably with different total cost) and using ecmp over them at
the headend, distributing traffic over different physical paths in the core.
you can add one more te tunnel to the above example, in this case you achieved 1/3-2/3 load balance over the physical paths.
you can configure exp bundle, in this case different qos classes will get different threatment (even over different paths).
you can configure link/node protection for a given p so if that fails, traffic will routed around
the failing p locally, without involving any other routers or protocols, until the core reconverges.
the path a te tunnel take could be specified explicitly (stricly or loosely) or computed automatically by the headend.
in the latter case you can specify constrains about the path, for example the available bandwidth, a bitmap of affinity
bits applied to links, and so on. moreover you can ask your headend to compute backup path for a given primary path, not
using the same shared risk links.
you can steer the traffic to the te tunnel by static routing, policy routing, or you can ask your headend to do autoroute
which leads to pointing the advertised routes of the tailend to the tunnel, in this way all the traffic towards the tailend
will go to the te tunnel. also you can configure forwarding adjacency, which consists two te tunnels between two pe
routers pointing to each other. in this case they will advertise each other as neighbors to the isis
or ospf so the traffic of neighboring routers also could go through the te tunnel. this technique probably
could be used if you would like to tunnel through a part of your core without a given mpls feature enabled. and the best of these
traffic steering techniques, as soon as something happens to the path, the te tunnel will go down and the traffic will flow as before,
just the policy expressed by te tunnels won't be applied.