Internet Engineering Task Force                      Ken Carlberg
INTERNET DRAFT                                       Ian Brown
March 2,
June 19, 2003                                        UCL
                                                     Cory Beard
                                                     UMKC

              Framework for Supporting ETS in IP Telephony
                  <draft-ietf-ieprep-framework-04.txt>
                  <draft-ietf-ieprep-framework-05.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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-Drafts.
   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
   http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
   Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt

Abstract

   This document presents a framework for supporting authorized
   emergency related communication within the context of IP telephony.
   We present a series of objectives that reflect a general view of how
   authorized emergency service, in line with the Emergency
   Telecommunications Service (ETS), should be realized within today's
   IP architecture and service models.  From these objectives, we
   present a corresponding set of protocols and capabilities, which
   provide a more specific set of recommendations regarding existing
   IETF protocols.  Finally, we present two scenarios that act as
   guiding models for the objectives and functions listed in this
   document.  These, models, coupled with an example of an existing

^L
   service in the PSTN, contribute to a constrained solution space.

1.  Introduction

   The Internet has become the primary target for worldwide communica-
   tions.  This is in terms of recreation, business, and various ima-
   ginative reasons for information distribution.  A constant fixture in
   the evolution of the Internet has been the support of Best Effort as
   the default service model.  Best Effort, in general terms, infers
   that the network will attempt to forward traffic to the destination
   as best as it can with no guarantees being made, nor any resources
   reserved, to support specific measures of Quality of Service (QoS).
   An underlying goal is to be "fair" to all the traffic in terms of the
   resources used to forward it to the destination.

   In an attempt to go beyond best effort service, [2] presented an
   overview of Integrated Services (int-serv) and its inclusion into the
   Internet architecture.  This was followed by [3], which specified the
   RSVP signaling protocol used to convey QoS requirements.  With the
   addition of [4] and [5], specifying controlled load (bandwidth
   bounds) and guaranteed service (bandwidth & delay bounds) respec-
   tively, a design existed to achieve specific measures of QoS for an
   end-to-end flow of traffic traversing an IP network.  In this case,
   our reference to a flow is one that is granular in definition and
   applying to specific application sessions.

   From a deployment perspective (as of the date of this document),
   int-serv has been predominantly constrained to intra-domain paths, at
   best resembling isolated "island" reservations for specific types of
   traffic (e.g., audio and video) by stub domains.  [6] and [7] will
   probably contribute to additional deployment of int-serv to Internet
   Service Providers (ISP) and possibly some inter-domain paths, but it
   seems unlikely that the original vision of end-to-end int-serv
   between hosts in source and destination stub domains will become a
   reality in the near future (the mid- to far-term is a subject for
   others to contemplate).

   In 1998, the IETF produced [8], which presented an architecture for
   Differentiated Services (diff-serv).  This effort focused on a more
   aggregated perspective and classification of packets than that of
   [2].  This is accomplished with the recent specification of the
   diff-serv field in the IP header (in the case of IPv4, it replaced
   the old ToS field).  This new field is used for code points esta-
   blished by IANA, or set aside as experimental.  It can be expected

^L
nternet Draft               IEPS Framework                March 2, 2003
   that sets of microflows, a granular identification of a set of pack-
   ets, will correspond to a given code point, thereby achieving an
   aggregated treatment of data.

   One constant in the introduction of new service models has been the
   designation of Best Effort as the default service model.  If traffic
   is not, or cannot be, associated as diff-serv or int-serv, then it is
   treated as Best Effort and uses what resources are made available to
   it.

   Beyond the introduction of new services, the continued pace of addi-
   tional traffic load experienced by ISPs over the years has continued
   to place a high importance for intra-domain traffic engineering.  The
   explosion of IETF contributions, in the form of drafts and RFCs pro-
   duced in the area of Multi Protocol Label Switching (MPLS), exempli-
   fies the interest in versatile and manageable mechanisms for intra-
   domain traffic engineering.  One interesting observation is the work
   involved in supporting QoS related traffic engineering. Specifically,
   we refer to MPLS support of differentiated services [9], and the on-
   going work in the inclusion of fast bandwidth recovery of routing
   failures for MPLS [10].

1.1.  Emergency Related Data

   The evolution of the IP service model architecture has traditionally
   centered on the type of application protocols used over a network.
   By this we mean that the distinction, and possible bounds on QoS,
   usually centers on the type of application (e.g., audio video tools)
   that is being referred to.

   While protocols like SMTP [11] and SIP [12] have embedded fields
   denoting "priority", there has not been a previous IETF standards
   based effort to state or define what this distinction means with
   respect to the underlying network or the end-to-end applications and
   how it should be supported at any layer.  Given the emergence of IP
   telephony, a natural inclusion of it as part of a telephony carrier's
   backbone network, or into the Internet as a whole, implies the abil-
   ity to support existing emergency related services.  Typically, one
   associates emergency calls with "911" telephone service in the U.S.,
   or "999" in the U.K. -- both of which are attributed to national
   boundaries and accessible by the general public.  Outside of this
   exists emergency telephone services that involved authorized usage,
   as described in the following subsection.

^L

1.1.1.  Government Emergency Telecommunications Service (GETS)

   GETS is an emergency telecommunications service available in the U.S.
   and overseen by the National Communications System (NCS) -- an office
   established by the White House under an executive order [30] and now
   a part of the Department of Homeland Security .  Unlike "911", it is
   only accessible by authorized individuals.  The majority of these
   individuals are from various government agencies like the Department
   of Transportation, NASA, the Department of Defense, and the Federal
   Emergency Management Agency (to name but a few).  In addition, a
   select set of individuals from private industry (telecommunications
   companies, utilities, etc.) that are involved in criticial infras-
   tructure recovery operations are also provided access to GETS.

   The purpose of GETS is to increase the probability that phone service
   will be available to selected authorized personnel in times of emer-
   gencies, such as hurricanes, earthquakes, and other disasters that
   may produce a burden in the form of call blocking (i.e., congestion)
   on the U.S. Public Switched Telephone Network by the general public.

   GETS is based in part on the ANSI T1.631 standard, specifying a High
   Probability of Completion (HPC) for SS7 signaling [13].

1.1.2.  International Emergency Preparedness Scheme (IEPS)

   [18] is a recent ITU standard that describes emergency related com-
   munications over international telephone service.  While systems like
   GETS are national in scope, IEPS acts as an extension to local or
   national authorized emergency call establishment and provides a
   building block for a global service.

   As in the case of GETS, IEPS promotes mechanisms like extended queu-
   ing, alternate routing, and exemption from restrictive management
   controls in order to increase the probability that international
   emergency calls will be established.  The specifics of how this is to
   be accomplished are to be defined in future ITU document(s).

1.2.  Scope of this Document

   The scope of this document centers on the near and mid-term support
   of ETS within the context of IP telephony, though not necessarily
   Voice over IP.  We make a distinction between these two by treating
   IP telephony as a subset of VoIP, where in the former case we assume
   some form of application layer signaling is used to explicitly

^L
   establish estab-
   lish and maintain voice data traffic.  This explicit signaling
   capability capa-
   bility provides the hooks from which VoIP traffic can be bridged to

^L
   the PSTN.

   An example of this distinction is when the Robust Audio Tool (RAT)
   [14] begins sending VoIP packets to a unicast (or multicast) destina-
   tion.  RAT does not use explicit signaling like SIP to establish an
   end-to-end call between two users.  It simply sends data packets to
   the target destination.  On the other hand, "SIP phones" are host
   devices that use a signaling protocol to establish a call signal
   before sending data towards the destination.

   One other aspect we should probably assume exists with IP Telephony
   is an association of a target level of QoS per session or flow.  [31]
   makes an argument that there is a maximum packet loss and delay for
   VoIP traffic, and both are interdependent.  For delays of ~200ms, a
   corresponding drop rate of 5% is deemed acceptable.  When delay is
   lower, a 15-20% drop rate can be experienced and still considered
   acceptable.  [32] discusses the same topic and makes an arguement
   that packet size plays a significant role in what users tolerate as
   "intelligible" VoIP.  The larger the packet, correlating to longer
   sampling rate, the lower the acceptable rate of loss.

   Regardless of a definitive drop rate, it would seem that interactive
   voice has a lower threshold of loss than elastic applications such as
   email or web browsers.  This places a higher burden on the problem
   space of supporting VoIP over the Internet.  This problem is further
   compounded when toll-quality service is expected because it assumes a
   default service model that is better than best effort.  This in turn
   can increase the probability that a form of call-blocking can occur
   with VoIP or IP telephony traffic.

   Beyond this, part of our motivation in writing this document is to
   provide a framework for ISPs and telephony carriers so that they have
   an understanding of objectives used to support ETS related IP
   telephony traffic.  In addition, we also wish to provide a reference
   point for potential customers in order to constrain their expecta-
   tions.  In particular, we wish to avoid any temptation of trying to
   replicate the exact capabilities of existing emergency voice service
   currently available in the PSTN to that of IP and the Internet.  If
   nothing else, intrinsic differences between the two communications
   architectures precludes this from happening. Note, this does not
   prevent us from borrowing design concepts or objectives from existing
   systems.

   Section 2 presents several primary objectives that articulate what is
   considered important in supporting ETS related IP telephony traffic.
   These objectives represent a generic set of goals and desired

^L
   capabilities. capa-
   bilities.  Section 3 presents additional value added objectives,
   which are viewed as useful, but not critical.  Section 4 presents

