Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain
RFC 4375
|
| Document |
Type |
|
RFC - Informational
(January 2006; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4375 (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: 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]
Show full document text