eff bw mgmt mpls full doc

8/3/2019 Eff BW Mgmt MPLS Full Doc

1/55

Efficient Distributed BandwidthManagement for MPLS Fast Reroute

Abstract:

Multiprotocol Label Switching, an IETF initiative that integrates Layer 2

information about network links (bandwidth, latency, utilization) into Layer 3 (IP) within

a particular autonomous system--or ISP--in order to simplify and improve IP-packet

exchange. MPLS gives network operators a great deal of flexibility to divert and route

traffic around link failures, congestion, and bottlenecks. From a QoS standpoint, ISPs

will better be able to manage different kinds of data streams based on priority and service

plan. For instance, those who subscribe to a premium service plan, or those who receive a

lot of streaming media or high-bandwidth content can see minimal latency and packet

loss. As service providers move more applications to their IP/MPLS (Multiple Protocol

Label Switching) backbone networks, rapid restoration upon failure becomes more and

more crucial. Recently MPLS fast reroute has attracted lots of attention as it was

designed to meet the needs of real-time applications, such as voice over IP. MPLS fast

reroute achieves rapid restoration by computing and signaling backup label switched path

(LSP) tunnels in advance and re-directing traffic as close to failure point as possible. To

provide a guarantee of bandwidth protection, extra bandwidth has to be reserved on

backup paths. Using path merging technique as described in IETF RFC 4090 only, the

network is able to share some bandwidth on common links among backup paths of the

same service LSP, i.e., so-called intra-sharing. But no solution is provided on how to

share bandwidth among backup paths of different service LSPs, i.e., so-called inter-

sharing. This technique provides an efficient distributed bandwidth management solution.


2/55

This solution allows bandwidth sharing among backup paths of the same and different

service LSPs, i.e., both intra-sharing and inter-sharing, with a guarantee of bandwidth

protection for any single node/link failure. Also an efficient algorithm for backup path

selection with the associated signaling extensions for additional information distribution

and collection is proposed.


3/55

INTRODU

CTION

INTRODUCTION

Both large and small Internet Service Providers (ISPs) constantly face the challenges of

adapting their networks to support rapid growth and customer demand for more reliable

and differentiated services. In the mid-1990s, the IP-over-ATM model provided many

ISPs a solution for delivering excellent performance and performing traffic engineering.

Moreover, many carriers found it cost-effective to multiplex Internet traffic as one of

many services carried over an ATM core.

Recently, the growth of Internet services and Wavelength Division Multiplexing (WDM)

technology at the fiber level has provided a viable alternative to ATM for multiplexing

multiple services over individual circuits. In addition, the once faster and higher


4/55

bandwidth ATM switches are being out-performed by Internet backbone routers. Equally

important, Multiprotocol Label Switching (MPLS) offers simpler mechanisms for packet-

oriented traffic engineering and multiservice functionality with the added benefit of

greater scalability. MPLS emerged from the IETFs effort to standardize a number of

proprietary multilayer switching solutions that were initially proposed in the mid-1990s.

As service providers move more applications to their IP/MPLS (Multiple Protocol Label

Switching) backbone networks, such as voice over IP and on-line games, et al., rapid

restoration upon failure becomes more and more crucial. Recently MPLS fast reroute has

attracted lots of attention as it enables the redirection of traffic onto backup LSP (label

switched path) tunnels rapidly in the event of a failure, which would be sufficient for

most of IP based application requirements. Internet Engineering Task Force (IETF) has

published RFC 4090 to address the necessary signaling extensions for supporting MPLS

fast reroute, and how to use path merging technique to share the bandwidth on common

links among backup paths of the same service LSP. However, no solution is provided on

how to share bandwidth among backup paths of different service LSPs so far. Recently

there has been a great deal of work addressing restoration functionality and schemes in

IP/MPLS networks as well as how to manage restoration bandwidth among network and

select optimized restoration paths. However, all of them deal with path-based end-to-end

LSP restoration and routing protocol fast re-convergence. The best related paper, which

