Frr Failure Detection Mechanisms; Bandwidth Preemption For P2Mp Te - Cisco ASR 920 Series Configuration
Aggregation services router
Hide thumbs
Also See for ASR 920 Series:
- Configuration manual ethernet router (438 pages) ,
- Installing manual (74 pages) ,
- Configuration manual (68 pages)
Table of Contents
Advertisement
MPLS Point-to-Multipoint Traffic Engineering
Bandwidth Preemption for P2MP TE
If only one sub-LSP becomes active, it remains down until all the sub-LSPs become active.
Note
FRR Failure Detection Mechanisms
To detect link failures in a P2MP TE network, you can use native link and interface failure detection
mechanisms, such as bidirectional forwarding detection (BFD), and RSVP hellos.
Bidirectional Forwarding Detection
The MPLS Traffic Engineering: BFD-triggered FRR feature allows you to obtain link by using the Bidirectional
Forwarding Detection (BFD) protocol to provide fast forwarding path failure detection times for all media
types, encapsulations, topologies, and routing protocols. In addition to fast forwarding path failure detection,
BFD provides a consistent failure detection method for network administrators. For more information, see
MPLS Traffic Engineering: BFD-triggered Fast Reroute (FRR).
RSVP Hellos
You can configure RSVP hellos on interfaces that do not provide FRR cutover notification during a link
failure. The behavior for RSVP hellos is similar for both P2MP TE and P2P TE. For every sub-LSP that has
a backup tunnel and has RSVP hellos enabled on its output interface, an RSVP hello instance is created to
the neighbor, and the sub-LSP is added to the neighbor's FRR tree in the hello database.
Hello instances between an output interface and neighbor address are shared by fast reroutable P2MP sub-LSPs
and P2P LSPs. When a hello session to a neighbor is declared down, all P2P LSPs and P2MP sub-LSPs that
are protected by a backup LSP or sub-LSP are switched to their respective backups in the control and data
planes.
RSVP hello sessions can also be used to inform the P2MP headend router of failures along a sub-LSP's path
before the RSVP state for the sub-LSP times out, which leads to faster reoptimization. If a sub-LSP cannot
select a backup tunnel but has RSVP hellos enabled on its output interface, it looks for a hello instance to its
neighbor. If none exists, a hello state time (HST) hello instance is created. If the neighbor goes down, that
sub-LSP is torn down. For more information, see MPLS Traffic Engineering (TE) - Fast Reroute (FRR) Link
and Node Protection.
Bandwidth Preemption for P2MP TE
Bandwidth Admission Control and preemption mechanisms for P2MP TE sub-LSPs are the same as for LSPs
associated with P2P TE tunnels. Any link affinities or constraints defined for the P2MP TE tunnel will be
taken into account. The bandwidth signaled for the sub-LSP is removed from the appropriate pool at the
appropriate priority, and if needed, lower priority sub-LSPs are preempted with a higher priority sub-LSP.
A P2MP tunnel can be configured to use sub-pool or global-pool bandwidth. When bandwidth is configured,
all sub-LSPs of the P2MP tunnel are signaled with the same bandwidth amount and type. If the bandwidth
amount or type of a P2MP tunnel is changed, the P2MP tunnel ingress always signals a new set of sub-LSPs
(a new P2MP LSP) with the new bandwidth amount and type.
Preemption procedures do not take into account the tunnel type. The same priority rules apply to P2P LSPs
and P2MP sub-LSPs. A sub-LSP with a higher setup priority preempts a (sub-)LSP with a lower hold priority,
regardless of tunnel type. Thus, a P2MP sub-LSP may preempt a P2P LSP, and vice versa. The determination
of which LSPs get preempted is based on hold priority.
MPLS Traffic Engineering Path Calculation and Setup Configuration Guide, Cisco IOS XE Release 3S (Cisco
ASR 920 Series)
20
Advertisement
Table of Contents