^L
   protocols and capabilities that relate or can play a role in support
   of the objectives articulated in section 2.  Finally, Section 5
   presents two scenarios that currently exist or are being deployed in
   the near term over IP networks.  These are not all-inclusive
   scenarios, nor are they the only ones that can be articulated ([38]
   provides a more extensive discussion on the topology scenarios
   related to IP telephony).  However, these scenarios do show cases
   where some of the protocols discussed in section 4 apply, and where
   some do not.

   Finally, we need to state that this document focuses its attention on
   the IP layer and above.  Specific operational procedures pertaining
   to Network Operation Centers (NOC) or Network Information Centers
   (NIC) are outside the scope of this document.  This includes the
   "bits" below IP, other specific technologies, and service level
   agreements between ISPs and telephony carriers with regard to dedi-
   cated links.

2.  Objective

   The support of ETS within IP telephony can be realized in the form objective of
   several primary objectives.  From this set, we document is to present a framework that
   describes how various protocols and capabilities (presented below in section 3) to (or mechanisms) can
   be considered by
   clients used to facilitate and providers of ETS type services.  This document uses support the
   IEPREP requirements of [39, 40] as traffic from ETS users.  In
   several cases, we provide a guide in specifying the objec-
   tives listed in this section.

   There are two underlying goals bit of background in each area so that
   the selection of these objectives.
   One goal reader is to produce given some context and more indepth understanding.  We
   also provide some discussion on aspects about a design given protocol or
   capability that maximizes the use of existing IP
   protocols could be explored and minimizes the set of additional specifications needed potentially advanced to support IP-telephony based
   ETS.  Thus,  This exploration is not to be confused with the inclusion of these
   minimal augmentations, the bulk of the work in achieving ETS over an
   IP network specific solutions
   since we do not articulate exactly what must be done (e.g., a new
   header field, or a new code point).

3.  Considerations

   When producing a solution, or examining existing protocols and
   mechanisms, there are some things that should be considered.  One is connected
   that inter-domain ETS communications should not rely on ubiquitous or unconnected to
   even wide-spread support along the Internet involves
   operational issues.  Examples of this would be path between the establishment of
   Service Level Agreements (SLA) with ISPs, and/or end points.
   Potentially, at the provisioning network layer there may exist islands of
   traffic engineered paths for ETS-related telephony traffic.

   A second underlying goal in selecting the following objectives is to
   take into account experiences from an existing emergency-type commun-
   ication system (as described support
   realized in section 1.1) as well as the existing
   restrictions and constraints placed by some countries.  In the former
   case, we do not attempt to mimic the system, but rather extract
   information as a reference model.  With respect to constraints based form of overlay networks.  There may also be cases
   where solutions may be constrained on laws an end-to-end basis (i.e., at
   the transport or agency regulations, application layer).  It is this would normally diversity and possi-
   bly partial support that need to be considered taken into account by those
   designing and deploying ETS related solutions.

   Another aspect to consider is that there are existing architectures
   and protocols from other standards bodies that support emergency

^L
   outside of the scope of any IETF document.  However,
   related communications.  The effort in interoperating with these con-
   straints act as sys-
   tems, presumably through gateways or similar type nodes with IETF
   protocols, would foster a means of determining the lowest common denominator
   in specifying technical functional requirements.  If such constraints
   do not exist, then additional capabilities can be added need to the base-
   line set. This last item will distinguish ETS flows from other
   flows.  One reason would be expanded upon in the description of
   Objective #3 below.

   The primary Objectives in support of authorized emergency calls:

       1) High Probability of Call Completion
       2) No loss of information when interacting with PSTN signaling
       3) Distinction scenario of triggering ETS data traffic
       4) Non-preemptive action
       5) Non-ubiquitous support
       6) Authenticated service

   The first objective is the crux of our work because it defines our
   expectations for both data and call signaling for IP telephony.  As
   stated, our objective is achieving a high probability that emergency
   related calls (both data and signaling packets) will be forwarded
   through
   from an IP network.  Specifically,

   Finally, we envision take into consideration the relevance of
   this objective during times requirements of congestion, [39, 40] in
   discussing the context of which we
   describe further protocols and mechanisms below in this section.  The critical word in this
   objective is "probability", as opposed to assurance or guarantee --
   the latter two placing a higher burden on Secytion 4.  In
   doing this, we do not make a one-to-one mapping of protocol discus-
   sion with requirement.  Rather, we make sure the network.  Objectives discussion of Sec-
   tion 4
   and 5 listed above help us to qualify the term probability in the
   context does not violet any of other objectives.

   The second objective involves the interaction of IP telephony signal-
   ing with existing PSTN support for emergency related voice communica-
   tions. As mentioned above requirements in Section 1.2, standard T1.631 [26] speci-
   fies emergency code points for SS7.  Specifically, the National Secu-
   rity [39,40].

4.  Protocols and Emergency Preparedness (NS/EP) Calling Party Category code
   point is defined for ISUP IAM messages used by SS7 [26]. Hence, when
   IP providers choose to interconnect with the PSTN, it is our objec-
   tive that Capabilities

   In this interaction between section, we take the PSTN objectives presented above and IP telephony with
   respect to ETS (and national indicators) is present a semantically straight-
   forward, reversible mapping of comparable code points.

   The third objective focuses on the ability to distinguish ETS data
   packets from other types
   set of VoIP packets.  With such an ability,
   transit providers can more easily ensure protocols and capabilities that pre-existing service
   level agreements relating can be used to ETS are adhered to.  Note that we do not
   assume achieve them.
   Given that the actions taken to distinguish ETS type packets objectives are
   easy.  Nor, predominantly atomic in this section, do we state the form of this distinc-
   tion.  We simply present nature, the objective of identifying flows that
   relate
   measures used to IEPS versus others that traverse a transit network.

^L
   At an abstract level, the fourth objective pertains address them are to the actions
   taken when an IP telephony call, via a signaling protocol such as
   SIP, cannot be forwarded because the network is experiencing viewed separately with no
   specific dependency upon each other as a form whole.  Various protocols
   and capabilities may be complimentary to each other, but there is no
   need for all to exist given different scenarios of congestion. operation, and
   that ETS support is not viewed as a ubiquitously available service.
   We state divide this in general terms because of two rea-
   sons: a) there may exist applications other than SIP, like H.248, section into 4 areas:

        1) Signaling
        2) Policy
        3) Traffic Engineering
        4) Security
        5) Routing

4.1.  Signaling & State Information

   Signaling is used for call establishment, and b) congestion may come in several
   forms.  For example, congestion may exist at the IP packet layer with
   respect to queues being filled convey various information to their configured limit. Congestion
   may also arise from resource allocation (i.e., QoS) attributed per
   call either intermedi-
   ate nodes or aggregated sets end nodes.  It can be out-of-band of calls.  In this latter case, while there
   may exist resources to forward the packets, a stateful signaling
   server may have reached data flow, and
   thus in a separate flow of its configured limit own, such as to how many telephony
   calls it will support while retaining toll-quality service per call.
   Typically, one terms this form SIP messages.  It can be
   in-band and part of congestion as call blocking.  Note
   that we do not address the case when congestion occurs at state information in a datagram containing
   the bit
   level below that voice data.  This latter example could be realized in the form of IP, due to
   diff-serv code points in the position that it is outside IP packet.

   In the
   scope following subsections, we discuss potential augmentations to
   different types of IP signaling and state information to help support
   the IETF.

   So, given the existence distinction of congestion emergency related communications in its various forms, our
   objective is general, and
   IEPS specifically.

^L

4.1.1.  SIP

   With respect to support ETS-related IP telephony call application level signaling and
   data traffic via non-preemptive actions taken by the network.  More
   specifically, for IP telephony, we associate this objective
   focus our attention to the Session Initiation Protocol (SIP).
   Currently, SIP has an existing "priority" field in the context of IP
   telephony acting as part Request-
   Header-Field that distinguishes different types of the Public Telephone Network (PTN).
   This, as opposed sessions.  The
   five currently defined values are: "emergency", "urgent", "normal",
   "non-urgent", "other-priority".  These values are meant to convey
   importance to the use of IP telephony within a private or stub
   network.  In section 5 below, we expand on this through the descrip-
   tion of two distinct scenarios of IP telephony end-user and its operation have no additional sematics associated
   with
   IEPS and the PSTN.

   It them.

   [15] is important a (soon to mention be) RFC that defines the fourth objective is requirements for a default
   position influenced by existing laws & regulations of some countries.
   Those countries, regions, or private networks not bound by these res-
   trictions can remove this objective and make provisions to enforce
   preemptive action.  In this case, it would probably be advantageous new
   header field for SIP in reference to deploy a signaling system similar resource priority.  This new
   header field is meant to provide an additional measure of distinction
   that proposed in [15],
   wherein multiple levels can influence the behavior of priority are defined gateways and preemption via
   admission control from SIP servers proxies.

