第 8部
ネット ワーク管理

253

1章
Prologue
第1.1 The NetMan working group
The NetMan working group has been active in the area of network management. The
aim of this working group is to make signi cant contribution in the areas of network
management in particular and the Internet in general.
1.1.1

Activities during the year 1992-93

In the year 1992-93 we have mainly concentrated on the issue of examining the required and available information components for network management. The requirement
analysis is based on the perceived use of the information. Having identi ed the network
infrastructure as an important information component we have proceeded to develop theframework to service this information requirement. Experimental protocols [98] [99] havebeen developed and experimentation is presently underway on an international scale. We
have investigated areas in the Internet which require managerial attention. As a casestudy, we have examined the non-optimality of FTP-trac in the Japanese portion of
the Internet. The non-optimality detected does call for attention. We have investigatedshort-term and long term solutions. Finally, we have taken up the issue of managing
network applications. MIBs have been developed [100] and implemented.
1.1.2

Planned activities for the year 1994-95

In the year 1993-94 we plan to work on the following deployment strategy for X.500 in the Internet. This involves populating the directorywith information from the Internet with minimal human intervention.

 development a framework for smart applications. Smart applications are those which
use network information to operate eciently and optimally as far as network accessand generated trac is concerned.
255

256

1993 年度 WIDE 報告書

 development of tools for cartography in the network. Tools that will (semi-) automatically generate network maps using information from the network.

 deployment of an overall management framework for a largescale network to evaluate
the tools and algorithms that have been developed.

1.2 Outline of the document
In chapter 2 we have examined the information requirements of network management
systems. We have enriched the information with con guration/ policy ... related details.
Based on this information, we have designed algorithms that can make decisions forecient network management.
For ecient network management it is essential that the directory services be used asa source of information for components that are static or quasi-static in nature. The
possible uses of such information components are discussed and their potential uses areshown. The corresponding areas where work needs to be done are described in chapter
3.
File retrieval constitutes a major component of the trac in the Internet. Several
servers o er the same le. This redundancy gives rise to a lot of avoidable non-optimality.
A study has been carried out to examine and estimate this non-optimality. The results
are presented and methods of improved user support based on knowledge of the network
topology for optimising the ftp-trac are discussed in chapter 4.
To date, network management systems have focussed on the lower three layers [ Interface, IP, Transport] of the Internet suite of Protocols. The standard MIB-II covers theselayers well. Further, more speci c MIBs have been developed for particular protocols ineach of these layers. However, with the maturation of network management systems , theneed for managing network applications is increasing. The development in this area has
become more interesting with the fact that there are a host of OSI applications [ X.400,
X.500, ..] running over the TCP/IP stack. As a result, the application management
protocols will need to address both OSI and Internet applications. Ongoing work in thisarea is described in chapter 5.
Chapter 6 details the work that has been done towards putting NIC information in the
directory. We have worked on the JPNIC [Japan Network Information Center] and APNIC [ Asia Paci c Network Information Center] databases. The experience and problems
encountered are described.

2章
Information, Intelligence & Algorithms forEcient Network Management
第2.1 Introduction
Any management basically involves gathering information about the subject that needs
to be managed. The gathered information is then processed and analyzed using theknowledge about the subject, to make judgements about the status of the subject andto take decisions about the future course of action.
Traditional network management systems which have concentrated mainly on monitoring network trac, performance and fault detection have focussed on the operations
and functions of the network elements and their interfaces. In the Internet there areseveral MIBs that are proposed standards or are under development- almost all relate
to protocol layers 1-4.
However for ecient network management, it is important to know about higher level
information e.g. the functioning of the applications and the network con guration, administration and policy.
Given the appropriate information intelligent management applications can be createdby developing algorithms that model an expert network managers approach to solving aparticular problem.
In the rest of this chapter a network is the media for transmitting information. network
elements are equipment with one or more network interfaces whereby it is possible toexchange information with the network. Network elements with multiple interfaces e.g.
gateways/routers/bridges/repeaters... may be used to connect networks.

2.2 A Model for Intelligent Network Management
Most of the work in Network Management, so far, has been done in building the framework for collecting information from the network. Presently, there is an agreed management framework. Agents residing in network elements will provide the network manager
257

1993 年度 WIDE 報告書

258

application with information about the network. Standards have been xed for communicating management information between the manager and the agent. The objects which
need to be managed, are listed up and described in terms of their properties in MIBs.
In this framework, the human managers' view of the network is limited to objects in theManagement Information Base(MIB). Of course extensive research has been carried todevelop these MIBs and the development and re nement is an ongoing process.
In the following discussion we will use the example of the SNMP [101], [102], [103] network management framework; it is possibly the most widely deployed and experimented.

