IAA System ("I Am Alive"): The Experiences of the Internet Disaster Drills

Nobuhiko TADA <tada@pana.net>
Matsushita Electric Industrial Co., Ltd.
Japan

Yukimitsu IZAWA <izawa@jaist.ac.jp>
Japan Advanced Institute of Science and Technology
Japan

Masahiko KIMOTO <kimoto@ohnolab.org>
Tokyo Institute of Technology
Japan

Taro MARUYAMA <taromaru@runetech.co.jp>
RuneTech Co., Ltd.
Japan

Hiroyuki OHNO <hohno@ohnolab.org>
Ministry of Posts and Telecommunications
Japan

Masaya NAKAYAMA <nakayama@nc.u-tokyo.ac.jp>
University of Tokyo
Japan

Abstract

Kobe, Japan, experienced an enormous earthquake on 17 January 1995, named the Hanshin-Awaji Earthquake. At that time, "lifeline" public services such as gas, electricity, and water service stopped. Many people outside of the afflicted area were anxious to know if their family and friends were safe, and so many telephone calls were made to the afflicted area that the the local telephone system was paralyzed. From this experience, we learned that the Internet stayed alive because of its robustness even in disasters. It became clear that the information system on the Internet should be prepared for burst access.

In the spring of 1995, the WIDE project organized the "lifeline working group" to study the feasibility and technology of using the Internet as a "lifeline," and began to develop a system for registration of information on persons' safety in afflicted areas and for reaching these people via various stable interfaces.

This system is called "IAA," which stands for "I Am Alive."

We also conducted "the Internet Disaster Drill" for evaluating the system on the assumption that the Internet users are disaster victims. The first drill was held on 17-18 January 1996, and the results were reported in INET'96. Since then, we have held the Internet Disaster Drill in coordination with other organizations around the 17th of January every year. In January 2000, we conducted the Fifth Internet Disaster Drill.

Our IAA system has been improved, and new architectures and new user interfaces have been developed and tested in the drills. Various user interfaces for accessing to this system are available. These include Web, fax, telephone, mobile phone and an original client application. From the experiences of the drills, it is rather stable in operation.

In this paper, we give an overview of the IAA system and also report on the drills, the results, and the current status of the system. We also discuss key issues of this system as well as future work.

Contents

1. Introduction

The Internet has grown up, and now many people get access to the Internet and communicate with each other. Consequently it has become a ubiquitous information infrastructure. The Internet is focused on such capabilities as global connectivity, broadcast/multicast capability, and information storage media. Therefore, the Internet is expected to fulfill critical functions in a disaster.

In an actual disaster, certain vital information will be necessary:

These types of information are very important for trapped people. In this sense, such information is considered to be a lifeline in the same way as gas, electricity, and water service. During disaster, unexpected communication traffic may be generated and concentrated on specific application servers that provide vital information. Consequently, applications or networks will require special functions: scalability, load distribution, fault tolerance, etc.

Currently, a web server is used as a tool for advertising information to the Internet. This allows the information to be accessed from all over the world. However, from the viewpoint of robustness, if the server is down, that service will not be available. Various products with a load balance function are already available, such as Cisco Distributed Director [1] and 3DNS [2]; and techniques such as NAT [3, 4] and a round-robin function of DNS [5] have been implemented. Though these products and techniques are working fine, to make use of the Internet as a lifeline, the Internet should also have the capability of fault tolerance on exchanging data over it. Such mechanism for supporting applications will be required especially in a disaster.

In Spring 1995, just after the Hanshin-Awaji earthquake, the WIDE Project [6] organized the "Lifeline Working Group" [7] to study the feasibility and technology for using the Internet as a lifeline. To provide the required applications in a disaster, we focused on safety information, and started to develop a system for confirming people's safety. This is because the enormous number of queries about the safety of family or friends overloaded the telephone system during the Hanshin-Awaji earthquake. This system provides registration and query functions of people's safety information in afflicted areas via various interfaces.

We call this system "IAA", which means "I am alive!"

