Core Backbone Convergence Mechanisms and Microloops Analysis

In this article we study approaches that can be used to minimise the convergence time, we also make a focus on microloops phenomenon, analysis and means to mitigate them. The convergence time reflects the time required by a network to react to a failure of a link or a router failure itself. When all nodes (routers) have updated their respective routing and forwarding databases, we can say the network has converged. This study will help in building real-time and resilient network infrastructure, the goal is to make any evenement in the core network, as transparent as possible to any sensitive and real-time flows. This study is also, a deepening of earlier works presented in (10) and (11). Keywords-component: FC(Fast-convergence); RSVP(ressource reservation protocol); LDP (Label Distribution Protocol); VPN(Virtual Private Network); LFA (loop free alternate); MPLS (Multiprotocol Label Switching); PIC(Protocol independent convergence); PE(Provider edge router); P(Provider core router ).


I. INTRODUCTION
Mpls/vpn backbones are widely used today by various operators and private companies in the world, high to mediumsized companies build their own Mpls/vpn backbone or use services of an operator .Real time applications like voice and video are more and more integrated to end user applications, making them ever more time sensitive.
Operators are offering services like hosting companies' voice platforms, VoIP call centers, iptv...Etc.All these aspects make the convergence time inside the backbone a challenge for service providers.However, the global convergence time is an assembly of several factors including: link or node failure detection, IGP failure detection, LSP Generation, SPT Computation, RIB update, local FIB creation and distribution ...updates signaling...etc.
Based on analysis and statistics of large backbone possibilities we have delimited our convergence target as follows: [PE to P] convergence, in other terms [PE to core] must be under sub-second, hopefully under 50 msec, even on highly loaded PE, the convergence time should be almost independent of vpnv4, 6PE, 6VPE or igp prefixes number…[P to PE] and [P to P] convergence must stay under sub-second and consistent in both directions: [core to PE], [PE to core].
From the customer point of view: the overall [end-to-end] convergence should stay under 1 sec (no impact on most time sensitive applications).A lot of approaches can be used to minimise the convergence time, our approach consists on enhancements and optimizations in control and forwarding plane.While a lot of things can also be made at the access, the scope of our work is the core backbone.
Not only a backbone design must take into account criterion like redundant paths at each stage, but redundancy at the control plane only, does not make a lot of sense if, in the forwarding plane, backup paths are not pre-computed.We can say that a backbone meets a good convergence design if at each segment of the tree structure; we are able to calculate the time it takes for flows to change from the nominal path to the backup one.
On the other hand, temporary microloops may occur during the convergence interval, indeed, after a link or node failure in a routed network and until the network re-converges on the new topology, routers several hops away from the failure, may form temporary microloops.This is due to the fact that a router's new best path may be through a neighbor that used the first router as the best path before failure, and haven't had yet a chance to recalculate "and/or" install new routes through its new downstream.We can understand microloops are transient and self-corrected, however depending on their duration, the CPU load on the control plan may increase to 100%, so in addition to mitigation methods presented in this article, some cpu protection mechanisms are also discussed.The approach used in this article is theory against lab stress and result analysis.The aim of the study is to give an accurate idea of gains and drawbacks of each method, and show when one or the other method more fits the network topology.

II. FAST CONVERGENCE MODELS
In an attempt to construct a model for IGP and BGP protocols, we must take into account the following components: www.ijacsa.thesai.org Time to detect the network failure, e.g.interface down condition.
 Time to propagate the event, i.e. flood the LSA across the topology.
 Time to perform SPF calculations on all routers upon reception of the new information.
 Time to update the forwarding tables for all routers in the area.
And then modelise the IGP Fast Convergence by a formula which is the sum of all the above components:

III. LINK FAILURE DETECTION MECHANISM
The ability to detect that a failure has happened is the first step to towards providing recovery, and therefore, is an essential building block for providing traffic protection.Some transmission media provide hard-ware indications of connectivity loss.One example is packet-over-SONET/SDH where a break in the link is detected within milliseconds at the physical layer.Other transmission media do not have this ability, e.g.Ethernet (note that the fast detection capability has been added to optical Ethernet).
When failure detection is not provided in the hardware, this task can be accomplished by an entity at a higher layer in the network.But there is disadvantage to that, using IGP hello as example: We know that IGPs send periodic hello packets to ensure connectivity to their neighbors.When the hello packets stop arriving, a failure is assumed.There is two reasons why hello-based failure detection using IGP hellos cannot provide fast detection times:  The architectural limit of IGP hello-based failure detection is 3 seconds for OSPF and 1 second for ISIS.In common configurations, the detection time ranges from 5 to 40 seconds.
 Since handling IGP hellos is relatively complex, raising the frequency of the hellos places a considerable burden on the CPU.