deals with backup bandwidth sharing for local restoration. Since the backup LSPs are

pre-established, even though they do not consume bandwidth before failure happens, the

network has to reserve enough restoration bandwidth to guarantee the LSP restoration for


5/55

any failure. Without bandwidth sharing among backup LSPs for different service LSPs,

the network may need to reserve much more bandwidth on its links than necessary.

Here we propose an efficient distributed bandwidth management solution for MPLS fast

reroute for bandwidth sharing among backup paths of different service LSPs. Our scheme

is based on the observation that the restoration bandwidth can be shared by multiple

backup LSPs so long as their protected service LSP path segments are not susceptible to

simultaneous failure. This observation has been used by many researchers. But how to

apply this observation on MPLS fast reroute in a distributed fashion is not well

addressed.

In this paper, we also provide an efficient distributed backup path selection algorithm to

maximize the bandwidth sharing. Our proposals do not conflict, but enhance the IETF

MPLS fast reroute RFC 4090. The IETF RFC 4090 mainly focus on defining signaling

extensions to establish the backup paths while our proposals focus on restoration

bandwidth reservation and backup path selection. Our proposals require link usage

information to be distributed throughout the network. Some of the required information is

provided by current link state routing protocol extensions. Different from other research

work assuming routing protocol to distribute all required information, here we propose to

extend signaling protocol to disseminate and collect few key information among network

nodes.1 Our proposals minimize the overhead of distributing and collecting the additional

information.


6/55

TECHNICAL REQUIREMENT

Hardware and Software requirement Specification:

Tools / Platform:

Operating system Microsoft Windows 2000 Service

Pack 3 /Windows XP and Windows

Server 2003.

Hardware Requirements:

Computer : PC with a Pentium class processor.

Peripherals : Mouse or pointing device and

Memory : 256 MB RAM

Hard disk space : 80GB

Video : 800 x 600 resolution, 256 colors

(High color 16-bit recommended)

Printer : 80/136 Columns Dot Matrix

Software Requirements:

Front End Tool : Java

Back End Tool : Microsoft SQL-Server


7/55

LITERA

LITERATURE


8/55

LITERATURE SURVEY

Scalable MPLS fast reroute switchover with reduced complexity

The invention claimed is:

1. In a router, a method for handling a failure, said method comprising: detecting

said failure; in response to said failure modifying forwarding data structure entries

storing information pertaining to a first output adjacency affected by said failure;

and thereafter based on said modification, forwarding protected traffic previously

handled by said first output adjacency via a backup tunnel employing a second

output adjacency; and wherein a time required for said modification is

independent of a number of protected tunnels employing said first output

adjacency and independent of a number of protected forwarding equivalence

classes employing said first output adjacency; wherein said router employs a

distributed forwarding architecture wherein forwarding processing is divided

between an ingress linecard and an egress linecard and modifying forwarding data

structure entries further comprises: on each linecard of said router, modifying a

forwarding data structure entry that previously specified said first output

adjacency to now specify said second output adjacency and a linecard hosting said

second output adjacency.

2. The method of claim 1 wherein said modifying forwarding data structure entries


9/55

comprises: modifying a table entry specific to said first adjacency to indicate a failed

status.

3. The method of claim 1 wherein said first output adjacency and said second output

adjacency are hosted on a single linecard.

4. The method of claim 1 wherein said first output adjacency and said second output

adjacency are hosted on different linecards.

5. In a router, a method for handling a failure, said method comprising: detecting said

failure; in response to said failure modifying forwarding data structure entries storing

information pertaining to a first output adjacency affected by said failure; and

thereafter based on said modification, forwarding protected traffic previously handled

by said first output adjacency via a backup tunnel employing a second output

adjacency; and wherein a time required for said modification is independent of a

number of protected tunnels employing said first output adjacency and independent of

a number of protected forwarding equivalence classes employing said first output

adjacency and wherein a first output interface hosts only said first output adjacency