Using the IAA system, we conducted the "Internet Disaster Drill" on the assumption that the Internet users were afflicted to find out the key issues in using the Internet as a lifeline and to evaluate the system itself. The first drill was held on 17-18 January 1996, one year after the Hanshin-Awaji earthquake. The results were reported in INET'96 [8]. Since then, every year around January 17 we have held the Internet Disaster Drill in coordination with other organizations. In January 2000, we conducted the Fifth Internet Disaster Drill.

This paper gives an overview of the IAA system and describes the evolution of this system through the drills. It also reports on the current status of the system and discusses key issues and future works.

The rest of this paper is organized as follows. Section 2 gives an overview of the IAA system as well as its design and implementation. Then, the details and results of the Internet disaster drills are given in Section 3. Section 4 presents issues involved in the current IAA system. Section 5 describes future works. Finally, we conclude the paper in Section 6 with a summary of the results.

2. Overview of the IAA system

2.1. Concept of the IAA system

The IAA system works as a database for handling people's safety information [9, 10]. This information is called IAA-data in the rest of this paper. As described above, the IAA system accumulates people's safety information and serves queries on them. IAA-data contains personal information. Therefore the IAA system requires the following functions:

2.2. Design and implementation of IAA system

2.2.1. Design of IAA system

The IAA system consists of more than one IAA cluster and IAA transport. The load distribution mechanism can avoid congestion by access to the specific server. Figure 1 illustrates the design of the IAA system. This model establishes its robustness by locating IAA clusters, which are geographically distributed.


Figure 1. Model of IAA System

An IAA cluster is composed of the following major parts: a registration processing part, a query processing part, a transport part, and a database part.

2.2.2. Implementation of IAA system

Here, we describe the actual implementation of the major parts.

2.2.3. LLDB Protocol

We developed a new protocol named LLDB, which uses TCP port 1190. It will enable the IAA system to be accessed via various user interfaces. Actually, TCP port 1190 is used for making both query and registration. The details of the LLDB protocol are described in the WWW server, http://www.iaa.wide.ad.jp/System/proto.html.

Figure 2 illustrates the total images of the IAA system.


Figure 2. Overview of IAA System

2.3. Design of IAA-DATA

Through many discussions and the feedback from the experiences of the past Internet disaster drills, we designed the database records in IAA-DB as shown in Table 1.

We distinguished every attribute from the following point of view: whether it is mandatory or optional in registration; whether it can be used as a query key in searching; and whether it is expressed in the query result, if matched. The "key word" attribute data is used for sharing information within an intimate community. It will not to be expressed even if the record is retrieved by query.

In case of registration for others, the data such as "Reporter Name,""Date of confirmation," and "Relationship" are required to increase the accuracy of IAA-data. In case of registration by the victim person, these data are completed automatically. Besides those data described in Table 1, IAA-data includes data such as an identifier, the registered time and client information. These data are added by the IAA system automatically.

Figure 3 shows a WWW interface for the registration by the victim person.

Table 1. Attributes of IAA data
Attributes Registration Query Key Query Result
Name (First, Family, Pronunciation) Mandatory Mandatory Expressed
Status, Report Place Mandatory - Expressed
 
Nicknames, Age, Sex, Blood Type Optional Can Use Expressed
Affiliation, Zip Code, Notes Optional - Expressed
Key Word Optional Can Use Not Expressed
 
Reporter Name, Date of confirmation, Relationship Mandatory - Expressed
How to confirm Option - Expressed


Figure 3. WWW Registration Interface

3. Internet disaster drills

We have conducted an Internet Disaster Drill around the 17th of January every year since 1996. This year, we held the Fifth Internet Disaster Drill. In this section, we summarize the past drills and describe the changes since the first drill.

3.1. Purpose of drills

The purposes of the Internet disaster drills are as follows:

3.2. Drill's scenario

Basically, we conducted drills according to the following scenario, though there were a few differences depending on the conditions at the time.

3.2.1. Drills via the Internet

On the assumption that Internet users had been afflicted by a disaster at their location, we had them perform the following operations:

3.2.2. Drills in public areas, in which we assumed that the specific area was struck by a disaster

When we can cooperate with other organizations in activities for disasters, we provide an IAA environment in public areas such as schools and parks as refuges. From such a site, the disaster victims can register or send queries.

3.3. Summary of drills