4.1.2.  Diff-Serv

   In accordance with [16], the differentiated services code point
   (DSCP) field is enforced. divided into three sets of values.  The fifth objective stipulates that we do not advocate the need or
   expectation for ubiquitous support first set is
   assigned by IANA.  Within this set, there are currently, three types
   of ETS across all administrative
   domains Per Hop Behaviors that have been specified: Default (correlating
   to best effort forwarding), Assured Forwarding, and Expedited For-
   warding.  The second set of the Internet.  While it would DSCP values are set aside for local or
   experimental use.  The third set of DSCP values are also set aside
   for local or experimental use, but may later be desirable reassigned to have ubiqui-
   tous support, we feel IANA in
   case the reliance first set has been completely assigned.

   One candidate approach to consider involves the specification of such a requirement
   new type of Per-Hop Behavior (PHB).  This would doom
   even the contemplation provide a specific
   means of supporting ETS by the IETF and the expected
   entities (e.g., ISPs and vendors) involved in its deployment.

   We use the existing GETS service in the U.S. as an existing example
   in which distinguishing emergency related communications does not need to be ubiqui-
   tous.  As mentioned previously, the measure traffic (signaling and amount user
   data) from other traffic.  The existence of support
   provided this PHB then provides a
   baseline by the U.S. PSTN for GETS does not exist for all U.S. IXCs

^L
   nor LECs.  Given the fact that GETS which specific code points may be defined related to
   various emergency related traffic: authorized emergency sessions
   (e.g., ETS), general public emergency calls (e.g., "911"), MLPP.
   Aggregates would still works within this context,
   it is our objective exist with respect to follow this deployment model such that we can
   accomplish the first objective listed above -- a higher probability bundling of call completion than that applica-
   tions per code point.  Further, one would associate a forwarding
   paradigm aimed at a low loss rate reflective of normal IP telephony call traffic.

   Our final objective is that only authorized users may use the ser-
   vices outlined code point
   selected.  The new PHB could be in this framework.  GETS users are authenticated using
   a PIN provided to the telephony carrier, which signals authentication
   to subsequent networks via the HPC class mark.  In an IP network, the
   authentication center will need to securely signal back to the IP
   ingress point that form of a given user is authorized to send ETS related
   flows.  Similarly, transit networks one or more code
   points that chose to support ETS SLAs
   must securely interchange authorized ETS traffic.  In both cases,
   IPSec authentication transforms may be used to protect this traffic.
   This is entirely separate from end-to-end IPSec protection duplicate EF-type traffic characteristics.  Policies
   would determine if a measure of user
   traffic, which will importance exists per EF-type code-
   point.

   A potential issue that could be configured addressed by users.  IP-PSTN gateways must
   also be able to securely signal ETS authorization for a given flow.
   As these gateways are likely to act as SIP servers, we further con-
   sider the use new PHB involves merge
   points of SIP's security functions to aid this objective.

3.  Value Added Objective

   This objective is viewed as being helpful in achieving flows within a high proba-
   bility diff-serv domain.  With EF, one can expect
   admission control being performed at the edges of call completion.  Its realization within an IP network the domain.
   Presumably, careful traffic engineering would be in applied to avoid

^L
   congestion of EF queues at internal/core merge points stemming from
   flows originating from different ingress nodes of the form diff-serv
   domain.  However, traffic engineering may not be able to compensate
   for congestion of EF-type traffic at the domain's core routers.
   Hence, a new protocols or enhancements PHB that has more than one code point to existing
   ones.  Thus, objectives listed in this section are treated as value
   added -- an expectation identify EF-
   type traffic may address congestion by associating a drop precedence
   for certain types of EF-type datagrams.  Note that their existence local policy and
   SLAs would define which EF-type of traffic, if any, would be beneficial, and
   yet not viewed as critical to support ETS related IP telephony
   traffic.

3.1.  Alternate Path Routing

   This objective involves the ability to discover and use associ-
   ated with a different
   path specific drop precedence.

4.1.3.  Variations Related to route IP telephony traffic around congestion points Diff-Serv and thus
   avoid them.  Ideally, the discovery process Queuing

   One variation to consider with respect to existing diff-serv work
   would be accomplished in
   an expedient manner (possibly even a priori to the need of its
   existence).  At this level, we make no assumptions as to how the
   alternate path is accomplished, define a new or even at which layer it is achieved
   -- e.g., fifth class for the network versus existing AF PHB.
   Unlike the application layer.  But other currently defined classes of 3 levels, this kind new one
   would be based on five levels of
   capability, at least drop precedence.  This increase in a minimal form,
   the number of levels would help contribute conveniently correlate to
   increasing the probability of call completion levels of IEPS traffic by mak-
   ing use
   MLPP, which has five types of noncongested alternate paths.  We use the term "minimal
   form" priorities.  The five levels would also
   correlate to emphasize the fact that care must be taken a recent effort in how the system
   provides alternate paths so it does not significantly contribute to Study Group 11 of the congestion that is ITU to be avoided (e.g., via excess
   control/discovery messages).

^L
   At the time that this document was written, we can identify two
   work-in-progress areas in
   define 5 levels for Emergency Telecommunications Service (ETS).
   Beyond these other standardization efforts, the IETF 5 levels would pro-
   vide a higher level of variance that can could be helpful in providing
   alternate paths for call signaling.  The first is [10], which is
   focused on network layer routing and describes a framework for
   enhancements used to supercede the LDP specification of MPLS to help achieve fault
   tolerance.  This in itself does not provide alternate path routing,
   but rather helps minimize loss in intradomain connectivity when MPLS
   is
   existing 3 levels used within a domain.

   The second effort comes from in the IP Telephony working group and
   involves Telephony Routing over IP (TRIP).  To date, a framework
   document [19] has been published as an RFC which describes other classes.  Hence, if other non-
   emergency aggregate traffic were assigned to the
   discovery and exchange of IP telephony gateway routing tables between
   providers.  The TRIP protocol [22] specifies application level
   telephony routing regardless of new class, the signaling protocol being used
   (e.g., SIP or H.323).  TRIP
   highest drop precedence they are assigned to is modeled after BGP-4 and advertises
   reachability and attributes of destinations.  In its current form,
   several attributes have already been defined, such as LocalPreference
   and MultiExitDisc.  Additional attributes can (3) -- corresponding
   to the other four currently defined classes.  Emergency traffic would
   be registered with
   IANA.

3.2.  End-to-End Fault Tolerance

   This topic involves set to (4) or (5), depending on the work SLA that has been done in trying defined.

   Another variation to compen-
   sate for lossy networks providing best effort service.  In particu-
   lar, we focus on the use of a) Forward Error Correction (FEC), and b)
   redundant transmissions that can Another approach would be used to compensate for lost data
   packets.  (Note that our aim is fault tolerance, as opposed make modifications
   or additions to an
   expectation of always achieving it).

   In the former case, additional FEC data packets are constructed from existing AF PHBs, with their four classes and
   three drop precedences per class.  One could use the existing AF PHBs
   if one assumed that a relatively homogeneous set of original data packets and inserted into the end-to-end
   stream.  Depending on packet flows were
   marked with the algorithm used, these FEC packets can
   reconstruct one same AF class markings (i.e., have only TCP flows, or more of
   only UDP-voice flows, but not both, within a class).  Then one could
   allocate the original set that were lost by lowest drop precedence to the
   network.  An example may be in emergency traffic, and the form of a 10:3 ratio, in which 10
   original packets are used
   other two drop precedences to generate three additional FEC packets.
   Thus, if the network loses 30% or less number rest of packets, then the
   FEC scheme will traffic.

   An original rationale for having three drop precedences was to be
   able to compensate for that loss.  The drawback to separate TCP flows from UDP flows by different drop pre-
   cedences, so UDP packets could be dropped more frequently than TCP
   packets.  TCP flows would reduce their sending rates while UDP likely
   would not, so this approach is that to compensate for the loss, a steady state
   increase in offered load has been injected into could be used to prevent UDP from bullying the network.  This
   makes an arguement that TCP
   traffic.  But if the act design does not create a mixing of protection against loss has con-
   tributed to additional pressures leading TCP and UDP,
   then three drop precedences are not as necessary and one could be
   used for emergency traffic.

   To implement preferential dropping between classes of traffic, with

^L
   one being emergency traffic, one would need to congestion, which in turn
   helps trigger packet loss.  In addition, in using use a ratio more advanced
   form of 10:3,
   the source (or some proxy) must "hold" all 10 packets in order Active Queue Management (AQM).  AQM would need to
   construct protect
   emergency traffic as much as possible until most, if not all, of the three FEC packets.
   non-emergency traffic had been dropped.  This contributes to the end-to-end
   delay would require creation
   of drop probabilities based on counting the packets as well as minor bursts number of load in addition to

^L
   changes packets in jitter.

   The other form of fault tolerance we discuss involves the
   queue for each drop precedence individually.  Instead, current imple-
   mentations use of
   redundant transmissions. By this we mean the case in which an origi-
   nal data packet is followed by one or more redundant packets.  At
   first glance, overall queue fill measurement to make decisions;
   this would appear might cause emergency packets to be even less friendly to the net-
   work than that of adding FEC packets.  However, the encodings dropped.  This new from of the
   redundant packets can
   AQM would be of a different type (or even transcoded into a lower quality) that produce redundant data packets that are signi-
   ficantly smaller than the original packet.

   Two RFCs [24, 25] have been produced that define RTP payloads for FEC
   and redundant audio data.  An implementation example Multiple Average-Multiple Threshold approach, instead
   of a redundant
   audio application can be found in [14].  We note that both FEC and
   redundant transmissions can the Single Average-Multiple Threshold approach used today.

   So, it could be viewed as rather specific and possible to a
   degree tangential solutions regarding packet loss and emergency com-
   munications.  Hence, these topics are placed under use the category current set of
   value added objectives.