and no other adjacencies and a second output interface hosts only said second output

adjacency and no other adjacencies.

6. For use with a router, a computer program product for handling a failure, said


10/55

computer program product comprising: code that causes detection of said failure;

code that, in response to said failure, causes modification of forwarding data structure

entries storing information pertaining to a first output adjacency affected by said

failure; code that, based on said modification, causes forwarding of protected traffic

previously handled by said first output adjacency via a backup tunnel employing a

second output adjacency; and a computer-readable storage medium that stores the

codes; and wherein a time required for said modification is independent of a number

of protected tunnels employing said first output adjacency and independent of a

number of protected forwarding equivalence classes employing said first output

adjacency; wherein said router employs a distributed forwarding architecture wherein

forwarding processing is divided between an ingress linecard and an egress linecard

and said code that causes forwarding data structure entries further comprises: code on

each linecard of said router that causes modification of a forwarding data structure

entry that previously specified said first output adjacency to now specify said second

output adjacency and a linecard hosting said second output adjacency.

7. The computer program product of claim 6 wherein said code that causes

modification of forwarding data structure entries comprises: code that causes

modification of a table entry specific to said first adjacency to indicate a failed status.

8. The computer program product of claim 6 wherein said first output adjacency and

said second output adjacency are hosted on a single linecard.


11/55

9. The computer program product of claim 6 wherein said first output adjacency and

said second output adjacency are hosted on different linecards.

10. For use with a router, a computer program product for handling a failure, said

computer program product comprising: code that causes detection of said failure;

code that, in response to said failure, causes modification of forwarding data structure

entries storing information pertaining to a first output adjacency affected by said

failure; code that, based on said modification, causes forwarding of protected traffic

previously handled by said first output adjacency via a backup tunnel employing a

second output adjacency; and a computer-readable storage medium that stores the

codes; and wherein a time required for said modification is independent of a number

of protected tunnels employing said first output adjacency and independent of a

number of protected forwarding equivalence classes employing said first output

adjacency and wherein a first output interface hosts only said first output adjacency

and no other adjacencies and a second output interface hosts only said second output

adjacency and no other adjacencies.

11. A network device incorporating capability for handling a failure, said network

device comprising: a processor system; a memory system storing instructions to be

executed by said processor system, said instructions comprising: code that causes

detection of said failure; code that, in response to said failure, causes modification of

forwarding data structure entries storing information pertaining to a first output

adjacency affected by said failure; and code that, based on said modification, causes


12/55


13/55

device comprising: a processor system; a memory system storing instructions to be

executed by said processor system, said instructions comprising: code that causes

detection of said failure; code that, in response to said failure, causes modification of

forwarding data structure entries storing information pertaining to a first output

adjacency affected by said failure; and code that, based on said modification, causes

forwarding of protected traffic previously handled by said first output adjacency via a

backup tunnel employing a second output adjacency; and wherein a time required for

said modification is independent of a number of protected tunnels employing said

first output adjacency and independent of a number of protected forwarding

equivalence classes employing said first output adjacency and wherein a first output

interface hosts only said first output adjacency and no other adjacencies and a second

output interface hosts only said second output adjacency and no other adjacencies.


14/55


15/55

SYSTEM

DESIGN


16/55

Existing systems:

As service providers move more applications to their IP/MPLS (Multiple Protocol

Label Switching) backbone networks, such as voice over IP and on-line games, rapid

restoration upon failure becomes more and more crucial. Recently MPLS fast reroute has

attracted lots of attention as it enables the redirection of traffic onto backup LSP (label

switched path) tunnels rapidly in the event of a failure, which would be sufficient for

most of IP based application requirements. Internet Engineering Task Force (IETF) has

published RFC 4090 to address the necessary signaling extensions for supporting MPLS

fast reroute, and how to use path merging technique to share the bandwidth on common

links among backup paths of the same service LSP.

Problem Description:

1. No solution is provided on how to share bandwidth among backup paths of