Here, we summarize the past drills especially focused on major topics in each drill, new user interfaces, and so on. Table 2 shows the participants and the date of the drills. Table 3 presents the locations of the IAA clusters in the drills.

Table 2. Number of Participants
Drills Date Registration Query
1st drill 17-18 January 1996 about 6,000
2nd drill 17 January 1997 about 2,000 about 10,000
3rd drill 17-18 January 1998 about 1,000 about 3,000
4th drill 17-18 January 1999 about 6,400 about 2,000
5th drill 16-17 January 2000 about 2,100 about 3,400

 

Table 3. Cluster Locations
Drills No. of Sites Sites
1st drill 4 JAIST, NAIST,WNOC-KYOTO, KEIO-SFC
2nd drill 5 TTC, WNOC-KYOTO, WNOC-HACHIOJI, NAIST, JAIST
3rd drill 3 JAIST, NAIST, U-TOKYO
4th drill 7 JAIST, NAIST, U-TOKYO, OKIX, NSPIXP3, SHIZUOKA-U, OTARU-SHOKA-U
5th drill 7 JAIST, NAIST, U-TOKYO, OKIX, NSPIXP3, SHIZUOKA-U, OTARU-SHOKA-U

3.3.1. First drill

In the first drill, we had two sub-drills. One was a backup of the WIDE backbone, which is managed by the WIDE project, for using a satellite link. The other was the IAA drill itself. In the IAA system, we provided MAIL and WWW(with Japanese menus) interfaces for registration and query, and the responses were returned via MAIL. The result of the first drill was both a success and a failure, as reported in INET'96 [8].

3.3.2. Second drill

Based on the results of the first drill, we prepared more PCs and WSs for processing normalization and parsing. We provided MAIL, WWW (with Japanese menus), telephone, and a group registration form as user interfaces. The drill was also conducted in Hibiya Park in cooperation with other organizations as a drill in public space.

The result was slightly worse than that of the first drill because we attempted many achievements as shown below:

Figure 4 shows the Internet-Car installed experimentally.


Figure 4. The IAA drill in Hibiya

3.3.3. Third drill

From the results of the first two drills, we gave up the n-version programming based on the idea that "smart work is the best." Instead, we implemented another user interface in cooperation with the "WIDE Telecommunication" (WT) working group. Working together, we have also improved the IAA system [16, 17].

We pursued the following refinements.

IAA drills were also conducted by other volunteer groups in the Niigata and Kobe areas. We also had a plan to hold the IAA drill in Akihabara Park, but we gave it up because of bad weather conditions. From the viewpoint of user interfaces, fax and an original IAA-client were added as new interfaces. The IAA-client was developed for windows users.

The system worked fine without any troubles during the period of the drill. We were totally satisfied with the results of this drill.

3.3.4. Fourth drill

We developed an IAA software package after the third drill. The package enables users to install the IAA system easily. As a result, we developed the IAA clusters as shown in Table 3. In this drill, we also developed a new interface for a bulk registration, which allowed registration of a number of IAA-data at a time. In this drill, we provided the following user interfaces: WWW (with Japanese menus), WWW (with English menus), fax, telephone, an original IAA-client, and bulk-registration.

As in the third drill, volunteer groups in Kobe and Akashi areas conducted the IAA drill in public spaces using our IAA system. And new local self-governing bodies in Okayama prefecture also joined us and conducted the IAA drill in the Okayama area.

3.3.5. Fifth drill

In the fifth drill, a personal mobile phone was added as a new user interface. The IAA cluster provided the registration and query menus, which were coded in Compact HTML. Registration and query are made from the personal mobile phone, which has the function to communicate via the Internet. So, WWW(with Japanese menus), WWW(with English menus), fax, telephone, and a personal mobile phone were provided as user interfaces to the IAA system. Unfortunately, in the fifth drill we did not provide the IAA client for Windows95/98/NT because of concern over the Y2K problem in the operating system.

As in the fourth drill, in cooperation with Okayama prefecture we conducted the IAA drill on the assumption that a specific area was afflicted. Figure 5 shows the person participating in the IAA drill in the Okayama area.


Figure 5. The IAA drill in Okayama

3.4. Lessons learned through drills

3.4.1. Daily operation