IV. BIDIRECTIONAL FORWARDING DETECTION (BFD)
The heart of the matter lies in the lack of a hello protocol to detect the failure at a lower layer.To resolve this problem, Cisco and Juniper jointly developed the BFD protocol.Today BFD has its own working group (with the same name IETF [BFD]).So what exactly is BFD ?BFD is a simple hello protocol designed to provide rapid failure detection for all media types, encapsulations, topologies, and routing protocols.It started out as a simple mechanism intended to be used on Ethernet links, but has since found numerous applications.Its goal is to provide a lowoverhead mechanism that can quickly detect faults in the bidirectional path between two forwarding engines, wether they are due to problems with the physical interfaces, with the forwarding engines themselves or with any other component.But how can BFD quickly detect such a fault ?
In a nutshell, BFD is exchanging control packet between two forwarding engines.If a BFD device fails to receive a BFD control packet within the detect-timer: Then it informs its client that a failure has occurred.Each time a BFD successfully receives a BFD control packet on a BFD session, the detect-timer for that session is reset to zero.Thus, the failure detection is dependent upon received packets, and is independent of the receiver last transmitted packet.So we can say that expected results depend on the platform and how the protocol is implemented, but available early implementations can provide detections in the range of tens of milliseconds.

A. FEATURE DESCRIPTION
Packet loss can occur when the actions of the IGP (e.g.ISIS) and LDP are not synchronized.It can occur in the following situations:  When an IGP adjacency is established, the router begins forwarding packets using the new adjacency before the LDP label exchange ends between the peers on that link.
If an LDP session closes, the router continues to forward traffic using the link associated with the LDP peer rather than an alternate pathway with a fully synchronized LDP session.
To solve the first point, the following algorithm is being used: If there is a route to the LDP peer, IGP adjacency is held down, waiting for LDP synchronization to be completed; in other words, waiting for labels exchange to be completed.By default, adjacency will stay down for ever if LDP does not synchronize.This default behavior is tunable via configuration command "mpls ldp igp sync hold-down <duration in ms>" to specify the maximum amount of time the adjacency will stay down.At expiration of this timer, the link will be advertised, but with metric set to maximum in order to avoid using this link.If there is no route to the LDP peer, IGP adjacency is brought up, but with a metric set to the maximum value in order to give a chance for the LDP session to go up.In this www.ijacsa.thesai.orgcase, once the LDP session goes up and finishes labels exchange, the IGP metric reverts back to its configured value.
To solve the second point, the feature will interact with IGP to modify link metric according to LDP session state.As soon as LDP session is going down, the IGP metric of the related link is set to its maximum.Then, others nodes on the network can compute a new path avoiding to use this link.

A. TUNING EXPLAINED
ISIS runs a Dijkstra-algorithm to compute the tree followed by a computation of the routing table.If the receipt of a modified LSP does affect the tree, an SPF (shortest path first calculation) is run; otherwise a simple PRC (partial route calculation) is run.An example of evenement that will trigger only a PRC is the addition of a loopback on a distant node (this does not change the tree, just one more IP prefix leaf is on the tree) The PRC process runs much faster than an SPF because the whole tree does not need to be computed and most of the leaves are not affected.However, by default, when a router receives an LSP which is triggering an SPF or a PRC, it does not start it immediately, it is waiting for a certain amount of time (5.5 seconds for SPF & 2 seconds for PRC).Lowering this initial "wait time" would significantly decrease the needed convergence time.
On the other hand, it is necessary to leave enough time to the router to receive all LSPs needed for computing the right SPF, so there is a lower limit not to be exceeded.Otherwise, If SPF computation starts before having received all important LSP, you may need to run another SPF computation a bit later.Then, overall convergence would not be optimal.
Between the first SPF (or PRC) and followings ones, the router will also wait for some times, default values are (5.5 seconds for SPF and 5 seconds for PRC).However the maximum amount of time a router can wait is also limited (10 seconds for SPF and 5 seconds for PRC).

