Skip to main content

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

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 4375.
Author Ken Carlberg
Last updated 2015-10-14 (Latest revision 2005-11-17)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 4375 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Jon Peterson
Send notices to
Internet Engineering Task Force                         Ken Carlberg
INTERNET DRAFT                                          G11
Nov 17, 2005

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

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This document presents a list of requirements in support of Emergency
   Telecommunications Service (ETS) within a single administrative
   domain. This document is an extension of the General Requirements of
   [rfc3689] and focuses on a more specific set of administrative
   constraints and scope.  Solutions to these requirements are not
   presented in this document.

Carlberg                        Expires May 17, 2006            [Page 1]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

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

   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

Carlberg                        Expires May 17, 2006            [Page 2]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

     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",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
   interpreted as described in [rfc2119].

2.  Scope

   IETF standards that cover the resources within an administrative
   domain are within the scope of this document.  This includes
   gateways, routers, servers, etc., that are located and administered
   within the domain.  This document also does not restrict itself to a
   specific type of application such as Voice over IP.

   QoS mechanisms are also within the scope of this document.  These
   mechanisms may reside at the application, transport, or IP network
   layer.  While QoS mechanisms may exist at the link/physical layer,
   this document would only consider potential mappings of labels or
   code points.

   Finally, since this document focuses on a single administrative
   domain, we do not make any further distinction between transit and
   stub domains within this document.

2.1 Out of Scope:

   Resources owned or operated by other administrative authorities are

Carlberg                        Expires May 17, 2006            [Page 3]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

   outside the scope of this document.  One example are SIP servers that
   operate in other domains.  Another example are access links
   connecting the stub domain and its provider.  Controlling only 1/2 of
   a link (the egress traffic from the stub) is considered insufficient
   for including inter-domain access links as a subject for this

3. Requirements

   It must be understood that all of the following requirements pertain
   to mechanisms chosen by a domain's administrative authority to
   specifically support ETS.  If that authority chooses not to support
   ETS or if these mechanisms exist within the domain exclusively for a
   different purpose, then the associated requirement does not apply.

   3.1 Label Mechanisms

   Application or transport layer label mechanisms used for ETS MUST be
   extensible such that they can support more than one label.  These
   mechanism MUST avoid a single off/on type of label (e.g., a single
   bit).  In addition, designers of such a mechanism MUST assume that
   there may be more than one set of ETS users.

   Network layer label mechanisms used for ETS SHOULD be extensible such
   that they can support more than one label.  We make this distinction
   in requirements because there may be fewer bits (a smaller field)
   available at the network layer than in the transport or application

   3.2  Proxies

   Proxies MAY set ETS labels on behalf of the source of a flow. This
   may involve removing labels that have been set by upstream node(s).

   If proxies take such action, then the security measures discussed in
   [rfc3689] MUST be considered.  More information about security in the
   single domain context is found below in Section 5.

   3.3 QoS mechanisms

   [rfc3689] defines a label as an identifier, and the set of
   characteristics associated with the label as policy.  However,
   Quality of Service (QoS) in the traditional sense of delay or
   bandwidth is not automatically bound to a label.  MPLS [rfc3031] is
   an example of a labeling mechanism that can provide specific QoS or
   simply traffic engineering of labeled flows.

Carlberg                        Expires May 17, 2006            [Page 4]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

   In the context of ETS, QoS mechanisms, at either the network or
   application layer, SHOULD be used when networks cannot be over-
   provisioned to satisfy high bursts of traffic load.  Examples can
   involve bridging fiber networks to wireless subnetworks, or remote
   subnetworks connected over expensive bandwidth constrained wide area

   Note well. Over-provisioning is a normal cost-effective practice
   amongst network administrators/engineers.  The amount of over-
   provisioning can be a topic of debate.  More in-depth discussion on
   this topic is presented in the companion Framework document of

   3.4  Users

   Regarding existing IETF specified applications, augmentations in the
   form of labeling mechanisms to support ETS  MUST NOT adversely affect
   its legacy usage by non-ETS users.  With respect to future
   applications, such labeling mechanisms SHOULD allow the application
   to support a "normal" (non-emergency) condition.

   3.5  Policy

   Policy MUST be used to determine the percentage of resources of a
   mechanism used to support the various (ETS and non-ETS) users.  Under
   certain conditions, this percentage MAY reach 100% for a specific set
   of users.  However, we recommend that this "all-or-nothing" approach
   be considered with great care.

   3.6  Discovery

   There should be a means of forwarding ETS labeled flows to those
   mechanisms within the domain used to support ETS.  Discovery
   mechanisms SHOULD be used to determine where ETS labeled flows
   (either data or control) are to be forwarded.

   3.8 MIB

   Management Information Bases (MIBs) SHOULD be defined for mechanisms
   specifically in place to support ETS.  These MIBs MAY include objects
   representing accounting, policy, authorization.