If a system for emergencies cannot be available on a consistent basis, people cannot use it. Therefore, the existence and use of such system should be familiar to all people, and the operators should be trained in its operation in the same manner as the system set up for emergency calls, 119 in Japan or 911 in the U.S. Our motto is that systems for emergencies should be routinely operated and accessible to the public. Therefore, we believe that it is very important to clarify the key issues through daily operation.

Therefore, in May 1998 after the third drill, we began experimental daily operation of the IAA system [18]. In the daily operation, we took precautions concerning the period of storing data, which is limited to seven days for privacy. As soon as we started the experimental daily operation, we encountered problems in the operation. While we conducted the Internet disaster drills, some operators were located next to the actual IAA cluster. However, in daily operation, we have to assume that operators are remote from the IAA clusters.

3.4.2. IAA drills in public space

We have conducted drills in public space since the second drill, and have recognized several difficulties. First, performance depends on the weather, and current computer systems have very weak resistance to dust; furthermore they need electrical power.

4. Issues of the IAA system

4.1. Management of daily operation

The daily operation of the IAA system shows us the necessity for an IAA management system. The IAA system is designed to consist of various parts, which are developed by developers located in different places; and the system itself is distributed geographically. So it is very difficult to judge whether it works adequately at a glance. Therefore, if any problems occur on the system, it takes a long time to find them and to troubleshoot them.

4.2. Internationalization of the IAA system

Disasters do not occur only in Japan or in the U.S. In addition, many foreigners live in Japan. Therefore, emergency systems should be internationalized; at least it is necessary for them to support major foreign languages.

Last summer, a big earthquake occurred in Turkey. Some volunteer groups asked us to use the IAA system, but at that time, we did not have enough capability to support an actual disaster. Sadly, we had to give up the idea of helping Turkey.

Taiwan also experienced a big earthquake. At that time, we coordinated with local Internet research groups but did not have enough time to discuss the installation of the IAA system. However, we prepared a page in English customized for Taiwanese people. Actually, we need to examine internationalization of the various interfaces that we already have.

4.3. Inter-connectivity with other systems

Five years have passed since the Hanshin-Awaji earthquake, and some other systems have made attempts similar to the IAA system. Interconnectivity among these systems would bring us a more robust system totally, although these systems have been managed by different policies from the IAA system.

For establishing interconnectivity with other systems, it is very important to standardize the protocol for exchanging data among them. As described above, even if the systems are similar, the policies might be different from each other. So, the necessity of describing the policy should be also taken into consideration.

5. Future work

5.1. Mobile IAA system kit

Thus far, we conducted the Internet disaster drills and made use of the IAA system from the point of view of query load distribution. To make queries, IAA-data have to be registered in advance. Therefore, the environment for registration on the IAA system has to be set up as soon as possible when a disaster occurrs. We will examine a kit for building a mini IAA cluster up, which should have a plug-and-play function and the mobility for saving the operation cost. We recognize that mobility will be another important factor in a struck area,

5.2. New application support layer

The IAA transport has been designed for the IAA system. The IAA system is capable of scalability and provides the functions of robustness and fault tolerance. Such functions will be generally required by other significant applications and will be necessary for the Internet to gain a role of lifeline. Therefore, we also continue to study the current IAA transport and to improve it, taking the use of multicast or satellite link. We will propose a more general framework for supporting applications [19].

5.3. Security and privacy

In the current IAA system, personal data are accumulated in the IAA-DB. For security, it is desirable to establish the same service without having to handle user information. We plan to study the use of a hash algorithm such as MD5 [20] for this purpose.

6. Conclusions

In this paper, we described the overview of the IAA system and summarized the Internet Disaster Drills which we have conducted for five years, and described the current status of the IAA system. Through the experiences of those drills, we identified several key issues.

After many changes made based on the feedbacks of the past drills, the IAA system has been improved and new user interfaces have been added. Currently, it provides pretty stable operation with many user interfaces such as WWW, telephone, fax, and mobile phone. We are also looking into the possibility of establishing a barrier-free environment.

Though the IAA system is designed for handling people's safety information, the architecture is capable of robustness and can be used as a basic framework for supporting significant applications. Naturally, we are continuing to study the feasibility of using Internet as a lifeline in cooperation with other organizations. We plan to propose a more general concept in implementing robust applications.

