<pre>Network Working Group                                        K. Carlberg
Request for Comments: 4190                                           G11
Category: Informational                                         I. Brown
                                                                     UCL
                                                                C. Beard
                                                                    UMKC
                                                           November 2005


                       <span class="h1">Framework for Supporting</span>
       <span class="h1">Emergency Telecommunications Service (ETS) in IP Telephony</span>

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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
   service in the Public Switched Telephone Network (PSTN), contribute
   to a constrained solution space.














<span class="grey">Carlberg, et al.             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
      <a href="#section-1.1">1.1</a>. Emergency Related Data .....................................<a href="#page-4">4</a>
           1.1.1. Government Emergency Telecommunications
                  Service (GETS) ......................................<a href="#page-4">4</a>
           <a href="#section-1.1.2">1.1.2</a>. International Emergency Preparedness Scheme (IEPS) ..5
      <a href="#section-1.2">1.2</a>. Scope of This Document .....................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Objective .......................................................<a href="#page-7">7</a>
   <a href="#section-3">3</a>. Considerations ..................................................<a href="#page-7">7</a>
   <a href="#section-4">4</a>. Protocols and Capabilities ......................................<a href="#page-7">7</a>
      <a href="#section-4.1">4.1</a>. Signaling and State Information ............................<a href="#page-8">8</a>
           <a href="#section-4.1.1">4.1.1</a>. SIP .................................................<a href="#page-8">8</a>
           <a href="#section-4.1.2">4.1.2</a>. Diff-Serv ...........................................<a href="#page-8">8</a>
           <a href="#section-4.1.3">4.1.3</a>. Variations Related to Diff-Serv and Queuing .........<a href="#page-9">9</a>
           <a href="#section-4.1.4">4.1.4</a>. RTP ................................................<a href="#page-10">10</a>
           <a href="#section-4.1.5">4.1.5</a>. GCP/H.248 ..........................................<a href="#page-11">11</a>
      <a href="#section-4.2">4.2</a>. Policy ....................................................<a href="#page-12">12</a>
      <a href="#section-4.3">4.3</a>. Traffic Engineering .......................................<a href="#page-12">12</a>
      <a href="#section-4.4">4.4</a>. Security ..................................................<a href="#page-13">13</a>
           <a href="#section-4.4.1">4.4.1</a>. Denial of Service ..................................<a href="#page-13">13</a>
           <a href="#section-4.4.2">4.4.2</a>. User Authorization .................................<a href="#page-14">14</a>
           <a href="#section-4.4.3">4.4.3</a>. Confidentiality and Integrity ......................<a href="#page-15">15</a>
      <a href="#section-4.5">4.5</a>. Alternate Path Routing ....................................<a href="#page-16">16</a>
      <a href="#section-4.6">4.6</a>. End-to-End Fault Tolerance ................................<a href="#page-17">17</a>
   <a href="#section-5">5</a>. Key Scenarios ..................................................<a href="#page-18">18</a>
      <a href="#section-5.1">5.1</a>. Single IP Administrative Domain ...........................<a href="#page-18">18</a>
      <a href="#section-5.2">5.2</a>. Multiple IP Administrative Domains ........................<a href="#page-19">19</a>
   <a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-20">20</a>
   <a href="#section-7">7</a>. Informative References .........................................<a href="#page-20">20</a>
   <a href="#appendix-A">Appendix A</a>: Government Telephone Preference Scheme (GTPS) .........<a href="#page-24">24</a>
      <a href="#appendix-A.1">A.1</a>.  GTPS and the Framework Document ..........................<a href="#page-24">24</a>
   <a href="#appendix-B">Appendix B</a>: Related Standards Work ................................<a href="#page-24">24</a>
      <a href="#appendix-B.1">B.1</a>.  Study Group 16 (ITU) .....................................<a href="#page-25">25</a>
   Acknowledgements ..................................................<a href="#page-26">26</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   The Internet has become the primary target for worldwide
   communications in terms of recreation, business, and various
   imaginative 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, implies
   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.



<span class="grey">Carlberg, et al.             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   In an attempt to go beyond best effort service, [<a href="#ref-1" title="&quot;Integrated Services in the Internet Architecture: an Overview&quot;">1</a>] presented an
   overview of Integrated Services (int-serv) and its inclusion into the
   Internet architecture.  This was followed by [<a href="#ref-2" title="&quot;Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification&quot;">2</a>], which specified the
   RSVP signaling protocol used to convey QoS requirements.  With the
   addition of [<a href="#ref-3" title="&quot;Specification of Guaranteed Quality of Service&quot;">3</a>] and [<a href="#ref-4" title="&quot;Specification of the Controlled-Load Network Element Service&quot;">4</a>], specifying controlled load (bandwidth
   bounds) and guaranteed service (bandwidth &amp; delay bounds),
   respectively, 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 applies 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.  [<a href="#ref-5" title="&quot;Aggregation of RSVP for IPv4 and IPv6 Reservations&quot;">5</a>] and [<a href="#ref-6" title="&quot;RSVP Refresh Overhead Reduction Extensions&quot;">6</a>] 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 [<a href="#ref-7" title="&quot;An Architecture for Differentiated Service&quot;">7</a>], which presented an architecture for
   Differentiated Services (diff-serv).  This effort focused on a more
   aggregated perspective and classification of packets than that of
   [<a href="#ref-1" title="&quot;Integrated Services in the Internet Architecture: an Overview&quot;">1</a>].  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
   established by IANA, or set aside as experimental.  It can be
   expected that sets of microflows, a granular identification of a set
   of packets, 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
   additional traffic load experienced by ISPs over the years has
   continued to place a high importance on intra-domain traffic
   engineering.  The explosion of IETF contributions, in the form of
   drafts and RFCs produced in the area of Multi-Protocol Label
   Switching (MPLS), exemplifies 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