4.  Protocols and Capabilities

   In this section, we take AF PHBs if each
   class where reasonably homogenous in the objectives presented above and present traffic mix.  But one might
   still have a
   set need to be able to differentiate three drop precedences
   just within non-emergency traffic.  If so, more drop precedences
   could be implemented.  Also, if one wanted discrimination within
   emergency traffic, as with MLPPs five levels of protocols and capabilities that can precedence, more drop
   precedences might also be used considered.  The five levels would also
   correlate to achieve them.
   Given that the objectives are predominantly atomic a recent effort in nature, the
   measures used to address them are Study Group 11 of the ITU to be viewed separately with no
   specific dependency upon each
   define 5 levels for Emergency Telecommunications Service.

   The other as question with AF PHBs would be whether one should create a whole.  Various protocols
   and capabilities may
   new fifth class.  This might be complimentary to each other, but there is no
   need for all to exist a useful approach, but, given the
   above discussion, a fifth class would only be needed if emergency
   traffic were considered a totally different scenarios type of operation, and
   that ETS support is not viewed as traffic from a ubiquitously available service.
   We divide this section into 4 areas:

        1) Signaling
        2) Policy
        3) Traffic Engineering
        4) Security

4.1.  Signaling & State Information

   Signaling is
   QoS perspective.  Scheduling mechanisms like Weighted Fair Queueing
   and Class Based Queueing are used to convey various information designate a percentage of the
   output link bandwidth that would be used for each class if all queues
   were backlogged.  Its purpose, therefore, it to either intermedi-
   ate nodes manage the rates and
   delays experienced by each class.  But emergency traffic does not
   necessarily require QoS any better or end nodes. different than non-emergency
   traffic.  It can be out-of-band just needs higher probability of completion which could
   be accomplished simply through drop precedences within a data flow, and
   thus in a separate flow of its own, such as SIP messages. class.
   Emergency requirements are primarily related to preferential packet
   dropping probabilities.

   Comments
   --------

   It can be
   in-band and part is important to note that as of the state information in a datagram containing time that this document was
   written, the voice data.  This latter example could be realized IETF is taking a conservative approach in specifying new
   PHBs.  This is because the form number of
   diff-serv code points in the IP packet.

^L
   In the following subsections, we discuss potential augmentations to
   different types of signaling that can be defined
   is relatively small, and state information to help support understandably considered a scarce resource.
   Therefore, the distinction possibility of a new PHB being defined for emergency
   related communications in general, and
   IEPS specifically.

4.1.1.  SIP

   With respect to application level signaling for IP telephony, we
   focus our attention to the Session Initiation Protocol (SIP).
   Currently, SIP has an existing "priority" field in the Request-
   Header-Field that distinguishes different types of sessions.  The
   five currently defined values are: "emergency", "urgent", "normal",
   "non-urgent", "other-priority".  These values are meant to convey
   importance to the end-user and have no additional sematics associated
   with them.

   [15] traffic is at best a (soon to be) RFC long term project that defines may or may not be
   accepted by the requirements IETF.

   In the near term, we would initially recommend using the Assured

^L
   Forwarding (AF) PHB [20] for distinguishing emergency traffic from
   other types of flows.  At a new
   header field minimum, AF could be used for the dif-
   ferent SIP in reference to resource priority.  This new
   header field call signaling messages.  If EF was also supported by the
   domain, then it would be used for IP telephony data packets.  Other-
   wise, another AF class would be used for those data flows.

   It is meant also critical to provide an additional measure of distinction understand that can influence one cannot specify an exact
   code point used exclusively for emergency related data flows.  This
   is because the behavior relevance of gateways and SIP proxies.

4.1.2.  Diff-Serv

   In accordance with [16], the differentiated services a code point
   (DSCP) field is divided into three sets local to the given diff-
   serv domain (i.e., code points are not globally unique per micro-flow
   or aggregate of values. flows).

4.1.4.  RTP

   The first set is
   assigned by IANA.  Within this set, there are currently, three types
   of Per Hop Behaviors that have been specified: Default (correlating
   to best effort forwarding), Assured Forwarding, and Expedited For-
   warding.  The second set of DSCP values are set aside Real-Time Transport Protocol (RTP) provides end-to-end delivery
   services for local or
   experimental use. data with real-time characteristics.  The third set type of DSCP values are also set aside
   for local or experimental use, but may later be reassigned to IANA data
   is generally in
   case the first set form of audio or video type applications, and are
   frequently interactive in nature.  RTP is typically run over UDP and
   has been completely assigned.

   One candidate approach to consider involves the specification of designed with a
   new fixed header that identifies a specific type
   of Per-Hop Behavior (PHB).  This would provide payload representing a specific
   means form of distinguishing emergency related traffic (signaling and user
   data) from other traffic. application media.  The existence
   designers of this PHB then provides a
   baseline by which specific code points may be defined related to
   various emergency related traffic: authorized emergency sessions
   (e.g., ETS), general public emergency calls (e.g., "911"), MLPP.
   Aggregates would still exist with respect RTP also assumed an underlying network providing best
   effort service.  As such, RTP does not provide any mechanism to
   ensure timely delivery or provide other QoS guarantees.  However, the bundling of applica-
   tions per code point.  Further, one would associate a forwarding
   paradigm aimed at a low loss rate reflective
   emergence of the code point
   selected.  The applications like IP telephony, as well as new PHB could be in the form of a one or more code
   points that duplicate EF-type traffic characteristics.  Policies
   would determine IF a measure of importance exists per EF-type code-

^L
   point.

   A potential issue that could be addressed by a service
   models, presents new PHB involves merge
   points of flows within a diff-serv domain.  With EF, one can expect
   admission control being performed at the edges of the domain.
   Presumably, careful environments where RTP traffic engineering would may be applied forwarded
   over networks that support better than best effort service.  Hence,
   the original scope and target environment for RTP has expanded to avoid
   congestion
   include networks providing services other than best effort.

   In 4.1.2, we discussed one means of EF queues at internal/core merge points stemming from
   flows originating from different ingress nodes marking a data packet for emer-
   gencies under the context of the diff-serv
   domain. architecture.  However, traffic engineering may we
   also pointed out that diff-serv markings for specific PHBs are not
   globally unique, and may be able arbitrarily removed or even changed by
   intermediary nodes or domains.  Hence, with respect to compensate
   for congestion emergency
   related data packets, we are still missing an in-band marking in a
   data packet that stays constant on an end-to-end basis.

   There are three choices in defining a persistent marking of EF-type traffic at data
   packets and thus avoid the domain's core routers.
   Hence, transitory marking of diff-serv code
   points.  One can propose a new PHB that has more than one code point to identify EF- dedicated for emergency type
   traffic may address congestion by associating as discussed in 4.1.2.  One can propose a drop precedence
   for certain types specification of EF-type datagrams.  Note that local policy and
   SLAs would define which EF-type of traffic, if any, would be associ-
   ated with a specific drop precedence.

4.1.3.  Variations Related to Diff-Serv and Queuing

   One variation to consider with respect
   new shim layer protocol at some location above IP.  Or, one can add a
   new specification to an existing diff-serv work
   would be application layer protocol.  The
   first two cases are probably the "cleanest" architecturally, but they
   are long term efforts that may not come to define pass because of a new or fifth class for limited
   amount of diff-serv code points and the existing AF PHB.
   Unlike contention that yet another
   shim layer will make the other currently defined classes, this new one would be
   based on five levels of drop precedence.  This increase IP stack too large.  The third case, placing

^L
   a marking in an application layer packet, also has drawbacks; the number
   of levels would conveniently correlate to key
   weakness being the levels of MLPP, which
   has five types specification of priorities.  The five levels would also correlate
   to a recent effort marking on a per-application
   basis.

   Discussions have been held in the Study Group 11 Audio/Visual Transport (AVT) work-
   ing group of the ITU to define 5 lev-
   els for Emergency Telecommunications Service (ETS).  Beyond augmenting RTP so that it can carry a marking that dis-
   tinguishes emergency-related traffic from that which is not.  Specif-
   ically, these
   other standardization efforts, the 5 levels would provide discussions centered on defining a higher
   level of variance new extention that could be used to supercede
   contains a "classifier" field indicating the existing 3 lev-
   els used in condition associated
   with the other classes.  Hence, if other non-emergency aggre-
   gate traffic were assigned to the new class, the highest drop pre-
   cedence they are assigned to is (3) -- corresponding to the other
   four currently defined classes.  Emergency traffic packet (e.g., authorized-emergency, emergency, normal) [29].
   The rationale behind this idea was that focusing on RTP would be set allow
   one to
   (4) or (5), depending rely on the SLA a point of aggregation that has been defined.

   Another variation to Another approach would be to make modifications
   or additions apply to all pay-
   loads that it encapsulates.  However, the existing AF PHB's, with their four classes and
   three drop precedences per class.  One could use AVT group has expressed a
   rough consensus that placing additional classifier state in the existing AF
   PHB's if RTP
   header to denote the importance of one assumed flow over another is not an
   approach that they wish to advance.  Objections ranging from relying
   on SIP to convey importance of a relatively homogeneous set flow, as well as the possibility of packet
   flows
   adversely affecting header compression, were marked with expressed.  There was
   also the same AF class markings (i.e., have only
   TCP flows, or only UDP-voice flows, but not both, within a class).
   Then one could allocate general feeling that the lowest drop precedence to extension header for RTP that acts
   as a signal should not be used.