B. FEATURE USAGE IN OUR STUDY
The worst case, to take into consideration while choosing the initial wait time, is a node failure.In this situation, all neighbors of the failing node will send LSP reporting the problem.These LSP will be flooded through the whole network.Some studies indicate that 100 ms is enough for very large and wide networks.So here our chosen values: The same parameters have been applied on all routers to keep a consistency and same behavior on all nodes.Figure 3. isis backoff algorithm timing 150 ms as initial waiting time for the first SPF calculation, then if there is a trigger for another SPF, the router will wait 300 ms, then wait 600 ms if there is a following one, until the max-value of 1000 ms. the waiting timer will stay equal to 1 second for as much as there is no trigger of a new calculation.In case there is no trigger during 1 second, the wait time is reset to the initial value and start as described in the "Fig.3".

C. MAIN GAIN FROM THIS TUNING
Simulations indicate that the most important gain is due to the first waiting timer decreased from default value to 150ms.

VII. BGP-4 SCALABILITY ISSUES (PROBLEM STATEMENT)
The BGP-4 routing protocol has some scalability issues related to the design of Internal BGP (IBGP) and External BGP (EBGP) peering arrangements. EBGP advertises everything to everyone by default. IBGP does not advertise "3rd-party routes" to other IBGP peers, this is because there is no way to do loop detection with IBGP The RFC 4456 states that any BGP-4 router with EBGP peers must be fully meshed with all the other BGP-4 routers with EBGP peers in the same AS.This rule effectively means that every IBGP peers must be logically fully meshed.So you must have all BGP-speaking routers in your AS peer with each other.Below is a graphical example of a full-meshed 16-router .For more details see [15].There are resource constraints when you scale a network to many routers, globally, if we have: n BGP speakers within an AS, that requires to maintain: [n*(n-1)/2] BGP session per router.Another alternative in alleviating the need for a "fullmesh" is to use of "Route Reflectors" the "Fig.5" above .
They provide a method to reduce IBGP mesh by creating a concentration router to act as a focal point for IBGP sessions.The concentration router is called a Route Reflector Server.Routers called Route Reflector Clients have to peer with the RR Server to exchange routing information between themselves.The Route Reflector Server "reflects" the routes to its clients.
It is possible to arrange a hierarchical structure of these Servers and Clients and group them into what is known as clusters.Below is a diagram that illustrates this concept.

VIII. ROUTE-REFLECTORS IMPACT ON THE CONVERGENCE
If we estimate the typical total number of customer's vpn routes transported inside an operator backbone to be something like 800 000 routes, each Route reflector have to learn, process the BGP decision algorithm to choose best routes, readvertise best ones, while maintaining peering relationships with all its client routers, the route-reflector CPU and memory get certainly consumed, and as a consequence, slows down route propagation and global convergence time.

A. TEST METHODOLOGY
The methodology we use to track this issue is to preload the route reflector by using a simulator acting as client routers (or PE routers), and then, nearly simultaneously, we clear all sessions on the route-reflector, then start the simulated sessions.Then we monitor convergence by issuing 'sh ip bgp vpnv4 all sum' commands while recording every 5 seconds all watched parameters (memory and CPU utilization for various processes).When all queues are empty and table versions are synchronized, we consider the router has converged, (finished updating all its clients by all routes it knows).All these tests are performed several times to ensure they are reproducible.Results could slightly differ but accuracy is kept within ± 5%.
The goal is to find a tolerated convergence time for route reflectors, then we must limit the number of peering and number of routes per peering to respect the fixed threshold.

A. FEATURE DESCRIPTION
By default within a given iBGP mesh, route-reflectors will advertise all vpn routes they have to their clients (PE routers), then PE routers use Route Target (RT) extended communities to control the distribution of routes into their own VRFs (vpn routing and forwarding instances).
However PE routers need only hold routes marked with Route Targets pertaining to VRFs that have local CE attachments.
To achieve this, there must be an ability to propagate route target membership information between iBGP meshes and the most simple way is to use bgp update messages, so that Route Target membership NLRI is advertised in BGP UPDATE messages using the MP_REACH_NLRI and MP_UNREACH_NLRI attributes.The [AFI, SAFI] value pair used to identify this NLRI is (AFI=1, SAFI=132).www.ijacsa.thesai.orgAs soon as route-reflectors Receive Route Target membership information they can use it to restrict advertisement of VPN NLRI to peers that have advertised their respective Route Targets.