<span class="grey">Carlberg, et al.             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   of differentiated services [<a href="#ref-8" title="&quot;Multi-Protocol Label Switching (MPLS) Support of Differentiated Services&quot;">8</a>], and the ongoing work in the inclusion
   of fast bandwidth recovery of routing failures for MPLS [<a href="#ref-9" title="&quot;Framework for Multi-Protocol Label Switching (MPLS)-based Recovery&quot;">9</a>].

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Emergency Related Data</span>

   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.

   [<a id="ref-10">10</a>] has defined a priority field for SMTP, but it is only for
   mapping with X.400 and is not meant for general usage.  SIP [<a href="#ref-11" title="&quot;SIP: Session Initiation Protocol&quot;">11</a>] has
   an embedded field denoting "priority", but it is only targeted toward
   the end-user and is not meant to provide an indication to the
   underlying network or end-to-end applications.

   Given the emergence of IP telephony, a natural inclusion of its
   service is an ability 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 there exist emergency telephone services
   that involve authorized usage, as described in the following
   subsection.

<span class="h4"><a class="selflink" id="section-1.1.1" href="#section-1.1.1">1.1.1</a>.  Government Emergency Telecommunications Service (GETS)</span>

   GETS is an emergency telecommunications service available in the U.S.
   and is overseen by the National Communications System (NCS) -- an
   office established by the White House under an executive order [<a href="#ref-27">27</a>]
   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 a few).  In
   addition, a select set of individuals from private industry
   (telecommunications companies, utilities, etc.) that are involved in
   critical infrastructure recovery operations are also provided access
   to GETS.

   The purpose of GETS is to achieve a high probability that phone
   service will be available to selected authorized personnel in times
   of emergencies, 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.




<span class="grey">Carlberg, et al.             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   GETS is based in part on the ANSI T1.631 standard, specifying a High
   Probability of Completion (HPC) for SS7 signaling [<a href="#ref-12" title="&quot;Signaling System No. 7(SS7), High Probability of Completion (HPC) Network Capability&quot;">12</a>][24].

<span class="h4"><a class="selflink" id="section-1.1.2" href="#section-1.1.2">1.1.2</a>.  International Emergency Preparedness Scheme (IEPS)</span>

   [<a id="ref-25">25</a>] is a recent ITU standard that describes emergency-related
   communications over the 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
   queuing, 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).

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Scope of This Document</span>

   The scope of this document centers on the near and mid-term support
   of ETS within the context of IP telephony versus 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 that some form of
   application layer signaling is used to explicitly establish and
   maintain voice data traffic.  This explicit signaling capability
   provides the hooks from which VoIP traffic can be bridged to the
   PSTN.

   An example of this distinction is when the Robust Audio Tool (RAT)
   [<a href="#ref-13">13</a>] begins sending VoIP packets to a unicast (or multicast)
   destination.  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
   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.  [<a href="#ref-28" title="&quot;Performance Measures for Voice on IP&quot;">28</a>]
   makes an argument that there is a maximum packet loss and delay for
   VoIP traffic, and that 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 be
   considered acceptable.  [<a href="#ref-29" title="&quot;Reliable Audio for Use over the Internet&quot;">29</a>] discusses the same topic and makes an
   argument that packet size plays a significant role in what users
   tolerate as "intelligible" VoIP.  The larger the packet, correlating
   to a longer sampling rate, the lower the acceptable rate of loss.
   Note that [<a href="#ref-28" title="&quot;Performance Measures for Voice on IP&quot;">28</a>, <a href="#ref-29" title="&quot;Reliable Audio for Use over the Internet&quot;">29</a>] provide only two of several perspectives in
   examining VoIP.  A more in-depth discussion on this topic is outside



