View source for Manual:TE Tunnels

== Overview ==

For MPLS overview and RouterOS supported MPLS features see [[MPLS Overview]].

MPLS RSVP TE tunnels are a way to establish unidirectional label switching paths. In general RSVP TE serves similar purpose as label distribution using LDP protocol - establishing label switched path that ensures frame delivery from ingress to egress router, but with additional features:
* possibility to establish label switching path using either full or partial explicit route;
* constraint based LSP establishment - label switching path is established over links that fulfill requirements, such as bandwidth and link properties.

MPLS RSVP TE is based on RSVP protocol with extensions introduced by RFC 3209 that adds support for explicit route and label exchange.

Note that constraints for path establishment are purely controlled by administrator - for example, bandwidth of link participating in RSVP TE network is set by administrator and does not necessarily reflect real bandwidth of the link. The same way bandwidth reserved for tunnel is set by administrator and does not automatically imply any limits on traffic sent over tunnel. Therefore at any moment in time, bandwidth available on TE link is bandwidth configured for link minus sum of all reservations made on link, not physically available bandwidth which can be either less (in case data is forwarded over tunnels with rate that exceeds bandwidth reserved for tunnel or if non-RSVP tunnel data is forwarded over link as well) or more (in case data is forwarded over tunnels with rate smaller than allocated for tunnel) than bandwidth available for reservations.

RSVP TE tunnels are initiated by head-end (ingress router) of tunnel. Head-end router sends RSVP Path message containing necessary parameters towards tail-end of the tunnel. Routers along the path ensure that they can forward Path message towards next hop, taking into acount path constraints. Once Path message reaches tail-end of the tunnel, tail-end router sends RSVP Resv message in the opposite direction. Resv message hop by hop traverses exactly the same path that Path message, only in the opposite direction. Each router forwarding Resv message allocates necessary bandwith on appropriate downstream link if possible. Once head-end router succesfully receives Resv message that matches sent Path message, tunnel can be considered established. Tunnel is maintained by periodically refreshing its state using Path and Resv messages.

RSVP TE tunnels can be established with number of path options:
* along path that data from head-end of tunnel is routed to tail-end - in this case each router along tunnel path figures out next hop of tunnel based on routing table. If at some point usable route is not found or downstream interface does not meet constraints (for example if requested bandwidth exceeds available bandwidth), tunnel can not be established.
* along statically configured explicit path - in this case each router along tunnel path figures out next hop of tunnel based on explicit route specified in Path message. This explicit route can be either complete (specifies all routers along the path in the order they must be traversed) or partial (specifies only some routers that must be traversed). To decide next hop router, each router along the path look up route to next router specified in explicit route. If no usable route is found or downstream interface does not meet constraints, tunnel can not be established
* Constrained Shortest Path First - in this case head-end router calculates path to tail-end using its knowledge of network state - properties of links and available bandwidth. This option needs assistance from IGP routing protocol (such as OSPF) to distribute bandwidth information throughout the network. This is implemented in OSPF by means of opaque LSAs. When using CSPF, head-end router calculates path that satisfies the requirements and produces explicit path for Path message. If path that matches constraints can not be calculated, tunnel can not be established. Dynamically calculated path can also be partially explicit - in this case CSPF seeks for shortest path matching constraints between every two explicit hops. If explicit path is specified completely and CSPF is used, CSPF just checks if this path meets the constraints taking into account knowledge about link states in network - so instead of failure to establish tunnel while forwarding Path message in network, Path message is not even sent as it is clear that establishing tunnel will fail.

== Forwarding traffic onto TE tunnels ==

RSVP TE tunnel head-end appears as interface in RouterOS. Note that RSVP TE tunnels are unidirectional - it is not necessary to have matching tunnel for reverse direction on tail-end router. When tail-end router receives data sent over tunnel, it either receives it with TE tunnel label stripped off by penultimate hop (non-default behaviour) or with explicit-null label, which gets stripped and packet is further inspected (if tunnel label is last label in stack, packet gets routed, otherwise it is processed based on next label in stack, for example, as VPLS packet). Bidirectional tunnel can be simulated by creating one tunnel in one direction and other in other direction between the same endpoints. Still no data will be accounted as received over TE tunnel, as in reality both tunnels are unrelated.