B. MAIN FINDINGS OF OUR STUDY
When we use Route-Target-constraints, The PEs receive considerably less routes.But, because in an operator backbone VRFs are spread everywhere geographically, they touch almost all route-reflectors, therefore:  Route-Target-constraints does not help reducing the number of routes handled by route reflectors.
The only gain is that, instead of each RR sending its entire table, it's going to prefilter it before it send it to each of its PEs, which means less data to send, and less data to send, means being able to send faster, provided that there is no cpu cost due to pre-filtering on the route-reflectors side.

A. BGP NEXT HOP TRACKING
By default within a given iBGP mesh, route-reflectors will advertise all vpn routes they have to their clients (PE routers), then PE routers use Route Target (RT) extended communities to control the distribution of routes into their own VRFs (vpn routing and forwarding instances).

XI. BGP PREFIX INDEPENDENT CONVERGENCE (PIC)
It provides the ability to converge BGP routes within subseconds instead of multiple seconds.The Forwarding Information Base (FIB) is updated independently of a prefix to converge multiple numbers of BGP routes with the occurrence of a single failure.This convergence is applicable to both core and edge failures and with or without MPLS.

A. SETUP DESCRIPTION
Let us consider the test setup in "Fig.6".The simulator is injecting M and N vpn routes respectively from PE2 and PE3, PE2 end PE3 advertise injected routes respectively to routereflector RR1 and RR2, PE1 imports the M and N VPN routes, each vpn prefixes uses as bgp next-hop either the IGP loopback of PE2 or PE3.The simulator attached to PE1 generates traffic toward those learned routes, we locate the best path chosen by PE1 in the it's forwarding table, then we cut the corresponding interface.Numbers M and N are increased progressively (by hundreds of thousands prefixes to make the impact more visible).
First phase: interface 0 fails down.It is detected and all FIB entries with this interface are deleted.
Second phase: IGP convergence occurs and new output interface is set to interface 1 for all VPN prefixes, hence a traffic disruption.Second Phase: IGP convergence occurs and as soon as the new path via if1 is deduced, loadinfo is updated.LoC = IGP convergence "only"

A. FEATURE DESCRIPTION
This feature describes such a mechanism that allows a router whose local link has failed to forward traffic to a precomputed alternate path.The alternate path stays used until the router installs the new primary next-hops based upon the changed network topology.
When a local link fails, a router currently must signal the event to its neighbors via the IGP, recompute a new primary next-hop for all affected prefixes, and only then install those new primary next-hops into the forwarding plane.Until the new primary next-hops are installed, traffic directed towards the affected prefixes is discarded.This process can take hundreds of milliseconds.The goal of IP Fast Reroute (IPFRR) is to reduce failure reaction time to 10s of milliseconds by using a pre-computed alternate next-hop in the event that the currently selected primary next-hop fails, so that, the alternate can be rapidly used when the failure is detected.A network with this feature experiences less traffic loss and less microlooping of packets than a network without IPFRR.There are cases where traffic loss is still a possibility since IPFRR coverage varies, but in the worst possible situation a network with IPFRR is equivalent with respect to traffic convergence to a network without IPFRR.[2].

B. CONFIGURING THE FEATURE
A loop-free path is one that does not forward traffic back through the router to reach a given destination.That is, a neighbor whose shortest path to the destination traverses the router is not used as a backup route to that destination.To determine loop-free alternate paths for IS-IS routes, a shortestpath-first (SPF) calculation is run on each one-hop neighbor.As a consequence the backup path through Rnet-A71 is precomputed and installed on the the forwarding table   We Chose isis metrics on the setup to make the Rnet-A72 the best IGP link, we shut this best link and observe the behavior of traffic curve as received on the Simulator connected to PE12 The Bleu curve is the forwarded traffic on the nominal link, the grey curve is the forwarded traffic on the backup link.The backup link have been mirrored to a free port and connected to the simulator to see the apparition and the disappearing of traffic on it.
As a comparison you can look at the traffic curve without the feature, it resembles to the diagram on the "Fig.12".You can notice the duration of "Next-hops" rewriting of vpn prefixes toward the backup link in the forwarding table.On the other hand, when we "de-shut" the best link, as in "Fig.13" we see that the traffic stays on the non-best link for more than 80 seconds, before going back to the best.

