General Requirements for Emergency Telecommunication Service (ETS)
RFC 3689
|
Document |
Type |
|
RFC - Informational
(February 2004; No errata)
|
|
Authors |
|
Randall Atkinson
,
Ken Carlberg
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 3689 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Jon Peterson
|
|
Send notices to |
|
<kimberly.s.king@saic.com>
|
Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
Extreme Networks
February 2004
General Requirements for
Emergency Telecommunication Service (ETS)
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document presents a list of general requirements in support of
Emergency Telecommunications Service (ETS). Solutions to these
requirements are not presented in this document. Additional
requirements pertaining to specific applications, or types of
applications, are to be specified in separate document(s).
1. Introduction
Effective telecommunications capabilities can be imperative to
facilitate immediate recovery operations for serious disaster events,
such as, hurricanes, floods, earthquakes, and terrorist attacks.
Disasters can happen any time, any place, unexpectedly. Quick
response for recovery operations requires immediate access to any
public telecommunications capabilities at hand. These capabilities
include: conventional telephone, cellular phones, and Internet
access via online terminals, IP telephones, and wireless PDAs. The
commercial telecommunications infrastructure is rapidly evolving to
Internet-based technology. Therefore, the Internet community needs
to consider how it can best support emergency management and recovery
operations.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [1].
Carlberg, et al. Informational [Page 1]
RFC 3689 ETS General Requirements February 2004
1.1. Terminology
Label:
The term label has been used for a number of years in various IETF
protocols. It is simply an identifier. It can be manifested in
the form of a numeric, alphanumeric value, or a specific bit
pattern, within a field of a packet header. The exact form is
dependent on the protocol in which it is used.
An example of a label can be found in RFC 3031; the Multiprotocol
Label Switching Architecture. Another example can be found in RFC
2597 (and updated by RFC 3260); a bit pattern for the Assured
Forwarding PHB group. This latter case is a type of label that
does not involve routing. Note that specification of labels is
outside the scope of this document. Further comments on labels
are discussed below in section 3.
1.2. Existing Emergency Related Standards
The following are standards from other organizations that are
specifically aimed at supporting emergency communications. Most
of these standards specify telephony mechanisms or define
telephony related labels.
Standard / Organization
--------------------------
1) T1.631 / ANSI
2) E.106 / ITU
3) F.706 / ITU
4) H.460.4 / ITU
5) I.255.3 / ITU
The first specifies an indicator for SS7 networks that signals the
need for a High Probability of Completion (HPC) service. This
indicator is termed National Security / Emergency Preparedness
(NS/EP) The T1.631 standard [2] is the basis for the U.S. Government
Emergency Telecommunications Service (GETS) [7].
The second standard describes functional capabilities for the Public
Switched Telephone Network (PSTN) to support International Emergency
Preparedness System (IEPS) [3]. From the PSTN perspective, one can
view NS/EP as a standard with national boundaries, while IEPS is an
extension to international boundaries for telephony.
The third standard extends IEPS beyond the scope of telephony into
other forms that encompass multimedia [4].
Carlberg, et al. Informational [Page 2]
RFC 3689 ETS General Requirements February 2004
The fourth and fifth standard focuses on a multi-level labeling
mechanism distinguishing emergency type traffic from that which is
not. The former case focuses on call signaling for H.323 networks
[5], while the latter has been applied for both SS7 [6] and data
networks.
While the above standards are outside the scope of the IETF, they do
represent existing efforts in the area of emergency communications,
as opposed to conceptual of potential possibilities. They act as
Show full document text