One way to forward traffic onto tunnel is to use routing, but this limits TE tunnel to be used only for routing IP packets.

Additionally, several types of traffic can be forwarded onto TE tunnel automatically, if it is known to be destined to the endpoint of tunnel and if tunnel is active:
* traffic that is routed using route route learned from BGP, if BGP NextHop is tunnel endpoint (this default behaviour can be changed by setting route porperty "use-te-nexthop" to "no"), both - regular IP and VPNv4 (MP-BGP IP VPN) routes fit in this category;
* traffic for VPLS interfaces, if remote endpoint of VPLS pseudowire is the same as TE tunnel endpoint.

For example, for IP BGP route having BGP NextHop x.x.x.x, forwarding method will be chosen according to the following rules:
* if TE tunnel with endpoint x.x.x.x is active, use it;
* otherwise if LDP label mapping from next hop towards x.x.x.x is received, use it;
* otherwise use regular routing (no MPLS encapsulation).

In similar way, if remote address of VPLS pseudowire is x.x.x.x, forwarding method will be chosen in the following order:
* if TE tunnel with endpoint x.x.x.x is active, use it;
* otherwise if LDP label mapping from next hop towards x.x.x.x is received, use it;
* otherwise VPLS tunnel can not be active.

Note that RSVP TE tunnels as a way to establish LSPs can be used together with LDP. Using RSVP TE does not replace or disable LDP, but LSP established by TE is usually preferred over one established using LDP.

== Example network ==

Consider the same network as used for LDP signaled VPLS example in [[MPLSVPLS]]:

[[Image:VPLS.png | 730px]]

Customer A wants to establish IP VPN between his 3 sites and Customer B wants to transparent connection for ethernet segments at his sites.

== Prerequisites for MPLS TE ==

In general, prerequisites for using MPLS TE are the same as mentioned in [[MPLSVPLS]], but there are a few details:
* by default TE tunnel tail-end router advertises explicit null label, therefore penultimate hop popping does not happen (the purpose of using explicit null label is to communicate QoS information in MPLS label Exp field), so main purpose of having "loopback" IP address for every router is to have tunnel endpoints unaffected by link state changes;
* in order to use CSPF path selection for tunnels, OSPF must be configured and running in network.

== Enabling TE support ==

In order for OSPF to distribute TE information, TE related OSPF parameters must be set:

<pre>
[admin@R1] > /routing ospf instance set mpls-te-area=backbone mpls-te-router-id=lobridge
</pre>

This instructs OSPF to distribute TE information in "backbone" area using IP address of "lobridge" as router ID.

In order for router to be able to participate in TE tunnel (either as head-end, tail-end or forwarding router), TE support must be enabled. TE support must be enabled on all interfaces that will receive and send RSVP TE protocol packets. On R1 it is done by commands (interface ether3 is facing network 1.1.1.0/24):
<pre>
[admin@R1] > /mpls traffic-eng interface add interface=ether3 bandwidth=100000
</pre>

This configures ether3 interface with TE support, having bandwidth 100000 Bps. Other routers are configured in similar way.

As soon as TE support is enabled on interface, appropriate opaque LSAs are distributed into OSPF area. For example, on R1 it can be seen, that there is total 15 opaque LSAs in LSA database:

<pre>
[admin@R1] > /routing ospf lsa print 
  ...