different service LSPs so far.

2. Existing techniques deal with path-based end-to-end LSP restoration and

routing protocol fast re-convergence.

3. Since the backup LSPs are pre-established, even though they do not consume

bandwidth before failure happens, the network has to reserve enough restoration

bandwidth to guarantee the LSP restoration for any failure. Without bandwidth

sharing among backup LSPs for different service LSPs, the network may need

to reserve much more bandwidth on its links than necessary.


17/55

Proposed System:

This technique proposes an efficient distributed bandwidth management solution

for MPLS fast reroute for bandwidth sharing among backup paths of different service

LSPs. This scheme is based on the observation that the restoration bandwidth can be

shared by multiple backup LSPs so long as their protected service LSP path segments are

not susceptible to simultaneous failure. This observation has been used by many

researchers. But how to apply this observation on MPLS fast reroute in a distributed

fashion is not well addressed. In this proposal, an efficient distributed backup path

selection algorithm to maximize the bandwidth sharing is provided. This proposal

requires link usage information to be distributed throughout the network. Some of the

required information is provided by current link state routing protocol extensions.

Advantages:

Minimizes the overhead of distributing and collecting additional informations

Able to reduce the amount of reserved restoration bandwidth dramatically

Significant cost savings to network providers


18/55

Modules:

1. Setting up a Local Area Network

2. Implementation of Multi Protocol Label Switching (Existing System)

3. Implementation of RSVP Extension

a. Label switching path Creation

b. Creation of Logical Segments

c. Detection of Failure nodes

d. Identification of Reroute

4. Performance Evaluation


19/55

Resources Required:

Hardware details

PROCESSOR : Intel Pentium-IV (3.00 GHz)

MEMORY : 128 MB

HARD DISK : 40 GB

MONITOR : EGA/VGA

MOUSE : LOGITECH MOUSE

KEYBOARD : LOGITECH KEYBOARD

Software details

OPERATING SYSTEM : MICROSOFT WINDOWS 2000

LANGUAGE : JAVA

DATABASE : SQL SERVER 2000.


20/55

MODULE

DESCRIPTION


21/55

Modules:










22/55

Modules Description:


A Model network topology as shown in the figure is created. Here we go

for the JAVA programming tool with MS-SQL 2000 Server as backend

considering each PC as a client and one as the server as the other clients start

joining the network.

(Fig. Sample Topology)


The existing Multi Protocol Label Switching without creating the LSP before any

of the faults could occur is implemented. Here it takes increased Packet delay and packet

loss occurs due to multiple node/link failure. Further it increases the path length due to

multiple node/link failure.


23/55


The existing Multi Protocol Label Switching-RSVP technique is extended here

and the LSP is created before any of the faults could occur. This implementation involves

the following sections:


Here we pre-determine the backup path during the LSP creation as well,

which is the extension of RSVP protocol. Instead of creating the LSP after a fault

the best possible alternate path is found and the same is pre stored for each

segment in the ILSR node. This prediction reduces the overhead burden on

individual nodes during Faults and there by reduces packet loss.


The LSP just created is divided into multiple segments. Each segment is

divided such that it has almost 2 nodes and 2 links. Then the alternate backup path

across the segments is predetermined.


24/55


During faults, the first failure detection node identifies the failure across

the segment. Here we go for the extension of OSPF.


In this module we find the efficient shortest backup path based on number

of failure nodes/links. Based on the informations/no. of faults/fault location, the

packets are then rerouted through the efficient backup path.


Finally we evaluate the performance of this RSVP /OSPF extension technique with

predicted and un-predicted faults.


25/55

FEASIBILITY


26/55

FEASIBILITY

FEASIBILIY STUDY

A feasibility study is concerned to select the best system that meets performance

requirements. These entities are an identification description, an evaluation of candidate

systems and the selection of the best system for the job.

Economic feasibility

Technical feasibility

Behavioural feasibility

Economic feasibility

Economic analysis is the most frequently used method for evaluating the

