Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
RFC 4375

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

• Versions
• 06

Network Working Group                                        K. Carlberg
Request for Comments: 4375                                           G11
Category: Informational                                     January 2006

       Emergency Telecommunications Services (ETS) Requirements
                   for a Single Administrative Domain

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

Abstract

   This document presents a list of requirements in support of Emergency
   Telecommunications Service (ETS) within a single administrative
   domain.  This document focuses on a specific set of administrative
   constraints and scope.  Solutions to these requirements are not
   presented in this document.

1.  Introduction

   The objective of this document is to define a set of requirements
   that support ETS within a single domain.  There have been a number of
   discussions in the IEPREP mailing list, as well as working group
   meetings, that have questioned the utility of a given mechanism to
   support ETS.  Many have advocated over-provisioning, while others
   have favored specific schemas to provide a quantifiable measure of
   service.  One constant in these discussions is that the
   administrative control of the resources plays a significant role in
   the effectiveness of any proposed solution.  Specifically, if one
   administers a set of resources, a wide variety of approaches can be
   deployed upon that set.  However, once the approach crosses an
   administrative boundary, its effectiveness comes into question, and
   at a minimum requires cooperation and trust from other administrative
   domains.  To avoid this question, we constrain our scenario to the
   resources within a single domain.

   The following provides an explanation of some key terms used in this
   document.

Carlberg                     Informational                      [Page 1]
RFC 4375                ETS Domain Requirements             January 2006

   Resource:  A resource can be a viewed from the general level as IP
     nodes such as a router or host as well as the physical media
     (e.g., fiber) used to connect them.  A host can also be referred
     to in more specific terms as a client, server, or proxy.
     Resources can also be viewed more specifically in terms of the
     elements within a node (e.g., CPU, buffer, memory).  However,
     this document shall focus its attention at the node level.

   Domain:  This term has been used in many ways.  We constrain its
     usage in this document to the perspective of the network layer,
     and view it as being synonymous with an administrative domain.
     A domain may span large geographic regions and may consist of
     many types of physical subnetworks.

   Administrative Domain:  The collection of resources under the
     control of a single administrative authority.  This authority
     establishes the design and operation of a set of resources
     (i.e., the network).

   Transit Domain:  This is an administrative domain used to forward
     traffic from one domain to another.  An Internet Service Provider
     (ISP) is an example of a transit domain.

   Stub Domain:  This is an administrative domain that is either the
     source or the destination of a flow of IP packets.  As a general
     rule, it does not forward traffic that is destined for other
     domains.  The odd exception to this statement is the case of
     Mobile IP and its use of "dog-leg" routing to visiting hosts
     located in foreign networks.  An enterprise network is an example
     of a stub domain.

1.1.  Previous Work

   A list of general requirements for support of ETS is presented in
   [RFC3689].  The document articulates requirements when considering
   the broad case of supporting ETS over the Internet.  Since that
   document is not constrained to specific applications, administrative
   boundaries, or scenarios, the requirements contained within it tend
   to be quite general in their description and scope.  This follows the
   philosophy behind its inception in that the general requirements are
   meant to be a baseline followed (if necessary) by more specific
   requirements that pertain to a more narrow scope.

   The requirements presented below in Section 3 are representative of
   the more narrow scope of a single administrative domain.  As in the
   case of [RFC3689], the requirements articulated in this document
   represent aspects to be taken into consideration when solutions are
   being designed, specified, and deployed.  Key words such as "MUST",

Carlberg                     Informational                      [Page 2]
RFC 4375                ETS Domain Requirements             January 2006

   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",