Browse Prior Art Database

General Requirements for Emergency Telecommunication Service (ETS) (RFC3689)

IP.com Disclosure Number: IPCOM000021744D
Original Publication Date: 2004-Feb-01
Included in the Prior Art Database: 2004-Feb-05
Document File: 11 page(s) / 22K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Carlberg: AUTHOR [+2]

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).

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 17% of the total text.

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 networ...