Acknowledgments

The authors would like to thank members of the WIDE project for their often hot arguments, as well as members of both the Lifeline and WT working group, especially those who actively participated in the development and operation of the IAA system.  They deserve to receive our sincere gratitude.

Finally, we would like to express our sincere gratitude to more than 30,000 people who volunteered to participate in the IAA drills.

References

[1] CISCO, "Distributed Director," available electronically at "http://www.cisco.com/warp/public/751/distdir/dd_wp.htm"

[2] F5, "3DNS," available electronically at "http://www.f5.com/3dns/index.html"

[3] K. Egevang and P. Francis, "The IP Network Address Translator (NAT)," RFC 1631, May 1994.

[4] Hiroyuki Inoue and Suguru Yamaguchi, "Implementation of Load Balancing of WWW Server using NAT," in Proceedings IPSJ-96-DPS-78, pages 19-24, Information Processing Society of Japan, May 1998.

[5] ISC, "ISC BIND," available electronically at "http://www.bind.org/"

[6] WIDE Project Page, available electronically at "http://www.wide.ad.jp/"

[7] Lifeline WG Page, available electronically at "http://www.wide.ad.jp/wg/lifeline/"

[8] Yoichi Shinoda, Tomomitsu Baba, Nobuhiko Tada, Akira Kato and Jun Murai, "Experiences from the 1st Internet Disaster Support Drill," in Proceedings of INET'96, June 1996.

[9] Nobuhiko TADA, "The Architecture of IAA System," in Proceedings IPSJ-98-DSM-9, pages 25-30, Information Processing Society of Japan, May 1998.

[10] WIDE Project IAA Page, available electronically at "http://www.iaa.wide.ad.jp/"

[11] Tomomitsu BABA and Suguru YAMAGUCHI, "A DNS Based Implementation on Widely Load Balancing Mechanism", in Proceedings IPSJ-98-DSM-9, pages 37-42, Information Processing Society of Japan, May 1998.

[12] Mark R. Horton. "Standard for Interchange of USENET Messages," RFC 850, May 1983.

[13] Yukimitsu Izawa. "A Technics of Reliable Data Transportation Using Netnews," in Proceedings IPSJ-98-DSM-9, pages 49--54, Information Processing Society of Japan, May 1998.

[14] Shuji Ishii and Susumu Sano. "Design and Implementation of Satellite based Multicast transpot mechanism," in Proceedings IPSJ-98-DSM-9, pages 43-48, Information Processing Society of Japan, May 1998.

[15] Yukimitsu Izawa, Shuji Ishii, Nobuhiko Tada and Masaya Nakayama. "Implementation and Evaluation of Widely Distributed Database System Using Satellite Based Multicast and NetNews System for the Transport Mechanism," in Proceedings of Internet Workshop'98 (IWS98), pages 75-83, IEICE and ETL March 1998.

[16] Kazuyoshi KOREEDA, Akio NODA, Hideki HONMA and Hiroyuki OHNO. "The User Interface for IAA System Using Telephones, Pagers and Facsimiles," in Proceedings IPSJ-98-DSM-9, pages 31-36, Information Processing Society of Japan, May 1998.

[17] Hideki Honma, Akio Noda and Hiroyuki Ohno. "An Alternative User Interface for the IAA System: Using OCR/OMR as on-ramp Gateway for the Internet," in Proceedings of IEICE Internet Workshop '98, March 1998.

[18] Nobuhiko Tada,Tomomitsu Baba, Yukimitsu Izawa, Taro Maruyama, Tomohide Tanaka and Masaya Nakayama. "IAA, a Information System about People's safety on the Internet and the Issues" (in Japanese), pages 41-50, in Proceedings of Internet Conference '98, December 1998.

[19] Yukimitsu Izawa, Shinsuke Miwa and Yoichi Shinoda. "A Design Issue of Data Transport Mechanism for the Loosely Coupled Widely Distributed System," In Proceedings IPSJ Symposium Series Vol.99, No.18, pages 67-72. Information Processing Society of Japan, December 1999.

[20] Ronald L. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.