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.