82
1 MPLS Protection/Restoration Instructor : Dr.Qiao Ph.d Student: Ming Zhao HanSheng Lei Hlei @buffalo. edu Mingzhao @ acsu .buffalo. edu

MPLS Protection/Restoration

  • Upload
    vashon

  • View
    25

  • Download
    0

Embed Size (px)

DESCRIPTION

MPLS Protection/Restoration. Instructor : Dr.Qiao Ph.d Student: Ming Zhao HanSheng Lei [email protected] [email protected]. Multiprotocol Label Switching Architecture & LDP. Introduction MPLS Basics LDP Procedures LDP Specification. MPLS&LDP->Introduction. - PowerPoint PPT Presentation

Citation preview

Page 1: MPLS Protection/Restoration

1

MPLS Protection/Restoration

Instructor : Dr.Qiao

Ph.d Student:

Ming Zhao

HanSheng Lei

[email protected]

[email protected]

Page 2: MPLS Protection/Restoration

2

Multiprotocol Label Switching Architecture & LDP

IntroductionMPLS BasicsLDP ProceduresLDP Specification

Page 3: MPLS Protection/Restoration

3

MPLS&LDP->Introduction

Conventional network forwarding

Each router analyzes the coming packet’s header and independently chooses a next hop. Routing algorithm and adequate speed are prerequisite.

MPLS forwarding All forwarding is driven by the labels, no header

analysis needed. Once a packet enters a network, it’s assigned a label. Each router forwards packets according their labels.

Page 4: MPLS Protection/Restoration

4

MPLS&LDP->Introduction

Advantages over conventional routing1. Router can use any information in determining label assignment,

not limited to packet header;

2. How to distribute labels may become more and more complicated, without any impact on the routers that merely forward labeled packets.

3. A label can be used to represent a pre-chosen route so that the identity of explicit route need not be carried with the packet.

4. Mutiprotocol: its techniques are applicable to ANY network layer protocol.

5. Etc.

Page 5: MPLS Protection/Restoration

5

MPLS&LDP->Introduction

Terminology. Some important terms.FEC(forwarding equivalence class) a group of IP packets which are

forwarded in the same manner (e.g., over the same path, with the same forwarding treatment)

LSR(label switching router) an MPLS node which is capable of forwarding native Layer 3 packets

label swap the basic forwarding operation consisting of looking up an incoming label to determine the outgoing label, encapsulation, port, and other data handling information.

MPLS domain a contiguous set of nodes which operate MPLS routing and forwarding and which are also in one Routing or Administrative Domain

Page 6: MPLS Protection/Restoration

6

MPLS&LDP->MPLS Basics

Labels Packet forward Route selection Tunnels and Hierarchy Multiprotocol

Page 7: MPLS Protection/Restoration

7

MPLS&LDP->MPLS Basics->Labels

A label is a short, fixed length, locally significant identifier which is used to identify a FEC. The label which is put on a particular packet represents the FEC to which that packet is assigned.

Most commonly, a packet is assigned to a FEC based (completely or partially) on its network layer destination address. However, the label is never an encoding of that address.

Page 8: MPLS Protection/Restoration

8

MPLS&LDP->MPLS Basics->Labels

Ru Rd

Upstream LSR Downstream LSR

Agreement: "binding" label L to FEC F for packets moving from Ru to Rd.

So, L becomes Ru's "outgoing label" representing FEC F, and L becomes Rd's "incoming label" representing FEC F. Note that L is an arbitrary value whose binding to F is local to Ru and Rd.

Page 9: MPLS Protection/Restoration

9

MPLS&LDP->MPLS Basics->Labels Label Assignment and Distribution The decision to bind a particular label L to a particular FEC

F is made by the LSR which is DOWNSTREAM with respect to that binding. The downstream LSR then informs the upstream LSR of the binding.

Attributes of a Label Binding A particular binding of label L to FEC F, distributed by Rd

to Ru, may have associated "attributes". If Ru, acting as a downstream LSR, distributes a binding of a label to FEC F, then under certain conditions, it may be required to also distribute the corresponding attribute that it received from Rd.

