DETOUR PATH RESOURCE MANAGEMENT METHODS FOR IP

SERVICE OPERATION

Yu Miyoshi, Tatsuyuki Kimura

NTT Corporation, NTT Network Service Systems Laboratories

9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan

Keywords:

Detour path, resource management, SP calculation, QoS-guaranteed video streaming service.

Abstract:

In the conventional IP network, equipment has been managed by periodical SNMP polling and periodical

ping by a network management system (NMS), and traps have been used when abnormalities occur. But it

is difﬁcult to operate a service related to network state changes by such a management method because IP

network services are best-effort services, so they may be affected by other multiplexed trafﬁc. In order to

solve such problems, we propose a detour path resource management method for IP networks. We discuss

its advantages and how to overcome problems and verify that IP network resource management that includes

detour path management is sufﬁcient for practical use.

1 INTRODUCTION

To offer QoS-guaranteed video streaming services in

an IP network, it is effective to use a Bandwidth Bro-

ker (Masuda et al., 2002) that controls a user’s ac-

cess according to the network resource situation. The

Bandwidth Broker speciﬁes the network topology and

service paths by using a network Resource Manage-

ment Server (RMS) that can comprehend the band-

width of the network. But, this is not sufﬁcient. A

service cannot be called a QoS-guaranteed service un-

less the service trafﬁc paths that bypass the failure

point are immediately speciﬁed after abnormalities.

The RMS needs to specify detour paths at the time

of failure and inform the Bandwidth Broker which re-

sources need to be managed.

In an IP network, there are various real-time path

management approaches based on a server such as an

RMS. However, there are discrepancies between the

service path information stored by the server and the

real network situation, whichever method is used, be-

cause of the processing delay of the RMS required for

refreshing path information and re-calculating short-

est paths (SPs).

On the other hand, an RMS can specify service

paths using weight (cost) information of OSPF (Moy,

1998) or IS-IS (Callon, 1990). And the Bandwidth

Broker can store detour path resource information that

the RMS speciﬁed. In this method, the Bandwidth

Broker can reallocate management resources to de-

tour paths at the moment of failure detection. How-

ever, it is not realistic to store all (detour and shortest)

path information in a database, because obtaining all

detour paths makes the number of assumed fault pat-

terns huge depending on the network scale. So, we

propose a “Look-ahead type” detour path speciﬁca-

tion method.

We succeeded in reducing the number of calcula-

tions required for detour paths by using an RMS that

implements the “Look-ahead type” detour path speci-

ﬁcation method. First, this paper describes the Band-

width Broker type QoS-guaranteed service which is

the target. Next, we describe related work, espe-

cially topology management approaches that have

been proposed. Then, we explain our “Look-ahead

type” detour path speciﬁcation method. In section V,

we evaluate the usefulness and implementability of

our method by testing an RMS that implemented our

method. Conclusions are drawn in section VI.

2 QOS-GUARANTEED SERVICE

In this section, we describe Bandwidth Broker type

QoS-guaranteed services using an RMS. One of the

biggest causes of poor video streaming quality is con-

gestion caused by multiplexing. If packet loss occurs

because of the congestion, the time sequence of the

287

Miyoshi Y. and Kimura T. (2004).

DETOUR PATH RESOURCE MANAGEMENT METHODS FOR IP SERVICE OPERATION.

In Proceedings of the First International Conference on E-Business and Telecommunication Networks, pages 287-292

DOI: 10.5220/0001390102870292

 SciTePress

video information will be spoiled and the pictures will

deteriorate. In video streaming, the user is looking at

the screen for a long time. That is, video streaming is

a service in which quality deteriorates in a conspicu-

ous manner. Moreover, the system must react to the

user’s demand in real time. So we have been investi-

gating how to achieve QoS-guaranteed video stream-

ing services using the Bandwidth Broker model (Ma-

suda et al., 2002) (Zhang et al., 2000).

For example, we have proposed a service whose

quality is guaranteed for live distribution and video

meetings where the time of use is ﬁxed beforehand

(Figure 1).

Figure 1: Quality reservation service.

First, the user tells the RMS when the service is re-

quired. The system checks free resources of the short-

est path at that time, and reserves quality. As a result,

the service can guarantee the quality of a target time

slot by performing priority control at the appropriate

time. Since the service can acquire time information

from the user beforehand, a Bandwidth Broker can

judge in advance in which time slot the service opera-

tor should guarantee the quality of which service. For

a user, if reservation is approved, a guarantee of qual-

ity can be received certainly, and if it is not given, it

may be possible to re-schedule in advance.

In contrast, if a distribution demand comes imme-

diately from a user like a video on demand (VoD) ser-

vice, the type of reservation described above is not

applicable (Figure 2).

For such a service, it is effective to provide a guar-

antee of quality based on an understanding of the con-