XIII. LDPORSVP
The ldp over rsvp principle can be illustrated like in the "Fig.14".Only core routers P1,P2 and P3 are enabling RSVP TE, ldp however they are configured to prefer rsvp tunnels to ldp one's.
The edge routers PE1 end PE2 are enabling only LDP with P1 and P3.PE1 end PE2 are VPN and use MP-iBGP to signal vpn labels.

A. CONTROL PLAN ESTABLISHMENT
Let us consider PE2_FEC representing prefixes coming from CE2.  3. Enable IGP shortcut on P1, the egress path for PE2_FEC will be the tunnel-1-3.
4. PE2_FEC triggers the establishment of LSP on PE2, and the label mapping message will be sent to P3, let us consider this label is L2.
5. After P3 receives the label mapping message, it forwards that message to P1 through the targeted LDP session, let us consider this label is Lx 6. P1 receives the label mapping message, and finds out that the egress fo the route is tunnel-1-3.Then the LSP from PE1 to PE2 is transmitted I RSVP TE.The external label is LR1.

B. FORWARDING PLANE PROCESS
The forwarding process of packets is as follows: We describe here the forwarding process of data from CE1 to CE2, if needed do the symmetrical reasoning regarding flows from CE2 to CE1: 1.After PE1 receives packets from CE1, it tags the BGP label Lb of private network and then it tags LDP label L1 of the provider network 2. (Lb,L1) label of PE1 is received on P1, replace L1 with Lx (the label sent to P1 through the targeted ldp session, and then tag tunnel label LR1 of RSVP TE, the label of packet becomes (Lb,Lx,Lr1).
3. From P2 to P3, with the RSVP TE transparently transmitting packets, the LR1 is replaced by LR2, that is, the packets received by P3 are tagged with the following labels (Lb,Lx,LR2) 4. Upon arriving P3, the LR2 is first stripped and then comes out Lx, and the label of LDP which is replaced by L2.The packet is then sent to PE2 and the label becomes (Lb,L2) 5.After the packet reaches PE2, L2 is first stripped and then the Lb.After that, the packet is sent to CE2

C. LSP PROTECTION , ONE TO ONE BACKUP METHOD
Each P creates a detour (tunnel) for each LSP, the detour will play the role of a protecting LSP : If the router P2 fails, P1 switches received traffic from PE1, along the detour tunnel [P1,P5] using the label received when P1 created the detour .
The detour is calculated based on the shortest IGP path from P1 to the router terminating the protected LSP, let us say: PE2.In this case the protecting LSP will avoid the failed router P2 (node protection).
At no point does the depth of the label stack increases as a consequence of taking the detour.While P1 is using the detour, traffic will take the path [PE1-P1-P5-P6-P7-PE2]

E. LAB SETUP AND TESTS SCOPE
Here are described the implementations made in our lab, the CSPF (constrained shortest path first) was simplified to only shortest igp:  Inter-P trafic will be encapsulated in a tunnel.
 No impact on all PE configuration, Only P routers are concerned by (LDPoRSVP).
 The tunnel is a TLDP session, between each P, so full mesh of: [n x P] routers.
 Each TLDP session is using an LSP which is dynamic.
 Signalling protocol for LSP is RSVP-TE , using cspf.
 CSPF is a modified version of SPF algo(Dijkstra) , used in ISIS.
 CSPF algorithme finds a path which satisfy constraints for the LSP (we simplify to only one constraint: the igp shortest path).
 Once a path is found by CSPF, RSVP uses the path to request the LSP establishment.

F. LAB TEST METHOD :
On each P router, we check that a (detour LSP is precalculated, presignaled for each LSP).We load heavily the P routers with: We generate traffic consisting of hundred thousands of packets in both directions, PE1 to PE3 see (Fig. 2), note that The grey curve represents recived packets, we notice a small traffic fall.In "Fig.18" the chosen igp metrics will force then nominal path to be :[PE1-P1-P3-P4-PE3] (the red path).We cut the link [P4-P3] : either by shuting the physical port or by removing the fiber from the port, we measure the convergence time through the number of lost packets related to the ratio: (sent /received) packets per second.
We check that, when the link [P4-P3] goes down, the P3 router, instead of waiting the igp convergence, instantly uses the precomputed backup link [P3-P1-P2-P4] (the green or detour path), then after the igp converges, the traffic goe, without impact, through the link [PE1-P1-P2-P4-PE3] (the blue path).www.ijacsa.thesai.org We check fast reroute performance at different load conditions: firstly we start with few LSPs then we increase the number progressively: (500, 1000, 2000 …)

G. TEST RESULTS:
We see that mainly: convergence time stays between 20 msec < t < 100 msec independently of number of LSPs.We notice some issues regarding scalability of LDP FECs.The "on purpose" studied case in the Fig. 4 shows that during the fast-reroute phase, traffic goes back to the sender before taking the good (remaining) path.This topology case would exist in a backbone design, so the sizing of the link must take into account the potential and transcient traffic load.

XIV. LDP FASTREROUTE
It's a mechanism that provides a local protection for an LDP FEC by pre-computing and downloading to the "forwarding plane hardware": both a primary and a backup NHLFE (Next Hop Label Forwarding Entry) for this FEC.
The primary NHLFE corresponds to the label of the FEC received from the primary next-hop as per standard LDP resolution of the FEC prefix in RTM (routing table manager).The backup NHLFE corresponds to the label received for the same FEC from a Loop-Free Alternate (LFA) next-hop.
 LFA next-hop pre-computation by IGP is described in [2].
 LDP FRR relies on using the label-FEC binding received from the LFA next-hop to forward traffic for a given prefix as soon as the primary next-hop is not available.
In case of failure, forwarding of LDP packets to a destination prefix/FEC is resumed without waiting for the routing convergence.
The RTM module (routing table manager) populates both primary and backup route and the "forwarding hardware" should populate both primary and backup NHLFE for the FEC.

A. ROUTES AND LFA COMPUTATION REMINDER
Assuming : a,b,c,d,e,f,g represent the igp metrics on each node link: The primary route will be via P1, assumed that:

a < (c + d) and (a + b) < (c + e + f)
The LFA route via P2 and P1 protects against failure of link PE1-P1:  Loop Free Criterion (computed by PE1): The cost for P2 to reach P4 via P1 must be lower than the cost via routes PE1 then P1, assumed that: d < (a + c )  Downstream Path Criterion (to avoid micro-loops): The cost of reaching P4 from P2 must be lower than the cost for reaching P4 from PE1, assumed that: d <a The LFA route via P2 and P3 protects against the failure of P1, node-protect condition for P2, assumed that: Attempt the computation of a node-protect LFA nexthop for a given prefix 2. If not possible, attempt the computation of a linkprotect LFA next-hop.3.If multiple LFA next-hops for a given primary nexthop are found, pick the node-protect in favor of the link-protect.4. If there is more than one LFA next-hop within the selected type, pick one based on the least cost. 5.If more than one have the same cost, the one with the least (outgoing interface: OIF) index is selected.Both the computed primary next-hop and LFA next-hop for a given prefix are programmed into the routing table management.

C. LDP FASTREOUTE: LAB SETUP AND TEST METHOD:
The work have being done on the setup of "Fig.22" and results are reported on tables: 2, 3.

D. LAB TEST METHOD:
Same as described before (2.6.1)except that, here we cut the inter P link [P1-P3], the backup path is [P1-P2-P4].we measure the convergence time through the number of lost packets related to the ratio: (sent /received) packets per second.

A. LDP FAST-REROUTE TEST RESULTS:
We see that mainly: the convergence time stays around 5 ms.This makes the LDP fast-reroute more attractif, however it doesn't offer a 100% topology coverage.lower backup coverage: depending on topologies may vary between: 65 to 85%, indeed, the source routing paradigm: LDP will always follows IP route, so if a candidate backup router has its best route through originating node, this candidate node cannot be chosen as backup.
While the conceptual restriction of LDP(/IP) FRR is efficient against loops, it doesn't allow a 100% coverage of all topologies, however we can reach a good compromise by a mixture of both, RSVP shortcuts will be deployed if and where LDP(/IP) FRR cannot offer coverage.

XVI. IGP MICRO-LOOPS
In standard IP networks, except when using source routing, each router takes its own routing decision (hop by hop routing).When the topology changes, during the convergence time, each router independently computes best route to each destination.

A. MICRO-LOOPS LOCALIZATION
The bandwidth consumption depends also on the packet size, consider 1 Gbps of traffic injected in the loop with a packet size of 500 bytes , it means that each second, 250k packets are injected in the loop. 4Gbps, injected in a loop with 3ms RTD in loop, TTL = 250, loop maximum rate is 1,5 Gbps, than max link BW usage of : 5,5 Gbps.

2) OVERLOAD IN ROUTERS CPU
If large amount of mpls traffic loops between two nodes A and B; at each hop, the ttl of mpls pkt decreases by 1.When the ttl of the mpls pkt expires, this pkt is dropped by the control plane hardware (the routing engine) and not by the forwarding plane hardware.
Depending the duration of the loop, the amount of mpls ttlexpiring packets arriving to the control plane, the CPU load may increase to 100%.
Mpls ttl expired packets come to the routing-engine mixed with other important packets: igp (ISIS or OSPF) , bfd, bgp ..etc and all routing control packets, (mpls and non mpls).As a consequence: bfd, the most sensitive one, may go down firstly, and carry along all level3 protocol depending on it.

