General Requirements for Emergency Telecommunication Service (ETS)
RFC 3689

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

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