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.
path computation could be done at an foreign node node using pcep.
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.