<span class="grey">Carlberg, et al.             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   the scope of this document, though it should be noted that the choice
   of codec can significantly alter the above results.

   Regardless of a single and definitive characteristic for stressed
   conditions, it would seem that interactive voice has a lower
   threshold of some combinations of loss/delay/jitter than elastic
   applications such as email or web browsers.  This places a higher
   burden on the problem 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 to understand the
   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 expectations.  In particular,
   we wish to avoid any temptation of trying to replicate the exact
   capabilities of existing emergency voice service that are 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.

   <a href="#section-2">Section 2</a> 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
   capabilities.  <a href="#section-3">Section 3</a> presents additional value-added objectives,
   which are viewed as useful, but not critical.  <a href="#section-4">Section 4</a> presents
   protocols and capabilities that relate or can play a role in support
   of the objectives articulated in <a href="#section-2">Section 2</a>.  Finally, <a href="#section-5">Section 5</a>
   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 ([<a href="#ref-34" title="&quot;Internet Emergency Preparedness (IEPREP) Telephony Topology Terminology&quot;">34</a>]
   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 <a href="#section-4">Section 4</a> 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
   dedicated links.



<span class="grey">Carlberg, et al.             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Objective</span>

   The objective of this document is to present a framework that
   describes how various protocols and capabilities (or mechanisms) can
   facilitate and support the traffic from ETS users.  In several cases,
   we provide a bit of background in each area so that the reader is
   given some context and a more in-depth understanding.  We also
   provide some discussion on aspects about a given protocol or
   capability that could be explored and potentially advanced to support
   ETS.  This exploration is not to be confused with specific solutions
   since we do not articulate exactly what must be done (e.g., a new
   header field, or a new code point).

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Considerations</span>

   When producing a solution, or examining existing protocols and
   mechanisms, there are some things that should be considered.  One is
   that inter-domain ETS communications should not rely on ubiquitous or
   even widespread support along the path between the end points.
   Potentially, at the network layer there may exist islands of support
   realized in the form of overlay networks.  There may also be cases
   where solutions may be constrained on an end-to-end basis (i.e., at
   the transport or application layer).  It is this diversity and
   possibly partial support that needs to be 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-
   related communications.  The effort in interoperating with these
   systems, presumably through gateways or similar types of nodes with
   IETF protocols, would foster a need to distinguish ETS flows from
   other flows.  One reason would be the scenario of triggering ETS
   service from an IP network.

   Finally, we take into consideration the requirements of [<a href="#ref-35" title="&quot;General Requirements for Emergency Telecommunication Service (ETS)&quot;">35</a>, <a href="#ref-36" title="&quot;IP Telephony Requirements for Emergency Telecommunication Service (ETS)&quot;">36</a>] in
   discussing the protocols and mechanisms below in <a href="#section-4">Section 4</a>.  In doing
   this, we do not make a one-to-one mapping of protocol discussion a
   requirement.  Rather, we make sure the discussion of <a href="#section-4">Section 4</a> does
   not violate any of the requirements in [<a href="#ref-35" title="&quot;General Requirements for Emergency Telecommunication Service (ETS)&quot;">35</a>, <a href="#ref-36" title="&quot;IP Telephony Requirements for Emergency Telecommunication Service (ETS)&quot;">36</a>].

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Protocols and Capabilities</span>

   In this section, we take the objectives presented above and present a
   set of protocols and capabilities that can be used to achieve them.
   Given that the objectives are predominantly atomic in nature, the
   measures used to address them are to be viewed separately with no
   specific dependency upon each other as a whole.  Various protocols
   and capabilities may be complimentary to each other, but there is no



<span class="grey">Carlberg, et al.             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   need for all to exist, given different scenarios of operation; and
   ETS support is not expected to be an ubiquitously available service.
   We divide this section into 5 areas:

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

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Signaling and State Information</span>

   Signaling is used to convey various information to either
   intermediate nodes or end nodes.  It can be out-of-band of a data
   flow, and thus in a separate flow of its own, such as SIP messages.
   It can be in-band and part of the state information in a datagram
   containing the voice data.  This latter example could be realized in
   the form of diff-serv code points in the IP packet.

   In the following subsections, we discuss the current state of some
   protocols and their use in providing support for ETS.  We also
   discuss potential augmentations to different types of signaling and
   state information to help support the distinction of emergency-
   related communications in general.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  SIP</span>

   With respect to application-level signaling for IP telephony, we
   focus our attention on 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 values currently defined are: "emergency", "urgent", "normal",
   "non-urgent", "other-priority".  These values are meant to convey
   importance to the end-user and have no additional semantics
   associated with them.

   [<a id="ref-14">14</a>] is an RFC that defines the requirements for a new header field
   for SIP in reference to resource priority.  The requirements are
   meant to lead to a means of providing an additional measure of
   distinction that can influence the behavior of gateways and SIP
   proxies.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Diff-Serv</span>

   In accordance with [<a href="#ref-15" title="&quot;Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers&quot;">15</a>], the differentiated services code point
   (DSCP) field is divided into three sets of values.  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



<span class="grey">Carlberg, et al.             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   to best effort forwarding), Assured Forwarding, and Expedited
   Forwarding.  The second set of 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 reassigned to IANA if
   the first set has been completely assigned.

   One approach discussed on the IEPREP mailing list is the
   specification of a new Per-Hop Behaviour (PHB) for emergency-related
   flows.  The rationale behind this idea is that it would provide a
   baseline by which specific code points may be defined for various
   emergency-related traffic: authorized emergency sessions (e.g., ETS),
   general public emergency calls (e.g., "911"), Multi-Level Precedence
   and Preemption (MLPP) [<a href="#ref-19" title="July">19</a>], etc.  However, in order to define a new
   set of code points, a forwarding characteristic must also be defined.
   In other words, one cannot simply identify a set of bits without
   defining their intended meaning (e.g., the drop precedence approach
   of Assured Forwarding).  The one caveat to this statement are the set
   of DSCP bits set aside for experimental purposes.  But as the name
   implies, experimental is for internal examination and use and not for
   standardization.

      Note:

         It is important to note that at the time this document was
         written, the IETF had been taking a conservative approach in
         specifying new PHBs.  This is because the number of code points
         that can be defined is relatively small and is understandably
         considered a scarce resource.  Therefore, the possibility of a
         new PHB being defined for emergency-related traffic is, at
         best, a long term project that may or may not be accepted by
         the IETF.

         In the near term, we would initially suggest using the Assured
         Forwarding (AF) PHB [<a href="#ref-18" title="&quot;Assured Forwarding PHB Group&quot;">18</a>] for distinguishing emergency traffic
         from other types of flows.  At a minimum, AF could be used for
         the different SIP call signaling messages.  If the Expedited
         Forwarding (EF) PHB [<a href="#ref-40" title="&quot;An Expedited Forwarding PHB (Per-Hop Behavior)&quot;">40</a>] was also supported by the domain, then
         it would be used for IP telephony data packets.  Otherwise,
         another AF class would be used for those data flows.

<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>.  Variations Related to Diff-Serv and Queuing</span>

   Scheduling mechanisms like Weighted Fair Queueing and Class Based
   Queueing are used to designate a percentage of the output link
   bandwidth that would be used for each class if all queues were
   backlogged.  Its purpose, therefore, is to manage the rates and
   delays experienced by each class.  But emergency traffic may not
   necessarily require QoS perform any better or differently than non-



<span class="grey">Carlberg, et al.             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   emergency traffic.  It may just need higher probability of being
   forwarded to the next hop, which could be accomplished simply by
   dropping precedences within a class.

   To implement preferential dropping between classes of traffic, one of
   which is emergency traffic, one would probably need to use a more
   advanced form of Active Queue Management (AQM).  Current
   implementations use an overall queue fill measurement to make
   decisions; this might cause emergency classified packets to be
   dropped.  One new form of AQM could be a Multiple Average-Multiple
   Threshold approach, instead of the Single Average-Multiple Threshold
   approach used today.  This allows creation of drop probabilities
   based on counting the number of packets in the queue for each drop
   precedence individually.

   So, it could be possible to use the current set of AF PHBs if each
   class were reasonably homogenous in the traffic mix.  But one might
   still have a need to differentiate three drop precedences within
   non-emergency traffic.  If so, more drop precedences could be
   implemented.  Also, if one wanted discrimination within emergency
   traffic, as with MLPP's five levels of precedence, more drop
   precedences might also be considered.  The five levels would also
   correlate to a recent effort in Study Group 11 of the ITU to define 5
   levels for Emergency Telecommunications Service.