Page 10: MPLS Protection/Restoration

10

MPLS&LDP->MPLS Basics->Labels

A label distribution protocol is a set of procedures by which one LSR

informs another of the label/FEC bindings it has made.

The label distribution protocol also encompasses any negotiations in which two label distribution peers need to engage in order to learn of each other's MPLS capabilities.

THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL DISTRIBUTION PROTOCOL. E.g., [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS], [MPLS-LDP], [MPLS-CR-LDP].

Page 11: MPLS Protection/Restoration

11

MPLS&LDP->MPLS Basics->Packet forward

Fig 1. Procedures to forward a packet

Examine the label of packet

ILM

NHLFE

DetermineFEC

FTN

Next Hop

Unlabeled labeled

Discard

Invalid label

No outgoing label

Page 12: MPLS Protection/Restoration

12

MPLS&LDP->MPLS Basics-> Packet forward ILM(Incoming Label Map) Maps each incoming label to a set of NHLFEs. NHLFE(Next Hop Label Forwarding Entry) It contains the following information: 1. the packet's next hop 2. the operation to perform on the packet's label stack; this is one of the following operations: a) replace the label at the top of the label stack with a specified new label b) pop the label stack c) replace the label at the top of the label stack with a specified new label, and then push one or more specified new labels onto the label stack. It may also contain some other information

Page 13: MPLS Protection/Restoration

13

MPLS&LDP->MPLS Basics-> Packet forward

FTN(FEC-to-NHLFE) The FTN maps each FEC to a set of NHLFEs. It is used

when forwarding packets that arrive unlabeled, but which are to be labeled before being forwarded.

Determine unlabeled packet’s FEC LSR analyzes the layer network header to make decision.

How to analyze is beyond the scope of architecture.

Page 14: MPLS Protection/Restoration

14

MPLS&LDP->MPLS Basics-> Packet forward

Invalid Incoming Labels when a labeled packet is received with an invalid incoming label, it

MUST be discarded, UNLESS it is determined by some means (not within the scope of the MPLS architecture) that forwarding it unlabeled cannot cause any harm.

Lack of Outgoing Label Unless it can be determined that neither of these situations obtains, the

only safe procedure is to discard the packet. - If the packet has been following an explicitly routed LSP, this

could result in a loop. -The packet's network header may not contain enough information to enable this particular LSR to forward it correctly.

Page 15: MPLS Protection/Restoration

15

MPLS&LDP->MPLS Basics-> Packet forward

Page 16: MPLS Protection/Restoration

16

MPLS&LDP->MPLS Basics-> Packet forward

Page 17: MPLS Protection/Restoration

17

MPLS&LDP->MPLS Basics-> Route selection

Hop by hop routing Allows each node to independently choose the next hop for each FEC.

This is the usual mode today in existing IP networks. A "hop by hop routed LSP" is an LSP whose route is selected using hop by hop routing.

Explicit routing A single LSR, generally the LSP ingress or the LSP egress, specifies

several (or all) of the LSRs in the LSP. Explicit routing may be useful for a number of purposes, such as policy routing or traffic engineering.

Page 18: MPLS Protection/Restoration

18

MPLS&LDP->MPLS Basics-> Route selection

Page 19: MPLS Protection/Restoration

19

MPLS&LDP->MPLS Basics-> Tunnels&Hierarchy

R1 R2

R21 R22 R23

R3 R4 Level m-1

Level m

Fig. 2. Tunnels and Hierarchy

Page 20: MPLS Protection/Restoration

20

MPLS&LDP->MPLS Basics-> Tunnels&Hierarchy

Hop-by-Hop Routed Tunnel

If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd.

Explicitly Routed Tunnel

If a Tunneled Packet travels from Ru to Rd over a path other than the Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. For example, we might send a packet through an Explicitly Routed Tunnel by encapsulating it in a packet which is source routed.

Page 21: MPLS Protection/Restoration

21

MPLS&LDP->MPLS Basics->Multiprotocol

Labels for RSVP

