1. CS 672 1 Summer 2003 Lecture 12 FastReRoute (FRR) - Big Picture

2. 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 X X 1 2 3 R6

3. 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.

4. 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 X X 1 2 4 R6 This local repair mechanism is referred to as FastReRoute (FRR) Repaired LSP may be suboptimal. Therefore, HE reoptimizes the LSP

5. 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.txt

6. 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).

7. CS 672 7 Summer 2003 Bypass and Detour R1R2 R6 R7 R0 R8R5 R9R4R3 To protect three LSPs, need 3 detour LSPs To protect three LSPs, need 1 bypass tunnel

8. 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!)

9. 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

10. CS 672 10 Summer 2003 Terminology R1R2 R6 R7R8 R5 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 X X X X

11. CS 672 11 Summer 2003 Bypass Tunnel - Link Protection R1R2 R6 R7R8 R5 R4R3 X X 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. CS 672 12 Summer 2003 Bypass Tunnel – Node Protection R1R2 R6 R7R8R5 R4R3 X X 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 PLRMP

13. 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) R1R2 R6 R7 R8R5 R4R3 X X PLR 67891011121314151617122014201320 121314 MP

14. CS 672 14 Summer 2003 Bypass Tunnel – Label Stacking R1R2 R6 R7R8R5 R4R3 1420 X X 1421 14 8

15. 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.

16. CS 672 16 Summer 2003 Bypass Tunnel – RSVP State R1R2 R6 R7 R8R5 R4R3 X X PLR MP LSP RSVP State X X X X X X R5 has failed. RSVP state is not refreshed. R7 times out the state. X X R5 has failed. RSVP state is not refreshed. R2 times out the state. X X LSP disrupted. Bypass tunnel does not any purpose.

17. 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.

18. CS 672 18 Summer 2003 Bypass Tunnel – Solution R1R2 R6 R7 R8R5 R4R3 X X PLR MP LSP RSVP State X X Bypass Tunnel RSVP State RSVP refresh msg Per LSP state not created

19. CS 672 19 Summer 2003 Detour Scalability Issue - Detour needs to create and refresh lot more information. R1R2 R6 R7R8R5 R4R3 X X 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.

20. 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.

21. 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 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. 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. FRR related new flags

23. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x01= local protection available 0x02= local protection in use 0x04 = bandwidth protection 0x08 = node protection

24. CS 672 24 Summer 2003 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.