sumption of each resource in real time and access con-

trol judgment according to the network resource situ-

ation.

In these services, a RMS needs to process a user’s

access in real time. Therefore, the burden on a sys-

tem is large and resource calculation cannot be done

before the deadline in a large-scale network. For load

balance, it will be necessary for the RMS which pre-

pares path and resource information to be separated

Figure 2: Real-time access control service.

from a Bandwidth Broker which receives a user’s ac-

cess. Even in a conventional IP network, a Bandwidth

Broker can provide video contents to a user with qual-

ity ensured by comprehending the resource situation

and controlling access to content.

Next, we describe the network resource informa-

tion of the RMS required for access control by a

Bandwidth Broker. What network resources should

be managed in order to ensure such service quality?

On an IP network, the typical resources that a service

consumes are related to the switching performance of

a node (a router or switch) and the bandwidth (inter-

face speed) of a network link. If a network is designed

in advance by operator as its switching performance

is greater than bandwidth, then our RMS should pro-

vide bandwidth capacities as the network resources

with service path information to a Bandwidth Bro-

ker. However, what is necessary is not just to treat

wire speed (the IF speed that enables MIB-II to ac-

quire data by SNMP) as a resource in that the service

quality is managed. It is necessary to take into con-

sideration the quantity of control protocol trafﬁc and

the burstiness of service trafﬁc.

Next, we describe methods for selecting service

paths. To manage bandwidth capacities of service

paths, the RMS has to specify each link from edge

routers that connect to the server to the edge routers

that connect to user nodes. If the service is an inter-

active one such as a videophone, then the RMS has

to specify the path from an edge router connected to

a caller to an edge router connected to the destination

user. For this reason, an RMS speciﬁes the paths be-

tween any two points. In particular, it gets the weight

(cost information used by OSPF or IS-IS) and IP ad-

dresses by SNMP. Next, the RMS determines the re-

lationships between NEs using IP addresses and sub-

net masks. As a result, the network topology can be

discovered. After the network topology has been dis-

covered, the RMS speciﬁes all service paths between

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

288

any two points. The paths have minimum weights of

OSPF between each pair of points (shortest paths).

In addition, a Dijkstra algorithm (Dijkstra, 1959) is

used as the shortest path selection algorithm as well

as OSPF.

3 RELATED WORK

Various methods have been proposed to discover the

topology and specify service paths in order to manage

network resources.

(Siamwalla et al., 1998) proposed a network topol-

ogy discovery method that does not use SNMP but

uses traceroute and ping. However, this method did

not describe shortest path speciﬁcation methods used

by OSPF.

((Shaikh et al., 2002) and (Shaikh and Greenberg,

2004)) proposed a method that uses an OSPF message

such as LSA. If an RMS uses this method, a Band-

width Broker can specify every shortest path of OSPF

in real time. However, in this method, we need special

servers that implement an LSA speaker method and a

robust security framework. And this method needs

to connect with each OSPF area. For our Bandwidth

Broker type QoS-guaranteed service, these costs are

large. Furthermore, in their method, a discrepancy

between the service path of a real network and the re-

sources stored by a Bandwidth Broker occurs in the

calculation time. Rapid convergence technology pro-

vided by router vendors has advanced greatly (Cis-

coSystems, 2003). After a failure occurs, network

topology convergence may be possible within in one

second. If an RMS starts calculating after failure de-

tection, it cannot eliminate the discrepancies in the

process.

On the other hand, if an RMS collects the weights

of OSPF or IS-IS, it can specify shortest paths before-

hand. In addition, an RMS assumes that each node

or link has failed, and calculates shortest paths in the

topology without assumed failure points. Therefore

it can also store detour paths beforehand. An RMS

can switch managed resources to detour paths as soon

as failure has been detected and discrepancies can

also be minimized. However, the number of assumed

failure patterns to calculate all detour paths becomes

huge depending on the network scale. So, it is not re-

alistic to store all path data in the database of an RMS

or Bandwidth Broker. Furthermore, the calculation

of detour paths is especially heavy. In the worst case,

the calculation could take several days. Therefore, the

service cannot be started quickly.

So, we devised a new detour path calculation

method called the “Look-ahead type” detour path

speciﬁcation. If failures occur, we can satisfy both the

need to reduce the number of necessary calculations

for detour paths and high-speed switching of managed

resources in a Bandwidth Broker type service.

4 “LOOK-AHEAD TYPE”

DETOUR PATHS

SPECIFICATION

In this method, an RMS calculates only shortest paths

and “primary” detour paths before service starts. It

does not calculate all detour paths. The detour path

calculation procedure is shown below. An RMS ex-

tracts shortest paths between every pair of nodes, and

saves them all in the database. At this time, the in-

formation about nodes and links between the starting