When RSVP is used to set up resource reservations for particular

flows, it can be desirable to label the packets in those flows, so

that the RSVP does not need to be applied at each hop. It can be argued that having RSVP distribute the labels as part of its path/reservation setup process is the most efficient method of

distributing labels for this purpose.

Page 22: MPLS Protection/Restoration

22

MPLS&LDP->MPLS Basics->Multiprotocol

Labels for Explicitly Routed LSPs In some applications of MPLS, particularly those related to traffic engineering, it is desirable to set up an explicitly routed path, from ingress to egress. It is also desirable to apply resource reservations along that path. One can imagine two approaches to this: - Start with an existing protocol that is used for setting up resource reservations, and extend it to support explicit routing and label distribution. - Start with an existing protocol that is used for label distribution, and extend it to support explicit routing and resource reservations.

Page 23: MPLS Protection/Restoration

23

MPLS&LDP-> LDP Procedures

The Procedures for Advertising and Using labels There are a number of different procedures that may be used to

distribute label bindings. The downstream LSR must perform: - The Distribution Procedure, and - the Withdrawal Procedure. The upstream LSR must perform: - The Request Procedure, and - the NotAvailable Procedure, and - the Release Procedure, and - the labelUse Procedure.

Page 24: MPLS Protection/Restoration

24

MPLS&LDP-> LDP Procedures

1. Downstream LSR: Distribution Procedure The Distribution Procedure is used by a downstream LSR to

determine when it should distribute a label binding for a particular address prefix to its label distribution peers.

2. Upstream LSR: Request Procedure The Request Procedure is used by the upstream LSR for an address

prefix to determine when to explicitly request that the downstream LSR bind a label to that prefix and distribute the binding.

Page 25: MPLS Protection/Restoration

25

MPLS&LDP-> LDP Procedures

3. Upstream LSR: Release Procedure Suppose that Rd is an LSR which has bound a label to address prefix X, and has distributed that binding to LSR Ru. If Rd does not happen to

be Ru's L3 next hop for address prefix X, or has ceased to be Ru's L3 next hop for address prefix X, then Ru will not be using the label. The Release Procedure determines how Ru acts in this case.

4. Upstream LSR: labelUse Procedure Suppose Ru is an LSR which has received label binding L for address

prefix X from LSR Rd, and Ru is upstream of Rd with respect to X. Ru will make use of the binding if Rd is Ru's L3 next hop for X. The

labelUse Procedure determines just how Ru makes use of Rd's binding.

Page 26: MPLS Protection/Restoration

26

MPLS&LDP-> LDP Procedures

Security Considerations Some routers may implement security procedures which depend on

the network layer header being in a fixed place relative to the data link layer header. The MPLS generic encapsulation inserts a shim between the data link layer header and the network layer header. This may cause any such security procedures to fail.

An MPLS label has its meaning by virtue of an agreement between the LSR that puts the label in the label stack, and the LSR that interprets that label (the "label reader"). If labeled packets are accepted from untrusted sources, or if a particular incoming label is accepted from an LSR to which that label has not been distributed, then packets may be routed in an illegitimate manner.

Page 27: MPLS Protection/Restoration

27

MPLS&LDP-> LDP specification

LDP Message Exchange LDP Operation LDP Discovery LDP Session

Page 28: MPLS Protection/Restoration

28

MPLS&LDP-> LDP specification-> Message Exchange

Discovery messages used to announce and maintain the presence of an LSR in a network.

Session messages used to establish, maintain, and terminate sessions between LDP peers.

Advertisement messages used to create, change, and delete label mappings for FECs.

Notification messages used to provide advisory information and to signal error information.

Page 29: MPLS Protection/Restoration

29

MPLS&LDP-> 5. LDP specification-> LDP Operation

FECs Each FEC is specified as a set of one or more FEC

elements. Each FEC element identifies a set of packets which may be mapped to the corresponding LSP.

1. Address Prefix. This element is an address prefix of any length from 0 to a full address, inclusive.

2. Host Address. This element is a full host address.