<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>.  RTP</span>

   The Real-Time Transport Protocol (RTP) provides end-to-end delivery
   services for data with real-time characteristics.  The type of data
   is generally in the form of audio or video type applications, and is
   frequently interactive in nature.  RTP is typically run over UDP and
   has been designed with a fixed header that identifies a specific type
   of payload representing a specific form of application media.  The
   designers of 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
   emergence of applications like IP telephony, as well as new service
   models, present new environments where RTP traffic may be forwarded
   over networks that support better than best effort service.  Hence,
   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 of marking a data packet for
   emergencies under the context of the diff-serv architecture.
   However, we also pointed out that diff-serv markings for specific
   PHBs are not globally unique, and may be arbitrarily removed or even
   changed by intermediary nodes or domains.  Hence, with respect to




<span class="grey">Carlberg, et al.             Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   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 data
   packets and thus avoiding the transitory marking 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 of a
   new shim layer protocol at some location above IP.  Or, one can add a
   new specification to an existing application layer protocol.  The
   first two cases are probably the "cleanest" architecturally, but they
   are long term efforts that may not come to pass because of a limited
   number of diff-serv code points and the contention that yet another
   shim layer will make the IP stack too large.  The third case, placing
   a marking in an application layer packet, also has drawbacks; the key
   weakness being the specification of a marking on a per-application
   basis.

   Discussions have been held in the Audio/Visual Transport (AVT)
   working group on augmenting RTP so that it can carry a marking that
   distinguishes emergency-related traffic from that which is not.
   Specifically, these discussions centered on defining a new extension
   that contains a "classifier" field indicating the condition
   associated with the packet (e.g., authorized-emergency, emergency,
   normal) [<a href="#ref-26" title="&quot;The Classifier Extension Header for RTP&quot;">26</a>].  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 payloads that it encapsulates.  However, the AVT group
   has expressed a rough consensus that placing an additional classifier
   state in the RTP header to denote the importance of one flow over
   another is not an approach they wish to advance.  Objections ranging
   from relying on SIP to convey the importance of a flow, 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 a signal should not be used.

<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>.  GCP/H.248</span>

   The Gateway Control Protocol (GCP) [<a href="#ref-21" title="&quot;Gateway Control Protocol Version 1&quot;">21</a>] defines the interaction
   between a media gateway and a media gateway controller.  [<a href="#ref-21" title="&quot;Gateway Control Protocol Version 1&quot;">21</a>] is
   viewed as an updated version of common text with ITU-T Recommendation
   H.248 [<a href="#ref-41" title="&quot;Gateway Control Protocol&quot;">41</a>] and is a result of applying the changes of <a href="./rfc2886">RFC 2886</a>
   (Megaco Errata) [<a href="#ref-43" title="&quot;Megaco Errata&quot;">43</a>] to the text of <a href="./rfc2885">RFC 2885</a> (Megaco Protocol version
   0.8) [<a href="#ref-42" title="&quot;Megaco Protocol version 0.8&quot;">42</a>].

   In [<a href="#ref-21" title="&quot;Gateway Control Protocol Version 1&quot;">21</a>], the protocol specifies a Priority and Emergency field for a
   context attribute and descriptor.  The Emergency is an optional
   boolean (True or False) condition.  The Priority value, which ranges
   from 0 through 15, specifies the precedence handling for a context.




<span class="grey">Carlberg, et al.             Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   The protocol does not specify individual values for priority.  We
   also do not recommend the definition of a well known value for the
   GCP priority as this is out of scope of this document.  Any values
   set should be a function of any SLAs that have been established
   regarding the handling of emergency traffic.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Policy</span>

   One of the objectives listed in <a href="#section-3">Section 3</a> above is to treat ETS
   signaling, and related data traffic, as non-preemptive in nature.
   Further, this treatment is to be the default mode of operation or
   service.  This is in recognition that existing regulations or laws of
   certain countries governing the establishment of SLAs 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 of SLA(s) may allow preemption, or even require its
   existence.  Given this disparity, we rely on local policy to
   determine the degree by which emergency-related traffic affects
   existing traffic load of a given network or ISP.  Important note: we
   reiterate our earlier comment that laws and regulations are generally
   outside the scope of the IETF and its specification of designs and
   protocols.  However, these constraints can be used as a guide in
   producing 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 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 to allocation of a
   domain's resources [<a href="#ref-16" title="&quot;The COPS (Common Open Policy Service) Protocol&quot;">16</a>].  There is no requirement as to how policy is
   accomplished.  Instead, if a domain follows actions outside of the
   default non-preemptive action of ETS-related communication, then we
   stipulate that some type of policy mechanism be in place to satisfy
   the local policies of an SLA established for ETS-type traffic.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Traffic Engineering</span>

   In those cases where a network operates under the constraints of
   SLAs, one or more of which pertains to ETS-based traffic, it can be
   expected that some form of traffic engineering is applied to the
   operation of the network.  We make no recommendations as to which
   type of traffic engineering mechanism is used, but that such a system
   exists in some form and can distinguish and support ETS signaling
   and/or data traffic.  We recommend a review of [<a href="#ref-32" title="&quot;Overview and Principles of Internet Traffic Engineering&quot;">32</a>] by clients and
   prospective providers of ETS service that gives an overview and a set
   of principles of Internet traffic engineering.





<span class="grey">Carlberg, et al.             Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   MPLS is generally the first protocol that comes to mind when the
   subject of traffic engineering is brought up.  This notion is
   heightened concerning the subject of IP telephony because of MPLS's
   ability to permit a quasi-circuit switching capability to be
   superimposed on the current Internet routing model [<a href="#ref-30" title="&quot;Requirements for Traffic Engineering Over MPLS&quot;">30</a>].

   However, having cited MPLS, we need to stress that it is an
   intradomain protocol, and so may or may not exist within a given ISP.
   Other forms of traffic engineering, such as weighted OSPF, may be the
   mechanism of choice by an ISP.

   As a counter example of using a specific protocol to achieve traffic
   engineering, [<a href="#ref-37" title="&quot;Some Thoughts on CoS and Backbone Networks&quot;">37</a>] presents an example of one ISP relying on a high
   amount of overprovisioning within its core to satisfy potentially
   dramatic spikes or bursts of traffic load.  In this approach, any
   configuring of queues for specific customers (neighbors) to support
   the target QoS is done on the egress edge of the transit network.

   Note: As a point of reference, existing SLAs established by the NCS
   for GETS service tend to focus on a loosely defined maximum
   allocation of, for example, 1% to 10% of calls allowed to be
   established through a given LEC using HPC.  It is expected, and
   encouraged, that ETS related SLAs of ISPs will be limited with
   respect to the amount of traffic distinguished as being emergency
   related and initiated by an authorized user.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Security</span>

   This section provides a brief overview of the security issues raised
   by ETS support.