backbone              opaque-area  1.0.0.0        1.1.1.2        0x80000004      1038      
backbone              opaque-area  1.0.0.0        2.2.2.3        0x80000004      1039      
backbone              opaque-area  1.0.0.0        3.3.3.4        0x80000004      1038      
backbone              opaque-area  1.0.0.0        4.4.4.5        0x80000004      1038      
backbone              opaque-area  1.0.0.0        11.11.11.1     0x80000004      1037      
backbone              opaque-area  1.0.0.1        1.1.1.2        0x80000004      1038      
backbone              opaque-area  1.0.0.1        2.2.2.3        0x80000004      1039      
backbone              opaque-area  1.0.0.1        3.3.3.4        0x80000004      1037      
backbone              opaque-area  1.0.0.1        4.4.4.5        0x80000004      1038      
backbone              opaque-area  1.0.0.2        1.1.1.2        0x80000004      1038      
backbone              opaque-area  1.0.0.2        2.2.2.3        0x80000004      1039      
backbone              opaque-area  1.0.0.2        3.3.3.4        0x80000004      1037      
backbone              opaque-area  1.0.0.2        4.4.4.5        0x80000004      1038      
backbone              opaque-area  1.0.0.3        2.2.2.3        0x80000004      1039      
backbone              opaque-area  1.0.0.3        11.11.11.1     0x80000004      1037 
  ...
</pre>

== Creating basic TE tunnel ==

Assume that we want to create TE tunnel from R1 to R5. In order to do this, tunnel path specification must be created:

<pre>
[admin@R1] > /mpls traffic-eng tunnel-path add use-cspf=yes name=dyn
</pre>

This creates path template for purely dynamic path that will use CSPF.

Next, TE tunnel itself must be created:
<pre>
[admin@R1] /interface traffic-eng> add name=te1 bandwidth=1000 primary-path=dyn \ 
   from-address=9.9.9.1 to-address=9.9.9.5 disabled=no record-route=yes
</pre>

We can monitor tunnel to see its state:
<pre>
[admin@R1] /interface traffic-eng> monitor 0
             tunnel-id: 7
    primary-path-state: established
          primary-path: dyn
  secondary-path-state: not-necessary
           active-path: dyn
          active-lspid: 1
          active-label: 29
        explicit-route: "S:1.1.1.2/32,S:2.2.2.2/32,S:2.2.2.3/32,S:4.4.4.3/32,S:4.4.4.5/32"
        recorded-route: "1.1.1.2[30],2.2.2.3[29],4.4.4.5[0]"
</pre>

Notice, that CSPF has created explicit route that traverses R2, R3 and R5 (tail-end). TE tunnel was requested to record route it is traversing (by "record-route=yes" setting), recorded route is displayed in status along with labels that particular router has allocated for this tunnel.

Once TE tunnel is established, VPLS interface from R1 to R5 automatically switches to use this TE tunnel:
<pre>
[admin@R1] /interface vpls> monitor 0
       remote-label: 24
        local-label: 25
      remote-status: 
          transport: te1
  transport-nexthop: 1.1.1.2
     imposed-labels: 30,24
</pre>

On routers in between R1 and R5, RSVP path and reservation state can be monitored, for example on R2:
<pre>
[admin@R2] > /mpls traffic-eng path-state print
Flags: L - locally-originated, E - egress, F - forwarding, P - sending-path, R - sending-resv
 #      SRC             DST             BANDWIDTH  OUT-INTERFACE                       OUT-NEXT-HOP
 0  FPR 9.9.9.1:1       9.9.9.5:2       1000       ether2                              2.2.2.3
[admin@R2] > /mpls traffic-eng resv-state print
Flags: E - egress, A - active, N - non-output, S - shared
 #    SRC             DST             BANDWIDTH  LABEL               INTERFACE         NEXT-HOP
 0 AS 9.9.9.1:1       9.9.9.5:7       1000       30                  ether2            2.2.2.3
</pre>

Note, that available bandwidth on ether2 interface (connected to R3) on R2 has changed:
<pre>
[admin@R2] > /mpls traffic-eng interface print
Flags: X - disabled, I - invalid
 #   INTERFACE                                    BANDWIDTH  TE-METRIC  REMAINING-BW
 0   ether1                                       100000     1          100000
 1   ether2                                       100000     1          99000
</pre>

[[Category:Manual]]
[[Category:MPLS]]
[[Category:Internetworking]]
[[Category:Case Studies]]
[[Category:QoS]]