![](bg5.png)
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 verified
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
specification 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 specification by assumption of fail-
ure patterns is not very efficient 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 specifies paths inside the
OSPF area first. 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 influence on
the start of service.
However, it will probably be difficult 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-
ification. 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-
ification. We discussed the advantages and problems
of detour path management methods and verified that
IP network resource management that includes detour
path management is sufficient 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