effectiveness of the candidate system. More commonly known as cost/benefit analysis,

the procedure is to determine the benefits and savings that benefits outweigh costs, and

then the decision is made to design and implement the system. Otherwise, further

justification or alterations in the proposed system will have to be made if it is to have an

enhancement to approve.


27/55

Technical feasibility

Technical analysis centre on the existing computer system (Hardware,

Software etc) and to what extend it can support the proposed addition. This involves

financial considerations to accommodate technical enhancement. If the budget is a

serious constraint, then the project is judged not feasible.

Behavioural Feasibility

An estimate should me made of how strong a reaction the user staff is

likely to have toward the development of a computerized system. It is common

Knowledge the computer installations have something to do understandable that the

introduction of a candidate system requires special effort to educate, sell and train the

Staff on new ways of considering business.


28/55

DESIGN AND

DEVELOPMENT


29/55

5. DESIGN AND DEVELOPMENT

The design phase is a multi step process which focuses on system creation with

the help of user specifications and informations gathered in the above phases. It is the

phase where the system requirements are translated to operational details.

5.1 SYSTEM DESIGN

System Design is the process of making the newly designed system fully operational and

consistent in performance. The following steps has been followed in the implementation

of the system.

Implementation in planning

User Training

As the part of implementation, the system is taken the site and

Loaded on to clients computer. Some of the users level, exposure to computer etc.these

users is trained first and they run the system for a month. A detailed documentation is

prepared for the employees and they trained to access the software. These users are

trained first and they can run the system for a month.

After installation of software, the hardware specifications are checked. If

hardware specifications are satisfactory, then the software is loaded for pilot run. User

training starts at this time itself. Users will be given a user manual, which documents how

to use the system and all the exception handling procedures.


30/55

5.1.1 INPUT DESIGN

Input design is the part of overall system design which requires very careful

attention. Often the collection of input data is the most expensive part of the system, in

terms of both the equipment used and the number of people involved; it is the point of

most contact for the users with the computer system; and it is prone to error. If data going

into the system are incorrect, then the processing and output will magnify these error.

In this system inputs are given in two ways, the Existing users can directly enter into

the system using login form, and new users have to register all their details in the

registration form provided.

>>

Input design is the very important part in the project and should be concentrated well as it

is prone to error. The data that are to be inserted are to be inserted with care as this plays

a very important role. In order to get the meaningful output and to achieve good accuracy

the input should be acceptable and understandable by the user.


31/55

5.1.2 OUTPUT DESIGN

Output design plays a very important role in a system. Getting a correct output is a task

that has to be concentrated, as a system is validated as a correct one only if it gives the

correct output according to the input.

>>>>

Here in this project in all the three days of inductions if the employee has completed all

his/her input, then the output shows the status as completed or his status will be pending.


32/55

SOFTWARE SPECIFICATION

Java

Java is related to C++, which is a direct descendant of C. The trouble with C and

C++ is that they are designed to be compiled for a specific target. But Java is a portable,

platform-independent language that could be used to produce code that would run on a

variety of CPUs under differing environments. Java can be used to create two types of

programs: applications and applets. An application is a program that runs on our

computer, under the operating system of that computer. An applet is an application

designed to be transmitted over the Internet and executed by a Java-compatible Web

browser. Java is Simple, Secure, Portable, Object-oriented, Robust, Multithreaded,

Architectural-neutral, Interpreted, High Performance, Distributed, and Dynamic.

Simple

Java was designed to be easy for the professional programmer to learn and use

effectively.

Security:

When a java comparable web=server is used, the user can download applets

without fear of virus infection. Java archives this protection by confining a java program

to the java execution environment and not allowing it access to other parts of the

computer.


33/55


34/55

Multithreaded

Java was designed to meet the real-world requirements of creating interactive,

networked programs. To accomplish this, java supports multithreaded programming,

which allows the user to write programs that do work simultaneously.

Architecture-neutral

A central issue for java designers was that of code longevity and portability. One