<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Denial of Service</span>

   Any network mechanism that enables a higher level of priority for a
   specific set of flows could be abused to enhance the effectiveness of
   denial of service (DoS) attacks.  Priority would magnify the effects
   of attack traffic on bandwidth availability in lower-capacity links,
   and increase the likelihood of it reaching its target(s).  An attack
   could also tie up resources such as circuits in a PSTN gateway.

   Any provider deploying a priority mechanism (such as the QoS systems
   described in <a href="#section-4.1">Section 4.1</a>) must therefore carefully apply the
   associated access controls and security mechanisms.  For example, the
   priority level for traffic originating from an unauthorized part of a
   network or ingress point should be reset to normal.  Users must also
   be authenticated before being allowed to use a priority service (see
   <a href="#section-4.4.2">Section 4.4.2</a>).  However, this authentication process should be
   lightweight to minimise opportunities for denial of service attacks



<span class="grey">Carlberg, et al.             Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   on the authentication service itself, and ideally should include its
   own anti-DoS mechanisms.  Other security mechanisms may impose an
   overhead that should be carefully considered to avoid creating other
   opportunities for DoS attacks.

   As mentioned in <a href="#section-4.3">Section 4.3</a>, SLAs for ETS facilities often contain
   maximum limits on the level of ETS traffic that should be prioritised
   in a particular network (say 1% of the maximum network capacity).
   This should also be the case in IP networks to again reduce the level
   of resources that a denial of service attack can consume.

   As of this writing, a typical inter-provider IP link uses 1 Gbps
   Ethernet, OC-48 SONET/SDH, or some similar or faster technology.
   Also, as of this writing, it is not practical to deploy per-IP packet
   cryptographic authentication on such inter-provider links, although
   such authentication might well be needed to provide assurance of IP-
   layer label integrity in the inter-provider scenario.

   While Moore's Law will speed up cryptographic authentication, it is
   unclear whether that is helpful because the speed of the typical
   inter-domain link is also increasing rapidly.

<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>.  User Authorization</span>

   To prevent theft of service and reduce the opportunities for denial
   of service attacks, it is essential that service providers properly
   verify the authorization of a specific traffic flow before providing
   it with ETS facilities.

   Where an ETS call is carried from PSTN to PSTN via one telephony
   carrier's backbone IP network, very little IP-specific user
   authorization support is required.  The user authenticates itself to
   the PSTN as usual -- for example, using a PIN in the US GETS.  The
   gateway from the PSTN connection into the backbone IP network must be
   able to signal that the flow has an ETS label.  Conversely, the
   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 to protect the integrity of the signaling
   information against attackers who have gained access to the backbone
   network, and to prevent such attackers from placing ETS calls using
   the egress PSTN gateway.  If the destination of a call is an IP
   device, the signaling should be protected directly between the IP
   ingress gateway and the end device.

   When ETS priority is being provided to a flow within one domain, that
   network must use the security features of the priority mechanism
   being deployed to ensure that the flow has originated from an
   authorized user or process.



<span class="grey">Carlberg, et al.             Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   The access network may authorize ETS traffic over a link as part of
   its user authentication procedures.  These procedures may occur at
   the link, network, or higher layers, but are at the discretion of a
   single domain network.  That network must decide how often it should
   update its list of authorized ETS users based on the bounds it is
   prepared to accept on traffic from recently-revoked users.

   If ETS support moves from intra-domain PSTN and IP networks to
   inter-domain end-to-end IP, verifying the authorization of a given
   flow becomes more complex.  The user's access network must verify a
   user's ETS authorization if network-layer priority is to be provided
   at that point.

   Administrative domains that agree to exchange ETS traffic must have
   the means to securely signal to each other a given flow's ETS status.
   They may use physical link security combined with traffic
   conditioning measures to limit the amount of ETS traffic that may
   pass between the two domains.  This agreement must require the
   originating network to take responsibility for ensuring that only
   authorized traffic is marked with ETS priority, but the recipient
   network cannot rely on this happening with 100% reliability.  Both
   domains should perform conditioning to prevent the propagation of
   theft and denial of service attacks.  Note that administrative
   domains that agree to exchange ETS traffic must deploy facilities
   that perform these conditioning and security services at every point
   at which they interconnect with one another.

   Processes using application-layer protocols, such as SIP, should use
   the security functionality in those protocols to verify the
   authorization of a session before allowing it to use ETS mechanisms.

<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>.  Confidentiality and Integrity</span>

   When ETS communications are being used to respond to a deliberate
   attack, it is important that they cannot be altered or intercepted to
   worsen the situation -- for example, by changing the orders to first
   responders such as firefighters, or by using knowledge of the
   emergency response to cause further damage.

   The integrity and confidentiality of such communications should
   therefore be protected as far as possible using end-to-end security
   protocols such as IPSec or the security functionality in SIP and SRTP
   [<a href="#ref-39" title="&quot;The Secure Real-time Transport Protocol (SRTP)&quot;">39</a>].  Where communications involve other types of networks such as
   the PSTN, the IP side should be protected and any security
   functionality available in the other network should be used.