4.1.5.  MEGACO/H.248

   The Media Gateway Control protocol (MEGACO) [23] defines the emergency
   traffic, interac-
   tion between a media gateway and a media gateway controller.  [23] is
   viewed as common text with ITU-T Recommendation H.248 and is a result
   of applying the other two drop precedences changes of RFC 2886 (Megaco Errata) to the rest text of
   RFC 2885 (Megaco Protocol version 0.8).

   In [23], the
   traffic.

   One original rationale protocol specifies a Priority and Emergency field for having three drop precedences was to be
   able to separate TCP flows from UDP flows by different drop pre-
   cedences, so UDP packets could be dropped more frequently than TCP

^L
   packets.  TCP flows would reduce their sending rates while UDP likely
   would not, so this could be used to prevent UDP a
   context attribute and descriptor.  The Emergency is an optional
   boolean (True or False) condition.  The Priority value, which ranges
   from bullying the TCP
   traffic.  But if 0 through 15, specifies the design does not create precedence handling for a mixing of TCP and UDP,
   then three drop precedences are context.

   The protocol does not as necessary and one could be
   used specify individual values for emergency traffic.

   To implement preferential dropping between classes of traffic, with
   one being emergency traffic, one would need to use a more advanced
   form of Active Queue Management (AQM).  AQM would need to protect
   emergency traffic as much as possible until most, if priority.  We
   also do not all, of recommend the
   non-emergency traffic had been dropped.  This would require creation definition of drop probabilities based on counting a well known value for the number
   MEGAGO priority.  Any values set should be a function of packets in any SLAs
   that have been established regarding the
   queue for each drop handling of emergency
   traffic.  In addition, given that priority values denote precedence individually.  Instead, current imple-
   mentations use an overall queue fill measurement
   (according to make decisions;
   this might cause emergency packets to be dropped.  This new from of
   AQM would be a Multiple Average-Multiple Threshold approach, instead
   of the Single Average-Multiple Threshold Megaco protocol), then by default the ETS telephony
   data flows should probably receive the same priority as other non-
   emergency calls.  This approach used today.

   So, it could be possible to use follows the current set objective of AF PHB's if each
   class where reasonably homogenous in not relying
   on preemption as the traffic mix.  But one might
   still have a need to be able default treatment of emergency-related.

^L

4.2.  Policy

   One of the objectives listed in section 3 above is to differentiate three drop precedences
   just within non-emergency traffic.  If so, more drop precedences
   could be implemented.  Also, if one wanted discrimination within
   emergency treat ETS- sig-
   naling, and related data traffic, as with MLPP's five levels of precedence, more
   drop precedences might also be considered.  The five levels would
   also correlate non-preemptive in nature.
   Further, that this treatment is to a recent effort be the default mode of operation
   or service.  This is in recognition that existing regulations or laws
   of certain countries governing the Study Group 11 establishment of SLAs may not
   allow preemptive actions (e.g., dropping existing telephony flows).
   On the ITU to
   define 5 levels for Emergency Telecommunications Service.

   The other question with AF PHB's would be whether one should create a
   new fifth class.  This might be a useful approach, but, given hand, the
   above discussion, a fifth class would only be needed if emergency
   traffic were considered a totally different type of traffic from a
   QoS perspective.  Scheduling mechanisms like Weighted Fair Queueing laws and Class Based Queueing are used to designate a percentage regulations of other countries
   influencing the
   output link bandwidth that would be used for each class if all queues
   were backlogged.  Its purpose, therefore, it specification of SLA(s) may allow preemption, or even
   require its existence.  Given this disparity, we rely on local policy
   to manage determine the rates and
   delays experienced degree by each class.  But which emergency related traffic does not
   necessarily require QoS any better or different than non-emergency
   traffic.  It just needs higher probability affects
   existing traffic load of completion which could
   be accomplished simply through drop precedences within a class.
   Emergency requirements are primarily related to preferential packet
   dropping probabilities.

   It is important to note given network or ISP.  Important note: we
   reiterate our earlier comment that as of laws and regulations are generally
   outside the time that this document was
   written, scope of the IETF is taking and its specification of designs and
   protocols.  However, these constraints can be used as a conservative approach guide in pro-
   ducing a baseline capability to be supported; in our case, a default
   policy for non-preemptive call establishment of ETS signaling and
   data.

   Policy can be in specifying new
   PHBs.  This is because the number form of code points that static information embedded in various
   components (e.g., SIP servers or bandwidth brokers), or it can be defined
   is relatively small,
   realized and understandably considered a scarce resource.

^L
   Therefore, the possibility supported via COPS with respect to allocation of a new PHB being defined for emergency
   related traffic
   domain's resources [17].  There is at best no requirement as to how policy is
   accomplished.  Instead, if a long term project that may or may not be
   accepted by the IETF.  In the near term, we would initially recommend
   using the Assured Forwarding (AF) PHB [20] for distinguishing emer-
   gency traffic from other types domain follows actions outside of flows.  At a minimum, AF could be
   used for the different SIP call signaling messages.  If EF was also
   supported by the domain,
   default non-preemptive action of ETS related communication, then it would be used for IP telephony data
   packets.  Otherwise, another AF class would be used for those data
   flows.

   It we
   stipulate that some type of policy mechanism is critical in place to understand that one cannot specify an exact code
   point used for emergency related data flows because satisfy
   the relevance local policies of an SLA established for ETS type traffic.

4.3.  Traffic Engineering

   In those cases where a code point is local to network operates under the given diff-serv domain (i.e., they are
   not globally unique per micro-flow constraints of
   SLAs, one or aggregate more of flows).  In addi-
   tion, we which pertains to ETS based traffic, it can expect be
   expected that the existence some form of a codepoint for emergency
   related flows traffic engineering is based on applied to the service level agreements established
   with a given diff-serv domain.

4.1.4.  RTP

   The Real-Time Transport Protocol (RTP) provides end-to-end delivery
   services for data with real-time characteristics.  The
   operation of the network.  We make no recommendations as to which
   type of data traffic engineering mechanism is generally used, but that such a system
   exists in the some form of audio or video type applications, and are
   frequently interactive in nature.  RTP is typically run over UDP can distinguish and
   has been designed with a fixed header that identifies support ETS signaling
   and/or data traffic.  We recommend a specific type review of payload representing [36] by clients and
   prospective providers of ETS service, which gives an overview and a specific form
   set of application media.  The
   designers principles of RTP also assumed an underlying network providing best
   effort service.  As such, RTP does not provide any mechanism Internet traffic engineering.

   MPLS is generally the first protocol that comes to
   ensure timely delivery or provide other QoS guarantees.  However, mind when the
   emergence sub-
   ject of applications like IP telephony, as well as new service
   models, presents new environments where RTP traffic may be forwarded
   over networks that support better than best effort service.  Hence, engineering is brought up.  This notion is heightened
   concerning the original scope and target environment for RTP has expanded to
   include networks providing services other than best effort.

   In 4.1.2, we discussed one means subject of marking a data packet for emer-
   gencies under the context IP telephony because of MPLS's ability to
   permit a quasi-circuit switching capability to be superimposed on the diff-serv architecture.
   current Internet routing model [33].

^L
   However, having cited MPLS, we
   also pointed out need to stress that diff-serv markings for specific PHBs are not
   globally unique, it is an intra-
   domain protocol, and so may be arbitrarily removed or even changed may not exist within a given ISP.
   Other forms of traffic engineering, such as weighted OSPF, may be the
   mechanism of choice by
   intermediary nodes or domains.  Hence, with respect to emergency
   related data packets, we are still missing an in-band marking in ISP.

   As a
   data packet that stays constant on counter example of using a specific protocol to achieve traffic
   engineering, [41] presents an end-to-end basis.

   There are three choices in defining example by one ISP relying on a persistent marking high
   amount of data
   packets and thus avoid the transitory marking overprovisioning within its core to satisfy potentially
   dramatic spikes or bursts of diff-serv code
   points.  One can propose a new PHB dedicated for emergency type traffic as discussed in 4.1.2.  One can propose a specification load.  In this approach, any
   configuring of a

^L
   new shim layer protocol at some location above IP.  Or, one can add a
   new specification queues for specific customers (neighbors) to an existing application layer protocol.  The
   first two cases are probably support
   target QoS is done on the "cleanest" architecturally, but they
   are long term efforts that may not come to pass because egress edge of the transit network.

   Note: As a limited
   amount point of diff-serv code points and the contention that yet another
   shim layer will make reference, existing SLAs established by the IP stack too large.  The third case, placing NCS
   for GETS service tend to focus on a marking in an application layer packet, also has drawbacks; the key
   weakness being the specification maximum allocation of (e.g., 1%)
   of calls allowed to be established through a marking on a per-application
   basis.

   Discussions have been held in given LEC using HPC.
   Once this limit is reached, all other GETS calls experience the Audio/Visual Transport (AVT) work-
   ing group same
   probability of augmenting RTP so call completion as the general public.  It is
   expected, and encouraged, that it can carry ETS related SLAs will have a marking that dis-
   tinguishes emergency-related traffic from that which is not.  Specif-
   ically, these discussions centered on defining a new extention that
   contains a "classifier" field indicating the condition associated limit
   with the packet (e.g., authorized-emergency, emergency, normal) [29].
   The rationale behind this idea was that focusing on RTP would allow
   one to rely on a point of aggregation that would apply to all pay-
   loads that it encapsulates.  However, the AVT group has expressed a
   rough consensus that placing additional classifier state in the RTP
   header respect to denote the importance amount of one flow over another is not traffic distinguished as being emer-
   gency related, and initiated by an
   approach that they wish authorized user.

