General Requirements for Emergency Telecommunication Service (ETS) (RFC3689)
Original Publication Date: 2004-Feb-01
Included in the Prior Art Database: 2004-Feb-05
Internet Society Requests For Comment (RFCs)
K. Carlberg: AUTHOR [+2]
AbstractThis 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).
Network Working Group K. Carlberg
Request for Comments: 3689 UCL
Category: Informational R. Atkinson
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 (C) The Internet Society (2004). All Rights Reserved.
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).
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
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 .
Carlberg, et al. Informational [Page 1]
RFC 3689 ETS General Requirements February 2004
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 networ...