Internet Engineering Task Force Hal Folts
INTERNET DRAFT National Communications System
Expires: December December 2002 Cory Beard
Univ. of Missouri-Kansas City
June 2002
Requirements for Emergency Telecommunication
Capabilities in the Internet
<draft-ietf-ieprep-requirements-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document outlines requirements that need to be met in IP-based
networks to enable and support communications for National
Security/Emergency Preparedness (NS/EP) operations. It provides a
basis from which an emergency telecommunications service can be
negotiated and provides a set of requirements that should be met for
acceptable emergency telecommunication capabilities for disaster
recovery operations. The focus here is on network requirements,
rather than requirements for particular applications. The
requirements are general, functional, and are intended to provide
wide latitude in implementation options for service providers.
Folts & Beard Expires - December 2002 [Page 1]
Internet-Draft Emergency Requirements June 2002
Table of Contents
1. Introduction...................................................2
1.1 Current PSTN Capabilities..................................4
1.2 Purpose and Scope of this Document.........................5
2. General Requirements...........................................6
2.2 Dependability..............................................6
2.3 Authorized Access..........................................7
2.4 Security Protection........................................7
2.5 Privacy....................................................8
3. Technical Requirements.........................................8
3.1 Identification of Emergency Traffic........................8
3.2 Signaling for Resource Requests............................8
3.3 Better Then Best Effort Service............................9
4. Special Requirements...........................................9
4.1 Application-Specific Support...............................9
4.2 Traffic Types.............................................11
5. Policy Decisions..............................................11
5.1 Emergency Service Activation..............................12
5.2 Restoration Procedures....................................12
5.3 Preemption................................................12
5.4 Cooperation Between Service Providers.....................12
6. Example Emergency Scenarios...................................13
6.1 Local recovery operations.................................13
6.2 Medical operations........................................13
6.3 Regional operations.......................................13
6.4 National operations.......................................14
7. Conclusions...................................................14
8. Security Considerations.......................................14
References.......................................................14
1. Introduction
Natural and man-made disasters can happen anywhere, anytime. These
include, for example, earthquakes, floods, airplane crashes, and
terrorist attacks. While some advance planning is possible for
expected disaster events, most disasters happen unexpectedly.
Readily available telecommunication capabilities are essential for
emergency recovery operations to quickly start saving lives and
restoring the community infrastructure. A number of
telecommunication facilities can be involved in disaster recovery
operations. These include local mobile radio, dedicated satellite
systems, transportable capabilities, and the public
telecommunications infrastructure. Some of these facilities need to
be deployed to the disaster site and very likely may not be
immediately available. The public telecommunication services,
however, are generally at hand except in the most remote areas. The
Folts & Beard Expires - December 2002 [Page 2]
Internet-Draft Emergency Requirements June 2002
publicly available capabilities include the traditional telephone
network and the Internet, which can both be accessed via wire line,
wireless, and various broadband facilities. Disaster recovery
operations can significantly benefit from a variety of modes for
interchange of critical information to organize and coordinate the
emergency activities. Emergency voice communications are supported
today by a preferential service through public telephone networks in
some countries. Now, however, an evolution is taking place in
traditional public telecommunication networks toward integrating
circuit-switched and packet-based technologies. This promises to
provide a rich menu of fully integrated capabilities for handling
voice, message, data, and video traffic to greatly enhance disaster
recovery operations.
Mostly voice traffic using either VoIP or conventional telephony is
used today for emergency communications over wireline and wireless
facilities. However, narrowband modes can also be effectively
applied, including instant messaging, email, and telemedicine
telemetry. In addition, wideband capabilities for video broadcast,
conferencing, and telemedicine will also greatly enhance emergency
recovery operations.
During serious disaster events, public networking facilities can
experience severe stress due to damaged infrastructure and heavy
traffic loads. As bandwidth gets severely constrained, it becomes
difficult to establish and maintain effective communication
sessions. It is essential that disaster recovery operations be able
to readily communicate to organize and coordinate essential
activities. Authorized emergency communication sessions need to have
immediate access to available network resources and be given a high
probability of successful completion of these critical
communications to help save lives and restore community
infrastructure.
Only people authorized by the appropriate authority are permitted to
establish emergency communication sessions through public networking
facilities for facilitating immediate disaster recovery operations.
Those typically authorized are local police, fire, and medical
personnel as well as designated government officials from local,
regional, and national levels who are responsible for various
aspects of disaster recovery operations.
All emergency communication sessions should be processed as normal
traffic along with all non-emergency traffic when sufficient network
bandwidth and resources are available. ONLY when networks reach
traffic saturation is there a need for giving emergency
communication sessions a higher probability of completion over non-
emergency communications. While this occurrence may never happen in
Folts & Beard Expires - December 2002 [Page 3]
Internet-Draft Emergency Requirements June 2002
the typical Internet-based environment, capabilities for
preferential handling of emergency traffic need to be established in
preparation for a serious catastrophe. These provisions should be in
place before a potential doomsday disaster, even for highly over-
provisioned networks. It is better to be prepared ahead of time and
not wait for the worst to happen first.
The telecommunication capabilities for handling authorized emergency
traffic should be accomplished using existing applications and
standards whenever possible. Establishment of new and different
standards would be both costly and unlikely to ever be implemented.
The desired approach is to adopt existing standards and where needed
adapt new standards with any necessary adjustments needed to support
preferential treatment of emergency traffic during severe periods of
congestion.
This document outlines requirements that need to be met in public
and private IP-based networks to enable communications for National
Security/Emergency Preparedness (NS/EP) operations. Recovery
activities can involve person-to-person communications, group
coordination, disaster assessment application execution, remote
information retrieval, continuity of government, etc.
From a network perspective, processing communications can be
particularly difficult even if the network infrastructure has not
been the target of a terrorist or affected by a natural disaster.
This is because there can be a drastic surge in the network load in
response to a disaster. In recent years the Public Switched
Telephone Network (PSTN) has experienced load levels three to five
times normal immediately after an event [1], and the same is
expected for the Internet, especially as IP telephony becomes more
prevalent.
1.1 Current PSTN Capabilities
As a starting point, the model to consider for emergency
communication services is the existing service capability in the
United States PSTN, the Government Emergency Telecommunications
Service (GETS). Some other countries have similar services.
The purpose of GETS is to increase the probability of completion of
a telephone call for authorized operations personnel in times of
emergencies. It does not guarantee that service will be available,
but it does implement a set of functions that increase the
likelihood of finding an available circuit to complete a call in the
PSTN.
The key aspects of GETS are as follows:
Folts & Beard Expires - December 2002 [Page 4]
Internet-Draft Emergency Requirements June 2002
o Personnel gain access to GETS by calling a specified telephone
number and presenting a credit-card type of authentication.
o Having authenticated themselves, the call is completed on a
preferential high probability of completion basis. If calls
are initially blocked, they can be queued and switched to
alternate carriers.
o If fundamental telephone services are compromised, services
contracted under GETS are restored first. This is under the
provisions of TSP (Telecommunication Service Priority [2]),
which is independent of GETS.
These features enhance the capability of NS/EP calls to be completed
with a high probability in congested networks. GETS will not
preempt public telephone calls, nor are there multiple levels of
precedence within GETS.
The approach of GETS is based on a preferential, high probability of
completion, treatment model. This model may also be used by
providers of Internet-based network services.
1.2 Purpose and Scope of this Document
The purpose of this document is to provide a basis from which
emergency service capabilities can be specified and negotiated
between network service providers and customers. It provides a set
of requirements that would need to be met for a service to
acceptably support emergency communications. The focus here is on
network requirements, rather than requirements for particular
applications. For particular requirements related to IP Telephony,
see [3].
More importantly, however, the requirements given here are quite
general and it is intended that wide latitude be available to
service providers to implement emergency services as they consider
appropriate. In [4], recommendations are provided as to how best to
implement these services, but in this document requirements are
stated so that service providers need not necessarily follow [4].
Section 2 provides general requirements that give high-level service
capabilities that should be provided. Section 3 then provides a
minimal set of specific technical requirements for meeting the
general requirements. Section 4 gives special considerations that
may optionally be addressed in an agreement for emergency services.
And finally, Section 5 provides a list of policy decisions that need
Folts & Beard Expires - December 2002 [Page 5]
Internet-Draft Emergency Requirements June 2002
to be made and explained to customers by a service provider, but no
specific requirements are given for policy issues.
2. General Requirements
This section outlines five requirements for services that aim to
provide emergency communications for the Internet-based
infrastructure (or any telecommunication medium for that manner).
They pertain to the ability to begin communications, complete
communications successfully, and conduct them in an authorized and
private manner.
2.1 Availability
The most fundamental requirement for emergency telecommunication
services is that emergency-related users must have a high likelihood
of network resources being available to them when they need them.
Authorized users must have a high probability of being able to
initiate and complete a communication session.
Two interpretations of the concept of "high availability" could be
applied, either in a relative sense or an absolute sense. Such
options on interpretation give latitude in implementation
possibilities for emergency services. The first interprets "high
availability" in a preferential or relative sense. Authorized users
would have preferred access to resources over normal users. A
service provider would implement mechanisms to identify and treat
emergency traffic in special ways. Such an approach would allow a
service provider to avoid having to meet specific availability
targets (e.g., 95% availability) through an assurance that is given
to emergency customers that their traffic is being treated
preferentially. If the network is stressed, availability for
emergency users may decrease, but it would still be relatively
higher (even much higher) than for normal users.
In the second interpretation, high availability would mean absolute
availability levels that would be provided regardless of the network
operating conditions. Service providers may choose to provide high
availability levels through overprovisioning even when the network
is stressed. They could choose to avoid using any mechanisms to
identify or preferentially treat emergency traffic, because
emergency traffic requirements would be met by the default operation
of their network.
2.2 Dependability
Authorized users must not only be able to initiate communication
sessions; they must also be able to successfully complete their
Folts & Beard Expires - December 2002 [Page 6]
Internet-Draft Emergency Requirements June 2002
intended activities. While PSTN services basically provide such
dependability by default, communications through the Internet might
be affected by a variety of network operating conditions, such as
congestion or link failures. An emergency telecommunication service
needs to protect authorized communications from being affected by
those conditions, at least to the extent that an emergency
communication session can still be conducted acceptably.
Definitions of acceptable performance will vary depending on the
application.
2.3 Authorized Access
Mechanisms must be implemented so that only authorized users have
access to emergency telecommunications services. Such authorization
could be PIN-based or based on assignment of cryptographic keys [5].
Authorization protects network resources from excessive use and
abuse. The two purposes for this requirement are to restrict usage
of network resources only to those who are allowed to use them and
to enable proper billing. Even when using an overprovisioning
approach where emergency users are not provided special services,
proper billing necessitates authorized access.
In today's public telephone networks a credit-card process is used.
This means entry of 32 digits of information to complete
establishment of a communication session. This is cumbersome and
time-consuming. With future technology in an Internet-based
infrastructure there is a need for a more time-responsive and
streamlined mechanism for rapid authentication.
Such authorization mechanisms should be flexible enough to provide
various levels of restriction and authorization depending on the
expectations of a particular service or customer. For example, it
might be desirable to provide access to emergency telecommunication
services differently after a hurricane where the emergency was
caused by a natural disaster as compared to after a terrorist attack
that was caused by humans. In the hurricane scenario, members of
the general public might be given access (e.g., at a lower
precedence level than emergency response organizations) where after
a terrorist attack security concerns might necessitate highly
restrictive access to emergency services.
Further requirements and recommended procedures are given in [5].
2.4 Security Protection
The overall problem of Internet security is being pursued by
appropriate and expert resources in the IETF and elsewhere. However,
specific problems of emergency traffic need to be considered.
Folts & Beard Expires - December 2002 [Page 7]
Internet-Draft Emergency Requirements June 2002
Emergency traffic needs to be protected against intrusion, spoofing,
and specifically, denial of service. If overall security measures
that are established do not satisfy these specific requirements,
additional consideration should be given to protection specifically
focused on emergency traffic. This is discussed further in [5].
2.5 Privacy
Some emergency communications will have a requirement that they not
be susceptible to viewing or modification by others, due to the
sensitive and urgent nature of emergency response activities. An
emergency telecommunications service should be able to protect the
integrity of all emergency user communications and have options to
encrypt certain user traffic. However, due to urgency and short-term
meaningfulness of the content at initial stages of disaster
response, encryption will have limited application.
3. Technical Requirements
The following technical requirements represent the functions that
need to be fulfilled to enable the general requirements listed above
to be realized. For several of the requirements below, it is
assumed that networks will experience temporary scarcity of
resources, especially because of damaged infrastructure and high
demand immediately following a disaster. If a service provider
employs an over provisioning approach to provide emergency services
so that resources are never scarce, some of the following
requirements might not be necessary.
3.1 Identification of Emergency Traffic
Emergency traffic should be recognized in the forwarding plane. An
emergency telecommunication service should have procedures by which
emergency traffic is marked so that it can be identified throughout
the network. The decisions about who does such marking (i.e., end
users or the network), where it occurs, who recognizes such marking,
whether re-marking might occur, and at what layer or layers marking
is implemented are left to the discretion of the policy makers and
specified in service level agreements. Standardized mechanisms,
however, should be utilized.
3.2 Signaling for Resource Requests
Emergency traffic should be recognized in the control plane. For
applications where sessions need to be established or network
resources reserved, signaling mechanisms can be used to support the
differentiation of emergency signaling messages.
Folts & Beard Expires - December 2002 [Page 8]
Internet-Draft Emergency Requirements June 2002
3.3 Better Then Best Effort Service
The default best-effort forwarding behavior available in existing
routers as standardized in [6] does not provide performance
assurances. This is especially true for emergency services where
severe congestion that accompanies disasters can cause the
performance of best-effort delivery to degrade well below acceptable
levels.
Quality of service for emergency telecommunication services does not
necessarily mean better quality of voice/video as compared to what
is available to normal users. The same QoS classes, which are
already defined for normal traffic, can be utilized for emergency
traffic as well.
The fundamental quality of service requirement for emergency traffic
is this - better than best effort service. Service providers have
the freedom to implement special quality of service mechanisms to
meet this requirement, but other approaches may be effective as
well.
Better than best effort service is provided to emergency traffic so
that it will receive assured performance levels that are at or above
a minimum performance level. Without such a requirement, the
dependability requirement outlined above could not be met.
Emergency traffic that suffers degraded QoS, however, should not be
terminated but should be allowed to continue. Disaster response
operations must be given the best chance to communicate, even if
with difficulty.
4. Special Requirements
In addition to the general and technical requirements given above,
this section provides additional requirements that may optionally be
requested for particular service agreements. They primarily involve
the specification of the particular approach that is being used by
service providers for particular networks, applications, and types
of traffic.
4.1 Application-Specific Support
The requirements in this document are for network layer mechanisms
to support emergency services. In general, these network layer
mechanisms will provide support to the rich array of applications
that could be used for emergency response operations. Specific
applications, however, may have additional requirements to be
acceptable for emergency users.
Folts & Beard Expires - December 2002 [Page 9]
Internet-Draft Emergency Requirements June 2002
Such requirements might include additional signalling or mechanisms
to provide preferential performance or dependability to authorized
users. Examples of applications include the following.
o Voice on IP, using such signaling architectures as H.323 or SIP
[7].
o Shared real-time whiteboard.
o Instant messaging and presence.
o Databases such as the Japanese "I am Alive" [8] service, for
communication with persons not involved in the crisis.
o Database services for managing the crisis, including
calendaring, contact management, order and trouble report
management, legal services, medical services, etc.
o Electronic mail.
o Telemedicine, victim observation video, and vital-sign
telemetry
o Damage assessment applications.
o File transfer.
o World Wide Web.
This document does not address specific requirements for these
applications. The focus of this document is to provide requirements
for network service providers. Requirements for the applications
should be met by content providers and end users. However, network
service providers may wish to provide network-based services that
could improve the performance of particular applications, for
example by providing web caching.
Of specific interest to current emergency management organizations
are IP Telephony and Voice on IP. Further requirements and
recommended procedures for these applications, in particular, are
given in [3]. In the future, however, it is anticipated that voice
communications will be overshadowed by a number of other multimedia
modes of communication that will significantly benefit emergency
recovery operations.
Folts & Beard Expires - December 2002 [Page 10]
Internet-Draft Emergency Requirements June 2002
4.2 Traffic Types
Consideration should be given to the different traffic types in
supporting the different multimedia applications for emergency
telecommunication services. The three types of traffic that may be
treated in distinctive ways are as follows.
o Inelastic traffic - As defined in [9], inelastic traffic is
traffic which has a firm delay bound. If packets arrive after
a maximum acceptable delay, the packets are essentially
worthless to the receiver. Real-time audio and video are
examples of inelastic traffic.
o Interactive elastic traffic - Elastic applications are
generally those which wait for data to arrive and do not
discard it if it is late. This does not mean that applications
are insensitive to delay, however, because such delays could
hurt application performance significantly. In particular,
interactive elastic traffic requires reasonable delays because
of the user interaction that is involved. Examples of
interactive elastic traffic include HTTP and instant messaging
traffic.
o Bulk transfer elastic traffic - Some elastic applications,
however, do not involve direct user interaction. In such
cases, delay is not so much a concern as average throughput.
Bulk transfers can have large variations in delay as long as an
expected average throughput is obtained. For example, if a
file can be downloaded in 100 seconds, it does not matter if
for part of the transfer the throughput was virtually zero.
Examples of bulk transfer traffic are FTP and SMTP.
As an example, service providers may wish to provide service
assurances for inelastic traffic using Diffserv [10] but use
overprovisioning for both types of elastic traffic.
5. Policy Decisions
The above general and technical requirements provide wide latitude
for creativity on the part of service providers to implement
emergency services. In addition to meeting the requirements above,
a series of policy decisions should be made in the implementation of
emergency services. No particular approach is prescribed regarding
these policies. However, the policies used by a service provider to
address the following issues should be clearly defined and
communicated.
Folts & Beard Expires - December 2002 [Page 11]
Internet-Draft Emergency Requirements June 2002
The user needs to determine specific policies for the emergency
telecommunications service, and these should be specified and agreed
upon in the service level agreement.
5.1 Emergency Service Activation
Providers of an emergency service should specify whether emergency
treatment is always available within the network or whether the
service is only activated upon declaration of emergency conditions
by an appropriate authority. Service providers may also choose to
provide a minimal service that is available at all times, but which
could be expanded once an emergency declaration was made.
5.2 Restoration Procedures
Service providers should describe the restoration procedures they
will use when substantial damage is experienced in their network.
They should provide plans and estimates in advance of how damaged
facilities will affect the availability of emergency services and,
if a critical relationship exists, how prioritized restoration of
those vital facilities will be accomplished. Service providers may,
of course, choose to rely upon rerouting mechanisms that would make
the restoration procedures they use irrelevant to the continued
dependability of emergency services. The only concern in that case
is when damage could be so extensive that rerouting mechanisms would
be ineffective. Also see [2].
5.3 Preemption
Service providers may wish to provide resources for emergency
communications by interrupting particular non-emergency traffic
flows. If such an approach is used, this should be explicitly
stated and details should be given on how preemption is carried out.
Regulatory guidelines in some jurisdictions may prohibit the use of
preemption to support emergency traffic.
5.4 Cooperation Between Service Providers
Emergency users will only be concerned with the quality of the end-
to-end communications they are provided. However, it is possible
that no one particular service provider will be able to support that
service end-to-end. Emergency services could be carried over a
combination of service providers, some of which would provide
emergency capabilities and some of which may not.
Service providers that do provide emergency services may choose to
provide services that are only operative within their networks and
are independent of other service providers. Alternatively, service
Folts & Beard Expires - December 2002 [Page 12]
Internet-Draft Emergency Requirements June 2002
providers may employ mechanisms to cooperate with other service
providers to provide emergency services. This would result in a
considerable portion of the end-to-end path being administered in a
cooperative fashion. If so, service providers should specify the
mechanisms they would use and the extent to which they would
cooperate with other service providers to support emergency
services.
6. Example Emergency Scenarios
Some example instances for emergency communications are described
below. These show some different levels of emergency communication
requirements that need to be supported.
6.1 Local recovery operations
While mobile radio is the primary mode of communication for police
and fire brigade operations, there is often a need to supplement
these capabilities with access to the public telecommunication
networks. This is particularly needed during the initial stages and
immediately following a disaster event. These emergency
communications can be accomplished through use of wireless access
(cellular phone or PDA) where priority service may be necessary due
to congestion. Some mobile radio systems interface with public
networks, but their use is often discouraged or avoided because of
limited bandwidth availability in the frequency allocation.
Communications outside the immediate local radio coverage area are
often required to request additional resources from other areas and
to notify and coordinate operations with regional (e.g. county and
state) and national authorities. Public telecommunications services
provide at-hand capability to immediately support these critical
emergency communications
6.2 Medical operations
The process of saving lives and providing medical treatment to
victims is greatly enhanced through the use of data telemetry to
remotely provide victim vital signs to a central medical center. In
addition, treatment of victims at the disaster site can be
significantly accelerated through the use of video telemedicine
transmissions to remote medical staff. These vital life-saving
communications can be very effectively supported by an Internet-
based infrastructure.
6.3 Regional operations
The magnitude of the event may require recovery support from
resources outside of the immediate area of impact. Critical
Folts & Beard Expires - December 2002 [Page 13]
Internet-Draft Emergency Requirements June 2002
information is provided for authorities to proclaim a disaster
crisis and activate vital support resources.
Regional emergency operations centers would need immediate and
effective telecommunication capabilities to rapidly organize and
coordinate support from elsewhere regionally, nationally, or
internationally. Public telecommunication resources are essential to
support these emergency activities.
6.4 National operations
The most serious disaster events can impact national security of a
country. Therefore, immediate action is required by government
officials to organize and coordinate the highest level of emergency
support resources. With a serious threat to national security,
actions to ensure continuity of government must be initiated. These
types of activities need to not only have priority treatment for
emergency communications in the public telecommunications domain,
but they also require protection against eavesdropping of
confidential/sensitive information. In addition, locations of source
and destination of some critical national security traffic needs
protection. While these communications can often be supported
directly by dedicated government networks, public telecommunication
facilities provide an essential alternate capability.
7. Conclusions
There are many critical requirements for emergency
telecommunications that need to be addressed as outlined above.
These are important ingredients to the total solution required for
effective and comprehensive emergency telecommunication capabilities
in a public Internet-based telecommunication service infrastructure.
Technical solutions are neither proposed nor suggested, so that full
consideration and innovation will be used in seeking effective
solutions. There are many other procedural, operational, policy,
regulatory, and full systems considerations that also need to be
addressed to ensure that the technical capabilities of Internet-
based infrastructures are established and sound.
8. Security Considerations
Detailed requirements are given in [5]. Authorized access, security
protection, and privacy are presented here as general security
requirements for emergency services in Section 2.
References
1 B. Brewin, "Nation's Networks See Large Volume Spikes After
Attacks,", Computerworld, September 17, 2001.
Folts & Beard Expires - December 2002 [Page 14]
Internet-Draft Emergency Requirements June 2002
2 Information Interchange Representation of National Security
Emergency Preparedness รป Telecommunications Service Priority,
American National Standard T1.211-1989 (R1999).
3 Carlberg, K. and I. Brown, "Framework for Supporting IEPS in IP
Telephony," draft-ietf-ieprep-framework-00 (work in progress),
February 2002.
4 Work-in-progress.
5 Brown, I., "Securing prioritised emergency traffic", draft-brown-
ieprep-sec-00 (work in progress), February 2002.
6 Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
7 Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
8 "IAA System (I Am Alive): The Experiences of the Internet
Disaster Drills", INET 2000, June 2000.
9 Braden, R., Clark, D., and Shenkar, S., "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
10 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998.
Author Addresses
Hal Folts, Senior Systems Engineer
Priority Services - Internet Team, Technology and Programs
National Communications System
1-703-607-6186
foltsh@ncs.gov
Cory Beard
School of Interdisciplinary Computing and Engineering
University of Missouri-Kansas City
5100 Rockhill Road
Kansas City, MO 64110
1-816-235-1550
beardc@umkc.edu
Folts & Beard Expires - December 2002 [Page 15]