4.4.  Security

   If ETS support moves from intra-domain PSTN and IP networks to advance.  Objections ranging
   inter-domain end-to-end IP, authenticated service becomes more com-
   plex to provide.  Where an ETS call is carried from relying
   on SIP PSTN to convey importance of a flow, as well PSTN via
   one telephony carrier's backbone IP network, very little IP-specific
   security support is required.  The user authenticates themself as
   usual to the possibility of
   adversely affecting header compression, were expressed.  There was
   also the general feeling that the extension header for RTP that acts
   as network using a signal should not be used.

4.1.5.  MEGACO/H.248 PIN.  The Media Gateway Control protocol (MEGACO) [23] defines gateway from the interac- PSTN connec-
   tion between a media gateway and a media gateway controller.  [23] is
   viewed as common text with ITU-T Recommendation H.248 and is a result
   of applying into the changes of RFC 2886 (Megaco Errata) backbone IP network must be able to signal that the text of
   RFC 2885 (Megaco Protocol version 0.8).

   In [23],
   flow has an ETS label. Conversely, the protocol specifies a Priority and Emergency field for a
   context attribute and descriptor.  The Emergency gateway back into the PSTN
   must similarly signal the call's label. A secure link between the
   gateways may be set up using IPSec or SIP security functionality. If
   the endpoint is an optional
   boolean (True or False) condition.  The Priority value, which ranges IP device, the link may be set up securely from 0 through 15, specifies
   the precedence handling for a context.

   The protocol does not specify individual values for priority.  We
   also do not recommend ingress gateway to the definition of a well known value for end device.

   As flows traverse more than one IP network, domains whose peering
   agreements include ETS support must have the
   MEGAGO priority.  Any values set should be means to securely signal
   a function of any SLAs

^L
   that have been established regarding given flow's ETS status. They may choose to use physical link secu-
   rity and/or IPSec authentication, combined with traffic conditioning
   measures to limit the handling amount of emergency
   traffic.  In addition, given ETS traffic that priority values denote precedence
   (according to may pass between the Megaco protocol), then by default
   two domains. The inter-domain agreement may require the originating
   network to take responsibility for ensuring only authorized traffic
   is marked with ETS telephony
   data flows should probably receive the same priority as other non-
   emergency calls.  This approach follows priority; the objective of not relying
   on preemption as downstream domain may still perform
   redundant conditioning to prevent the default treatment propagation of emergency-related.

4.2.  Policy

   One of the objectives listed in section 3 above is to treat ETS- sig-
   naling, theft and related data traffic, as non-preemptive in nature.
   Further, that this treatment is to be the default mode denial
   of operation service attacks.  Security may be provided between ingress and
   egress gateways or service.  This is in recognition that existing regulations IP endpoints using IPSec or laws
   of certain countries governing SIP security

^L
   functions.

   When a call originates from an IP device, the establishment of SLAs ingress network may not
   allow preemptive actions (e.g., dropping existing telephony flows).
   On the other hand, the laws and regulations of other countries
   influencing the specification
   authorize IEPS traffic over that link as part of SLA(s) may allow preemption, or even
   require its existence.  Given this disparity, we rely on local policy
   to determine user authentica-
   tion procedures. These authentication procedures may occur at the degree by which emergency related traffic affects
   existing traffic load of a given network
   link or ISP.  Important note: we
   reiterate our earlier comment that laws and regulations network layers, but are generally
   outside entirely at the scope discretion of the IETF and
   ingress network. That network must decide how often it should update
   its specification list of designs authorized ETS users based on the bounds it is prepared
   to accept on traffic from recently-revoked users.

4.5.  Alternate Path Routing

   This subject involves the ability to discover and
   protocols.  However, these constraints can be used as a guide in pro-
   ducing use a baseline capability different
   path to route IP telephony traffic around congestion points and thus
   avoid them.  Ideally, the discovery process would be supported; accomplished in our case,
   an expedient manner (possibly even a default
   policy for non-preemptive call establishment of ETS signaling and
   data.

   Policy can be in the form of static information embedded in various
   components (e.g., SIP servers or bandwidth brokers), or it can be
   realized and supported via COPS with respect priori to allocation the need of a
   domain's resources [17].  There is its
   existence).  At this level, we make no requirement assumptions as to how policy the
   alternate path is
   accomplished.  Instead, if a domain follows actions outside of accomplished, or even at which layer it is achieved
   -- e.g., the
   default non-preemptive action of ETS related communication, then we
   stipulate that some type network versus the application layer.  But this kind of policy mechanism is
   capability, at least in place a minimal form, would help contribute to satisfy
   increasing the local policies probability of an SLA established for ETS type traffic.

4.3.  Traffic Engineering

   In those cases where a network operates under the constraints of
   SLAs, one or more call completion by making use of which pertains
   noncongested alternate paths.  We use the term "minimal form" to ETS based traffic, it can
   emphasize the fact that care must be
   expected taken in how the system provides
   alternate paths so it does not significantly contribute to the
   congestion that some form of traffic engineering is applied to be avoided (e.g., via excess control/discovery
   messages).

   At the
   operation of the network.  We make no recommendations as to which
   type of traffic engineering mechanism is used, but time that such a system
   exists this document was written, we can identify two areas
   in some form and the IETF that can distinguish and support ETS signaling
   and/or data traffic.  We recommend a review of [36] by clients and
   prospective providers of ETS service, be helpful in providing alternate paths for call
   signaling.  The first is [10], which gives an overview is focused on network layer
   routing and describes a

^L
   set of principles of Internet traffic engineering.

   MPLS is generally the first protocol that comes framework for enhancements to mind when the sub-
   ject LDP specif-
   ication of traffic engineering is brought up. MPLS to help achieve fault tolerance.  This notion in itself does
   not provide alternate path routing, but rather helps minimize loss in
   intradomain connectivity when MPLS is heightened
   concerning the subject of IP telephony because of MPLS's ability to
   permit used within a quasi-circuit switching capability to be superimposed on domain.

   The second effort comes from the
   current Internet routing model [33].

   However, having cited MPLS, we need to stress that it is an intra-
   domain protocol, IP Telephony working group and so may or may not exist within
   involves Telephony Routing over IP (TRIP).  To date, a given ISP.
   Other forms of traffic engineering, such framework
   document [19] has been published as weighted OSPF, may be the
   mechanism of choice by an ISP.

   Note: As a point of reference, existing SLAs established by RFC which describes the NCS
   for GETS service tend to focus on a maximum allocation of (e.g., 1%)
   discovery and exchange of calls allowed to be established through a given LEC using HPC.
   Once this limit is reached, all other GETS calls experience the same
   probability IP telephony gateway routing tables between
   providers.  The TRIP protocol [22] specifies application level
   telephony routing regardless of call completion as the general public.  It signaling protocol being used
   (e.g., SIP or H.323).  TRIP is
   expected, modeled after BGP-4 and encouraged, that ETS related SLAs will have a limit
   with respect to the amount advertises
   reachability and attributes of traffic distinguished destinations.  In its current form,
   several attributes have already been defined, such as being emer-
   gency related, and initiated by an authorized user.

4.4.  Security

   If ETS support moves from intra-domain PSTN LocalPreference
   and IP networks to
   inter-domain end-to-end IP, authenticated service becomes more com-
   plex to provide.  Where an ETS call MultiExitDisc.  Additional attributes can be registered with
   IANA.

^L
   Inter-domain routing is carried from PSTN to PSTN via
   one telephony carrier's backbone IP network, very little IP-specific
   security not an area that should be considered in
   terms of alternate path routing support is required. for ETS.  The user authenticates themself as
   usual to Border Gateway
   Protocol is currently strained in meetings its existing requirements,
   and thus adding additional features that would generate an increase
   in advertised routes will not be well received by the network using IETF.  Refer to
   [42] for a PIN.  The gateway from commentary on Inter-Domain routing.

4.6.  End-to-End Fault Tolerance

   This topic involves the PSTN connec-
   tion into work that has been done in trying to compen-
   sate for lossy networks providing best effort service.  In particu-
   lar, we focus on the backbone IP network must use of a) Forward Error Correction (FEC), and b)
   redundant transmissions that can be able used to signal compensate for lost data
   packets.  (Note that the
   flow has our aim is fault tolerance, as opposed to an ETS label. Conversely,
   expectation of always achieving it).

   In the gateway back former case, additional FEC data packets are constructed from
   a set of original data packets and inserted into the PSTN
   must similarly signal the call's label. A secure link between end-to-end
   stream.  Depending on the
   gateways may be set up using IPSec algorithm used, these FEC packets can
   reconstruct one or SIP security functionality. If more of the endpoint is an IP device, original set that were lost by the link
   network.  An example may be set up securely from in the ingress gateway form of a 10:3 ratio, in which 10
   original packets are used to generate three additional FEC packets.
   Thus, if the network loses 30% or less number of packets, then the
   FEC scheme will be able to compensate for that loss.  The drawback to
   this approach is that to compensate for the loss, a steady state
   increase in offered load has been injected into the end device.

   As flows traverse more than one IP network, domains whose peering
   agreements include ETS support must have network.  This
   makes an arguement that the means act of protection against loss has con-
   tributed to securely signal additional pressures leading to congestion, which in turn
   helps trigger packet loss.  In addition, in using a given flow's ETS status. They may choose ratio of 10:3,
   the source (or some proxy) must "hold" all 10 packets in order to use physical link secu-
   rity and/or IPSec authentication, combined with traffic conditioning
   measures
   construct the three FEC packets.  This contributes to limit the amount end-to-end
   delay of ETS traffic that may pass between the
   two domains. packets as well as minor bursts of load in addition to
   changes in jitter.

   The inter-domain agreement may require other form of fault tolerance we discuss involves the originating
   network to take responsibility for ensuring only authorized traffic
   is marked with ETS priority; use of
   redundant transmissions. By this we mean the downstream domain may still perform case in which an origi-
   nal data packet is followed by one or more redundant conditioning packets.  At
   first glance, this would appear to be even less friendly to prevent the propagation net-
   work than that of theft and denial adding FEC packets.  However, the encodings of service attacks.  Security may the
   redundant packets can be provided between ingress of a different type (or even transcoded into
   a lower quality) that produce redundant data packets that are signi-
   ficantly smaller than the original packet.

   Two RFCs [24, 25] have been produced that define RTP payloads for FEC
   and