<span class="grey">Carlberg, et al.             Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Alternate Path Routing</span>

   This subject involves the ability to discover and use a different
   path to route IP telephony traffic around congestion points, and thus
   avoid them.  Ideally, the discovery process 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, or even at which layer it is achieved
   -- e.g., the network versus the application layer.  But this kind of
   capability, at least in a minimal form, would help contribute to
   increasing the probability of ETS call completion by making use of
   noncongested alternate paths.  We use the term "minimal form" to
   emphasize the fact that care must be taken in how the system provides
   alternate paths so that it does not significantly contribute to the
   congestion that is to be avoided (e.g., via excess control/discovery
   messages).

   Routing protocols at the IP network layer, such as BGP and OSPF,
   contain mechanisms for determining link failure between routing
   peers.  The discovery of this failure automatically causes
   information to be propagated to other routers.  The form of this
   information, the extent of its propagation, and the convergence time
   in determining new routes is dependent on the routing protocol in
   use.  In the example of OSPF's Equal Cost Multiple Path (ECMP), the
   impact of link failure is minimized because of pre-existing alternate
   paths to a destination.

   At the time this document was written, we can identify two additional
   areas in the IETF that can be helpful in providing alternate paths
   for the specific case of call signaling.  The first is [<a href="#ref-9" title="&quot;Framework for Multi-Protocol Label Switching (MPLS)-based Recovery&quot;">9</a>], which is
   focused on network layer routing and describes a framework for
   enhancements to 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 used within a domain.

   The second effort comes from the IP Telephony working group and
   involves Telephony Routing over IP (TRIP).  To date, a framework
   document [<a href="#ref-17" title="&quot;A Framework for Telephony Routing over IP&quot;">17</a>] has been published as an RFC that describes the
   discovery and exchange of IP telephony gateway routing tables between
   providers.  The TRIP protocol [<a href="#ref-20" title="&quot;Telephony Routing over IP (TRIP)&quot;">20</a>] specifies application level
   telephony routing regardless of the signaling protocol being used
   (e.g., SIP or H.323).  TRIP 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 be registered with
   IANA.




<span class="grey">Carlberg, et al.             Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   Inter-domain routing is not an area that should be considered in
   terms of additional alternate path routing support for ETS.  The
   Border Gateway Protocol is currently strained in meeting its existing
   requirements, and thus adding additional features that would generate
   an increase in advertised routes will not be well received by the
   IETF.  Refer to [<a href="#ref-38" title="&quot;Commentary on Inter-Domain Routing in the Internet&quot;">38</a>] for a commentary on Inter-Domain routing.

<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  End-to-End Fault Tolerance</span>

   This topic involves work that has been done in trying to compensate
   for lossy networks providing best effort service.  In particular, we
   focus on the use of a) Forward Error Correction (FEC), and b)
   redundant transmissions that can be used to compensate for lost data
   packets.  (Note that our aim is fault tolerance, as opposed to an
   expectation of always achieving it.)

   In the former case, additional FEC data packets are constructed from
   a set of original data packets and inserted into the end-to-end
   stream.  Depending on the algorithm used, these FEC packets can
   reconstruct one or more of the original set that were lost by the
   network.  An example may be in the 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% of packets or less, 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 network.  This
   makes an argument that the act of protection against loss has
   contributed to additional pressures leading to congestion, which in
   turn helps trigger packet loss.  In addition, by using a ratio of
   10:3, the source (or some proxy) must "hold" all 10 packets in order
   to construct the three FEC packets.  This contributes to the end-to-
   end delay of the packets, as well as minor bursts of load, in
   addition to changes in jitter.

   The other form of fault tolerance we discuss involves the use of
   redundant transmissions.  By this we mean the case in which an
   original data packet is followed by one or more redundant packets.
   At first glance, this would appear to be even less friendly to the
   network than that of adding FEC packets.  However, the encodings of
   the redundant packets can be of a different type (or even transcoded
   into a lower quality) that produce redundant data packets that are
   significantly smaller than the original packet.

   Two RFCs [<a href="#ref-22" title="&quot;RTP Payload for Redundant Audio Data&quot;">22</a>, <a href="#ref-23" title="&quot;An RTP Payload Format for Generic Forward Error Correction&quot;">23</a>] have been produced that define RTP payloads for FEC
   and redundant audio data.  An implementation example of a redundant
   audio application can be found in [<a href="#ref-13">13</a>].  We note that both FEC and
   redundant transmissions can be viewed as rather specific, and to a
   degree tangential, solutions regarding packet loss and emergency



<span class="grey">Carlberg, et al.             Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   communications.  Hence, these topics are placed under the category of
   value-added objectives.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Key Scenarios</span>

   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 and 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 <a href="#section-1.2">Section 1.2</a>, [<a href="#ref-32" title="&quot;Overview and Principles of Internet Traffic Engineering&quot;">32</a>] provides a more extensive set of
   scenarios in which IP telephony can be deployed.  Our selected set
   below is only meant to provide a couple of examples of how the
   protocols and capabilities presented in <a href="#section-3">Section 3</a> can play a role.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Single IP Administrative Domain</span>

   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 scenario represents a single
   isolated IP administrative domain that has no directly adjacent IP
   domains connected 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 generation 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 (e.g., SIP) internally, which rides on top of the IP
   infrastructure.












<span class="grey">Carlberg, et al.             Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


    Legacy            Next Generation            Next Generation
    Carrier              Carrier                    Carrier
    *******          ***************             **************
    *     *          *             *     ISUP    *            *
   SW&lt;---&gt;SW &lt;-----&gt; SG &lt;---IP---&gt; SG &lt;--IAM--&gt; SG &lt;---IP---&gt; SG
    *     *   (SS7)  *     (SIP)   *    (SS7)    *    (SIP)   *
    *******          ***************             **************

               SW - Telco Switch, SG - Signaling Gateway

                           Figure 1

   The significant aspect of this scenario is that all the resources f
   each IP "island" falls within a given administrative authority.
   Hence, there is not a problem in retaining PSTN type QoS for voice
   traffic (data and signaling) exiting the IP network.  Thus, the need
   for support of mechanisms like diff-serv in the presence of
   overprovisioning, and an expansion of the defined set of Per-Hop
   Behaviors, is reduced 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
   infrastructure 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
   existing authorized emergency telephony systems.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Multiple IP Administrative Domains</span>

   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.












