FastReRoute (FRR) - Big Picture

1
Lecture 12
FastReRoute (FRR) - Big Picture
2
Handling Link Failures
3
Handling Link Failures - Issues

• The previous approach suffers from following
  problems
• It takes long time (order of 60 to 120 sec) to
  signal (propagate) fault information to the
  headend.
• Thus during this period traffic on effected LSPs
  is dropped. Clearly not a desirable option.
• A better solution would be to adopt a two step
  approach
• First, quickly repair the LSP locally to minimize
  the data loss.
• After the broken LSPs have been locally repaired,
  the path of the repaired LSP may no longer be
  optimal. Therefore, as a second step, re-optimize
  the LSP using the make-before-break approach.

4
Local Repair
5
RSVP-TE Extensions for LSP Local Repair

• As we have learned earlier, upon link/node
  failure, LSP local repair quickly diverts traffic
  from protected LSPs onto the backup LSP.
• In order to support LSP local repair commonly
  known as FastReRoute (FRR), some extensions are
  required in the RSVP-TE.
• These extensions are specified in the following
  Internet Draft.

Fast Reroute Extensions to RSVP-TE for LSP
Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-
02.txt
6
Overview

• The FRR draft specifies two approaches for LSP
  local repair namely
• Bypass (proposed by Cisco)
• Detour (proposed by Juniper)
• Detour and Bypass are similar in following
  aspects
• both are used to protect LSP against link and
  node failures.
• Detour and Bypass are different in following
  aspects
• Detour requires a separate backup LSP for each
  LSP that needs to be protected. Thus Detour
  provides a one-for-one (11) LSP protection.
• Bypass tunnel can be used to protect multiple
  LSPs (facility).
• Detours does not use label stack (needs to
  maintain per LSP RSVP state)
• Bypass use label stack (no need to maintain per
  LSP RSVP state).

7
Bypass and Detour
To protect three LSPs, need 3 detour LSPs
R9
R4
R3
R1
R2
R7
R8
R5
R6
R0
To protect three LSPs, need 1 bypass tunnel
8
Detour or Bypass?

• For Bypass
• need 1 backup for n primary LSPs.
• Requires much less LSP state
• More deployed
• For Detour
• need 1 detour for 1 working (or protected) LSP.
• Much more RSVP state to maintain for each LSP
• Very little deployed (detour is dead!)

9
Terminology

• Reroutable LSP - an LSP for which the HE has
  requests link/node protection.
• Point of Local Repair (PLR) - the node that act
  as a headend for a backup (bypass) tunnel.
• Merge Point (MP) - Tail end of one or more
  backup tunnels.
• NHOP Bypass Tunnel - a bypass tunnel that
  bypasses (protects) a link.
• NNHOP Bypass Tunnel - a bypass tunnel that
  bypasses (protects) a single node.
• Shared Risk Link Group (SRLG) Disjoint - two
  paths that don't share any link or node

10
Terminology
NNHOP Bypass tunnel (Node Protection)
R9
R4
R3
Head
X
X
R1
R2
R7
R8
R5
Merge Point (MP)
Point of Local Repair(PLR)
Reroutable LSP
Merge Point (MP)
R6
NHOP Bypass Tunnel (Link Protection)
11
Bypass Tunnel - Link Protection
R4
R3
X
R5
R1
R2
R7
R8
R6

• Uses a bypass tunnel to the next-next-hop (i.e.,
  NHOP)
• Protects against a single link failure
• Upon link failure, protected LSPs are rerouted
  over the bypass tunnel

12
Bypass Tunnel Node Protection
R4
R3
X
R1
R2
R7
R8
R5
PLR
MP
R6

• Uses a bypass tunnel to the next-next-hop (i.e.,
  NNHOP)
• Protects against a single link AND node failure
• Upon link failure, protected LSPs between
  R2-R5-R7 are rerouted over the bypass tunnel

13
Bypass Tunnel Label Stacking
R4
R3
X
PLR
R1
R2
R8
R5
R7
MP
R6

• PLR (R2) replaces the normal out label of the
  re-routable LSPs (i.e., 9,10,11) with the labels
  expected by MP (R7) (i.e., 12,13,14). How does
  PLR learns about the labels expected by R7 ?
  (Hint think about RSVP Objects)
• Secondly, PLR pushes a label of the bypass tunnel
  (i.e., 20).
• R6 pops the backup tunnel for R7 to receive the
  packets with expected labels.