point S and the destination point D is held as attribute

information of the shortest path. We assume that one

of these links or nodes breaks down. The shortest path

between S-D in the network topology avoiding the as-

sumed failure is recalculated (Figure 3).

Figure 3: Detour path speciﬁcation.

This is repeated for all nodes or links. Next, the

DETOUR PATH RESOURCE MANAGEMENT METHODS FOR IP SERVICE OPERATION

289

RMS calculates the detour paths in the case of multi-

ple link or node failures. Furthermore, this procedure

is repeated for all shortest paths. If a selected path

produces the same results, the path is not stored. The

speciﬁed paths when the shortest paths break down

are deﬁned as primary (1st) detour paths.

In the stage in which the primary detour path cal-

culations ended, an RMS provides Bandwidth Broker

with path information and service starts. Paths that

bypass the primary detour path are deﬁned as sec-

ondary detour paths. Theoretically an RMS could cal-

culate the secondary detour paths when assuming that

the primary detour paths are broken. Likewise, the

more-than-third detour paths can be extracted. But

in our method, these detour paths are not calculated

before service starts (only shortest paths and primary

detour paths are calculated), because the detour paths

more than secondary are not used at the service start

time. Another reason for not calculating detour paths

more than secondary is because the load becomes sev-

eral times larger than for a primary path since the

number of failure patterns increases. By not calculat-

ing the detour paths more than secondary, we sharply

reduce the amount of calculation before service starts.

However, we think the RMS cannot provide QoS-

guaranteed services using only primary detour paths

in the long-term service employment, because the

possibility of serious failure occurring increases and

more-than-secondary detour paths are needed for ser-

vices in long-term service operation. In this case, an

RMS may not obtain necessary detour paths with-

out calculating more-than-secondary detour paths.

But our “Look-ahead type” detour path speciﬁcation

method deﬁnitely provides detour path information

about one step ahead using network monitoring. Af-

ter providing shortest paths and primary detour paths,

an RMS continuously monitors the network by ping

and trap. If a network failure is detected, the RMS

reports the failure point to a Bandwidth Broker. The

Bandwidth Broker immediately switches managed re-

sources to detour paths. At this time, the Bandwidth

Broker does not interrupt its service because it has

already stored necessary paths among the primary de-

tour paths. After informing the Bandwidth Broker,

the RMS starts calculating new primary detour paths

based on the present network topology existing after

the failure. The new primary detour paths are actu-

ally included among secondary detour paths at ser-

vice start. The amount of calculation for new primary

detour paths is less than that for all secondary detour

paths before the service starts because necessary de-

tour paths are limited by failure. These calculations

are performed as background processes by an RMS.

Therefore, the current service by a Bandwidth Broker

is not interrupted.

In this method, the RMS can achieve a result equiv-

alent to calculating the third and higher detour paths

by calculating primary detour paths after a failure.

When there is two or more failure, a network topol-

ogy pattern is changed in accordance with the order of

recovery. Therefore, the RMS has to calculate the re-

covery path with primary detour paths, and the paths

are reported to a Bandwidth Broker. The calculation

ﬂow of our method for detour paths is shown in Fig-

ure 4.

Figure 4: State changes of “Look-ahead type” detour path

calculation.

5 EVALUATION

In this section, we evaluate the “Look-ahead type” de-

tour path speciﬁcation method. The model network of

OSPF topology is shown in Figure 5.

Figure 5: Network model (OSPF topology).

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

290

In this network, OSPF areas are directly connected

to area 0. We assume the basic topology in each area

is a tree type. However, some paths are duplex, and

detour paths exist for service redundancy. We veriﬁed

our method for 100 to 2000 edge routers.

The dependence of the number of links and paths

or the number of nodes for the above-mentioned con-

ditions is shown in Figure 6.

Figure 6: Dependence of the number of links and paths on

the number of nodes.

In this simulation, the number of links was almost

linearly proportional to the number of nodes, and the

number of paths was proportional to the 2nd power of

the number of links.

First, the number of paths is shown in Table 1.

Table 1: Number of paths.

ERs Shortest path 1st 2nd 3rd

100 9,900 31,460 55,730 356,390

1000 999,900 3,909,560 6,848,930 20,431,590

2000 3,998,000 15,818,520 27,696,860 82,859,380

The number of times of the Dijkstra calculation is

considered to occupy a large proportion of the path

speciﬁcation processing as shown in Table 2.

Table 2: Number of times of Dijkstra calculation.

ERs Shortest path 1st 2nd 3rd

100 2,956 11,824 47,296 281,411

1000 35,240 140,960 563,840 3,354,848

2000 79,622 318,488 1,273,952 7,580,014

The detour path speciﬁcation by assumption of fail-

ure patterns is not very efﬁcient because of reachabil-

ity loss and re-extraction of the same paths. However,