<span class="grey">Carlberg, et al.             Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


    Legacy           Next Generation            Next Generation
    Carrier              Carrier                    Carrier
    *******          ***************            **************
    *     *          *             *            *            *
   SW&lt;---&gt;SW &lt;-----&gt; SG &lt;---IP---&gt; SG &lt;--IP--&gt; SG &lt;---IP---&gt; 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
   emergency 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 complementary work in
   progress in providing ISUP transparency across SS7-SIP interworking
   [<a href="#ref-33" title="&quot;Session Initiation Protocol for Telephones (SIP-T): Context and Architectures&quot;">33</a>].  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 [<a href="#ref-33" title="&quot;Session Initiation Protocol for Telephones (SIP-T): Context and Architectures&quot;">33</a>]), 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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   Information on this topic is presented in sections <a href="#section-2">2</a> and <a href="#section-4">4</a>.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Informative References</span>

   [<a id="ref-1">1</a>]  Braden, R., Clark, D., and S. Shenker, "Integrated Services in
        the Internet Architecture: an Overview", <a href="./rfc1633">RFC 1633</a>, June 1994.

   [<a id="ref-2">2</a>]  Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
        "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
        Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.

   [<a id="ref-3">3</a>]  Shenker, S., Partridge, C., and R. Guerin, "Specification of
        Guaranteed Quality of Service", <a href="./rfc2212">RFC 2212</a>, September 1997.