of the main problems facing programmers that no guarantee exists that if you write a

program today, it will run tomorrow ,even in the same machine, operating system

upgrades, processor upgrades, changes in core system resources can all combine to make

program malfunction. But in java the goal was write once, run anywhere, any time,

forever.

Interpreted and high performance

Java enables cross-platform program by compiling into a intermediate

representation. The code can be interpreted on any system that provides java virtual

machine. Cross-platform solution has done at the expense of performance. Java,

however, was designed to perform well on very low-power CPUs. Java runtime

machine that provides this feature lose none of the benefits of platform-independent code.

High performance cross-platform is no longer an oxymoron.


35/55

Distributed

Java is designed for distributed environment of the internet, because it handles

TCP/IP protocols. The original version of java(Oak) include features for intra-address-

space messaging. This allows objects on two computers to execute procedures remotely.

Java has revived these interfaces in a package called remote method invocation (RMI).

Dynamic

Java programs carry with them substantial amounts of run-time type information

that is used to verify and resolve accesses to objects at runtime. This makes it possible to

dynamically link code in a safe and expedient manner.


36/55

DIAGRAMS:-

System Flow Diagram:

initialize

Setting up of LAN

M P L S creation

RSVP Extension

PERFORMANCE

ANALYSIS


37/55

Data Flow Diagram:

INITIALISATION

LSP creationINCOMMING n/w

TRAFFIC

Link

failureFast rerouteEarly fault

detection

Bandwidth sharing

GUARANTEED QOS

segmentation


38/55

SYSTEM

IMPLEMTATION


39/55

SYSTEM IMPLEMENTATION

System implementation is the important stage of project when the theoretical

design is tuned into practical system. The main stages in the implementation are as

follows:

Planning

Training

System testing and

Changeover Planning

Planning is the first task in the system implementation. Planning means deciding

on the method and the time scale to be adopted. At the time of implementation of any

system people from different departments and system analysis involve. They are

confirmed to practical problem of controlling various activities of people outside their

own data processing departments. The line managers controlled through an

implementation coordinating committee. The committee considers ideas, problems and

complaints of user department, it must also consider:

The implication of system environment;

Self selection and allocation for implementation tasks;

Consultation with unions and resources available;

Standby facilities and channels of communication


40/55

TRAINING

To achieve the objectives and benefits from computer based system, it is essential

for the people who will be involved to be confident of their role in new system. This

involves them in understanding overall system and its effect on the organization and in

being able to carry out effectively their specified task. So training must take place at an

early stage. Training sessions must give user staff, the skills required in their new jobs.

The attendance to sort out any queries.


41/55

TEST PLAN

UNIT TESTING

A program represents the logical elements of a system. For a program to run

satisfactorily, it must compile and test data correctly and tie in properly with other

programs. Achieving an error free program is the responsibility of the programmer.

Program testing checks for two types of errors: syntax and logical. Syntax error is

a program statement that violates one or more rules of the language in which it is

written. An improperly defined field dimension or omitted keywords are common

syntax errors. These errors are shown through error message generated by the computer.

For Logic errors the programmer must examine the output carefully.

When a program is tested, the actual output is compared with the expected

output. When there is a discrepancy the sequence of instructions must be traced to

determine the problem. The process is facilitated by breaking the program into

self-contained portions, each of which can be checked at certain key points .The

idea is to compare program values against desk-calculated values to isolate the

problems.


42/55

FUNCTIONAL TESTING

Functional testing of an application is used to prove the application delivers correct

results, using enough inputs to give an adequate level of confidence that will work

correctly for all sets of inputs. The functional testing will need to prove that the

application works for each client type and that personalization function work correctly.

Test case no Description Expected result

1 Test for all peers All peers should work

without errors.

2 Test for various peer in a distributed

network framework as it display all

users available in the group

The result after execution

should give the accurate

result.


43/55

NON-FUNCTIONAL TESTING

This testing used to check that an application will work in the operational environment.