2.3 Information Components of a Network Management System
The Information Components of a network management system are as follows: Communication operations related{ System{ Lower Layers{ Network Layer{ Transport Layer{ Application Layer

 Infrastructure related Administrative & Policy related
In the following we brie y describe the issues related to various sub-components.

2.4 System, Lower, Network & Transport
These components are possibly the most widely explored and discussed and deployed.
The MIB-II [103] contains the core set of managed objects for the for the System, Lower,
Network & Transport layers of the Internet suite of protocols. The Host Resources MIB[104] has been developed. It covers the system and process related details of network
elements. There are several other MIBs which deal with a speci c type of interface ortransport medium or protocol. Together these MIBs allow the monitoring and management of the communication infrastraucture - the lines nodes and the communication
protocol entities. They give an immediate idea of the functioning of the network and arewidely used for network monitoring, trac and performance estimation, fault-detection,etc. .

第 8部

2.5 Application

ネットワーク管理

259

With the basic management framework reasonably well established and with the growing spread of network applications like mail, news, DNS, Directory Services, ... , the issueof managing Network Service Applications[NSA] is gathering attention. NSAs include allapplications that provide network services. The necessity of managing Network Service
Applications is particularly critical for NSAs which have (widely) distributed components
such as the Mail and Directory Services.
The targeted NSA management centers around general monitoring to detect a broad range of operational problems: broken connectivity, system failure,congestion, ..

 to monitor performance and utilization
Presently a generic NSA-MIB [105] which covers the general network service related
aspects has been de ned. It focusses on the NSA description, the operations and activity
indications, the associations and association related details and two application speci c MIBs for mail [106] and directory [100] applications which focus on the respective
application-speci c aspects have been de ned to work in conjunction with the NSA-MIB.
Detail discussion on the MIBs and their development follows in chapter 5.

2.6 Network Infrastraucture
The widening span of computer networking has highlighted the importance of holding
and servicing information about the networking infrastructure itself. The growing andactive interest in network management [107], is severely constrained by the lack of any
organized pool of information about the network infrastructure itself. Some attempts
have been made, on a piecemeal basis, to provide a larger view of some particular aspectof the network (WHOIS, DNS, .. in the case of the Internet; [108], [95]). Presently, there
is a movement to explore the possibility of setting up a framework to hold and serve theinfrastructural information of a network [109].

2.7 Infrastructural information requirements
Network operation and management requires information about the structure of the
network, the nodes, links and their properties & functions. Further, with current networks
extending literally beyond bounds, the scope of the information covers networks beyond
the span of local domain of authority or administration. When the Network was relatively
small and simple the map was already known to the knowledgable network administrator.

1993 年度 WIDE 報告書

260

Based on this knowledge the course of the packets to di erent destinations would becharted. But presently the size of the Network is already beyond such usages, with thecurrent growth being near explosive. This is giving rise to the urgent necessity of having
infrastructural and service related information made accessible from all places and at all
times in a reasonably ecient manner and with reasonable accuracy.
Network related information, referred to as 'network map' in the rest of this paper,
should
1. Show the interconnection between the various network elements. This will basically represent the Network as a graph where vertices represent objects like gateways/workstations/ subnetworks and edges indicate the connections.
2. Show properties and functions of the various network elements and the interconnections. Attributes of vertices will represent various properties of the objects e.g.
speed, charge, protocol, OS, etc. Functions include services o ered by a network
element.
3. Contain various name and address information of the networks and network elements.
4. Contain information about various administrative and management details related
to the networks and network elements.
5. Contain the policy related information, part of which may be private while the otherpart may be made public.
Using this map the following services may be provided
1. Con guration management: Display the physical con guration of a network, i.e. nodes and their physicalinterconnections

 Display the logical con guration of a network, i.e. nodes and their logical interconnections.

2. Route management:

 Find alternate routes by referring to the physical and logical con gurations.
 Generate routing tables considering local policy and policy of transit domains.
 Check routing tables for routing loops, non- optimality, incorrect paths, etc.
3. Fault management: In case of network failures alternatives may be found and used
to bypass the problem node or link.
4. Service management: Locate various services and servers in the Network.

第 8部

ネットワーク管理

261

5. Optimization: The information available can be used to carry out various optimizations, for example cost, trac, response-time, etc.
6. Provide mappings between the various names and addresses of elements
7. Depict administrative/autonomous domains.
8. Network Administration and Management: References to people responsible foradministering and technically maintaining a network will be useful.
Examples of such usages are described in [98], [110], [111].

2.8 Algorithms
As can be expected a whole range of applications can be developed based on the information components provided. Simple monitoring of the network for fault detection,
generating annotated network maps, making routing decisions, nding alternate paths incases of failures or congestion, nding the cheapest source of a document are just someexamples.
In this section we examine the various algorithms that may be used in some of theseapplications for ecient management.
2.8.1

Monitoring Algorithm

One of the purposes of network monitoring is to detect any abnormality or fault. Thisis the simplest of algorithms which involves the periodic checking of the value a managed
object or a set of managed objects. The detection of abnormality or fault depends on
the type and de nition of the managed object. For example, for a Status type object,
if the value is a direct indication. For Gauge or Counter type objects there will be areference value or threshold which decides whether there is an abnormality or not. E.g.
the presence of error packets beyond a certain critical count would indicate a de niteabnormality.
2.8.2

Network Maps

A map is very important for management purposes - irrespective of whether the manager is a human being or a application process. Given the con guration information
is a straight forward generate the topological graph of the network where the vertices
represent the components of the network and edges indicate the connections. For visual
representation the graph may be translated to a more "physical" illustration.
Just as there are several maps of the same geographical domain (political, natural...)one can envisage several views of the same network and its components. A view (called1993 年度 WIDE 報告書

262\image" in the remainder) could pertain to a particular protocol suite (IP/OSI/...), an
administrative domain or purpose. Using images, several abstractions of the same object
is possible. For more details refer to [99].
2.8.3

SoftPages[SPP]

It is desirable to query for les always on lestores that are nearest/cheapest to theusers' site. For that purpose, it is necessary to evaluate distance/cost between the users'
host and possible servers. Also, it is necessary to search the contents of the servers. For
example, a user on host A looking for a certain document should under ideal situation
carry out the search in the ordered list of leservers [C,B,D], the ordering being basedon the potential retrieval costs.
The Soft Pages Project [110] which implements this algorithm started with the wish
to reduce ftp trac on crowded overseas links and national backbones. The algorithm
makes use of the network infrastructure information concerning network con guration,
location of servers and their contents, the links and their charges.
The algorithm makes use of the network infrastructure information concerning network
con guration, location of servers and their contents, the links and their charges.
Parameter values are read from the network database and represent:

speed - the bandwidth (in kbps) theoretically available in a networktrac - the average use (as percentage) of this network, thus telling something about
congestion

charge - monetary units (as abstract integer number) to be paid for the transmissionof one packet; this should be used to express relationship between several charges
rather than absolut amount of money (not to speak of currency, exchange rates,etc.)

priority - sometimes system administrators want to keep certain connections free forimportant trac like mails. They can do this by increasing the priority (integer
value) of the network connection in comparison to another.

Cost is calculated as follows:= f (speed; traf f ic; charge; priority)
cost = a 3 (1=speed) + b 3 traf f ic + c 3 charge + d 3 priority
cost

whereas the weights a, b, c, d can be chosen freely by the administrator of a site. This
way an individual evaluation is possible. For some sites speed has a higher weight thancharge, for others it may be the other way around.

第 8部

ネットワーク管理

263

With the formula given above, a cost index can be calculated for one network connection. If trac has to pass several networks, their cost indexes will be added to an overall
cost index for the end-to-end connection. Thus, the number of network hops goes into
the cost index, too.

2.8.4

Alternate Paths

Given the mesh-type connectivity of networks, it is very important to have a clear
picture about the connections; for example, A-net has potential connectivity to D-net
via multiple routes. The topological map of the network is useful; to nd alternate paths
in case of failure, to know the transit policy of the provider on the alternate path, toknow the point of contact for the provider. Needless to say the map can be used todetect non-optimal routes and to evaluate the quality of the connectivity in terms of
redundancy.

2.8.5

Fault Tolerant Management

In the present management scheme a manager monitors networks through the manager
workstation. Now if the link from the manager workstation to the agent is down or stillworse if the link to the managed network is down without alternate means there will bea collapse of network management. Among the alternate means are the following Use Alternate paths for management trac
This implies that the management application has control over the networking
layer. It uses the network con guration information to decide the next alternative path/router and instructs the networking layer to route its requests/queries
accordingly. The intelligent agent at the other end reads the request and sends the
reply along the appropriate route.

 Use Proxy AgentsThis method is a more simpler method but involves the cooperation of a few moreagents in the network. For example suppose the the link between management
stattion A and Managed Station B is down. Now, if the link between A and somestation C is up, and if there is a link between C and B, then if there is an agent on
C which agrees to act as a proxy for the agent on B then the management station
can redirect its query to the proxy agent on C.

264

2.9 Conclusion

1993 年度 WIDE 報告書

As part of an e ort to cope with the rapidly changing communications scene andthe explosive growth in communication networks, the need for a framework to hold theinfrastructural and service related information about communication networks has beenemphasised. The use of such a map is manifold. A Pilot based on this idea, presently
covering the Japanese Internet, is in operation. Future plans involve extending the pilot
to the International arena to cover other countries/NICs. The network model adopted
in the Pilot for representing a communication network with all its related details anddescriptions in the Directory, is described. Experience with problems and strategies forbootstrapping, operation and maintenance of the Pilot are discussed. A new genre ofapplications based on this proposal are coming up and their current status is reviewed.

3章
Using the X.500 Directory for Ecient
Network Management
第3.1 Introduction
Management basically involves gathering information, processing it in an appropriatemanner to derive some conclusions and, carrying out appropriate action based on theinferences. Network managemnent is no exception. The nature of the information utilized
by network management can be broadly classi ed as dynamic. The information that (potentially) changes frequently, e.g., the operational

status of an interface, the cumulative number of error packets at a particular receiveretc..

 quasi-static. Information that changes - but not with high frequency - i.e. not on
an hourly or daily basis. E.g. Network con guration.

 static. Information that changes very infrequently - for example the ip-address of ahost, the manager of a network, ...

The information components required for network management have been outlined inchapter 2. The dynamic components are in general serviced by querying some agent which
has access to the latest information e.g. link status or the number of active connections.
Some of the static/quasi-static components and the problems involved in holding andservicing these components are discussed in the following.

 Network Maps:

Like any other map, the utility of a map detailing the network con guration istremendous. Yet, implementing and maintaining a detailed map of the network
poses a serious problem. The scope of the map is global and the network itself is
expanding. Some of the problems that are peculiar to the network map are listed
below:
265

1993 年度 WIDE 報告書

266{ The Network con guration is quasi-static. Nodes, links and networks are being
added,updated and deleted someplace or the other.
{ The Network is huge and geographically distributed.
{ The Network spans several political and administrative areas. The related information is also controlled and maintained in a distributed fashion.

In short, global network con guration information is unwieldy and growing continuously. It is impossible to service such information in a centralized fashion. So,a distributed database system is necessary. In this context, the X.500 Directory
system [112] is an appropriate candidate on which the network map may be implemented. The X.500 Directory is intended to be a very large and highly distributed
database. It is structured hierarchically with entries arranged in the form of a tree
in which each object corresponds to a node or an entry. Information is stored aboutan object as a set of attributes.

 NIC-information:

The information services provided by the various NICs scattered all over the network
is essentailly quasi-static. The information is in generally administered locally while
the information may be sought and used from any part of the network. It is clearthat a service based on X.500 will be much more powerful due to the global anddistributed database providing a single window whois-type service.

It is beyond doubt that the X.500 Directory provides an excellent framework for storingand servicing information which is of static or quasi-static nature, in a distributed fashion.
Pilot projects employing the directory are already in place. The PARADISE [113] project
presently spans 35 countries including Japan and covers more than a million entries. Thus
the directory services, if properly utilized, could be a repertory of useful information for
network management.
Though there has been extensive work on the Directory system, it has mainly been
concentrated on persons, organizations, ..., there has been little or no work on the framework for representing networks in the Directory. Only recently the situation has started
changing as is described in the following.

3.2 Present Status of research and experimentation
A major challenge in employing the X.500 directory for novel applications and purposes
is to design appropriate schemas. Schemas related to the applications mentioned above
are listed below along with the present status.

 A model in which a communication network with all its related details and descrip-

tions can be represented in the X.500 Directory is de ned in [99]. Schemas of objects

第 8部

ネットワーク管理267

and their attributes which may be used for this purpose are presented. The model
envisages physical objects and several logical abstractions of the physical objects.

 The objects necessary to include information about IP networks and IP numbers in

the X.500 Directory are de ned in [98]. It extends the work "Charting networks in
the X.500 Directory" [99] where a general framework is presented for representing
networks in the Directory by applying it to IP networks. This application of the
Directory is intended to support the work of IP network assigning authorities, NICs,
as well as other applications looking for a mapping of IP numbers to data of related
networks. Furthermore, Autonomous Systems and related routing policy information can be represented in the Directory along with their relationship to networks
and organizations.

 A mapping of domains onto X.500 is proposed in [114]. It gives a range of new
management and user facilities over and above those currently available. This speci cation proposes an experimental new mechanism to access and manage domain
information on the Internet. This document is slated for revision in the light of the
new experimental protocols [99] [98] that have come up.

3.3 Potential areas for research and experimentation{ Con guration management:

3 Display the physical con guration of a network, i.e. nodes and their physicalinterconnections
3 Display the logical con guration of a network, i.e. nodes and their logicalinterconnections.
{ Route management:

3 Find alternate routes by referring to the physical and logical con gurations.
3 Generate routing tables considering local policy and policy of transit do-mains.
3 Check routing tables for routing loops, non- optimality, incorrect paths, etc.
{ Fault management: In case of network failures alternatives may be found andused to bypass the problem node or link.
{ Service management: Locate various services and servers in the Network.
{ Optimization: The information available can be used to carry out various optimizations, for example cost, trac, response-time, etc.
{ Provide mappings between the various names and addresses of elements

1993 年度 WIDE 報告書

268{ Depict administrative/autonomous domains.
{ Network Administration and Management: References to people responsible foradministering and technically maintaining a network will be useful.

 Extensive deployment of the directory and network related info.
 WHOIS info in the Directory - multilingual scheme.

Extensions to incorporate multilingualism supported by some NICs needs to beurgently designed.

 NIC info in the directory Use of network con guration information for smarter applications:{ Smart Archie{ SoftPages{ WWFS{ Other applications

 Assistance in con guring Applications

Several applications need to have ( application-speci c) con guration info during
operation/installation. Servicing this requirement by using the X.500 directory is apromising area. It basically envisages storing and servicing{ NTP maps in the directory.
{ NNTP maps in the directory.
{ other maps in the directory.

3.4 Challenges
There are three major areas of challenge in realizing the proposal for using the directoryfor ecient network management :1. Schema design and Naming Context: The issues that need to be taken care of indesigning the schemas and naming contexts are as follows: Scalability, Distribution of control & maintenance Preservation of administrative boundaries/controls.
 Minimize data duplication
 Evolving technologies/problems
 Security and access control

第 8部

ネットワーク管理

269

2. A framework for dissemination of Schema information: A methodology for using the
Directory itself for disseminating schema informatio n.
3. Bootstrapping, Operation & Maintenance: The strategy for startup, operation andmaintenance of the proposed directory services is a the most crucial aspect that will
decide the success of the proposal.

3.5 The Contribution
The proposed framework will have far reaching consequences in the networking arena.
The spread of networking is seeing a revolution that was beyond imagination. however
researches in some of the important infrastructural aspects have not kept pace withthe rapid pace of growth. To date there is no concept of cost among the majority of
network users. The main reason being that the appropriate framework is non-existent.
Without the global network map con guration management in the large is impossible.
The management of services, an area of growing importance as the network is moving
to within the reach of ordinary citizens, is impossible without a truly global distributed
information infrastructure. The proposal addresses the key issues stated above.

3.6 Conclusion
The success of the scheme to use the directory for management purposes depends
heavily on the deployment of the directory in general and on experimentation of therelated schema that has been developed into experimental RFCs. Given wide enoughexperimentation the information of IP-networks in the directory could be routinely looked
up for con guration management purposes. The directory service could o er a parallel
DNS service. The disjoint WHOIS systems could be integrated in the directory. Most
important, we envisage that newer , hitherto unthought of, uses of the directory will
emerge. That is probably the most challenging and exciting aspect of this exercise.

4章
Estimation of the Non-Optimality in
FTP-trac
第4.1 Introduction
One of the most popular tools in the Internet is the quite simple le transfer protocol
ftp [115]. This protocol enables users to send and receive les from virtually any IPconnected computer in the (network) world, provided proper access rights apply. Manyorganizations have set up anonymous ftp server which can be accessed by any user (inread-only mode in most cases). These ftp servers have been proven to hold a substantial
number of useful les (software, documents, etc.), which are of interest to many people.
As a result of broad usage, it has been found that the ftp component constitutes
nearly half of the network trac along backbone and trunk routes ([116], [117]).
Within a local or campus network, in most cases bandwidth will be sucient to encourage le transfers via ftp. Problems arise when a user ftps (network jargon for transfering
les using ftp) data from a non-local computer. Wide area connections between networks
of di erent organizations generally have a limited bandwidth. Typically, a university campus network is connected to other networks by a link of 64 to 256 kByte/s (only in somecases 2 MByte/s and more). If a connection is established with a very remote network(e.g. from Japan to US), several transit networks have to be passed. In such a case, theend-to-end throughput might be decreased to a level below user acceptance. Thus, it
makes a big di erence in terms of time if a le is copied from a local or a remote server.
Naturally, there have been studies on reducing the volume of ftp-trac. The Alex [118]system uses ftp operations in conjunction with NFS to build a local cache of retrieved
les. [119] has made a case for building a hierarchically distributed cache of le objects
inside Internetworks to reduce trac. There have also been proposals to make ftp itself
more ecient by incorporating ways of compression etc.
In this work we take a di erent line and show that the Internet already provides anenvironment rich with replications - the problem lies in the lack of awareness about the
network con guration.
In general the same le is served by several ftp-servers in the Internet. This redundancy
270

第 8部

ネットワーク管理271

if used judiciously could help in reducing network trac. But unfortunately without

any support in the form of knowledge about the network topology this has notbeen the case. On the contrary, it has resulted in poor bandwidth utilizationand deterioration in service.

In this work we propose a model based on which the cost of retrieving a le is calculated.
Based on this model we calculate the non-optimality involved in le retrievals by studying
real life data from the logs of ftp-servers. The results are used to show an e ective
way of having cheap and ecient le retrieval.

4.2 Network trac optimality
The global network can be considered as an undirected graph, a mesh. The edges
represent lines with certain properties and nodes the gateways. Usually, the optimization
problem is to nd the shortest path between the nodes A and B. There are several
algorithms that deal with shortest-path routing. These algorithms fall into two categories- distance-vector algorithms DVA and link state algorithms LSA. In the DVA a node(router) knows the length of the shortest path from each of its neighbours to every
destination in the network. This information is used to compute the distance of therouter itself from all destinations in the network and thereby select the shortest path.
In the LSA each node (router) knows the entire network topology based on which it
calculates the shortest path to the destination.
Our work is not concerned with the routing issues and algorithms. We look at the mapof the network where the shortest path is being used by the underlying IP implementations. Thereby the reachability between the nodes is xed - so is the communication
cost for inter-node communication. Admittedly, there is an element of inaccuracy as
the routing is dynamic, leading to costs that are varying. However from experience, thevariation is small and the simpli cation is logical.
A path can be evaluated by summing the weights of all parts (edges) along this path.
Routing protocols try to solve this optimization problem. In simple routing protocols,
all edges have the weight 1. In that case, only the number of edges (called numberof hops) counts for path evaluation and optimization. For networks, this means thatthe (di erent) bandwidth of links are not considered when estimating a path. Thereis, however, a signi cant di erence between two links, when one has a capacity of say
512 kByte/s, and the other is a 9.6 kByte/s line.
For distributed network applications, path optimization is an even more dicult problem. Also with end-to-end routes optimized by lower-level protocols, a client-servercommunication can be non-optimal. This can occur when the application allows a client
to choose one out of several (apparently identical) servers to contact. The connection toeach of these servers is in itself optimal, i.e. there is no better way to reach server X. But

272

1993 年度 WIDE 報告書

the link to server X might be worse than the link to server Y. Presently, applications

like ftp do not provide a way to compare alternate client-server-connections
with respect to network characteristics.

Users are basically concerned with a "fast" connection to remote services. It does notmake a di erence where a server is located or which organization it belongs to. But one
can foresee that in the near future users will also have to worry about the cost of sending
network trac over speci c links or using certain services.
For this study, we investigated ftp trac on the backbone of the Japanese Internet .

Connections chosen by users were compared against possible better connections. Details of this investigation are given in the remainder.

4.3 Network model for cost calculation
Strictly speaking for a mesh network consisting of n elements there will be 21 n(n 0 1) costelements which basically form a [n 2 n] symmetrical matrix. This does lead to practicalcomputational problems in a network of reasonable size. However, fortunately enoughthe con guration of networks are simpler and for all practical purposes arehierarchical with a backbone connecting regionals and the regional backbone
connecting locals. The hierarchy could be deep depending on the network.

This allows us a very useful simpli cation. Instead of looking at all the n elements wecan concentrate on the m regionals i.e. on the inter-region costs. Generally m is muchsmaller and the cost computation problem is much more tractable.
In the case of our study, the medium size Japanese network, the constituent networks
could be grouped into a reasonably small number of regions. For our study, we focussed
on the networks belonging to the 15 WIDE or JAIN regions1 . A region in this context
is the group of regional networks which are connected to the backbone by a common
gateway. Thus, they all have the same entry point for wide area trac. Regions areinterconnected by backbone links as depicted in the following gure.

1 There are several other important constituent networks of the Japan Internet. However for the sakeof simplicity we have restricted this study to the WIDE and JAIN regions only. The map itself is a
simpli ed and is outdated now.

第 8部
192

192

FUK

273

ネットワーク管理
64

192

KYO

FUJ

SND

64
384

64
10000

HIR

768

Kyu

Hir

OSK

TYO

64

192

64

Osk

64

Tyo

Kyo

Toh

Hok

64

WIDE
Jain

Nag

link speed (kbps)

WIDE and JAIN regions.

As a result, the mesh graph with nodes and (weighted) edges can be used for further
consideration of the network.
Trac between regions is routed according to topology and policy rules. Unfortunately,
there is no common database revealing all routes. Therefore we had to run a lot of
traceroute checks to get an accurate picture of how packets are routed. Had we beeninterested only in the number of hops a packet takes from region A to region B, we weredone with the model. The basic idea of this study was, however, to compare network
connections with respect to their link properties, such as bandwidth, trac, etc. Thiskind of information (attributes to existing links) is more dicult to gather. With thehelp of WIDE members at least the bandwidth of all backbone links was known. There
was no reliable data for usage/trac on the links. Therefore we had to estimate that alllinks are equal in this respect, and connection costs were calculated on the basis of linkspeeds only.

4.4 The Cost Model
4.4.1

Simple cost calculation

There are several possible de nitions of cost. Cost could re ect tari , speed, policy, . . . with varying degree of weightage on the parameters.

For our purposes - namely estimating the non-optimality of trac - weconcentrated on the time the network packet exists in the network. In the1993 年度 WIDE 報告書

274

present situation lines are either leased or free so the tari does not come into the picture(There were no dial-up lines in the picture that we considered).
The cost has two components:= timeat0nodes + timein0transmission
The time at nodes is of the order of micro seconds and is negligible when comparedwith the time in transmission along lines of max speed 1 Mbps.
Thus,
cost  timein0transmission
As unit of cost we took the time taken for 1 Mbyte to reach from source to destination.
This way, the de nition of cost is reduced to
cost

cost

=

X 1000ni=1

spi

where spi is the speed of a single link i in kbps, and n the total number of links involvedin the end-to-end connection.
4.4.2

Total cost calculation

The simpli ed communication model wherein the network comprises of 15 regions andthe regions are connected by the backbone networks, greatly simpli es the total-cost
calculation. It is clear that
total costabsolute= costinter0node= costsource0region + costinter0region + costdestination0region

where,

 source-region [destination-region] costs are the costs from [to] the source [destination]
node to [from] the backbone router and,

 inter-region cost is the cost between the source-region router and the destinationregion router on the backbone.

As far as comparative costs from one xed starting point are concerned the sourceregion cost will drop - so that
total costcompare= costinter0region + costdestination0region

Thus to carry out the cost calculations we needed a [15215] symmetric matrix

of inter-region costs and an array of intra-region costs. Calculation of thismatrix using network con guration information and the above cost model was
straight forward.

第 8部

275

ネットワーク管理

表 4.1: Connection costs as seen from jp-gate.wide.ad.jp (Fujisawa)target region

cost

regioncost

WIDE Fukuoka (FUK)156

WIDE Hiroshima (HIR)

208

WIDE Osaka (OSK)208

WIDE Kyoto (KYO)52

WIDE Tokyo (TYO)

26

WIDE Sendai (SND)

156

JAIN Kyushu (Kyu)

104

JAIN Hiroshima (Hir)221

JAIN Osaka (Osk)364

JAIN Kyoto (Kyo)208

JAIN Nagoya (Nag)234

JAIN Tokyo (Tyo)78

JAIN Tohoku (Toh)312

JAIN Hokkaido (Hok)234

Table 4.1 gives an extract of this matrix. Here, the connection costs from one region(FUJ) to all other regions are given.
When placing client and server of an application into the according regions, we canestimate the relative cost this connection has in comparison to other connections. For
anonymous ftp, a comparison of servers located in di erent regions is possible from thevery point a user is situated.

4.5 Data Collection
For this study, we were interested in real-life ftp trac statistics. When a user fromhost A received a le from host B, we want to nd out if there would have been a hostC which is better accessible for user at A for this speci c le transfer.
For this purpose, records are necessary that contain the following information:
 ftp client host ftp server host name of le transferred size of le transferred date and time of transfer

This data can be obtained by logging all ftp client sessions . There are tools aroundfor collecting statistical data on outgoing ftp trac, but the resource requirements areheavy, distributed and complicated. Therefore, we chose to use the logs generated by theftp servers. This approach is simple - processing the logs was a bit more complicated,but the information content was sucient.
Data has been collected for the following well-known anonymous ftp servers shown in
Table 4.2.

1993 年度 WIDE 報告書276

表 4.2: Summary of ftp server logs

serveroperations
logtime operations/hour
ftp.is.titech.ac.jp4295 21 days 14:19 hours
8.3
ftp.kuis.kyoto-u.ac.jp61607 58 days 22:32 hours
43.5
ftp.mei.co.jp
2658 27 days 22:21 hours
3.9
ftp.ricoh.co.jp
461 19 days 04:40 hours
1.0
ftp.tohoku.ac.jp6643 12 days 23:48 hours
21.3
utsun.s.u-tokyo.ac.jp5260 8 days 23:45 hours
24.4
Furthermore, the contents of all anonymous ftp servers within the considered area (inthis case: the Japanese Internet) have to be known. For cross-checking of le retrieval
possibilities, records are necessary containing: name of le size of le date le was writtenCollection of these data records was fairly easy, because all we had to do was get
ls-lR les from ftp servers. This was done for 44 anonymous ftp servers within Japan.
This list of 44 servers (see table 4.3) was compiled out of several documents and the setof servers registered with the central Japanese archie server archie.wide.ad.jp.
Details of processing these records are discussed in the following section.

4.6 Data processing
4.6.1

Preprocessing of logs

Before optimality checks were carried out, the input les had to be preprocessed togenerate a common input format for logs of all servers. In most cases, ftp-logs had been
written by syslogd. But almost each syslogd used a di erent format to log date, time,
name and size of le. Also, the complete information for one le retrieval is usually logged
in two (not necessarily consecutive) lines: One entry containing information about theuser, the other about the le retrieved. These two lines had to be merged. We de ned asimple intermediate record format with the data elds:
ftp_server ftp_client file_name file_size retrieval_date

第 8部

ネットワーク管理

表 4.3: Major anonymous ftp servers in Japan

serverazabu.tkl.iis.u-tokyo.ac.jp
etlport.etl.go.jp
ftp.ascii.co.jp
ftp.cc.saga-u.ac.jp
ftp.cs.titech.ac.jp
ftp.csce.kyushu-u.ac.jp
ftp.dcl.co.jp
ftp.ecei.tohoku.ac.jp
ftp.foretune.co.jp
ftp.fujixerox.co.jp
ftp.is.titech.ac.jp
ftp.kyushu-id.ac.jp
ftp.meiji.ac.jp
ftp.phys.keio.ac.jp
ftp.sigmath.osaka-u.ac.jp
ftp.u-tokyo.ac.jp
ftp.wg.omron.co.jp
nuis.nuie.nagoya-u.ac.jp
scslwide.sony.co.jp
solaris.ims.ac.jp
theta.iis.u-tokyo.ac.jp
utsun.s.u-tokyo.ac.jp

les
56
6907
2168
5016
1641
3049
119
25619
2214
152
516
580
4166
477
779
51897
18583
3855
2154
14
19784
9120

serverlesbash.cc.keio.ac.jp
3695
ftp.ae.keio.ac.jp693
ftp.c.u-tokyo.ac.jp
2148
ftp.cs.keio.ac.jp
85939
ftp.cs.uec.ac.jp
1718
ftp.csrl.aoyama.ac.jp
206
ftp.dit.co.jp
2678
ftp.elcom.nitech.ac.jp
26841
ftp.fujita3.iis.u-tokyo.ac.jp 10852
ftp.ics.osaka-u.ac.jp
42208
ftp.kuis.kyoto-u.ac.jp162859ftp.mei.co.jp
9630
ftp.nig.ac.jp757
ftp.ricoh.co.jp
5676
ftp.tohoku.ac.jp
4516
ftp.waseda.ac.jp8444
icpcs41.icpc.fukui-u.ac.jp1420
onlnews.kek.ac.jp509
sh.wide.ad.jp3948
srawgw.sra.co.jp
32864
tutserver.tut.ac.jp17704
wnoc-fuk.wide.ad.jp
3425

277

1993 年度 WIDE 報告書

278

The hostname of the ftp client was reduced to the domain name. This is quite simple
for Japan, because there is a well structured naming of domains. Third-level names correspond to the organization, second level give the type of organization (ac=academic,
co=commercial, go=government, ad=administrative), and top-level is .jp. Thus, all information below third level was supressed and user sites could easily be matched to the
15 regions shown above. All ftp accesses from sites outside Japan were mapped to thevirtual domain foreign.ad.jp. They were processed as if originated at the international
gateway point. The parameter retrieval date was written in the unique way yymmddHHMMSS. Some entries in logs had to be left out because one or more parameters (e.g.
originating domain) could not be identi ed.
Similarly the contents les of the ftp servers to check data against were preprocessed.
To speed up searches, non-interesting elds were removed from ls-lR output format. As
a result, a line of a contents le looked like:
file_name file_size write_date
4.6.2

The algorithm

With the network model described in subsection 4.2 and allocated cost indexes, network
connections can be compared to each other. A connection with a smaller cost index is
supposed to be cheaper because it uses faster links or less gateways. The basic idea of thealgorithm presented here is to compare the connection a user has chosen (by retrievinga le from a certain server) to connections he could have used to retrieve the same lefrom another server. If there is at least one ftp server holding the same le and witha cheaper connection from the users site, we found a so called non-optimal retrieval.
Correspondingly, an optimal retrieval is agged when there was no cheaper way.

4.7 Results
The algorithm described in subsection 4.6.2 was run on the collected data (see subsection 4.5). Table 4.4 summarises the results for the studied ftp servers. Data is given interms of number and size of les, and estimated cost.
These tables reveal that an average of 20 % of all les transferred with anonymous ftp
use scarce backbone bandwidth without necessity. For the amount of data beingtransferred (and this corresponds directly to packets on the network), theshare of non-optimal trac is more than 30 % of the total ftp trac.

It also shows that the more well known ftp-sites are subject to a larger percentage of
non-optimal retrieval. This is understandable. Without any support users tend toplay it safe and attempt to obtain the le from the server that is most likely

第 8部

ネットワーク管理279

表 4.4: Ftp study summary
server
ftp.is.titech.ac.jp
ftp.kuis.kyoto-u.ac.jp
ftp.mei.co.jp
ftp.ricoh.co.jp
ftp.tohoku.ac.jp
utsun.s.u-tokyo.ac.jp

les
opt n-opt
14
614137 8341
1225
766
334
47
4309
930
2739
819

Mbytes
opt n-opt
3
1
2,154 1,647
452
203
108
22
397
161
276
161

106 2 cost
opt
n-opt
0
84
401,027 550,794
103,382
55,59012,1595,457
40,60016,608
9,625
18,136n-opt : total (%)
les bytes
cost
30.0
31.1 100.0
37.1
43.3
57.8
38.5
31.0
35.0
12.3
16.6
31.0
17.8
28.9
29.0
23.0
36.7
65.3

to have the le.

In this study we have limited ourselves to national trac on thenational backbone only. A similar trend, and with more serious consequences could be
expected to be seen if the trac on the international backbones were examined.
Looking at the overall cost for these le transfers, the gures reveal an even higher
percentage of non-optimality trac. Because in our cost model cost is basically equivalent
to transmission time, much non-optimality means long waiting time for the user.

4.8 Summary of Results
The results presented in this paper con rm that there is indeed a lot of non-optimal
ftp-trac. Further, the non-optimality stems from the mis-use of the replication-rich leserver environment in the Internet. With ever growing demand for network resources thisabuse of backbone bandwidth will need to be limited. Bandwidth is a sacred resource
which many users have to share. Also, with trac accounting to come usage patterns
have to change.
We have shown a way of avoiding this. User support based on knowledge of the

network topology could result in better service and utilization of network
bandwidth. We presented a model based on which the cost retrieving a le may be
calculated. This shows an e ective way of providing user support for cheap and ecient le retrieval. The SoftPages project [110] based on this concept is presently underexperimentation.

280

4.9 SmartArchie

1993 年度 WIDE 報告書

networkDB

X.500

CLIENTSERVERDB

THE SMART ARCHIE

SmartArchie is a very simple improvement on the conventional Archie mechanism [120].
The conventional archie clients return a list of le-servers to the user. The list of leservers may be sorted according to some very simple ordering - for example based on agiven ordering of the rst-level domain components (.jp, .us .uk, .edu .. etc.). However,this is very inadequate - particularly when one considers the diculty of associating any
preference based on the next level (.ac, .co .or, .ad .. etc.) or levels below.
In its simpli ed form a SmartArchie client works by using the actual information onnumber of hops and the RTT for the various candidates. In the absence of such information - the client itself may collect the information using some simple network query tools e.g. ping, traceroute. The results are cached in a local database- to improve performance.
The list of servers returned by the Archie server is sorted based on this cost.
A SmartArchie server would use information from the Directory in the same manneras the SoftPages client does to sort the potential servers depending on the cost as seenby the client/user.

Conclusion
FTP trac, one of the largest consumers of network bandwidth, is taken as a casestudy to investigate how e ectively network con guration information can be used. A
workable and scalable mechanism is shown using which a user or an application canevaluate the cost factor corresponding to several ftp-servers. By choosing the serverwith the lowest cost factor, network cost of the retreival is optimized. Cost could pertain
to response time, tari , or any other parameter. A network model based on which thecomparative costs of several servers in a network can actually be calculated is shown. Twoexperimental implementations of the idea are discussed to demonstrate the e ectivenessand practicality of the the proposal. The concept can be pro tably employed in several
other application which utilize ftp mechanisms e.g. World Wide File Server [121].

5章
MIBs for Network Service Applications
第5.1 Introduction
The rapid and widespread use of computer networking has highlighted the importanceof research and development in the area of network management. In the presently accepted framework of network management, network elements [ hosts, routers, bridges, ...]
[107] are monitored and controlled through access to their management information, by
Network management stations. The management information is viewed as a collection ofmanaged objects [MO] and is termed as the Management Information Base.
For the SNMP suite of Protocols, MOs are de ned using a subset of ASN.1, which inturn is de ned in RFC 1155. The de nition of MIBs is an ongoing process. MIBs are to
be developed and de ned as and when the requirement arises, while existing MIBs may
be re ned in accordance with the extensibility mechanisms de ned in the SMI.
To date, network management systems have focussed on the lower three layers [ Interface, IP, Transport] of the Internet suite of Protocolsa. The standard MIB-II covers theselayers well. Further, more speci c MIBs have been developed for particular protocols ineach of these layers. However, with the maturation of network management systems , theneed for managing network applications is increasing. The development in this area has
become more interesting with the fact that there are a host of OSI applications [ X.400,
X.500, ..] running over the TCP/IP stack. As a result, the application management
protocols will need to address both OSI and Internet applications.

5.2 Modelling Network Service Applications.
Unlike the lower layers where there is a very speci c though complex, functionality,
the application layer covers a very broad and general eld of system-independent cooperation. The services required by the applications are very diverse. While some of these
services are speci c to the application others are used by diverse applications. It would
be poor policy to approach the MIB development of a particular application without
attempting to modularize the application into generic and speci c parts. Thus, it is281

1993 年度 WIDE 報告書

282

intended that the application monitoring MIB be designed based on a model wherein
the several generic submodules have been identi ed and corresponding MIBs developed.
The speci c submodules will be identi ed and developed as and when the necessity arises.

 Application process:

Carries out the information processing for a particular application task. It is invokedeither by a local user/program request, or by the initiating activity of a remoteapplication requiring its cooperation. The Application process may be considered
to be composed of two parts- the application agent and the application entity.
The Application agent interfaces to the user and to the operating system of theend system on which it is mounted. The application entity performs the system
independent part of the application activities.

 The Connection oriented model:

Most network applications establish a connection with a peer application, carry out
some activity , close the connection. In this simple model it is clear that the part
dealing with the opening and closing of connections is common to applications while
the part dealing with the activity will be application speci c and will have minimalcommonality with other appplications.

Ofcourse, it is clear that there will be applications which function in the connection-lessfashion.

5.3 The Network Service Application MIB development
5.3.1

Why a Network Services Monitoring MIB ?

A substantial amount of work has been carried out in managing the communication
infrastructure - the lines nodes and the communication protocol entities. With the basic management framework reasonably well established and with the growing spread of
network applications like mail, news, DNS, Directory Services, ... , the time is ripe totake up the issue of managing network service applications[NSA]. NSAs include all applications that provide network services. The necessity of managing Network Service
Applications[NSA] is particularly critical for NSAs which have (widely) distributed components such as the Mail and Directory Services.
5.3.2

The Network Management Framework

Though the target applications that we will be considering could be from the Internet
suite of Protocols or from the OSI suite of protocols [or from any other suite of protocols

第 8部

ネットワーク管理

283

for that matter], we adopt the SNMP [Simple Network Management Protocol] network
management framework which is perhaps the most widely and successfully deployed, todate.
Also, as will be clear in the latter part of this document we have attempted to adhere,
as far as possible, to the principle of simplicity that is the underlying principle of SNMP.
The SNMP Network Management framework is laid out in the three documents-

 STD 16/ RFC 1155 [122] de nes the generic structure of network management information

 STD 15/ RFC 1157 [123] de nes the protocol for accessing network management
information

 STD 17/ RFC 1213 [103] de nes the primary set of managed objects.
The framework is adaptable/extensible by de ning newer MIBs to suit the requirementsof speci c applications/protocols/devices/situations.
5.3.3

Scope of Management

The realm of NSA management is vast and there are several "requirements" that need
to be met. However, in this document we have attempted to keep things simple andhave focussed on the rudimentary aspects only. The primary goal is a simple, useful,
and widely implementable scheme for NSA management which integrates nicely withthe existing network management framework. The proposed NSA management centersaround general monitoring to detect a broad range of operational problems: broken connectivity, system failure,congestion, ..

 to monitor performance and utilization
Admittedly, the capability to manage (monitor and control) the con guration of NSAs
 manage (monitor and control) the status of individual entries in the NSA queues.
 manage (monitor and control) the progress of a speci c activity (e.g. locate and if
necessary expedite a speci c mail message)

 control the NSA operation - cause some action be performed (e.g. force an immediateconnection and transfer of pending messages to some speci c system).

 etc.

1993 年度 WIDE 報告書

284

is impressive, useful and desirable from a NSA management system. But, these capabilities would require provisions for strict security checks, mandate a much more complex
design, give rise to contentious alternatives between generic and implementation-speci capproaches. Since such features are likely to be dicult to implement, we have opted fora simpler design that focusses on the basic monitoring aspects.
5.3.4

Relationship to Directory Services

The Directory Services [112] provide an excellent framework whence information canbe retrieved for applications and management purposes. Already some NSAs [e.g. mail]are tied to the Directory Services. On some systems the Directory Services is being used
to provide a dynamic mapping between application-name and the application-context.
It is clear that placing static information in the directory and using it for management
purposes will be advantageous as the richness of the directory information framework
will not have to be duplicated in the MIB. [Static information is that which has a meantime of change of the order of days or longer.]
The emphasis in this work is on the dynamic component of the NSA related informationthat needs to be represented in the MIB.
To exploit the bene ts of the Directory services, it is recommended that, whereverapplicable, a linkage be established between the Directory component and the MIB component of management information. The following linkages may be considered: The MIB ! Directory linkage: de ne a Managed Object [MO] that contains the

Directory Name of the corresponding application entity. Management applications
capable of performing directory queries will thus be able to supplement the dynamic
information in the MIB with static information from the Directory by referring to
the linkage MO. It is intended that this will be the normal case.

 Directory ! MIB linkage: The Directory will contain a reference to the SNMP

agent which is servicing the MIB of the application entity of interest. This willallow an SNMP capable directory query agent to probe dynamic characteristics ofthe application entity.

 This approach could be extended further by modelling SNMP MOs as attributes of
directory entries. This would dramatically simplify the design of directory service
agents.

5.3.5

The MIB Model for NSA management

A NSA-manager may wish to monitor several aspects of an operational NSA. He/she
may want to know the process related aspects- the CPU, memory, .. utilization of the第 8部

ネットワーク管理

285

operational NSA; the general network service related aspects - operational status, associations, ... and nally the NSA-speci c information - its operations and performance.
The MIB proposed in this section covers only the general network service related aspects. It focusses on the NSA description, the operations and activity indications, theassociations and association related details. The relationship of this MIB with the other
MIBs is shown in the following gure.

Host Resources MIB
Specific Mib for NSA
Generic NSA MIB
Other Mibs
[MIB-II, ... ]Relationship of MIBs

The manager (application) of a NSA will use the Host Resources MIB [104] to obtain process related information [ resource usage,..]. The proposed generic NSA MIB
provides the information for the generic objects. The NSA speci c objects are de nedin the corresponding MIBs. For management information pertaining to the lower layer
TCP/UDP/IP/... the MIB-II o ers the repertoire of MOs.
There are NSAs to which some components of the the proposed generic MIB do not
apply e.g. "connectionless" NSAs like DNS[95], NFS[124] do not use associations. MIBs
for such NSAs for such applications may be developed independently of the generic MIB
proposed in this work e.g. DNS- MIB [125][126] though the other components of thegeneric NSA MIB could still be used pro tably for managing such NSAs.
5.3.6

NSA Managed Objects

The APPLICATION-MIB focusses on the NSA description, the operations and activity
indications, the associations and association related details.
A table is de ned which will have one row for each NSA running on the system. Oneof the columns is applName which is the Directory name of the NSA. This will be used
to extract static information from the Directory. The table is indexed by an integer key
applIndex which will also be used by the NSA-speci c MIBs for reference purposes.

1993 年度 WIDE 報告書286

表 5.1: MOs for Network Service Application Management
MO

Parentapplication

mib-2.27

applConformance
applGroups
applCompliances
applTCPProtoID
applUDPProtoID

application.3
applConformance.1
applConformance.2
application.4
application.5

applTable
applEntry
applIndex
applName
applDirectoryName
applVersion
applUptime
applOperStatusapplLastChange
applInboundAssociations
applOutboundAssociations
applAccumulatedInboundAssociations
applAccumulatedOutboundAssociations
applLastInboundActivity
applLastOutboundActivity
applRejectedInboundAssociations
applFailedOutboundAssociations
assocTable
assocEntry
assocIndex
assocRemoteApplication
assocApplicationProtocol
assocApplicationType
assocDuration

application.1
applTable.1
applEntry.1
applEntry.2
applEntry.3
applEntry.4
applEntry.5
applEntry.6
applEntry.7
applEntry.8
applEntry.9
applEntry.10
applEntry.11
applEntry.12
applEntry.13
applEntry.14
applEntry.15
application.2
assocTable.1
assocEntry.1
assocEntry.2
assocEntry.3
assocEntry.4
assocEntry.5

applGroup
assocGroup

applGroups.1
applGroups.2

applComplianceassocCompliance

applCompliances.1
applCompliances.2

Type

Aggregate
Aggregate
INTEGER
DisplayString
DistinguishedName
DisplayString
TimeStamp
INTEGERTimeStamp
Gauge32
Gauge32
Counter32
Counter32
TimeStamp
TimeStamp
Counter32
Counter32
Aggregate
Aggregate
INTEGER
DisplayString
ObjectID
INTEGERTimeStamp

第 8部
5.3.7

ネットワーク管理

287

MIB Model for DSA Management

A DSA-manager may wish to monitor several aspects of the operational DSA. He/she
may want to know the process related aspects-the resource utilization of the operational DSA; the network service related aspects e.g., inbound-associations, outboundassociations, operational status, and nally the information speci c to the DSA application - its operations and performance.
The MIB de ned in this part covers the portion which is speci c to the DSA-application.
The network service related part of the MIB, and the host-resources related part of the
MIB, as well other parts of interest to a Manager monitoring the DSA-application, arecovered in separate documents [105][104].
5.3.8

The DSA functions and operations

The Directory System Agent [DSA], a component of the OSI-Directory [112][127], isan application process. It provides access to the Directory Information Base [DIB] to
Directory User Agents [DUA] and/or other DSAs. Functionally , a User [DUA] and the
Directory are bound together for a period of time at an access point to the Directory[DSA]. A DSA may use information stored in its local database or interact with (chain
the request to) other DSAs to service requirements. Alternatively, a DSA may return areference to another DSA.
The local database of a DSA consists of the part of the DIT that is mastered by the
DSA, the part of the DIT for which it keeps slave copies and cached information that isgathered during the operation of the DSA.
The speci c operations carried out by the DSA are: Read, Compare, AddEntry, ModifyEntry, ModifyRDN, RemoveEntry, List, Search. There is also the special operation
Abandon. In response to requests results and/or errors are returned by the DSA.
5.3.9

X.500 Directory Monitoring MIB design

The basic principle has been to keep the MIB as simple as possible. The Managed
objects included in the MIB are divided into three tables - dsaOpsTable, dsaEntryTableand dsaIntTable.

 The dsaOpsTable provides summary statistics on the accesses, operations and errors.
 The dsaEntriesTable provides summary statistics on the entries held by the DSA
and on cache performance.

 The dsaIntTable provides some useful information on the interaction of the monitored DSA with peer DSAs.

288

1993 年度 WIDE 報告書

There are references to the Directory itself for static information pertaining to the DSA.
These references are in the form of "Directory Distinguished Name" [128] of the corresponding object. It is intended that DSA management applications will use thesereferences to obtain further related information on the objects of interest.

第 8部

ネットワーク管理

表 5.2: MOs for Directory Management
MO

ParentType

dsaMIB

mib-2.29

dsaConformancedsaMIB.4

dsaGroups

dsaConformance.1

dsaCompliances

dsaConformance.2

dsaOpsTable

dsaMIB.1

Aggregate

dsaOpsEntry

dsaOpsTable.1

AggregatedsaAnonymousBinds

dsaOpsEntry.1

Counter32

dsaUnauthBinds

dsaOpsEntry.2

Counter32

dsaSimpleAuthBinds

dsaOpsEntry.3

Counter32

dsaStrongAuthBinds

dsaOpsEntry.4

Counter32

dsaBindSecurityErrors

dsaOpsEntry.5

Counter32

dsaInOps

dsaOpsEntry.6

Counter32

dsaReadOps

dsaOpsEntry.7

Counter32

dsaCompareOps

dsaOpsEntry.8

Counter32

dsaAddEntryOps

dsaOpsEntry.9

Counter32

dsaRemoveEntryOps

dsaOpsEntry.10

Counter32

dsaModifyEntryOps

dsaOpsEntry.11

Counter32

dsaModifyRDNOps

dsaOpsEntry.12

Counter32

dsaListOps

dsaOpsEntry.13

Counter32

dsaSearchOps

dsaOpsEntry.14

Counter32

dsaOneLevelSearchOps

dsaOpsEntry.15

Counter32

dsaWholeTreeSearchOps

dsaOpsEntry.16

Counter32

dsaReferrals

dsaOpsEntry.17

Counter32

dsaChainings

dsaOpsEntry.18

Counter32

dsaSecurityErrors

dsaOpsEntry.19

Counter32

dsaErrors

dsaOpsEntry.20

Counter32

dsaEntriesTable

dsaMIB.2

Aggregate

dsaEntriesEntry

dsaEntriesTable.1

Aggregate

dsaMasterEntries

dsaEntriesEntry.1

Gauge32

dsaCopyEntries

dsaEntriesEntry.2

Gauge32

dsaCacheEntries

dsaEntriesEntry.3

Gauge32

dsaCacheHits

dsaEntriesEntry.4

Counter32

dsaSlaveHits

dsaEntriesEntry.5

Counter32

dsaIntTable

dsaMIB.3

Aggregate

dsaIntEntry

dsaIntTable.1

Aggregate

dsaIntIndex

dsaIntEntry.1

INTEGERdsaNamedsaIntEntry.2

DistinguishedName

dsaTimeOfCreation

dsaIntEntry.3

TimeStamp

dsaTimeOfLastAttemptdsaIntEntry.4

TimeStamp

dsaTimeOfLastSuccessdsaIntEntry.5

TimeStamp

dsaFailuresSinceLastSuccessdsaIntEntry.6

Counter32

dsaFailuresdsaIntEntry.7

Counter32

dsaSuccesses

dsaIntEntry.8

Counter32

dsaOpsGroup

dsaGroups.1

dsaEntryGroup

dsaGroups.2

dsaIntGroup

dsaGroups.3

dsaOpsCompliancedsaCompliances.1

dsaEntryCompliancedsaCompliances.2

dsaIntCompliancedsaCompliances.3

289

6章
NIC 情報のディレクト リ化
第6.1 はじめにこれまで、ネットワークに関する情報をディレクトリに格納し 、各管理システムがディレクトリにアクセスすることにより必要な情報を得て、ネットワーク管理を実現する環境を提案してきた。
現実には、ネットワークに関する情報を保持するディレクトリは、まだ存在しないので、初めにそれを構築しなければならない。ところでネットワーク情報は、NIC(以後、国や地域のネットワークインフォメーションセンターを指す) と呼ばれる機関が管理している。
本稿では、日本の管理機関である JPNIC(Japan Network Information Center) と、ア
ジア太平洋地域のために設立準備されている APNIC(Asia Paci c Network Information
Center) の登録情報をディレクトリ化するまでの過程と問題点を述べる。
また、ディレクトリへの登録データを利用した応用システムも紹介する。

6.2 NIC 情報の現状
JPNIC の管理している情報や提供するサービスについては 、例えば [129] から連載で紹介されている。一般組織向けの管理情報として、参加組織について以下の項目がある。
(詳細は、[130] を参照されたい) ド メイン情報 (ド メイン名, 組織名, 使用 IP ネットワーク, 管理者)
 ネットワーク情報 (IP アドレス, ネットワーク省略名, 管理者)
 ホスト情報 (ネームサーバホスト名,IP アドレス)
 個人情報 (住所, 氏名, 電話番号, メール宛先, 所属組織/部局)
このほかに、プロジェクト情報 (ネットワークプロジェクト )/NOC 情報 (ネットワーク
運用センター)/コミュニティ情報 ( メーリングリスト ) がある。
APNIC の管理する情報は、以下の二つである。

290

第 8部

ネットワーク管理291

 ネットワーク情報 (IP アドレス, ネットワーク名, 管理者)
 個人情報 (住所, 氏名, 電話番号, メール宛先)
これらの情報は、mail や whois といったツールによって参照できる。しかし 、個別管理のために以下の問題が発生する。

 各 NIC によって、提供形式が異なっている。(項目, 言語, 表記)
 検索時、関係しそうなホストを全て個別にアクセスする必要がある。
 会社/部門/個人が、階層的に提供されない。

6.3 ディレクト リの利点
ディレクトリでは、実世界の対象毎に対応する情報を集め、管理の単位 (エントリ) としている。ディレクトリ全体 (Directory Information Base) は、このエントリをツリー構
造 (Directory Information Tree) に沿って整理・格納したものである。
また、情報提供を受ける利用者側とディレクトリとのプロトコルは DAP(Directory Access Protocol) 、ディレクトリ内部でのプロトコルは DSP(Directory System Protocol) 、という形で規定されている ([112])。このディレクトリの以下の特性によって、前記の問題を解決できる。

 どの情報格納システムにアクセスした結果であっても、一定の形式で情報を取得できる。

 ツリー構造により、全体のデータ構造を知らなくても、希望するデータにアクセスできる。

 別名や複数の属性値により、言語や表現の違いを吸収する仕組みがある。
つまり、図 6.1に示すように、現在の NIC 情報ユーザ利用者は、情報がありそうな NIC
全てにアクセスしなければならないが、ディレクトリ利用者は、ひとつのアクセス方法を知っているだけでよい。

1993 年度 WIDE 報告書

292

JPNIC
WHOIS
mail

DB

APNIC

mail
finger

X.500

ディレクトリを直接利用できる場合

ディレクトリ利用環境

NIC環境

図 6.1: NIC とディレクトリ環境の比較

6.4 ディレクト リへの登録

登録のためのディレクトリ・ソフトウェアは、現在よく普及している ISODE の QUIPU[131](DUA(Directory User Agent) は、dish) を使用した。手順は、以下の通りである。

1. デ ィレクトリ・エントリの構造 (オブジェクトクラス, 階層, 属性など ) を決定する。
2. NIC 情報の各項目 (会社/部門/個人など ) を関連付け、上記の構造に合致させる。
3. dish を用いて、エントリを add する。
ここで、今回登録したオブジェクトと NIC 情報 (登録フォームのレコード ) の対応関係を図 6.2〜図 6.6に示す。(図中、[] で括られた部分が NIC 情報から得られる属性値である。)
QUIPU で標準的に用意されていないオブジェクト (ipNetworkObject など ) については、[98]・[99] の定義を利用した。

第 8部

ネットワーク管理

objectclass= organization & domainRelatedObject & quipuNonLeafObject@c=(エントリ位置)o=[Organization]
description=[Description]
postalCode=[郵便番号]
postalAddress=[Address]
telephoneNumber=(関連する個人情報の電話番号)
facsimileTelephoneNumber=(関連する個人情報の FAX 番号)
associatedDomain=[ド メイン名]
masterDSA=(登録する DUA 名)

図 6.2: 組織情報objectclass= organizationalUnit & quipuNonLeafObject@c=(エントリ位置)ou=(個人情報の [Division])masterDSA=(登録する DUA 名)

図 6.3: 組織の部局情報

objectClass= top & quipuObject & quipuNonLeafObject &CommunicationObject & ImageCommunicationObject &networkImage & ipNetworkImage@c=(エントリ位置)
IPnw=[ワークアドレス省略名]
ipNwNumber=[IP ネットワークアドレス]
adminContact=[運用責任者]
technContact=[技術連絡担当者]
description=[Description]
IpNwMask=(ネットワークマスク)
associatedDomain=(関連付けた情報)
masterDSA=

図 6.4: ネットワーク情報

293

294

1993 年度 WIDE 報告書

objectClass= top & person & pilotObject & newPilotPerson& quipuObject& pilotPerson@c=(エントリ位置)cn=[First, Last]
sn=[Last]
postalCode=[郵便番号]
postalAddress=[Address]
telephoneNumber=[電話番号]
facsimileTelephoneNumber=[FAX 番号]mail=[電子メイル]
whoisIdent=[NIC ハンドル ]図 6.5: 個人情報

objectClass= top & domain & quipuObject & quipuNonLeafObject@c=(エントリ位置)dc=(JP の直前のド メイン )o=(ド メイン名の xx.JP を除いた部分)
postalAddress=[Address]postalCode=[郵便番号]
description=[Description]
associatedName=[Organization]
masterDSA=

図 6.6: ド メイン情報

第 8部

6.5 登録における問題

ネットワーク管理295

上記の手順において以下の問題点があり、データ形式変換などの処理を必要とした。

1. NIC 情報の形式と dish のスキーマとの不一致の修正

 住所を郵便 O/R アドレス (30 文字 6 行) の形式に変換する。
 '#' や'&' など 、属性値スキーマに一致しない文字を変換する。
2. 所望するモデルのための名前付けの工夫

 ipNetworkImage。JPNIC 情報では、ひとつのネットワーク省略名に複数の使用
IP ネットワークが対応しているので、ネットワーク省略名だけでは同一エントリ位置になる場合がある。
今回は、'IP ネットワークアドレス%ネットワーク省略名' とした。

 同姓同名の区別。特に、APNIC 情報からは組織名を機械的に取得できないので、姓名だけでは同一エントリ位置になる場合がある。
今回は、同姓同名の場合、' 姓名%NIC ハンドル名' とした。

6.6 データの実際
以上のように登録したエントリの dish による表示画面を図 6.7〜図 6.10に示す。([113])
JPNIC 情報は、図 6.7の organizationName=Japan Network Information Center
APNIC 情報は、organizationName=Asia Paci c Network Information Center の位置にそれぞれ格納されている。特に JPNIC 情報では、組織名の下に部局名が、その下に個人名が登録され、階層構造が正しく構築されているのがわかる。

1993 年度 WIDE 報告書

296

Dish -> squid
Connected to rhea at '0101'H/Internet=150.80.254.2+17003
Current position: @c=JP
User name: @Current sequence: default
Dish -> list
1 pss.4000000.1.2="A"6organizationName=AIC Systems Laboratories

8

organizationName=Asia Pacific Network Information Center

16

organizationName=Japan Network Information Center

28

organizationName=WIDE

図 6.7: エントリ位置:@c=JP

Connected to rhea at '0101'H/Internet=150.80.254.2+17003
Current position: @c=JP@o=Japan Network Information Center@l=Registered Organizations
User name: @Current sequence: default
Dish -> list
57 organizationName=3Com K.K.
77 organizationName=Advanced Integration Technology, Inc., Japan
79 organizationName=Advanced Intelligent Communication Systems
Laboratory, LTD.
80 organizationName=Advanced Materials Lab., Inc
81 organizationName=Advanced Mobile Systems, Inc.
82 organizationName=Advanced Software Institute

図 6.8: エントリ位置:@c=JP@o=Japan Network Information Center @l=Registered Or-

ganizations

第 8部

ネットワーク管理

297

Dish -> squid
Connected to rhea at '0101'H/Internet=150.80.254.2+17003
Current position: @c=JP@o=Japan Network Information
Center@l=Registered Organizations@o=Advanced Intelligent Communication
Systems Laboratory, LTD.
User name: @Current sequence: default
Dish -> list
111 ipNetworkImageName=AIC-NET1
112 organizationalUnitName=Intelligent Network Management Division

図 6.9: エントリ位置:@c=JP@o=Japan Network Information Center@l=Registered Or-

ganizations@o=Advanced Intelligent Communication Systems Laboratory, LTD.

298

1993 年度 WIDE 報告書

Dish -> squid
Connected to rhea at '0101'H/Internet=150.80.254.2+17003
Current position: @c=JP@o=Asia Pacific Network Information Center@l=Registered Persons
User name: @Current sequence: default
Dish -> list
120 commonName=Adam Kaye-Smith
121 commonName=Adam Olmstead
122 commonName=Adi Indrayanto
123 commonName=Adrian Corston
124 commonName=Adrian Ward
125 whoisIdent=(undefined)%surname=Harianto%commonName=Agus Harianto
126 whoisIdent=AH107%surname=Harianto%commonName=Agus Harianto
127 whoisIdent=AH11%surname=Harianto%commonName=Agus Harianto
128 commonName=Akane Shindo
129 commonName=Akinori Saitoh
130 commonName=Akio Ichikawa
131 commonName=Akira Fujii
132 commonName=Akira Kato
133 commonName=Akira Nagamine
134 commonName=Akira Okihana
135 commonName=Akira Tomoyoshi
136 commonName=Akiro Kosakada
137 commonName=Alan Brooks
138 commonName=Alan Brown
139 commonName=Alan Hogan
140 commonName=Alan Ramadan
141 commonName=Alan Roberts

図
6.10:
エントリ位置:@c=JP@o=Asia Paci c Network Information Center@l=Registered Per-

sons

第 8部

6.7 まとめと今後の課題

ネットワーク管理

299

NIC 情報を機械的にディレクトリに登録する方法を述べた。このディレクトリを利用した現在稼働中の情報検索システムを示す。このシステムでは、mail や nger のデーモンを修正し 、

x500-query@wnoc-snd-ss2.wide.ad.jp に mail を送信するか (本文を nd key とする) 、または、

nger key@wnoc-snd-ss2.wide.ad.jp を実行することによって、従来の whois では行なえなかった電話/ファクス番号による検索も可能にしている。(図 6.11・図 6.12参照)
今後の課題を以下に示す。

 情報源 (NIC) の更新をディレクトリにも反映するツールの開発。
 マルチ言語 (今回は、JPNIC 情報の日本語部分は欠落している。) やディレクトリの
国際化への対応。

 NIC にない情報のディレクトリへの登録とその応用システムの開発。

1993 年度 WIDE 報告書

300

Received: by wnoc-snd-ss2.wide.ad.jp (5.65+1.5W/2.7W)
id AA00697; Tue, 10 May 94 19:43:27 JST
Date: Tue, 10 May 94 19:43:27 JST
Return-Path: <daemon@wnoc-snd-ss2.wide.ad.jp>
Message-Id: <9405101043.AA00697@wnoc-snd-ss2.wide.ad.jp>
From: "X.500 Query Program" <X500-Query@wnoc-snd-ss2.wide.ad.jp>
Subject: Re:
In-Reply-To: Your message of "Tue, 10 May 1994 19:44:22 +0900"<9405101044.AA01028@XXXXXX.aic.co.jp>
To: Ouchi Masatomo <oouchi@XXXXXX.aic.co.jp>
2 phone number matches were found for '279-3310':"Advanced Intelligent Communication Systems Laboratory
Glenn MansfieldDr.

図 6.11: x500-query@wnoc-snd-ss2.wide.ad.jp からのリプライ

XXXXXX.oouchi 31: finger 279-3310@wnoc-snd-ss2.wide.ad.jp[wnoc-snd-ss2.wide.ad.jp]
X.500 Finger Service...
2 phone number matches for "279-3310":
Name
Whois ID e-mail============ ======"Advanced Intelligent Communication Systems Laboratory
Glenn Mansfield
glenn@aic.co.jp

図 6.12:nger 279-3310@wnoc-snd-ss2.wide.ad.jp の実行画面