<span class="grey">Carlberg, et al.             Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   [<a id="ref-4">4</a>]  Wroclawski, J., "Specification of the Controlled-Load Network
        Element Service", <a href="./rfc2211">RFC 2211</a>, September 1997.

   [<a id="ref-5">5</a>]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
        "Aggregation of RSVP for IPv4 and IPv6 Reservations", <a href="./rfc3175">RFC 3175</a>,
        September 2001.

   [<a id="ref-6">6</a>]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
        Molendini, "RSVP Refresh Overhead Reduction Extensions", <a href="./rfc2961">RFC</a>
        <a href="./rfc2961">2961</a>, April 2001.

   [<a id="ref-7">7</a>]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
        Weiss, "An Architecture for Differentiated Service", <a href="./rfc2475">RFC 2475</a>,
        December 1998.

   [<a id="ref-8">8</a>]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P.,
        Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label
        Switching (MPLS) Support of Differentiated Services", <a href="./rfc3270">RFC 3270</a>,
        May 2002.

   [<a id="ref-9">9</a>]  Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol
        Label Switching (MPLS)-based Recovery", <a href="./rfc3469">RFC 3469</a>, February 2003.

   [<a id="ref-10">10</a>] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
        between X.400 and <a href="./rfc822">RFC 822</a>/MIME", <a href="./rfc2156">RFC 2156</a>, January 1998.

   [<a id="ref-11">11</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>, June 2002.

   [<a id="ref-12">12</a>] ANSI, "Signaling System No. 7(SS7), High Probability of
        Completion (HPC) Network Capability", ANSI T1.631-1993, (R1999).

   [<a id="ref-13">13</a>] Robust Audio Tool (RAT):  <a href="http://www-mice.cs.ucl.ac.uk/multimedia/software/rat">http://www-</a>
        <a href="http://www-mice.cs.ucl.ac.uk/multimedia/software/rat">mice.cs.ucl.ac.uk/multimedia/software/rat</a>

   [<a id="ref-14">14</a>] Schulzrinne, H., "Requirements for Resource Priority Mechanisms
        for the Session Initiation Protocol (SIP)", <a href="./rfc3487">RFC 3487</a>, February
        2003.

   [<a id="ref-15">15</a>] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
        the Differentiated Services Field (DS Field) in the IPv4 and
        IPv6 Headers", <a href="./rfc2474">RFC 2474</a>, December 1998.

   [<a id="ref-16">16</a>] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A.
        Sastry, "The COPS (Common Open Policy Service) Protocol", <a href="./rfc2748">RFC</a>
        <a href="./rfc2748">2748</a>, January 2000.




<span class="grey">Carlberg, et al.             Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   [<a id="ref-17">17</a>] Rosenberg, J. and H. Schulzrinne, "A Framework for Telephony
        Routing over IP", <a href="./rfc2871">RFC 2871</a>, June 2000.

   [<a id="ref-18">18</a>] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
        Forwarding PHB Group", <a href="./rfc2597">RFC 2597</a>, June 1999.

   [<a id="ref-19">19</a>] ITU, "Multi-Level Precedence and Preemption Service, ITU,
        Recommendation, I.255.3, July, 1990.

   [<a id="ref-20">20</a>] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing
        over IP (TRIP)", <a href="./rfc3219">RFC 3219</a>, January 2002.

   [<a id="ref-21">21</a>] Groves, C., Pantaleo, M., Anderson, T., and T. Taylor, "Gateway
        Control Protocol Version 1", <a href="./rfc3525">RFC 3525</a>, June 2003.

   [<a id="ref-22">22</a>] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
        Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
        for Redundant Audio Data", <a href="./rfc2198">RFC 2198</a>, September 1997.

   [<a id="ref-23">23</a>] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
        Generic Forward Error Correction", <a href="./rfc2733">RFC 2733</a>, December 1999.

   [<a id="ref-24">24</a>] ANSI, "Signaling System No. 7, ISDN User Part", ANSI T1.113-
        2000, 2000.

   [<a id="ref-25">25</a>] "Description of an International Emergency Preference Scheme
        (IEPS)", ITU-T Recommendation  E.106 March, 2002

   [<a id="ref-26">26</a>] Carlberg, K., "The Classifier Extension Header for RTP", Work In
        Progress, October 2001.

   [<a id="ref-27">27</a>] National Communications System: <a href="http://www.ncs.gov">http://www.ncs.gov</a>

   [<a id="ref-28">28</a>] Bansal, R., Ravikanth, R., "Performance Measures for Voice on
        IP", <a href="http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/">http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-</a>
        <a href="http://www.ietf.org/proceedings/97aug/slides/tsv/ippm-voiceip/">voiceip/</a>, IETF Presentation: IPPM-Voiceip, Aug, 1997

   [<a id="ref-29">29</a>] Hardman, V., et al, "Reliable Audio for Use over the Internet",
        Proceedings, INET'95, Aug, 1995.

   [<a id="ref-30">30</a>] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
        McManus, "Requirements for Traffic Engineering Over MPLS", <a href="./rfc2702">RFC</a>
        <a href="./rfc2702">2702</a>, September 1999.

   [<a id="ref-31">31</a>] "Service Class Designations for H.323 Calls", ITU Recommendation
        H.460.4, November, 2002.





<span class="grey">Carlberg, et al.             Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


   [<a id="ref-32">32</a>] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. Xiao,
        "Overview and Principles of Internet Traffic Engineering", <a href="./rfc3272">RFC</a>
        <a href="./rfc3272">3272</a>, May 2002.

   [<a id="ref-33">33</a>] Vemuri, A. and J. Peterson, "Session Initiation Protocol for
        Telephones (SIP-T): Context and Architectures", <a href="https://www.rfc-editor.org/bcp/bcp63">BCP 63</a>, <a href="./rfc3372">RFC</a>
        <a href="./rfc3372">3372</a>, September 2002.

   [<a id="ref-34">34</a>] Polk, J., "Internet Emergency Preparedness (IEPREP) Telephony
        Topology Terminology", <a href="./rfc3523">RFC 3523</a>, April 2003.

   [<a id="ref-35">35</a>] Carlberg, K. and R. Atkinson, "General Requirements for
        Emergency Telecommunication Service (ETS)", <a href="./rfc3689">RFC 3689</a>, February
        2004.

   [<a id="ref-36">36</a>] Carlberg, K. and R. Atkinson, "IP Telephony Requirements for
        Emergency Telecommunication Service (ETS)", <a href="./rfc3690">RFC 3690</a>, February
        2004.

   [<a id="ref-37">37</a>] Meyers, D., "Some Thoughts on CoS and Backbone Networks"
        <a href="http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf">http://www.ietf.org/proceedings/02nov/slides/ieprep-4.pdf</a> IETF
        Presentation: IEPREP, Dec, 2002.

   [<a id="ref-38">38</a>] Huston, G., "Commentary on Inter-Domain Routing in the
        Internet", <a href="./rfc3221">RFC 3221</a>, December 2001.

   [<a id="ref-39">39</a>] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
        Norrman, "The Secure Real-time Transport Protocol (SRTP)", <a href="./rfc3711">RFC</a>
        <a href="./rfc3711">3711</a>, March 2004.

   [<a id="ref-40">40</a>] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J.,
        Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
        Expedited Forwarding PHB (Per-Hop Behavior)", <a href="./rfc3246">RFC 3246</a>, March
        2002.

   [<a id="ref-41">41</a>] ITU, "Gateway Control Protocol", Version 3, ITU, September,
        2005.

   [<a id="ref-42">42</a>] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B., and
        J. Segers, "Megaco Protocol version 0.8", <a href="./rfc2885">RFC 2885</a>, August 2000.

   [<a id="ref-43">43</a>] Taylor, T., "Megaco Errata", <a href="./rfc2886">RFC 2886</a>, August 2000.









<span class="grey">Carlberg, et al.             Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


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
   emergency-related communication within the context of IP telephony.
   We also use GETS as a helpful model from which to draw experience.
   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 within the UK.  The lines are divided into Categories 1, 2, and
   3.  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-gapping for a given Category.  The authority to activate GTPS
   has been extended to either a central or delegated authority.

<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>.  GTPS and the Framework Document</span>

   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.

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 <a href="#section-1.1.1">Section 1.1.1</a>, the ANSI T1S1 group has previously defined a label
   in the 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 snapshot 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.




<span class="grey">Carlberg, et al.             Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


<span class="h3"><a class="selflink" id="appendix-B.1" href="#appendix-B.1">B.1</a>.  Study Group 16 (ITU)</span>

   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 [<a href="#ref-31" title="&quot;Service Class Designations for H.323 Calls&quot;">31</a>] 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
   transported via the Resource Priority field for SIP [<a href="#ref-14" title="&quot;Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)&quot;">14</a>].

   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
   PriorityClassGenericData.  The PriorityClassInfo of the
   PriorityClassGenericData contains the Priority and Priority Extension
   fields.

   At present, 4 levels have been defined for the Priority Value part of
   the Priority Class parameter: 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:

      CALL-PRIORITY {itu-t(0) recommendation(0) h(8) 460 4 version1(0)}
      DEFINITIONS AUTOMATIC TAGS::=

      BEGIN
      IMPORTS
         ClearToken,
         CryptoToken
          FROM H235-SECURITY-MESSAGES;

      CallPriorityInfo::= SEQUENCE
      {
        priorityValue  CHOICE
         {
           emergencyAuthorized     NULL,
           emergencyPublic         NULL,
           high                    NULL,
           normal                  NULL,
           ...
         },

        priorityExtension   INTEGER (0..255)  OPTIONAL,



<span class="grey">Carlberg, et al.             Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


        tokens              SEQUENCE OF ClearToken       OPTIONAL,
        cryptoTokens        SEQUENCE OF CryptoToken    OPTIONAL,
        rejectReason        CHOICE
        {
            priorityUnavailable         NULL,
            priorityUnauthorized        NULL,
            priorityValueUnknown        NULL,
            ...
        } OPTIONAL,        -- Only used in CallPriorityConfirm
        ...
      }

   The advantage of 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.

Acknowledgements

   The authors would like to acknowledge the helpful comments, opinions,
   and clarifications of Stu Goldman, James Polk, Dennis Berg, Ran
   Atkinson 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.



























<span class="grey">Carlberg, et al.             Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


Authors' Addresses

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

   EMail: k.carlberg@cs.ucl.ac.uk


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

   EMail: I.Brown@cs.ucl.ac.uk


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

   EMail: BeardC@umkc.edu




















<span class="grey">Carlberg, et al.             Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc4190">RFC 4190</a>                 IP Telephony Framework            November 2005</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

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

Acknowledgement

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







Carlberg, et al.             Informational                     [Page 28]
</pre>