3) CAUTION ON QOS MODELS
If some quality of service models are used, and some types of packets are prioritized, have this type of packets entering in a loop, and depending on the loop duration, the amount of prioritized traffic, they may consume all the bandwidth and force control (routing) packets to be dropped.That is why, it is a wise design to put the control packets on the top priority, even above voive or other sensitive applications.

4) MICROLOOPS PROPAGATION
A level 3 loop occurring between two points A and B, and as explained in paragraph 4.2.2, may trigger a convergence again, potentially other microloops can appear far on other routers, generating cpu load.The overall network will undergo a phenomena we can define as a "loop propagation".Obviously, the cpu load will stay 100% until micro loops disappear and convergence stabilize.

XVII. MICROLOOPS LAB SETUP AND TEST METHOD
Given the Figure 28, firstly we confirmed we can produce loops by configuring different isis convergence timers to facilitate loops appearance, then is a second stage, in order to have more control, we created manual loops between P1-P3 and P1-P2.
We used a simple way to create loops: given a vpnA on a PE1 connected to P1 and a vpnB on a PE2 connected to P2:

7) CPU-PROTECTION MECHANISMS
Depending on the router manufacturer, several CPU protection mechanisms may be implemented: Ability to put a port overall rate that measures the arrival of all control packets sent to the CPU for processing, giving the possibility to selectively discard out-of-profile-rates. Ability to create per protocol queues and guarantee selective high priority for important packets.A dedicated study would assess the efficiency of one or the other protection mechanism and proof their robustness by testing under worst conditions.