^L
   egress gateways or IP endpoints using IPSec or SIP security func-
   tions.

   When redundant audio data.  An implementation example of a call originates from an IP device, the ingress network may
   authorize IEPS traffic over redundant
   audio application can be found in [14].  We note that link both FEC and
   redundant transmissions can be viewed as part of its user authentica-
   tion procedures. These authentication procedures may occur at the
   link or network layers, but rather specific and to a

^L
   degree tangential solutions regarding packet loss and emergency com-
   munications.  Hence, these topics are entirely at the discretion of placed under the
   ingress network. That network must decide how often it should update
   its list category of authorized ETS users based on the bounds it is prepared
   to accept on traffic from recently-revoked users.
   value added objectives.

5.  Key Scenarios

   There are various scenarios in which IP telephony can be realized,
   each of which can imply a unique set of functional requirements that
   may include just a subset of those listed above.  We acknowledge that
   a scenario may exist whose functional requirements are not listed
   above.  Our intention is not to consider every possible scenario by
   which support for emergency related IP telephony can be realized.
   Rather, we narrow our scope using a single guideline; we assume there
   is a signaling & data interaction between the PSTN and the IP network
   with respect to supporting emergency-related telephony traffic.  We
   stress that this does not preclude an IP-only end-to-end model, but
   rather the inclusion of the PSTN expands the problem space and
   includes the current dominant form of voice communication.

   Note: as stated in section 1.2, [36] provides a more extensive set of
   scenarios in which IP telephony can be deployed.  Our selected set
   below is only meant to provide an couple of examples of how the pro-
   tocols and capabilities presented in Section 3 can play a role.

   Single IP Administrative Domain
   -------------------------------

   This scenario is a direct reflection of the evolution of the PSTN.
   Specifically, we refer to the case in which data networks have
   emerged in various degrees as a backbone infrastructure connecting
   PSTN switches at its edges.  This represents a single isolated IP
   administrative domain that has no directly adjacent IP domains con-
   nected to it.  We show an example of this scenario below in Figure 1.
   In this example, we show two types of telephony carriers.  One is the
   legacy carrier, whose infrastructure retains the classic switching
   architecture attributed to the PSTN.  The other is the next genera-
   tion carrier, which uses a data network (e.g., IP) as its core
   infrastructure, and Signaling Gateways at its edges.  These gateways
   "speak" SS7 externally with peering carriers, and another protocol

^L
   (e.g., SIP) internally, which rides on top of the IP infrastructure.

^L
     Legacy            Next Generation            Next Generation
     Carrier              Carrier                    Carrier
     *******          ***************             **************
     *     *          *             *     ISUP    *            *
    SW<--->SW <-----> SG <---IP---> SG <--IAM--> SG <---IP---> SG
     *     *   (SS7)  *     (SIP)   *    (SS7)    *    (SIP)   *
     *******          ***************             **************

                                        SW - Telco Switch
                                        SG - Signaling Gateway

                            Figure 1

   The significant aspect of this scenario is that all the resources of
   each IP "island" fall within a given administrative authority.
   Hence, there is not a problem of retaining toll quality Grade of Ser-
   vice as the voice traffic (data and signaling) exits the IP network
   because of the existing SS7 provisioned service between telephony
   carriers.  Thus, the need for support of mechanisms like diff-serv,
   and an expansion of the defined set of Per-Hop Behaviors is reduced
   (if not eliminated) under this scenario.

   Another function that has little or no importance within the closed
   IP environment of Figure 1 is that of IP security.  The fact that
   each administrative domain peers with each other as part of the PSTN,
   means that existing security, in the form of Personal Identification
   Number (PIN) authentication (under the context of telephony infras-
   tructure protection), is the default scope of security.  We do not
   claim that the reliance on a PIN based security system is highly
   secure or even desirable.  But, we use this system as a default
   mechanism in order to avoid placing additional requirements on exist-
   ing authorized emergency telephony systems.

   Multiple IP Administrative Domains
   ----------------------------------

   We view the scenario of multiple IP administrative domains as a
   superset of the previous scenario.  Specifically, we retain the
   notion that the IP telephony system peers with the existing PSTN.  In
   addition, segments

   (i.e., portions of the Internet) may exchange signaling with other IP
   administrative domains via non-PSTN signaling protocols like SIP.

^L
     Legacy           Next Generation            Next Generation
     Carrier              Carrier                    Carrier
     *******          ***************            **************
     *     *          *             *            *            *
    SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
     *     *   (SS7)  *     (SIP)   *    (SIP)   *    (SIP)   *
     *******          ***************            **************

                                          SW - Telco Switch
                                          SG - Signaling Gateway

                           Figure 2

   Given multiple IP domains, and the presumption that SLAs relating to
   ETS traffic may exist between them, the need for something like
   diff-serv grows with respect to being able to distinguish the emer-
   gency related traffic from other types of traffic.  In addition, IP
   security becomes more important between domains in order to ensure
   that the act of distinguishing ETS-type traffic is indeed valid for
   the given source.

   We conclude this section by mentioning a complimentary work in pro-
   gress in providing ISUP transparency across SS7-SIP interworking
   [37].  The objective of this effort is to access services in the SIP
   network and yet maintain transparency of end-to-end PSTN services.
   Not all services are mapped (as per the design goals of [37], so we
   anticipate the need for an additional document to specify the mapping
   between new SIP labels and existing PSTN code points like NS/EP and
   MLPP.

6.  Security Considerations

   Information on this topic is presented in sections 2 and 4.

7.  References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Braden, R., et. al., "Integrated Services in the Internet
      Architecture: An Overview", Informational, RFC 1633, June 1994.

   3  Braden, R., et. al., "Resource Reservation Protocol (RSVP)

^L
      Version 1, Functional Specification", Proposed Standard, RFC
      2205, Sept. 1997.

   4  Shenker, S., et. al., "Specification of Guaranteed Quality of
      Service", Proposed Standard, RFC 2212, Sept 1997.

   5  Wroclawski, J., "Specification for Controlled-Load Network
      Service Element", Proposed Standard, RFC 2211, Sept 1997.

   6  Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6
      Reservations", Proposed Standard, RFC 3175, September 2001.

   7  Berger, L, et. al., "RSVP Refresh Overhead Reduction Extensions",
      Proposed Standard, RFC 2961, April, 2001.

   8  Blake, S., et. al., "An Architecture for Differentiated
      Service", Proposed Standard, RFC 2475, Dec. 1998.

   9  Faucheur, F., et. al., "MPLS Support of Differentiated Services",
      Standards Track, RFC 3270, May 2002.

   10 Sharma, V., Hellstrand, F., “Framework "Framework for MPLS-Based Recovery”, Recovery",
      Informational, RFC 3469, February 2003

   11 Postel, J., "Simple Mail Transfer Protocol", Standard, RFC 821,
      August 1982.

   12 Handley, M., et. al., "SIP: Session Initiation Protocol",
      Proposed Standard, RFC 2543, March 1999.

   13 ANSI, "Signaling System No. 7(SS7) _ 7(SS7), High Probability of
      Completion (HPC) Network Capability_, Capability", ANSI T1.631-1993, (R1999).

   14 Robust Audio Tool (RAT):
      http://www-mice.cs.ucl.ac.uk/multimedia/software/rat

   15 Schulzrinne, H, "Requirements for Resource Priority Mechanisms for
      the Session Initiation Protocol", Internet Draft, Work In Pro-
   gress,
      December, 2001. Informational, RFC 3487,
      February 2003

   16 Nichols, K., et. al.,"Definition of the Differentiated Services
      Field (DS Field) in the Ipv4 and Ipv6 Headers", Proposed
      Standard, RFC 2474, December 1998.

   17 Durham, D., "The COPS (Common Open Policy Service) Protocol",
      Proposed Standard, RFC 2748, Jan 2000.

^L

   18 ITU, "International Emergency Preparedness Scheme", ITU

^L
      Recommendation, E.106, March 2000.

   19 Rosenburg, J., Schulzrinne, H., "A Framework for Telephony Routing
      Over IP", Informational, RFC 2871, June 2000

   20 Heinanen. et. al, "Assured Forwarding PHB Group", Proposed
      Standard, RFC 2597, June 1999

   21 ITU, "Multi-Level Precedence and Preemption Service, ITU,
      Recomendation, I.255.3, July, 1990.

   22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)",
      Standards Track, RFC 3219, January 2002.

   23 Cuervo, F., et. al, "Megaco Protocol Version 1.0", Standards
      Track, RFC 3015, November 2000

   24 Perkins, C., et al., "RTP Payload for Redundant Audio Data",
      Standards Track, RFC 2198, September, 1997

   25 Rosenburg, J., Schulzrinne, H., "An RTP Payload Format for
      Generic Forward Error Correction", Standards Track, RFC 2733,
      December, 1999.

   26 ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-2000,
      2000.

   27 Brown, I., "Securing IEPS over IP", White Paper,
      http://iepscheme.net/docs/secure_IEPS.doc

   28 "Description of an International Emergency Preference
      Scheme (IEPS)", ITU-T Recommendation  E.106 March, 2002

   29 Carlberg, K., "The Classifier Extension Header for RTP", Internet
      Draft, Work In Progress, October 2001.

   30 National Communications System: http://www.ncs.gov

   31 Bansal, R., Ravikanth, R., "Performance Measures for Voice on IP",
      http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/,
      IETF Presentation: IPPM-Voiceip, Aug, 1997

   32 Hardman, V., et al, "Reliable Audio for Use over the Internet",
      Proceedings, INET'95, Aug, 1995.

   33 Awduche, D, et al, "Requirements for Traffic Engineering Over
      MPLS", Informational, RFC 2702,  September, 1999.