Page 30: MPLS Protection/Restoration

30

MPLS&LDP-> 5. LDP specification-> LDP Operation

Label Spaces The notion of "label space" is useful for

discussing the assignment and distribution of labels.

- Per interface label space. Interface-specific incoming labels are used for interfaces

that use interface resources for labels. An example of such an interface is a label-controlled ATM interface that uses VCIs as labels.

- Per platform label space. Platform-wide incoming labels are used for interfaces

that can share the same labels.

Page 31: MPLS Protection/Restoration

31

MPLS&LDP-> 5. LDP specification-> LDP Operation

LDP Identifiers An LDP identifier is a six octet quantity used to identify an LSR

label space. The first four octets identify the LSR and must be a

globally unique value, such as a 32-bit router Id assigned to the

LSR. The last two octets identify a specific label space within the

LSR. The last two octets of LDP Identifiers for platform-wide label

spaces are always both zero.

<LSR Id> : <label space id>

e.g., lsr171:0, lsr19:2.

Page 32: MPLS Protection/Restoration

32

MPLS&LDP-> 5. LDP specification-> LDP Operation

LDP Sessions LDP sessions exist between LSRs to support label exchange between

them. When an LSR uses LDP to advertise more than one label space to another LSR it uses a separate LDP session for each label space.

LDP Transport LDP uses TCP as a reliable transport for sessions.

When multiple LDP sessions are required between two LSRs there is

one TCP session for each LDP session.

Page 33: MPLS Protection/Restoration

33

MPLS&LDP-> 5. LDP specification-> LDP Operation

Page 34: MPLS Protection/Restoration

34

MPLS&LDP-> 5. LDP specification-> LDP Discovery

LDP discovery is a mechanism that enables an LSR to discover potential LDP peers. Discovery makes it unnecessary to explicitly configure an LSR's label switching peers.

- A basic discovery mechanism used to discover LSR neighbors that are directly connected at the link level.

- An extended discovery mechanism used to locate LSRs that are not directly connected at the link level.

Page 35: MPLS Protection/Restoration

35

MPLS&LDP-> 5. LDP specification-> LDP Discovery

Extended Discovery Mechanism

LDP sessions between non-directly connected LSRs are supported by LDP Extended Discovery.

Extended Discovery differs from Basic Discovery in the following ways:

- A Targeted Hello is sent to a specific address - Unlike Basic Discovery, which is symmetric, Extended Discovery is asymmetric. Targeted LSR decides whether to respond to or

ignore the Targeted Hello.

Page 36: MPLS Protection/Restoration

36

MPLS&LDP-> 5. LDP specification-> LDP Session

Session Establishment

The exchange of LDP Discovery Hellos between two LSRs triggers LDP session establishment. Session establishment is a two step process:

- Transport connection establishment.

- Session initialization

Page 37: MPLS Protection/Restoration

37

MPLS&LDP-> 5. LDP specification-> LDP Session

Fig.3 Session Initialization State Machine

NON EXISTENT

OPERATIONAL

OPENSENTOPENREC

INITIALIZEDACTIVE ROLE

PASSIVE

Keep Alive

Shut Down/Time out

Time out/Error

Time out/Error

Keep Alive

Time out/Error

Page 38: MPLS Protection/Restoration

38

Outline Introduction MPLS Recovery Framework MPLS Mechanism for Protection/Restoration

Shared Backup LSP Restoration Fast reroute RSVP-TE Recovery

A Heuristic Restoration Approach Analysis Simulations Comparison

Page 39: MPLS Protection/Restoration

39

Outline Introduction MPLS Recovery Framework MPLS Mechanism for Protection/Restoration

Shared Backup LSP Restoration Fast reroute RSVP-TE Recovery

A Heuristic Restoration Approach Analysis Simulations Comparison

Page 40: MPLS Protection/Restoration

40

Current Backbone Networks Protection

Link layer protection (SONET/SDH) Be capable of service restoration within few tens of milliseconds The scope of the protection is limited, has no visibility into higher layer operations