4.  Issues

   This section presents issues that arise in considering solutions for
   the requirements that have been defined for Stub Domains that support
   ETS.  This section does not specify solutions nor is it to be

Carlberg                        Expires May 17, 2006            [Page 5]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

   confused with requirements.  Subsequent documents that articulate a
   more specific set of requirements for a particular service may make a
   statement about the following issues.

4.1 Alternative Services

   The form of the service provided to ETS users and articulated in the
   form of policies may be realized in one of several forms.  Better
   than best effort is probably the service that most ETS users would
   expect when the communication system is stressed and overall quality
   has degraded.  However, the concept of best available service should
   also be considered under such stressed conditions.  Further, a
   measure of degraded service may also be desirable to ensure a measure
   of communication versus none.  These services may be made available
   at the network or application layer.

4.2 Redundancy

   The issue of making networks fault tolerant is important and yet not
   one that can be easily articulated in terms of requirements of
   protocols.  Redundancy in connectivity and nodes (be it routers or
   servers) is probably the most common approach taken by network
   administrators, and it can be assumed that administrative domains
   apply this approach in various degrees to there own resources.

5. Security Considerations

   This document recommends that readers review and follow the comments
   and requirements about security presented in [rfc3689].  Having said
   that, there tends to be many instances where intra-domain security is
   held at a lower standard (i.e., less stringent) that inter-domain
   security.  For example, while administrators may allow telnet service
   between resources within an administrative domain, they would only
   allow SSH access from other domains.

   The disparity in security policy can be problematic when domains
   offer services other than best effort for ETS users.  Therefore, any
   support within a domain for ETS should be accompanied by a detailed
   security policy for users and administrators.

   Given the "SHOULD" statement in section 3.8 concerning MIBs, there
   are a number of related security considerations that need to be
   brought to attention to the reader.  Specifically,

     - Most current deployments of SNMP are of versions prior to
       SNMPv3, even though there are well-known security

Carlberg                        Expires May 17, 2006            [Page 6]

Internet Draft          ETS Domain Requirements             Nov 17, 2005

       vulnerabilities in those versions of SNMP.

     - SNMP versions prior to SNMPv3 cannot support cryptographic
       security mechanisms.  Hence, any use of SNMP prior to
       version 3 to write or modify MIB objects do so in a
       non-secure manner.  As a result, it may be best to constrain
       the use of these objects to read-only by MIB managers.

     - Finally, any MIB defining writable objects should carefully
       consider the security implications of an SNMP compromise on
       the mechanism(s) being controlled by those writable MIB

6. Acknowledgements

   Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and
   Ian Brown for comments on previous versions of this draft.

7. References

7.1 Normative Reference

   [rfc3668]  Bradner, S., "Intellectual Property Rights in IETF
              technology", BCP 79, RFC 3668, February 2004

7.2 Informative References

   [rfc2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

   [rfc3031]  Rosen, E., et. al., "Multiprotocol Label Switching
              Architecture", RFC3031, January 2001

   [rfc3689]  Carlberg, K., Atkinson, R., "General Requirements for
              Emergency Telecommunications Service", RFC3689
              Feb 2004

   [frame]  Carlberg, K., "A Framework for Supporting ETS in Stub
            Domains", Internet Draft, Work in Progress,
            draft-ieprep-domain-frame-02.txt, June 2003.

8.  Author's Addresses

   Ken Carlberg
   123a Versailles Circle
   Baltimore, MD

Carlberg                        Expires May 17, 2006            [Page 7]

Internet Draft          ETS Domain Requirements             Nov 17, 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Carlberg                        Expires May 17, 2006            [Page 8]