XVIII. CONCLUSION
In this paper we presented the most important features wich can contribute in convergence enhancement; it is not aimed at detailing all existing features We focused on methods that can be used to precompute backup paths on the forwarding plane, we presented features like: Prefix independent convergence and loop free alternate, test results and gains obtained in comparison to the situation with and without these features .
We presented a comparative study of RSVP-TE versus LDP (/IP) Fast reroute, it appears that: with RSVP-TE, the detour LSP is precalculated, presignaled for each LSP, the convergence time is around: 20 msec < t < 100 msec.However it has drawbacks like additional level of routing complexity, requiring That P-to-P trunks support rsvp and full mesh TLDP sessions, additional cpu load, due to rsvp messages.With LDP(/IP) FRR we have local decisions, hence no interop issues with other vendors, a simple configuration (just turn it on),a better scaling compared to full-mesh RSVP model and less overhead compared to RSVP soft-refresh states.However LDP (/IP) FRR has an important drawback: A lower backup coverage because of the source routing paradigm Finally, we analyzed micro-loops phenomenon, bandwidth and CPU consumption; we studied their birth mechanisms and propagation, and initiated a reflexion on means to mitigate them.
Overall, it is clear that the control of the convergence in its globality is not an easy task, but our measurements and simulations indicate that with good design and choice of tuning features, we are confident a sub-second to tens of milliseconds convergence time can be met.

Figure 2 .
Figure 2. ldp-igp synchronization chronogram T1 s(10 default )   www.ijacsa.thesai.orgIBGP and EBGP are the basically the same routing protocol just with different rules and applications.

a c e 1 Figure 6 .
Figure 6.Lab setup diagramB.FEATURE DESCRIPTION