^L
   34 Polk, J., "An Architecture for Multi-Level Precedence and
      Preemption over IP", Internet Draft, Work In Progress,
      November, 2001.

   35 "Service Class Designations for H.323 Calls", ITU
      Recommendation H.460.4, November, 2002

   36 Awduche, D., et. al., "Overview and Principles of Internet Traffic
      Engineering", Informational, RFC 3272, May 2002.

   37 Vemuri, A., Peterson, J., "SIP for Telephones (SIP-T): Context and
      Architectures", work in progress, Internet-Draft, June, 2002. Best Current Practice, RFC 3372, September 2002

   38 Polk, J., “IEPREP "IEPREP Telephony Topology Scenarios”, Work in Progress, Internet-
      Draft, December, 2002 Terminology", Informational,
      RFC 3523, April 2003

   39 Carlberg, K., Atkinson, R., “General "General Requirements for Emergency
      Telecommunications Service”, Service", Work in Progress, Internet-Draft,
      January, 2003

   40 Carlberg, K., Atkinson, R., “IP "IP Telephony Requirements for
      Emergency Telecommunications Service”, Service", Work In Progress, Internet-
      Draft, January, 2003

   41 Meyers, D., "Some Thoughts on CoS and Backbone Networks"
      http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf
      IETF Presentation: IEPREP, Dec, 2002

   42 Huston, G., "Commentary on Inter-Domain Routing In the Internet",
      Informational, RFC 3221, December 2001.

8.  Appendix A: Government Telephone Preference Scheme (GTPS)

   This framework document uses the T1.631 and ITU IEPS standard as a
   target model for defining a framework for supporting authorized emer-
   gency related communication within the context of IP telephony.  We
   also use GETS as a helpful model to draw experience from.  We take
   this position because of the various areas that must be considered;
   from the application layer to the (inter)network layer, in addition
   to policy, security (authorized access), and traffic engineering.

   The U.K. has a different type of authorized use of telephony services
   referred to as the Government Telephone Preference Scheme (GTPS).  At
   present, GTPS only applies to a subset of the local loop lines of
   within the UK.  The lines are divided into Categories 1, 2, and 3.

^L
   The first two categories involve authorized personnel involved in
   emergencies such as natural disasters.  Category 3 identifies the
   general public.  Priority marks, via C7/NUP, are used to bypass
   call-gaping for a given Category.  The authority to activate GTPS has
   been extended to either a central or delegated authority.

^L

8.1.  GTPS and the Framework Document

   The design of the current GTPS, with its designation of preference
   based on physical static devices, precludes the need for several
   aspects presented in this document.  However, one component that can
   have a direct correlation is the labeling capability of the proposed
   Resource Priority extension to SIP.  A new label mechanism for SIP
   could allow a transparent interoperation between IP telephony and the
   U.K. PSTN that supports GTPS.

9.  Appendix B: Related Standards Work

   The process of defining various labels to distinguish calls has been,
   and continues to be, pursued in other standards groups.  As mentioned
   in section 1.1.1, the ANSI T1S1 group has previously defined a label
   SS7 ISUP Initial Address Message.  This single label or value is
   referred to as the National Security and Emergency Preparedness
   (NS/EP) indicator and is part of the T1.631 standard.  The following
   subsections presents a snap shot of parallel on-going efforts in
   various standards groups.

   It is important to note that the recent activity in other groups have
   gravitated to defining 5 labels or levels of priority.  The impact of
   this approach is minimal in relation to this ETS framework document
   because it simply generates a need to define a set of corresponding
   labels for the resource priority header of SIP.

9.1.  Study Group 16 (ITU)

   Study Group 16 (SG16) of the ITU is responsible for studies relating
   to multimedia service definition and multimedia systems, including
   protocols and signal processing.

   A contribution [35] has been accepted by this group that adds a
   Priority Class parameter to the call establishment messages of H.323.
   This class is further divided into two parts; one for Priority Value
   and the other is a Priority Extension for indicating subclasses.  It
   is this former part that roughly corresponds to the labels tran-
   sported

^L
   transported via the Resource Priority field for SIP [15].

   The draft recommendation advocates defining PriorityClass information
   that would be carried in the GenericData parameter in the H323-UU-PDU
   or RAS messages.  The GenericData parameter contains Priori-
   tyClassGenericData.  The PriorityClassInfo of the PriorityClassGener-
   icData contains the Priority and Priority Extension fields.

^L

   At present, 5 levels have been defined for the Priority Value part of
   the Priority Class parameter: Low, Normal, High, Emergency-Public,
   Emergency-Authorized. An additional 8-bit priority extension has been
   defined to provide for subclasses of service at each priority.

   The suggested ASN.1 definition of the service class is the following:

      ServiceClassInfo ::= SEQUENCE
      {
        priority   CHOICE
         {
           emergencyAuthorized  NULL,
           emergencyPublic      NULL,
           high                 NULL,
           normal               NULL,
           low                  NULL
         }
        priorityExtension       INTEGER (0..255) OPTIONAL;
        requiredClass           NULL OPTIONAL
        tokens                  SEQUENCE OF ClearToken OPTIONAL
        cryptoTokens            SEQUENCE OF CryptoH323Token OPTIONAL
      }

   The advantage in using the GenericData parameter is that an existing
   parameter is used, as opposed to defining a new parameter and causing
   subsequent changes in existing H.323/H.225 documents.

10.  Acknowledgments

   The authors would like to acknowledge the helpful comments, opinions,
   and clarifications of Stu Goldman, James Polk, Dennis Berg, as well
   as those comments received from the IEPS and IEPREP mailing lists.
   Additional thanks to Peter Walker of Oftel for private discussions on
   the operation of GTPS, and Gary Thom on clarifications of the SG16
   draft contribution.

^L

11.  Author's Addresses

   Ken Carlberg                            Ian Brown
   University College London               University College London
   Department of Computer Science          Department of Computer Science
   Gower Street                            Gower Street
   London, WC1E 6BT                        London, WC1E 6BT
   United Kingdom                          United Kingdom

^L

   Cory Beard
   University of Missouri-Kansas City
   Division of Computer Science
   Electrical Engineering
   5100 Rockhill Road
   Kansas City, MO  64110-2499
   USA
   BeardC@umkc.edu

^L
                           Table of Contents

1. Introduction ...................................................    2
1.1  Emergency Related Data .......................................    3
1.1.1  Government Emergency Telecommunications Service (GETS) .....    4
1.1.2  International Emergency Preparedness Scheme (IEPS) .........    4
1.2  Scope of this Document .......................................    4
2.  Objective .....................................................    6
3.  Value Added Objective .........................................    9
3.1  Alternate Path Routing .......................................    9
3.2  End-to-End Fault Tolerance ...................................   10  Considerations ................................................    6
4.  Protocols and Capabilities ....................................   11    7
4.1  Signaling & State Information ................................   11    7
4.1.1  SIP ........................................................   12    8
4.1.2  Diff-Serv ..................................................   12    8
4.1.3  Variations Related to Diff-Serv and Queuing ................   13    9
4.1.4  RTP ........................................................   15   11
4.1.5  MEGACO/H.248 ...............................................   16   12
4.2  Policy .......................................................   17   13
4.3  Traffic Engineering ..........................................   17   13
4.4  Security .....................................................   18   14
4.5  Alternate Path Routing .......................................   15
4.6  End-to-End Fault Tolerance ...................................   16
5.  Key Scenarios .................................................   19   17
6.  Security Considerations .......................................   21   19
7.  References ....................................................   21   19
8.  Appendix A: Government Telephone Preference Scheme (GTPS) .....   24   22
8.1  GTPS and the Framework Document ..............................   25   23
9.  Appendix B: Related Standards Work ............................   25   23
9.1  Study Group 16 (ITU) .........................................   25   23
10.  Acknowledgments ..............................................   26   24
11.  Author's Addresses ...........................................   26   25

Full Copyright Statement

   "Copyright (C) The Internet Society (date). 2003. All Rights Reserved.  This
   document and translations of it may be copied and furnished to
   others, oth-
   ers, and derivative works that comment on or otherwise explain it or
   assist in its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other

^L
   Internet organizations, except as needed for the purpose of develop-
   ing Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or as
   required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided as an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR MER-
   CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.