• What is the basic assumption being made here?
  (Hint think about uniqueness of labels)

14
Bypass Tunnel Label Stacking
15
Bypass and RSVP State

• By now, hopefully, it is clear that MPLS TE uses
  RSVP-TE as a control plane.
• Because RSVP has a soft state model, the state is
  periodically refreshed. If the state is not
  refreshed with (e.g., 4 refresh periods)), the
  state is removed.
• Thus following a link/node failure, if a
  downstream node does not receive the expected
  refreshes, the LSP state is removed which would
  defeat the purpose of the bypass tunnel.

16
Bypass Tunnel RSVP State
17
Bypass Solution

• In order to maintain LSP state after link/node
  failure, RSVP refresh messages are also sent over
  the backup tunnel.
• The RSVP messages are not visible any node along
  the bypass tunnel.
• As a result, although several LSP are being
  rerouted over the bypass tunnel, none of the
  nodes along the bypass tunnel will create per LSP
  state.
• Thus from maintenance point of view, bypass is
  very scalable.

18
Bypass Tunnel Solution
RSVP refresh msg
R4
R3
LSP RSVP State
X
X
PLR
R1
R2
R8
R5
R7
MP
R6
Per LSP state not created
Bypass Tunnel RSVP State
19
Detour

• Scalability Issue - Detour needs to create and
  refresh lot more information.

20
RSVP-TE FRR extensions

• Bypass related RSVP-TE extensions.
• Two new flags are defined in the Session
  Attribute Object to request bandwidth protection
  and node protection.
• Two new flags are defined in the Record Route
  Object (RRO) to report status.
• Bandwidth protection (0x04) set by PLR when
  requested BW is available on the backup.
• Node Protection (0x08) set by a PLR when node
  protection is available.
• Note FastReRoute and Detour Objects are NOT
  used by Bypass method.

21
Session Attribute Object
SESSION_ATTRIBUTE class 207, LSP_TUNNEL_RA
C-Type 1   0 1
2 3 0 1 2 3 4 5 6 7
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
------------------------
--------
Exclude-any
-------------------------
-------
Include-any
-------------------------
-------
Include-all
-------------------------
------- Setup Prio Holding Prio
Flags Name Length
-------------------------
-------
//
Session Name (NULL padded display string)
//
---------
- ------------------------
--------
SESSION_ATTRIBUTE class 207, LSP_TUNNEL
C-Type 7   0 1
2 3 0 1 2 3 4 5 6 7
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
------------------------
-------- Setup Prio Holding
Prio Flags Name Length
-------------------------
-------
//
Session Name (NULL padded display string)
//
-----------
---------------------
22
Session Attribute Object (new flags)
23
RRO (new flags)
RRO Object
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
-------
//
(Subobjects)
//

-------------------------
------- ----------
Subobject 1, IPv4 Address
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Type Length
IPv4 address (4 bytes)
-------------------------
------- IPv4 address (continued)
Prefix Length Flags
-------------------------
------- ----------
Subobject 3, Label
0x01 local protection available 0x02 local
protection in use 0x04 bandwidth
protection 0x08 node protection
0 1 2
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-------------------------
------- Type Length
Flags C-Type
-------------------------
------- Contents of Label
Object
-------------------------
-------
24
RRO (new flags)
Bandwidth protection 0x04 The PLR will set
this when the protected LSP has a backup
path which is guaranteed to provide the desired
bandwidth specified in the FAST_REROUTE object or
the bandwidth of the protected LSP, if no
FAST_REROUTE object was included. The PLR may
set this whenever the desired bandwidth is
guaranteed the PLR MUST set this flag when the
desired bandwidth is guaranteed and the
"bandwidth protection desired" flag was set in
the SESSION_ATTRIBUTE object. If the requested
bandwidth is not guaranteed, the PLR MUST NOT
set this flag.    Node protection 0x08    The
PLR will set this when the protected LSP has a
backup path which provides protection against a
failure of the next LSR along the protected LSP.
The PLR may set this whenever node protection
is provided by the protected LSP's backup path
the PLR MUST set this flag when the node
protection is provided and the "node protection
desired" flag was set in the SESSION_ATTRIBUTE
object. If node protection is not provided, the
PLR MUST NOT set this flag. Thus, if a PLR
could only setup a link-protection backup path,
the "Local protection available" bit will be set
but the "Node protection" bit will be cleared.