Layer 3 protection Routing protocol provide much greater flexibility The cost of the restoration time in the order of seconds

to minutes

Page 41: MPLS Protection/Restoration

41

Motivation: MPLS-Based Recovery

MPLS is the lowest layer with the knowledge of the entire network topology

MPLS provide necessary traffic engineering capabilities MPLS has desirable attributes when applied to the

purpose of recovery for connectionless networks MPLS provide restoration times significantly shorter then

the convergence times of IP routing protocols

Page 42: MPLS Protection/Restoration

42

Definitions and Terminology Rerouting

the recovery path or path segments are created dynamically after the detection of a fault on the working path. (the recovery path is not pre-established)

Protection Switching

In contrast the Rerouting, the recovery path is pre- established

Page 43: MPLS Protection/Restoration

43

Definitions and Terminology Path Switch LSR (PSL)

The PSL is responsible for switching or replicating the traffic between the working path and the recovery path

Normally chose as the Ingress LSR or the nearest upstream LSR upon the failure node

Path Merge LSR (PML) The PML is responsible for receiving the recovery path

traffic, and either merges the traffic back onto the working path, or, if it is itself the destination, passes the traffic on to the higher layer protocols

Normally chose as the Egress LSR

Page 44: MPLS Protection/Restoration

44

Definitions and Terminology Fault Indication Signal (FIS)

A signal that indicates that a fault along a path has occurred. It is relayed by each intermediate LSR to its upstream or downstream neighbor, until it reaches the PSL

Fault Recovery Signal (FIS)

A signal that indicates a fault along a working path has been repaired.Like the FIS,it is relayed by each intermediate LSR to its upstream or downstream neighbor, until is reaches the PSL

Page 45: MPLS Protection/Restoration

45

Fault Detection Path Failure detected by a link probing mechanism (hello liveness message )

between neighbor LSRs Path Degraded path has connectivity, but that the quality of the connection is

unacceptable (eg.high error bit rate, label mismatch or due to TTL errors). it is detected by a path performance monitoring mechanism

Link Failure Link Degraded the link over which the working path is carried is performing

below an acceptable level

Page 46: MPLS Protection/Restoration

46

Path Mapping Path Mapping : the methods of mapping traffic from a

faulty working path on to the recovery path 1-to-1 Protection recovery path that is only to be used to recover that specific

working path n-to-1 Protection n working paths are protected using only one recovery path n-to-m Protection n working paths are protected using m recovery paths, the n working paths and the m recovery paths should be diversely routed between the same PSL and PML

Page 47: MPLS Protection/Restoration

47

Scope of Recovery Local Repair

protect against a link or neighbor node fault and to minimize the amount of time required for failure propagation

Fast but not optimized Global Repair

the PSL is usually distant from the failure and needs to be notified by a FIS

the recovery path can be made completely link and node disjoint with its working path

slower than local repair

Page 48: MPLS Protection/Restoration

48

Post Recovery Operation When traffic is flowing on the recovery path

decisions can be made to whether let the traffic remain on the recovery path and consider it as:

a new working path (Non-Revertive Mode ) switch to the old (Revertive Mode ) switch to a new preferred working path

( make before break ----- RSVP TE Recovery)

Page 49: MPLS Protection/Restoration

49

Outline Introduction MPLS Recovery Framework MPLS Mechanism for Protection/Restoration

Shared Backup LSP Restoration Fast reroute RSVP-TE Recovery

A Heuristic Restoration Approach Analysis Simulations Comparison

Page 50: MPLS Protection/Restoration

50

MPLS-based Recovery Principles Configuration of Recovery

Default-recovery (No MPLS-based recovery enabled) Recoverable (MPLS-based recovery enabled)

Initiation of Path Setup Pre-established Pre Qualified Established-on-Demand

Initiation of Resource Allocation Pre-reserved Reserved-on-Demand

Page 51: MPLS Protection/Restoration

51

MPLS Recovery Cycle Model Network Impairment Network Impairment

Start of Notification Start of Recovery Operation

Recovery Operation CompletePath Traffic Restored

Fault Detected

