FRR

Allows for sub-50ms failover after link failure detection. Applicable for LSPs established using RSVP-TE. CSPF plays an important role. Allows protection to be applied as close to the point of failure as

MPLS Fast Reroute (FRR) defines ways of automatically establishing

protection paths before a failure the foellowing are the characteristics:-

The protection method is signaled in the Flags field of the One-to-one (0x01) Facility (0x02)



also indicates the following flags:

In the Session_Attribute object of the PATH message, the router local-protection-desired



FRR is only established after the primary LSP path is established.

Routers wait for the second RESV (first refresh) message

calculating and signaling the detours.



established end-to-end.This is to ensure that the primary LSP-Path is successfully

Upon receipt of the second RESV message, all routers along the

primary LSP-Path (except the Tail-End):



Assume the PLR (Point of Local Repair) role.



themselves, taking into account the protection method and type

(one-to-one and node-protect in this example)

When a router receives the refresh message for the previously established primary LSP-Path, it initiates the pending

detour calculation process. As a result of the randomization introduced in the session refresh timers, as described in

Module 4, the detour calculation and establishment processes may start at slightly different times on each router.

While testing with Fast Reroute, establishing all the detours along the primary LSP-Path might take a while (mostly up

to 60-70 seconds) because of the reasons described above.

When computing a protection path on a PLR, the constraints for

CSPF are:



that avoids the downstream node and all of its network links.

Node-protect ― To find a protection path for the primary LSP



that avoids only the link connected to the downstream node.

Link-protect ― To find a protection path for the primary LSP



(failure of the Tail-End router is catastrophic for the

LSP).

The router just before the Tail-End always performs linkprotection



constraints other than Shared Link Risk Groups (“srlg-frr

needs to be enabled in the global MPLS context, if that is desired).

SRLG concept can also be used for Fast Reroute, if the following system-wide configuration is enabled:

A:R1>config>router>mpls#

srlg-frr [strict]

•

SRLG constraint.

Strict: With the strict option, CSPF will not establish any FRR protection tunnel if there is no path that meets the

•

constraint, it disregards the constraint and tries to establish a tunnel over links that are not complaint to SRLG.



Merge point for one to one

The termination point for a protection tunnel is called the Merge

Point (MP) router.



protected tunnel merge, or meet again.

In other words, the MP is where the protection tunnel and



protection mode and the actual topology.

The location of the MP for a protection tunnel depends on the



to the Tail-End router of the protected LSP as possible.

For One-to-One protection, the detour tunnel terminates as near



using the shortest IGP path.

In the above figure the metric is changed which changes the merge point

Path message for the detour tunnel:-

The PLR sends a separate RSVP PATH message to signal the detour

tunnel.



Object (ERO) of the PATH message.

The result of the CSPF calculation is included in the Explicit Route



original primary LSP-Path. This is to identify the association on all

the routers.

The detour tunnel uses the same Tunnel ID and LSP ID as the



takes the following format:

The LSP-Name field in the PATH message of the detour tunnel



<LSP-Name>::<Path-Name>_detour For example, “to_R6::fully_loose_detour”

When a PLR router calculates a path for the detour, the hop information calculated by CSPF is inserted into the ERO of

the PATH message sent by the PLR. This PATH message is used to signal the detour.\

This association is achieved by assigning the

The difference lies in the

name to identify the detours.

Detour Object used in the Detour PATH Message



PLR to signal the detour path.

A Detour Object is also included in the PATH message sent by the



different PLRs.

The detour object helps to distinguish the detour tunnels from



Among other fields, the detour object contains:



PLR ID: System IP address of the PLR



— Node protect: System IP address of the protected router

— Link protect: The interface IP address of the protected

router

Accordingly, multiple detours protecting the same LSP might be transiting or terminating on a certain router. The main

purpose of the Detour object is to distinguish between them.

The ERO field contains the hops that are calculated by the PLR for the detour.

The Detour object indicates the PLR_ID as 10.10.10.1, which is the System IP address of router R1.

The

with a System IP address of 10.10.10.2.Avoid_Node field indicates that the detour is created to avoid the next router for router R1, which is router R2,Avoid_Node, depending on the protection mode:same Tunnel ID and LSP ID for the detour tunnels as their protected LSPPath.LSP-Name given to detour tunnels. A “_detour” suffix is appended to the original LSPPathIn other words, the detour tunnel is calculated to the Tail-End,Non-Strict: With the non-strict (default) option, if CSPF cannot find a path for the protection tunnel using the SRLGFRR protection tunnels do not follow any protected path” optionCalculate separate protection tunnels that originate onnode-protection-desired (unless disabled in configuration)

When Fast Reroute is enabled on an LSP, the Head-End includes an

additional Fast_Reroute object in the PATH message.









Fast_Reroute object:

























RRO:-

Record Route Object (RRO) is included, by default, in RSVP PATH

and RESV messages.

 Each router along the LSP-Path updates the RRO field.

 RRO is used to track the exact path that an LSP-Path takes.

 Interface IP addresses are used.

 In the context of FRR, routers make special use of the RRO inside

the RESV message.

 Labels are also recorded in the RRO of the RESV message.