Non-functional testing includes:

Load testing

Performance testing

Usability testing

Reliability testing

Security testing


44/55


45/55

RELIABILITY TESTING


1 This is to check that the server is rugged

and reliable and can handle the failure of

any of the components involved in

provide the application.

In case of failure of the

server an alternate server

should take over the job

SECURITY TESTING

It is necessary to check that the applications data is secured.

Test

case no

Description Expected result

1

2

Checking that the user identification is

authenticated

Check whether all the modules are

secured with integration

In case failure it should not be

connected in the framework

The integration is successful

WHITE BOX TESTING


46/55

White box testing, sometimes called glass-box testing is

a test case design method that uses the control structure of the procedural design to

derive test cases.

Using white box testing method, the software engineer can derive test cases.


1 Exercise all logical decisions on their

true and false sides

All the logical decisions

must be valid

2 Execute all loops at their boundaries and

within their operational bounds.

All the loops must be finite

3 Exercise internal data structures to

ensure their validity.

All the data structures must

be valid

BLACK BOX TESTING

Black box testing, also called behavioral testing,

focuses on the functional requirements of the software. That is, black testing enables

the software engineer to derive sets of input conditions that will fully exercise all

functional requirements for a program. Black box testing is not alternative to white box

techniques. Rather it is a complementary approach that is likely to uncover a

different class of errors than white box methods. Black box testing attempts to find

errors in the following categories.

Test Description Expected result


47/55

case no

1 To check for incorrect or missing

functions

All the functions must be valid

2 To check for interface errors All the interface must function normally

3 To check for errors in a data

structures or external data base

access.

The database updation and retrieval must

be done

4 To check for initialization and

termination errors.

All the functions and data structures must

be initialized properly and terminated

normally


48/55

CONCLUSI

ON

CONCLUSION


49/55

With this project we analyzed the problem of distributed bandwidth management and

backup path selection for protected LSPs in MPLS fast reroute using one-to-one backup

method. In particular, we proposed a new bandwidth management mechanism with

implementation procedures. We further proposed using three simple signaling messages

between neighbor nodes to distribute and collect extra information required by our

proposed optimal backup path selection algorithm. We demonstrate that with limited

signaling overhead, we can use network capacity much more efficiently for MPLS fast

reroute. The proposed new methods keep accurate information about the amount of

capacity that must be reserved on each link in the network to restore any single link/node

failure. Our proposed approaches are based on efficient distributed routing and signaling

protocols, and do not rely on centralized approaches. We conclude that the savings in

restoration bandwidth from backup path sharing is significant, and that considerable

savings could be obtained by extending the MPLS fast reroute signaling protocol to

support our proposals.

FUTURE ENHANCEMENTS

Several enhancements are possible to the configuration, provisioning, and

management of MPLS networks. One such we propose is to create cookie-cutter

templates for some standard configurations for some simple deployments. For example,

VPN configurations can be simplified if the requirement is always full-mesh connectivity

between sites. Many vendors, including Cisco, also offer several management

applications that can help manage MPLS services, including some complex computations


50/55

that can help place TE LSPs explicitly and provide bandwidth guarantees in failure

conditions.

Adaptive Self-Healing Networks

Failure detection is extremely important to make re-routing decisions and reconverge on

a topology. With MPLS embedded management capabilities, both control and data plane

liveliness can be monitored. The liveliness data can be combined with some intelligence

in software to make the following:

Fast reroute decisions

Automatic invocation of a trace to find the location of fault

Isolation of that fault by re-routing around that failure, using FRR or other

mechanisms

This creates a powerful network paradigm that heals itself when it detects failures. A

liveliness check of the LSPs and TE tunnels helps distinguish control plane from data

plane failures. An automatic invocation of traces helps find the fault location in the

network and, by changing routing metrics and re-routing of traffic, this can be achieved

around the failure within a short timethereby creating the powerful notion of a self-

healing network.


51/55

BIBLIOGRP