T1 Fault Detection Time T2 Hold-off Time

T3 Notification Time T4 Recovery Operation Time

T5 Traffic Restoration Time

T1 T2 T3 T4 T5 T

Page 52: MPLS Protection/Restoration

52

Main Comparison Criteria Recovery Time

the time required for a recovery path to be activated (and traffic flowing) after a fault Loss

Recovery schemes may introduce a certain amount of packet loss during switchover to a recovery path.

Backup Capacity : corresponding to ( Quality of Protection )

The capacity will be dependent on the traffic characteristics of the network, the particular protection plan selection algorithms as well as the signaling and re-routing methods.

Re-ordering the action of putting traffic back on preferred paths might cause packet re-ordering

State Overhead

As the number of recovery paths in a protection plan grows, the state required to maintain them also grows

Page 53: MPLS Protection/Restoration

53

Outline Introduction MPLS Recovery Framework MPLS Mechanism for Protection/Restoration

Shared Backup LSP Restoration Fast reroute RSVP-TE Recovery

A Heuristic Restoration Approach Analysis Simulations Comparison

Page 54: MPLS Protection/Restoration

54

Shared Backup LSP Restoration links on the backup path can be shared between different

active paths Single link failure restoration is guaranteed using only aggregate network usage information without

requiring per-LSP routing information for all current active LSPs

Aggregate information is obtainable by adding a few new information elements to the link state advertisement of a link state routing protocol like OSPF or ISIS

Page 55: MPLS Protection/Restoration

55

Model

BA

C

LSP 2

GFE

D

LSP 1

LSP 1 B LSP 1 B

LSP 2 B LSP 2 B

LSP 1 B LSP 2 B

LSP1 : E- F-G LSP1 Backup : E-C-D-G

LSP2 : A- B LSP2 Backup : A-C-D-B

Page 56: MPLS Protection/Restoration

56

Algorithm

For link (i,j) the cumulative bandwidth allocated for active

paths is F(i,j) the cumulative bandwidth allocated for backup

paths is G(i,j) the residual bandwidth free for allocation is R(i,j)

Page 57: MPLS Protection/Restoration

57

Algorithm For a request of bandwidth b the active path is calculated as

the shortest path on the topology of links that have R(i,j) > b Let M be the max of the F values along the active path The backup path is calculated as follows. The cost of a link

(u,v) is now taken as: 0 if { M+b < G(u,v) } else b if { G(u,v) <= M and b <= R(u,v) } else M+b - G(u,v) if { M <= G(u,v) and M+b <= G(u,v)+R(u,v) } else infinity in all other cases

The backup path is calculated as the shortest path on the topology with the cost of links calculated as above

Page 58: MPLS Protection/Restoration

58

Fast Reroute Main Idea: reverse traffic at the point of failure of the protected LSP back

to the source switch of the protected LSP such that the traffic flow can be redirected via a parallel LSP between source and destination switches of the protected LSP tunnel

Objective: provide a single failure protection with quick restoration

comparable to the order of milliseconds Minimize the alternative path computation complexity and

signaling requirements 1:1 protection and 1:N protection can be achieved

Page 59: MPLS Protection/Restoration

59

Fast Reroute Model

1:1 protection

LSR 1 LSR 3 LSR 5 LSR 7

LSR 2 LSR 4 LSR 6

13 35 57

755331

12

24 46

67

From LSR 1 to LSR 7 LSR1: PSL , LSR7 : PML

Working LSP: 13-35-57 alternative LSP: 53 –31-12-24-46-67

Page 60: MPLS Protection/Restoration

60

Fast Reroute Model 1:N protection

LSR 1 LSR 3 LSR 5 LSR 7

LSR 2 LSR 4 LSR 6

13 35 57

755331

12

24 46

67

LSR 8 LSR 9

10

15

203040

2457

4657

57

1257

1220

2420

4620

20

( Using Label Stack )

3157

4020

Page 61: MPLS Protection/Restoration

61

Restoration Shortcuts

Source LSR A LSR B LSR C

LSR D

Destination