The RRO is updated at each hop of the PATH message.

 Each router adds its own IP address connecting to the downstream

router at the top of the list.

When sending the PATH message, the Head-End router R1 inserts its own interface IP address (10.1.2.1) in the RRO list.

Router R2 adds its own address (10.2.3.2) to the top of the list, when forwarding the PATH message to router R3.

Router R3 does the same so that, eventually, router R4 has full visibility over the path that the RSVP PATH message has

traversed.





possible.

FRR:- Protection Methods:-



One-to-One Backup Facility Backup



Each LSP can use only one method.



the protected LSP.

The protection method needs to specified in the configuration of

Given below is an example of one to one protection path:-

 Given below is an example of facility protection path:-

All the LSP's are protected by the same bypass tunnel:-

FRR protection types:-

From a topological perspective, both one-to-one and facility

backup can protect different network elements:



downstream router.

Node Protection ― Protects against the failure of the next



next downstream router.

Link Protection ― Protects against the failure of the link to the



Possible configuration options for an LSP are:



One-to-one node protection



One-to-one link protection



Facility node protection

By default node protection is enabled by default and need not be mentioned however it can be optionally be disabled.

In the below case router R3 and all its links are avoided.

In the case of link protection it does not avoid any node:-

The default method is node protection.
 If node protection is desired:
 A router may make up to 3 consecutive attempts to establish a
node protection tunnel.
 If this cannot be accomplished, as a result of topological or
other constraints, the router reverts to link protection.
 Node protection can be disabled in the LSP configuration
 In this case, the routers only attempt link protection.Routers play different roles in Fast Reroute protection.
 Head-End Router ― Where the primary (protected) LSP-Path is
configured and where it originates.
 Tail-End Router ― Where the primary (protected) LSP terminates.
 Point of Local Repair (PLR) ― Where the protection tunnel
originates.
 Merge Point (MP) ― Where the protection tunnel terminates and
merges into the original protected LSP-Path.

All the routers along the path acts as a PLR except the tail end tries to establish a detour path hence all the routers along the lsp path acts as a PLR.Point of Local Repair (PLR) is the router where the protection tunnel
originates. When the link fails, the LSP traffic is locally recovered at
this point.
 Merge Point (MP) is the router where the protection tunnel
terminates and merges into the original LSP-Path.

In the above figure R2 is the PLR and R3 is the merge point.

FRR requirements:-For Fast Reroute to function, the Head-End needs to know the
exact path of the LSP-Path before signaling it.
 This can be accomplished in several ways:
 A path with fully strict hops (CSPF need not be enabled) in this case CSPF is not required however global revertive will not work in this case.
 A path with loose hops (CSPF must be enabled)
 A path with a mixture of strict and loose hops (CSPF must be
enabled)
 For a primary LSP-Path that has:
 Loose hops in path definition,
 Fast-Reroute enabled,
 CSPF disabled,
the LSP does NOT come up with failure code “looseHopsInFRRLsp”

Given below is the configuration for the FRR:-A:R2>config>router>mpls#
--------------------------------
path “fully_loose”
no shutdown
lsp "to_R4“
to 10.10.10.4
cspf
fast-reroute one-to-one
node-protect
primary “fully_loose”
exit
no shutdown
exit

FRR has two objects in the path message:-The RSVP-TE protocol was extended to allow for the automatic
signaling of the protection tunnels.
 Defined in RFC 4090.
 Introduces two objects:
 Fast_Reroute Object
 Detour Object (only for one-to-one method)
 The new objects are also carried in the RSVP PATH messages.Facility link protectionFRR can only protect the primary LSP-Path of an LSP, there is no protection for the secondary LSP path.

There are two methods of FRR protection.

An RRO is also present in the RESV message.

 Each router adds:

 Its interface IP address connecting to the upstream router

 The label allocated for the LSP

The Tail-End router R4 adds its own interface IP address (10.3.4.4) and the label it reserved for the LSP-Path (400) in

the RRO list.

Router R3 receives the RESV message from router R4. It appends its own interface IP address (10.2.3.3) and the label it

reserved for the LSP to the top of the list.

Router R2 performs a similar operation and, eventually, router R1 has full visibility over the LSP-Path with label

reservation information.

RRO to report FRR status

One of the uses of the RRO in the Fast Reroute implementation is the reporting of protection tunnel status to the Head-

End.

When a PLR router is able to successfully establish a protection tunnel, it sets the “local-protection-available” flag in

the following RESV refresh messages that it sends.

If node-protection was requested by the Head-End, and a node-protection tunnel is successfully established by the PLR,

the node-protection-available flag is also set. If a link-protection tunnel is established instead, then the flag value

remains at zero.

In the end, the Head-End router has full visibility of the routers and labels along the LSP-Path, as well as the tunnel

protection status on each router.

The above slide illustrates the reporting of protection tunnel process performed by all the PLRs.

Router R4 is the Tail-End router, and does not perform the PLR role.

Router R3 is able to establish a link protection tunnel and sets only the “local protection available” flag, which is

indicated with a “@” symbol in the SR OS CLI.

Router R2 is able to establish a node protection tunnel and sets both the “local protection available” (@) and “node

protection available” (n) flags in the RESV refresh messages.