AHY


52/55

[1.] D. Awduche et al., RSVP-TE: Extensions to RSVP for LSP Tunnels

RFC3209, Dec. 2001.

[2.] J. Ash et al., LSP Modification Using CR-LDP RFC 3214, Jan. 2002.

[3.] G. Li et al., Detail study of IP/reconfiguable optical network

architectures, in OFC 2004.

[4.] Callon, R., A. Viswanathan, and E. Rosen, Multiprotocol Label

Switching Architecture, draft-ietf-mpls-arch-02.txt, July 1998.

[5.] Davie, B., Y. Rekhter, A. Viswanathan, S. Blake, V. Srinivasan, and

E. Rosen, Use of Label Switching With RSVP, draft-ietf-mpls-rsvp-00.txt,

March 1998.

[6.] Davie, B., T. Li, Y. Rekhter, and E. Rosen, Explicit Route Support in

MPLS, draft-davie-mpls-explicit-routes-00.txt, November 1997.

[7.] Doolan, P., B. Davie, D. Katz, Y. Rekhter, and E. Rosen, Tag

Distribution Protocol, draft-doolan-tdp-spec-01.txt, May 1997.

[8.] Feldman N., and A. Viswanathan, ARIS Specification, draft-

feldman-aris-spec-00.txt, March 1997.


53/55

[9.] Viswanathan, A., N. Feldman, R. Boivie, and R. Woundy, ARIS:

Aggregate Route-Based IP Switching, draft-viswanathan-aris-overview-

00.txt, March 1997.

[10.] P. Ho, J. Tapolcai, and H. Moufth, On achieving optimal survivable

routing for shared protection in survivable next-generation internet, IEEE

Trans. Reliability, vol. 53, no. 2, pp. 216225, Jun. 2004.

[11.] P. Ho, J. Tapolcai, and Cinkler, Segment shared protection in mesh

communications networks with bandwidth guaranteed tunnels, IEEE

Trans. Networking, vol. 12, no. 6, Dec. 2004.

[12.] S. Han and G. Shin, Fast restoration of real-time communication

service from component failure in multi-hop networks, in ACM

SIGCOMM , 1997

[13.] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. Zappala,

RSVP: A New Resource ReSerVation Protocol., IEEE Network,

September 1993.


54/55

[14.] Zhang, L., Braden, R., Estrin, D., Herzog, S., and S. Jamin, Resource

ReSerVation Protocol -- Version 1 Functional Specification. IETF Work

in Progress, July 1995.

[15.] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and S. Jamin,

Resource ReSerVation Protocol -- Version 1 Functional Specification.

IETF Work in Progress, May 1997.

[16.] Zappala, D., RSVP LOOP Prevention for Wildcard Reservations. ISI

internal document, February 1996. Available from

ftp://ftp.isi.edu/rsvp/docs/WF.scope.ps.

[17.] Downey, Tom, Cisco Systems, Inc., MPLS for Network Service

Providers, Multilayer Switching Symposium, November 6, 1998.

[18.] Halpern, Joel, Newbridge Networks, Technologies for Advanced

Internet Services, Conference Tutorial, November 2, 1998.

[19.] Heinanen, Juha, Telia Finland, Inc., MPLSATM Like

Functionality for Router Backbones, Multilayer Switching Symposium,

November 6, 1998.
ftp://ftp.isi.edu/rsvp/docs/WF.scope.psftp://ftp.isi.edu/rsvp/docs/WF.scope.ps


55/55

[20.] McQuillan, John, McQuillan Consulting, Major Trends in

Broadband Networking, Conference Introduction, November 3, 1998.

[21.] Metz, Chris, Cisco Systems, Inc., A Survey of Advanced Internet

Protocols, Conference Tutorial, November 2, 1998.

[22.] Metz, Chris, Cisco Systems, Inc., IP Switching in the Enterprise,

Multilayer Switching Symposium, November 6, 1998.

eff bw mgmt mpls full doc

Documents