LSR B setup the a shortcut alternative LSP

Applied for Voice over IP service

Page 62: MPLS Protection/Restoration

62

Prof. and Cons. Path computation complexity is greatly reduced

both primary and alternative path computations can be localized at a single switch

The amount of LSP setup signaling is minimized presence of traffic on the alternative segment path

can be used as an FIS of the downstream primary path

Data packet need reordering during the path rerouting process

Less efficient use the resources (total length protection)

Page 63: MPLS Protection/Restoration

63

RSVP Detour To achieve timely detour path setup, using pre-

computed and pre- established detour path is essential for data traffic where packet loss is undesirable

Detour decision must be made as close to the failure point as possible

Ideal detour mechanism is to protect the entire LSP by establishing detour paths throughout the LSP

To minimize the path computation overhead, it is desirable for the detour paths to merge back to the main LSP as soon as possible

Now, only protect unidirectional LSP

Page 64: MPLS Protection/Restoration

64

RSVP Detour Model

For detour ( Ingress,LSR2 ) , LSR1 and LSR 3 are not aware of the detour

Activate RSVP Tunnel (LSP)

RSVP Detour (LSP)

Ingress EgressLSR 1 LSR 3LSR 2

detour ( Ingress,LSR2 )

Page 65: MPLS Protection/Restoration

65

RSVP ExtensionTwo new objects are defined to support LSP fast-reroute FAST_REROUTE object

Setup (Holding) Priority: The priority of the detour with respect to taking(holding) resources

Hop – limit: The maximum number of extra hops the detour is allowed to take

Bandwidth DETOUR object

Source ID : IPv4 address identifying the beginning point of detour Downstream Node ID :IP address identifying the downstream

node that source is trying to avoid

Page 66: MPLS Protection/Restoration

66

Make before break In general, it is highly desirable not to disrupt traffic, or

adversely impact network operations while TE tunnel rerouting is in progress.

This adaptive and smooth rerouting requirement necessitates establishing a new LSP tunnel and transferring traffic from the old LSP tunnel onto it before tearing down the old LSP tunnel

The principle (implemented by RSVP Tunnel) applies not only in the case of failure but also when better routes are available than the existing ones.

Page 67: MPLS Protection/Restoration

67

Outline Introduction MPLS Recovery Framework MPLS Mechanism for Protection/Restoration

Shared Backup LSP Restoration Fast reroute RSVP-TE Recovery

A Heuristic Restoration Approach Analysis Simulations Comparison

Page 68: MPLS Protection/Restoration

68

Analysis

Basic Idea Providing fault tolerance in MPLS networks based on the

concept of “ domain protection” In that domain, protection paths for all working paths that

terminate in an egress router are calculated simultaneously The algorithm attempts to locate two trees in the domain

such that no single link failure would disconnect a node form the root of the tree (the egress node)

Permit the decoupling the protection path placement from the working path (much greater flexibility)

Page 69: MPLS Protection/Restoration

69

Analysis

Conditions Assume MPLS domain represented by graph

G(N,L) N is the set of n nodes L is the set of l links between the nodes

Assume that graph G is two-edge redundant and therefore can be protected against any single link failure

Page 70: MPLS Protection/Restoration

70

Analysis Input : The MPLS domain D and the egress router e Output : two collections of protection path

connecting ingress routers to egress router e Initialization:

Find a spanning tree of graph G rooted in the egress router e.

Let P be the set of nodes for which the protection paths have been established

Initially it contains the egress router: p ={e}

Page 71: MPLS Protection/Restoration

71

Heuristic Algorithm Repeat until all nodes are protected (P=N):

1. Select one of the branches of the spanning tree attached to the egress node and mark all its nodes except for the egress node

2. Scan all marked nodes to find node i that has a link to an unmarked node j

3. Find a ring path consisting of the links of the spanning tree leading from e to i, the link between I and j, and the links of the spanning tree between j and e ( note that if j = e, this segment of the ring is empty )

Page 72: MPLS Protection/Restoration

72

Heuristic Algorithm (Cont.)4. Place two ring paths along the ring:

1) one in clockwise, the other in counterclockwise direction

2) Merge the created protection paths with protection paths established in the previous iterations of the algorithm for the protected nodes that are now a part of the egress node

3) All nodes on the ring are added to p

5. Consider a new graph constructed by treating all nodes in P as a single node that will act as the egress node

6. Begin the subsequent iteration

Page 73: MPLS Protection/Restoration

73

Heuristic Model

A

B

C

F

D

E

B

C

F 1. Find a branch

2. Find node C has a link with an unmarked node D

3. construct the ring

B

4. All nodes on the ring are now a part of the egress node

C

D

E

5. Next iteration : Node F assume both node C and D as egress node, and setup the protection path respectively

F

Page 74: MPLS Protection/Restoration

74

Quality of a protection Scheme

Finding optimal protection path The length of the protection path

Indicate the delay of the traffic after a link failure Reflect the amount of the resources required to protect

the domain The number of protection paths pre link

Indicate the amount of resources (eg. Label table size, signalling overhead need to maintain the protection)

Indicate that how well the protection paths are distributed throughout the network

Page 75: MPLS Protection/Restoration

75

Heuristic Decisions Spanning tree selection

The protection paths are routed mostly along the branched of the spanning tree

Try to find up a spanning tree with many short branches

Using the Dijkstra’s algorithm to calculate the shortest path spanning tree

Finding the smallest possible ring Reduce the maximum and the average protection

path lengths

Page 76: MPLS Protection/Restoration

76

Heuristic Decisions Example

Find the short branch A-B-C (step 1)

Comparison the length of the ring (step 2 &3) A-B-C-F selected

Heuristic edge Decisions

Page 77: MPLS Protection/Restoration

77

Simulations

Maximum length of protection paths for meshes Average length of protection paths for meshes

Page 78: MPLS Protection/Restoration

78

Simulations

Number of protection paths per link for meshes Avg. number of protection paths per link for meshes

Page 79: MPLS Protection/Restoration

79

Comparison of MPLS Protection Schemes

Page 80: MPLS Protection/Restoration

80

Conclusion The scheme considers protection of all paths leading from

ingress routers to a common egress router Protection using two paths allow for greater flexibility in

protection path placement It provides the protection is better than Fast Reroute scheme The algorithmic complexity is less than that of RSVP

Backup Tunnel while providing comparably good protection Unlike the FR and BT schemes, it guarantees independence

of the working and protection path placement

Page 81: MPLS Protection/Restoration

81

MPLS Recovery Goals Using traffic engineering to optimal use of resources Aim to facilitate restoration times that are sufficiently fast for the end user application Aim to maximize network reliability and availability Aim to be applicable for protection of traffic at various granularities

for a portion of the traffic on an individual path for all traffic on an individual path for all traffic on a group of paths

Be applicable for segments or an entire end-to-end path

Page 82: MPLS Protection/Restoration

82

References Framework for MPLS-based recovery Vishal Sharma, Ben-Mack Crane,

<Draft-ietf-mpls-recovery-framework-03> , July 2001 Extensions to RSVP-TE for MPLS Path Protection Ken Owens, Vishal Sharma <Draft-chang-mpls-path-protection-02>, July 2001 Shared Backup Label Switched Path Restoration Sriganesh Kini Murali Kodialam

<Draft-kini-restoration-shared-backup-01>, May 2001 A Method for Setting an Alternative Label Switched Paths to Handle

Fast Reroute Dimitry Haskin , Ram Krishnan <Draft-haskin-mpls-fast-reroute-05>, November 2000

A Method for MPLS LSP Fast-Reroute Using RSVP Detours Der-Hwa Gan,

<Draft-gan-fast-reroute-00 > April 10, 2001 MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute Alia

Atlas ,Curtis Villamizar <Draft-atlas-rsvp-local-protect-interop-01>, July 2001 “ A heuristic approach to service restoration in MPLS networks,” in proc. Of the 2001

IEEE International Conference on Communications (ICC), Helsinki, Finland, June 2001