interface: xe-0/2/0.0Weight: 0x4000 alternate path See "Fig.1" for lab setup C. TEST CONDITIONS From the lab setup described above, we announce 500000 routes, by 50k routes per vrf (vpn routing instances) from 10 different PE.The M1 receives the 50k routes in 10 different routing-instances, by 50K for each.From the Simulator (an Agilent chassis) connected to the M1 we generate traffic consisting of 500K packets sized to 64 bytes: This flow use as a source an ip address varying randomly within the interval [ 10.0.9x.1/32 to 10.0.9x.254/32] while x=1 for vrf 1, 2 for vrf 2 etc until N for vrf N.  This flow use as a destination an address varying sequentially within the interval [ x.0.0.1/32 to x.0.195.80/32] while x=1 for vrf 1, 2 for vrf 2 etc until N for vrf N.

Figure 11 .
Figure 11.curve of vpn traffic with LFA

Figure 12 .
Figure 12. curve of vpn traffic without LFA

1 .
Establish RSVP tunnel-1-3 from P1 to P3, the label distributed to P2 from P3 is LR2, and the label distributed from P2 to P1 is LR1 Shutdown of best link (bleu curve) , we see little negligible Impact on outgoing traffic from the MX www.ijacsa.thesai.org

Figure 14 .
Figure 14.LDP over RSVP principle 2. Establish a targeted ldp session between P1 and P3

7 .
P1 continues to send Label mapping message to PE1, the label is L1. 8. PE1 generates Ingress 9. MP-BGP sends private network route of CE2 from PE2 to PE1, the label of private network is Lb.At this stage the establishment of LSP between PE1 and PE2 is complete.This LSP traverses the RSVP TE area ( P1 ~~ P3).

Figure 15 .
Figure 15.LDP over RSVP backup method

Figure 17 .
Figure 17.LDPoRSVP Lab setup D. LDPORSVP LABEL STACK DURING FRR Nota: when deploying LDPoRSVP and enabling FRR (facility) as protection mechanism keep the 4 potential MPLS labels into account for MTU definition

Table 4 .
LDP-FRR Traffic measurement XV.RSVP-TE AND LDP-FRR COMPARAISON OUTCOMES RSVP-TE gains:  Fast convergence « P » (detour LSP is precalculated, presignaled for each LSP)  A convergence time around: 20 msec < t < 100 msec  RSVP-TE drawbacks:  additional level of routing complexity; requires P-P trunk support rsvp, TLDP sessions, additional cpu load (rsvp msg) LDP(/IP) FRR gains:  local decision, no interop issues with other vendors  very simple configuration (just turn it on)  better scaling compared to full-mesh RSVP model  less overhead compared to RSVP soft-refresh states LDP(/IP) FRR drawbacks:

Figure 24 .
Figure 24.Microloop birth Micro-loops can be triggered by any topology change that causes the network to converge like: link down, link up,metric change ..etc.
On PE1 vpnA have a static route to a destination [a.b.c.d/mask] with PE2 loopback as the next-hop. On PE2 vpnB have a static route to the same destination with PE1 loopback as the next-hop.PE1 and PE2 know loopback of each other through isis.Using a traffic simulator we inject 10Millions packets having the destination [a.b.c.d/mask], and to accelerate the effect on CPU we put the TTL of all packet to values randomly equal to 2 or 3.

Figure 28 .
Figure 28.Microloops lab setupA.MICROLOOPS AND TRAFFIC PROTECTION5) MICROLOOPS AND LFAAs explained, LFA computes an alternate nexthop that is used when a local failure appears, however the alternate nexthop may not be the converged backup nexthop.Given the case of "Fig.29":H is the LFA node  E is the converged nexthop, the backup calculated node after the link [A-B] broke down Figure 7. Forwarding table, rewriting of indexation toward interface 0Third phase: all VPN prefixes attached to the NH1 are rewritten in the FIB with the new interface if1.LoC = (IGP convergence) + (N * FIB Rewriting time)Let us now analyze the behavior (with PIC feature): An intermediate Next-hop (called loadinfo) is created, and the content of the forwarding table modified as described below: Figure9.Forwarding table, structure modified when using the feature First phase: if0 fails down.It is immediately erased but the loadinfo structure is not: www.ijacsa.thesai.org Figure 10.Forwarding table, deletion and rewriting concerns only one Nexthop

Table 2 .
Example of LFA precomputation