1 / 24

Protection and Restoration

Protection and Restoration. Definitions A major application for MPLS. The problem. Network resources will fail Nodes and links IGP will re-converge But this may take some time 10s of seconds Fast convergence has a price May make IGP more sensitive/unstable

tvasquez
Télécharger la présentation

Protection and Restoration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protection and Restoration • Definitions • A major application for MPLS

  2. The problem • Network resources will fail • Nodes and links • IGP will re-converge • But this may take some time • 10s of seconds • Fast convergence has a price • May make IGP more sensitive/unstable • I may have sensitive traffic that can not afford interruptions • Voice, Consumer TV • Do something for the time until IGP re-converges

  3. Terminology • Restoration • Bring traffic back to normal • Backup • Alternative resources to be used when there is a failure • Protection • Determine and allocate the backup resources before the failure • When there is a failure just activate them • Can be very fast • Repair • Determine, allocate and activate the backup resources after the failure • Will be slower

  4. Failure Modes • Single vs. multiple link failures • If duration of link failure is short, can assume that there will be only a single link failure • Much harder to deal with multiple link failures • Node vs. link failures • Can assume that links will fail more frequently than nodes • Node failures are harder to handle

  5. Backup resources • Can be multiple types • Links • Paths • Trees • Cycles • Whole topologies • In order to avoid network overload after a failure need to have some extra capacity for backup resources • Problem is how to engineer them so as not to make the network too expensive • Minimize the amount of backup capacity that is reserved

  6. More jargon • 1:1 • 1 working, 1 backup • Wastes a lot of bandwidth for the backups • 1:N • N working and 1 backup • Assume that only 1 working will fail • Then 1 backup is enough – save bandwidth • Revertive: • when the failure is fixed, revert to the primary • SRLG: Shared Risk Link Group • A set of network links that fails together • E.g fibers that are in the same conduit • A bulldozer will cut all of them together

  7. Other issues • How to detect the failure fast • BFD is one general solution • There are medium specific solutions • OAM for ATM • Alarms for SONET • Preferable if they exist • Protocol mechanisms (RSVP HELLOs, OSPF HELLOs, etc) • How to activate the backup • I.e how to make traffic use an alternate path, or a tree

  8. Backbone failure analysis • Sprint backbone ca. March 2002 • Link in class website • Monitor IS-IS traffic • Data only for link failures, not node failures • Failure Duration • 50% failures last less than 1 min • 40% failures last between 1 and 20 min • Maintenance • 50% of failures during maintenance windows • Mean time between failure (MTBF) • Mean time between failures varies a lot across links • “good” and “bad” links • 3 bad links account for 25% of the failures

  9. More analysis • Unplanned failure breakdown • Shared link failures = 30% • Router related = 16.5% • Optical related = 11.5% • Individual link failures = 70% • Node failures less common that single link failures • About 16.5% of failures affect more than 1 link

  10. Handling failures with IP • Easy case • ECMP, no need to do anything extra during failure • But it may not repair all failures • Coverage: what percentage of the possible failures can be repaired • In general activating backup resources is hard with IP • Packets will follow the IP route table/FIB • Forwarding is hop-by-hop • Even if I compute a backup link for a failure, I have no control what will happen after the next hop • May have routing loops

  11. IP protection • Backup next-hop • Each node computes a backup nexthop for each destination • so that I will not have routing loops • It may not have 100% coverage • For more general solutions I need tunneling • Must force packets to reach their destination • Without crossing the failed resource • Tunnel to the node after the failed link • Tunnel to an intermediate node • IP tunneling is an expensive operation • It is packet encapsulation

  12. Not-Via addresses • Consider router A, with interfaces A1, A2, A3 • A1 connects to interface B1 or router B, • A2 connects to interface C2 of router C • B1 has a second address B1-not-via-A • All routers compute paths to B1-not-via-A by removing router A from topology and running SPF • When router A fails, if C wants to reach B sends packets to address B1-not-via-A • Encapsulates the packets • 100% coverage • Can handle node and link failures • Still needs encapsulation

  13. Multi-topology protection • New approach • Have multiple subsets of the topology • IGP protocols already support multi-topology routing • Switch to a different topology when there is a failure • By modifying the header of the packet • Or even using an MPLS label • Allows for more flexible routing of traffic after a failure

  14. Using MPLS • MPLS can conveniently direct traffic where I want • Ideal for setting up backup resources • Mostly backup paths • Can be used to repair both IP and MPLS failures (I.e. LSP failure) • LSP protection can be • Path • Local

  15. Path protection • For each LSP (primary) have a backup LSP • It is already established (with RSVP) but it is not carrying any traffic • Primary and backup LSPs should be link and node disjoint • When there a failure the source of the LSP will start sending traffic to the backup • Source needs to be notified for the failure • May take some time for the repair of the traffic • Can work in both 1:1 and 1:N modes

  16. Local protection • When a link or node fails the node upstream from the failure repairs the traffic • Traffic is put into a back LSP that does not go over the failed resource • Backup LSP merges with the primary LSP • Repairing router does not send a PATHerr upstream • Instead notify upstream nodes that it is repairing the failure • It is very fast • Can work in 1:1 and 1:N modes • Can be • Node • Bypass a failed node • Link • Bypass a failed link

  17. Link local protection • The node upstream of the failed link initiates the protection • Point of local repair (PLR) • Backup LSP will merge back to the primary one • At the next-hop (Nhop) of the PLR • Can work in 1:1 and 1:N modes • Usually a single backup LSP protects multiple primary LSPs • Else scalability is not good

  18. Node local protection • When a node fails, assume its links have failed too • The node upstream of the failed node initiates the protection • Point of local repair (PLR) • Backup LSP will merge back to the primary one • At the next-next-hop (NNHop) of the PLR • What label does the NNHop use for the primary LSP? • Need RSVP’s help to find out • Will need multiple backup LSPs for each node • At least one for each NNHop • Can optionally configure more

  19. Label stacking • Each time I send traffic into an LSP I push a label on the packets • Packets in the primary LSP already have a label • I create a label stack • Top label is popped by the router just before the merge point • A catch • At the merge point, packet arrives from an interface different than the expected one • Must have global (platform) label space

  20. Need some RSVP support • If the LSP is protected do not send a errors upstream/downstream when there is a failure • Instead notify upstream nodes that repair is in progress • During failure the PATH,RESV for the primary LSP must continue • Send them through the backup LSP • For node protection need to know the label the NNHop is using for the primary • Use the record label option for the LSP • All the labels used in all the hops are recorded in the RESV message

  21. LSP protecting IP • Can use the above techniques to also protect IP traffic • If a link fails all the traffic that would go through the link is sent over the backup LSP • Similar for node failures • But in this case, do I know the nnhop for IP? • In general, If I have MPLS in my network all my traffic will be inside MPLS tunnels anyway

  22. Observations • If node degree is d and I have N nodes then • I need at least O(Nd) tunnels for link protection • And at least O(Nd^2) for node protection • Of course I can not protect from failures of the ingress or egress node • The assumption is that failures will be short lived • Traffic may be unbalanced during the failure • Links can get overloaded

  23. The resource allocation problem • How do I setup the backup tunnels so that • I do not overload any link after a failure • I minimize the amount of extra bandwidth that will need to be reserved for the backups • It is a form of traffic engineering (TE) • We will see more on TE later on • Has been studied a lot • In optical and telephone networks • And recently in MPLS type networks • Solutions can be • On-line (as the requests arrive) • Off-line

  24. Example • Kodialam, Lakshman, 2001 • Local link and node protection • Assume I know the b/w demands of all LSPs • Assume that only one link or node can fail at a time • Find a set of backup paths that minimizes the amount of bandwidth for both primary and backup LSPs • Backup LSPs can share bandwidth on some links • What do I know about the links? • How much bandwidth is used by each LSP • Complete but expensive to maintain • How much bandwidth is available • Almost zero information • How much bandwidth is used by backup LSPs • Little bit better than zero

More Related