the number of calculations is less than the number

of paths because the RMS speciﬁes paths inside the

OSPF area ﬁrst. Next, it connects each path between

areas. Finally, it determines an end-end path.

The simulation showed that when calculations were

performed using a general-purpose PC (CPU: Pen-

tium 4 2.5GHz), the calculation time for deriving

about 4 million SPs in a 2000-node network was

about 60 seconds. These results show that the Dijk-

stra algorithm is fast enough for service. And it took

11 minutes to calculate the 15 million primary detour

paths. They show that there is no serious inﬂuence on

the start of service.

However, it will probably be difﬁcult to prepare

detour paths beforehand if the “Look-ahead type”

method is not used because the calculation time was

more than 3 days until the third detour path was

completely extracted. Specifying beyond third de-

tour paths takes even more time. When the “Look-

ahead type” is used, service can start after 11 minutes.

Primary detour paths for the present topology are

consistently prepared after service has started. The

worst case that we consider is that the discrepancy

for re-calculating the shortest paths occurs for about

1 minute in our “Look-ahead type” detour path spec-

iﬁcation. This is because the discrepancy only occurs

in the case where many nodes break down simultane-

ously and the detour paths more than primary detour

paths used by the service are suddenly required. In

these cases, you should consider the case where a se-

rious failure, like loss of network connection, occurs.

6 CONCLUSION

We proposed a resource management method for IP

networks, called “Look-ahead type” detour path spec-

iﬁcation. We discussed the advantages and problems

of detour path management methods and veriﬁed that

IP network resource management that includes detour

path management is sufﬁcient for practical use.

In addition, each function of a RMS has been devel-

oped as a software module that operates on a service

management platform called a service resource agent

(SRA) (Miyoshi and Kimura, 2002) (Miyoshi et al.,

2002) (Figure 7).

A SRA has a general-purpose interface to connect

network management systems and network elements.

A SRA can collect data to perform service manage-

ment by SNMP or telnet using this interface. More-

over, the table of a database is designed so that one

service path can be managed as one object. We could

use these functions without changing a SRA platform

and implement a RMS on a SRA as only one func-

tion module which calculates shortest paths and de-

tour paths.

DETOUR PATH RESOURCE MANAGEMENT METHODS FOR IP SERVICE OPERATION

291

Figure 7: Service management platform.

Even for IP network services, which are best-effort

services, the topology and paths can be speciﬁed by

the method presented in this paper and functions that

achieve QoS-guaranteed service can be provided. Our

detour path speciﬁcation method is applicable to var-

ious other services, so we want to use it to contribute

to the creation of new services.

REFERENCES

Callon, R. (1990). RFC1195 : Use of OSI IS-IS for Routing

in TCP/IP and Dual Environments.

CiscoSystems (2003). Cisco NSF and Timer Manipulation

for Fast Convergence. Cisco Systems White Paper.

Dijkstra, E. W. (1959). A note on two problems in conexion

with graphs. 1:269–271.

Masuda, A., Hironaka, T., Yaguchi, M., Shima, M., and

Kuronaka, A. (2002). Prototype implementation of

a bandwidth agent for content delivery service. In

Proceedings of World Telecommunications Congress

(WTC-ISS) 2002, Paris, France.

Miyoshi, Y. and Kimura, T. (2002). Service resource man-

agement architecture. NTT REVIEW, 14(3):28–34.

Miyoshi, Y., Kimura, T., Otsuka, Y., Fujita, Y., Majima,

S., and Suda, K. (2002). An implementation of ser-

vice resource management architecture. In Proceed-

ings of World Telecommunications Congress (WTC-

ISS), Paris, France.

Moy, J. (1998). RFC2328 : OSPF Version2.

Shaikh, A., Goyal, M., Greenberg, A., Rajan, R., and Ra-

makrishnan, K. K. (2002). An ospf topology server:

Design and evaluation. IEEE Journal on selected ar-

eas in communications, 20(4):746–755.

Shaikh, A. and Greenberg, A. (2004). Ospf monitoring:

Architecture, design and deployment experience. In

USENIX Symposium on Networked System Design

and Implementation (NSDI).

Siamwalla, R., Sharma, R., and Keshav, S. (1998). Dis-

covering internet topology. In [online], Available:

http://www.cs.cornell.edu/skeshav/papers/discovery.pdf.

Zhang, Z.-L., Duan, Z., Gao, L., and Hou, Y. T. (2000).

Decoupling qos control from core routers: a novel

bandwidth broker architecture for scalable support of

guaranteed services. In Proceedings of ACM Special

Interest Group on Data Communication (ACM SIG-

COMM’00), New York, NY, USA.

ICETE 2004 - SECURITY AND RELIABILITY IN INFORMATION SYSTEMS AND NETWORKS

292