CS 672
1
Summer 2003
Lecture 12
FastReRoute (FRR) - Big Picture
CS 672
2
Summer 2003
Handling Link Failures
1 Link fails.
2 HE detects link failure event through IGP/RSVP-TE.
3 HE calculates alternate path, establishes a new LSP and reroute traffic onto it.
Head-end Tail
R2 R3 R4 R7
R5
R1
R5
XX12
3
R6
CS 672
3
Summer 2003
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.
CS 672
4
Summer 2003
Local Repair
1 Link fails.
3 HE learns about the link failure sometime later.
4 HE calculates alternate path, establishes a new LSP (make-before-break) and reroute traffic onto it.
R3 detects the link failure very quickly (e.g., 1-2 millisecond). Reroute the traffic onto backup LSP.2
Head-end Tail
R2 R3 R4 R7
R5
R1
R5
XX12
4
R6
This local repair mechanism isreferred to as FastReRoute (FRR)
Repaired LSP may be suboptimal.Therefore, HE reoptimizes the LSP
CS 672
5
Summer 2003
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.txtFast Reroute Extensions to RSVP-TE for LSP Tunnels draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
CS 672
6
Summer 2003
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 (1:1) 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).
CS 672
7
Summer 2003
Bypass and Detour
R1 R2
R6
R7
R0
R8R5
R9R4R3
To protect three LSPs, need 3 detour LSPs
To protect three LSPs, need 1 bypass tunnel
CS 672
8
Summer 2003
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!)
CS 672
9
Summer 2003
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
CS 672
10
Summer 2003
Terminology
R1 R2
R6
R7 R8R5
R9R4R3
Reroutable LSP
NNHOP Bypass tunnel (Node Protection)
Point of Local Repair(PLR)
Merge Point (MP)
Protected LSP
NHOP Bypass Tunnel (Link Protection)
Merge Point (MP)
Head
XXXX
CS 672
11
Summer 2003
Bypass Tunnel - Link Protection
R1 R2
R6
R7 R8R5
R4R3
XX
• 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
• 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
CS 672
12
Summer 2003
Bypass Tunnel – Node Protection
R1 R2
R6
R7 R8R5
R4R3
XX
• 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
• 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
PLR MP
CS 672
13
Summer 2003
Bypass Tunnel – Label Stacking
• 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)
• 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)
R1 R2
R6
R7 R8R5
R4R3
XXPLR
6 7 8 9 10 11 12 13 14 15 16 17
1220
1420
1320
121314
MP
CS 672
14
Summer 2003
Bypass Tunnel – Label Stacking
R1 R2
R6
R7 R8R5
R4R3
1420
XX
1421
14
8
CS 672
15
Summer 2003
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.
CS 672
16
Summer 2003
Bypass Tunnel – RSVP State
R1 R2
R6
R7 R8R5
R4R3
XXPLR
MP
LSP RSVP State
XX XXXX
R5 has failed. RSVP state is not refreshed. R7 times out the state.
XX
R5 has failed. RSVP state is not refreshed. R2 times out the state.
XX
LSP disrupted.
Bypass tunnel does not any purpose.
CS 672
17
Summer 2003
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.
CS 672
18
Summer 2003
Bypass Tunnel – Solution
R1 R2
R6
R7 R8R5
R4R3
XXPLR
MP
LSP RSVP State
XX
Bypass Tunnel RSVP State
RSVP refresh msg
Per LSP state not created
CS 672
19
Summer 2003
Detour
Scalability Issue - Detour needs to create and refresh lot more information.Scalability Issue - Detour needs to create and refresh lot more information.
R1 R2
R6
R7 R8R5
R4R3
XX
Detour creates per LSP state in the nodes along the detour path.
Detour LSPs
Detour creates per LSP state in the nodes along the detour path.
Detour does not use label stack.
CS 672
20
Summer 2003
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.
CS 672
21
Summer 2003
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_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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CS 672
22
Summer 2003
Session Attribute Object (new flags)
Flags: 0x01 Local protection desired (to request local repair via FRR) 0x02 Label recording desired (in RRO) 0x04 SE Style desired (e.g., for LSP re-optimization). (A tunnel egress node SHOULD use the SE Style when responding with a Resv message).
0x08 Bandwidth protection desired. This flag indicates to the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP, if no FAST_REROUTE object is included in the PATH message; if a FAST_REROUTE object is in the PATH message, then the bandwidth specified therein is that to be guaranteed
0x10 Node protection desired.
Flags: 0x01 Local protection desired (to request local repair via FRR) 0x02 Label recording desired (in RRO) 0x04 SE Style desired (e.g., for LSP re-optimization). (A tunnel egress node SHOULD use the SE Style when responding with a Resv message).
0x08 Bandwidth protection desired. This flag indicates to the PLRs along the protected LSP path that a backup path with a bandwidth guarantee is desired. The bandwidth to be guaranteed is that of the protected LSP, if no FAST_REROUTE object is included in the PATH message; if a FAST_REROUTE object is in the PATH message, then the bandwidth specified therein is that to be guaranteed
0x10 Node protection desired.
FRR related new flags
CS 672
23
Summer 2003
RRO (new flags)
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-
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) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+
RRO Object:
Subobject 1, IPv4 Address:
Subobject 3, Label:
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0x01= local protection available0x02= local protection in use0x04 = bandwidth protection0x08 = node protection
CS 672
24
Summer 2003
RRO (new flags)
Bandwidth protection: 0x04
The PLR will set this when the protected LSP has a backup pathwhich is guaranteed to provide the desired bandwidth specifiedin 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.
Bandwidth protection: 0x04
The PLR will set this when the protected LSP has a backup pathwhich is guaranteed to provide the desired bandwidth specifiedin 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.