[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-carlberg-ieprep-framework) 00 01 02 03 04 05 06 07 08 09 10 RFC 4190

Internet Engineering Task Force                    Ken Carlberg
INTERNET DRAFT                                     Ian Brown
May 14, 2002                                       UCL



             Framework for Supporting IEPS in IP Telephony
                  <draft-ietf-ieprep-framework-01.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 International
   Emergency Preparedness Scheme (IEPS), should be realized within
   today's IP architecture and service models.  From these objectives,
   we present a corresponding set of functional requirements, 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 PSTN, contribute to a constrained solution space.




Carlberg & Brown         Expires November 14, 2002              [Page 1]

Internet Draft               IEPS Framework                 May 14, 2002


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 control load (bandwidth bounds)
   and guaranteed service (bandwidth & 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 refer-
   ence 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 stub 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 sub-
   ject 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
   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



Carlberg & Brown         Expires November 14, 2002              [Page 2]

Internet Draft               IEPS Framework                 May 14, 2002


   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 the work in progress discussion of Proposed MPLS/DiffServ
   Traffic Engineering Class Types [9], and the inclusion of fault
   tolerance [10].  This latter item can be viewed as being similar to
   "crank-back", a term used to describe the means by which the Public
   Switched Telephone Network (PSTN) routes around congested switches.


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 and how it should be supported.
   Given the emergence of IP telephony, a natural inclusion of it as
   part of a telco carrier's backbone network, or into the Internet as a
   whole, implies the ability to support existing emergency related ser-
   vices.  Typically, one associates emergency calls with "911" tele-
   phone service in the U.S., or "999" in the U.K. -- both of which are
   attributed to national boundaries and accessible by the general pub-
   lic.  Outside of this exists emergency telephone services that
   involved authorized usage, as described in the following subsection.


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].  Unlike
   "911", it is only accessible by authorized individuals.  The majority
   of these individuals are from various government agencies like the



Carlberg & Brown         Expires November 14, 2002              [Page 3]

Internet Draft               IEPS Framework                 May 14, 2002


   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 (telecom-
   munications companies, utilities, etc.) that are involved in criti-
   cial infrastructure 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 government agency 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., conges-
   tion) on the U.S. Public Switched Telephone Network by the general
   public.

   The key aspect of GETS is that it supports a probabilistic approach
   to call completion through priority, as opposed to guaranteed
   approach through preemption.  This distinction is important because
   emergency services like GETS are not allowed to tear down existing
   calls (i.e., seize resources) in order to establish a GETS call. 
   Instead, GETS increases the probability of call completion by provid-
   ing an additional label used in the contention for assignment of lim-
   ited resources required for the call.  Thus, the GETS features focus
   on increasing the probability that a particular telephone call will
   be established, but cannot guarantee call completion.

   GETS is supported by Signaling System 7 (SS7) via the T1.631 protocol
   on High Probability of Completion (HPC) network capability [13].
   This document describes the specification of a National Security and
   Emergency Preparedness (NS/EP) Calling Party Category (CPC) code
   point used for SS7 ISDN User Part (ISUP) Initial Address Message
   (IAM).  In the presence of this code point, when a GETS call
   encounters a restrictive network management control that has been
   activated to reduce traffic overload to a congested route, the Local
   Exchange Carriers (LECs) will provide the GETS call priority by
   exempting the call from this restriction.  After receiving the exemp-
   tion, if the GETS call finds all circuits busy in the route, the LEC
   will provide further priority by queuing the call for the next avail-
   able circuit. 

   The procedure for a user (i.e., a person) establishing a GETS call is
   as follows:

       1) Dial a non-geographical area code number: 710-XXX-XXXX
       2) Dial a PIN used to authenticate the call
       3) Dial the actual destination number to be reached

   In conjunction with the above, the source LEC (where the call ori-
   ginated) attempts to establish the call through an IXC.  This is done



Carlberg & Brown         Expires November 14, 2002              [Page 4]

Internet Draft               IEPS Framework                 May 14, 2002


   even if the destination number is within the LEC itself.  If the IXC
   cannot forward the call to the destination LEC, then the source LEC
   attempts to route the call through an alternate IXC.  If alternate
   IXCs cannot help establish the call, then a busy signal is finally
   returned to the user.  Otherwise, the call is completed and retains
   the same quality of service as all other telephone calls.

   The HPC component of GETS is not ubiquitously supported by the U.S.
   PSTN.  The only expectation is that the 710 area code is recognized
   by all carriers.  Additional support is conditional and dependent
   upon the equivalent Service Level Agreements (SLA) established
   between the U.S. Government and various telco carriers to support
   GETS.  Thus, the default end-to-end service for establishing a GETS
   call can be roughly viewed as best effort and associated with the
   same priority as calls from the general public.

   It should be noted from the above description that GETS is separate
   and unrelated to other emergency services like "911".


1.1.2.  International Emergency Preparedness Scheme (IEPS)

   [18] is a recent ITU standard that describes emergency related com-
   munications over international telephone service (Note, this document
   has also been published as a draft-RFC in [28]).  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 IEPS 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 estab-
   lish and maintain voice data traffic.  This explicit signaling capa-
   bility provides the hooks from which VoIP traffic can be bridged to
   the PSTN.

   An example of this distinction is when the Redundant Audio Tool (RAT)



Carlberg & Brown         Expires November 14, 2002              [Page 5]

Internet Draft               IEPS Framework                 May 14, 2002


   [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 arguement 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 other elastic applications.
   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 carriers so that they have an under-
   standing of objectives and accompanying functional requirements used
   to support IEPS related IP telephony traffic.  In addition, we also
   wish to provide a reference point for potential customers (users of
   IEPS) in order to constrain their expectations.  In particular, we
   wish to avoid any temptation of trying to replicate the exact capa-
   bilities 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 IEPS related IP telephony traffic.
   These objectives represent a generic set of goals and capabilities
   attributed to supporting IEPS based IP telephony.  Section 3 presents
   additional value added objectives.  These are capabilities that are
   viewed as useful, but not critical in support of IEPS.  Section 4
   presents a series of functional requirements that stem from the
   objectives articulated in section 2.  Finally, Section 5 presents two



Carlberg & Brown         Expires November 14, 2002              [Page 6]

Internet Draft               IEPS Framework                 May 14, 2002


   scenarios in IEPS 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.  However, they do
   show cases where some of the functional requirements 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 carriers with regard to dedicated links.


2.  Objective

   The support of IEPS within IP telephony can be realized in the form
   of several primary objectives.  These objectives define the generic
   functions or capabilities associated with IEPS, and the scope of the
   support needed to achieve these capabilities.  From this generic set
   of objectives, we present specific functional requirements of exist-
   ing IP protocols (presented below in section 3).

   There are two underlying goals in the selection of these objectives.
   One goal is to produce a design that maximizes the use of existing IP
   protocols and minimizes the set of additional specifications needed
   to support IP-telephony based IEPS.  Thus, with the inclusion of
   these minimal augmentations, the bulk of the work in achieving IEPS
   over an IP network that is connected or unconnected to the Internet
   involves operational issues.  Examples of this would be the estab-
   lishment of Service Level Agreements (SLA) with ISPs, and/or the pro-
   visioning of traffic engineered paths for IEPS-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 in section 1.1.1) as well as the exist-
   ing 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 con-
   straints based on laws or agency regulations, this would normally be
   considered outside of the scope of any IETF document.  However, these
   constraints act as a means of determining the lowest common denomina-
   tor in specifying technical functional requirements.  If such con-
   straints do not exist, then additional functions can be added to the
   baseline set of functions.  This last item will be expanded upon in
   the description of Objective #3 below.




Carlberg & Brown         Expires November 14, 2002              [Page 7]

Internet Draft               IEPS Framework                 May 14, 2002


   The following list of objectives are termed primary because they per-
   tain to that which defines the underlying goals of IEPS.  However,
   the primary objectives are not meant to dictate major overhauls of
   existing IP protocols, nor do they require completely new protocols
   to be developed.

   Primary Objectives in support of authorized emergency calls:

       1) High Probability of Call Completion
       2) Interaction with PSTN
       3) Distinction of IEPS 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) will be forwarded through an
   IP network.  Specifically, we envision the relevance of this objec-
   tive during times of congestion, the context of which we describe
   further 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 the network.  It stands to reason,
   though, that the word "probability" is a less tangible description
   that cannot be easily quantified.  It is relative in relation to
   other traffic transiting the same network.  Objectives 4 and 5 listed
   above help us to qualify the term probability in the context 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 in Section 1.2, standard T1.631 [26]
   specifies emergency code points for SS7.  Specifically, the National
   Security and Emergency Preparedness (NS/EP) Calling Party Category
   code point is defined for ISUP IAM messages used by SS7 [26].  Hence,
   our objective in the interaction between the PSTN and IP telephony
   with respect to IEPS (and national indicators) is a direct mapping
   between related code points.

   The third objective focuses on the ability to distinguish IEPS data
   packets from other types of VoIP packets.  With such an ability,
   transit providers can more easily ensure that service level agree-
   ments relating to IEPS are adhered to.  Note that we do not assume
   that the actions taken to distinguish IEPS type packets is easy.
   Nor, in this section, do we state the form of this distinction.  We
   simply present the objective of identifying flows that relate to IEPS
   versus others that traverse a transit network.



Carlberg & Brown         Expires November 14, 2002              [Page 8]

Internet Draft               IEPS Framework                 May 14, 2002


   At an abstract level, the fourth objective pertains to the actions
   taken when an IP telephony call, via a signaling protocol such as
   SIP, cannot be forwarded because the network is experiencing a form
   of congestion.  We state this in general terms because of two rea-
   sons: a) there may exist applications other than SIP, like H.248,
   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 to their configured limit. Congestion
   may also arise from resource allocation (i.e., QoS) attributed per
   call or aggregated sets of calls.  In this latter case, while there
   may exist resources to forward the packets, a signaling server may
   have reached its limit as to how many telephony calls it will support
   while retaining toll-quality service per call.  Typically, one terms
   this form of congestion as call blocking.  Note that we do not
   address the case when congestion occurs at the bit level below that
   of IP, due to the position that it is outside the scope of IP and the
   IETF.

   So, given the existence of congestion in its various forms, our
   objective is to support IEPS-related IP telephony call signaling and
   data traffic via non-preemptive actions taken by the network.  More
   specifically, we associate this objective in the context of IP
   telephony acting as part of the Public Telephone Network (PTN).
   This, as opposed 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 and its operation with
   IEPS and the PSTN.

   It is important to mention that this is a default objective influ-
   enced by existing laws & regulations.  Those countries not bound by
   these restrictions can remove this objective and make provisions to
   enforce preemptive action.  In this case, it would probably be advan-
   tageous to deploy a signaling system similar to that proposed in
   [15], wherein multiple levels of priority are defined and preemption
   via admission control from SIP servers is enforced.

   The fifth objective stipulates that we do not advocate the need or
   expectation for ubiquitous support of IEPS across all administrative
   domains of the Internet.  While it would be desirable to have ubiqui-
   tous support, we feel the reliance of such a requirement would doom
   even the contemplation of supporting IEPS by the IETF and the
   expected entities (e.g., ISPs and vendors) involved in its deploy-
   ment.

   We use the existing GETS service in the U.S. as an existing example
   in which emergency related communications does not need to be ubiqui-
   tous.  As mentioned previously, the measure and amount of support
   provided by the U.S. PSTN for GETS does not exist for all U.S. IXCs



Carlberg & Brown         Expires November 14, 2002              [Page 9]

Internet Draft               IEPS Framework                 May 14, 2002


   nor LECs.  Given the fact that GETS still works within this context,
   it is our objective to follow this deployment model such that we can
   accomplish the first objective listed above -- a higher probability
   of call completion than that of normal IP telephony call traffic.

   Our final objective is that only authorized users may use the ser-
   vices outlined in this framework.  GETS users are authenticated using
   a PIN provided to the telecommunications 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 a given user is authorized to send
   IEPS related flows.  Similarly, transit networks with IEPS SLAs must
   securely interchange authorized IEPS traffic.  In both cases, IPSec
   authentication transforms may be used to protect this traffic.  This
   is entirely separate from end-to-end IPSec protection of user
   traffic, which will be configured by users.  IP-PSTN gateways must
   also be able to securely signal IEPS authorization for a given flow.
   As these gateways are likely to act as SIP servers, we further con-
   sider the use of SIP's security functions to aid this objective.


3.  Value Added Objective

   This objective is viewed as being helpful in achieving a high proba-
   bility of call completion.  Its realization within an IP network
   would be in the form of new protocols or enhancements to existing
   ones.  Thus, objectives listed in this section are treated as value
   added -- an expectation that their existence would be beneficial, and
   yet not viewed as critical to support IEPS related IP telephony
   traffic.


3.1.  Alternate Path Routing

   This objective 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 requirements 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 call completion of IEPS traffic by mak-
   ing 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 it does not significantly contribute to
   the congestion that is to be avoided (e.g., via excess
   control/discovery messages).



Carlberg & Brown         Expires November 14, 2002             [Page 10]

Internet Draft               IEPS Framework                 May 14, 2002


   At the time that this document was written, we can identify two
   work-in-progress areas in the IETF that can be helpful in providing
   alternate paths for call signaling.  The first is [10], which is
   focused on network layer routing and describes 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 [19] has been published as an RFC which describes the
   discovery and exchange of IP telephony gateway routing tables between
   providers.  The TRIP protocol [22], a supplemental work in progress,
   specifies application level telephony routing regardless of the sig-
   naling protocol being used (e.g., SIP or H.323).  TRIP is modeled
   after BGP-4 and advertises reachability and attributes of destina-
   tions.  In its current form, several attributes have already been
   defined, such as LocalPreference and MultiExitDisc.  Upon standardi-
   zation of TRIP, additional attributes can be registered with IANA.
   Initially, we would recommend two additional attributes that would
   relate to emergency related flows.  These being:


      EmergencyMultiExitDisc

        The EmergencyMultiExitDisc attribute is similar to the
        MultiExitDisc in that it is an inter-domain attribute used
        to express a preference of one or more links over others
        between domains.  Unlike the MultiExitDisc, this attribute
        specifically identifies links that are preferred for emergency
        related calls that span domains.

      EmergencyLocalPreference

        The EmergencyLocalPreference attribute is similar to the
        LocalPreference in that it is an intra-domain attribute used
        to inform other LSs of the local LSs preference for a given
        route.  The difference between the two types attributes is
        that the preferred route specifically relates to emergency-type
        calls (e.g., 911).  This attribute has no significance between
        domains.  Local policy determines if there is an association
        between the EmergencyLocalPreference and the
        EmergencyMultiExitDisc attribute.







Carlberg & Brown         Expires November 14, 2002             [Page 11]

Internet Draft               IEPS Framework                 May 14, 2002


3.2.  End-to-End Fault Tolerance

   This topic involves the work that has been done in trying 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 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% 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 network.  This
   makes an arguement that the act of protection against loss has con-
   tributed to additional pressures leading to congestion, which in turn
   helps trigger packet loss.  In addition, in 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 origi-
   nal data packet is followed by one or more redundant packets.  At
   first glance, this would appear to be even less friendly to the net-
   work 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 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 of a redundant
   audio application can be found in [14].  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 com-
   munications.  Hence, these topics are placed under the category of
   value added objectives.


4.  Functional Requirements

   In this section, we take the objectives presented above and specify a



Carlberg & Brown         Expires November 14, 2002             [Page 12]

Internet Draft               IEPS Framework                 May 14, 2002


   corresponding set of functional requirements to achieve them.  Given
   that the objectives are predominantly atomic in nature, the
   corresponding functional requirements are to be viewed separately
   with no specific dependency upon each other as a whole.  They may be
   complimentary with each other, but there is no need for all to exist
   given different scenarios of operation, and that IEPS support is not
   viewed as a ubiquitously available service.  We divide the functional
   requirements into 4 areas:

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


4.1.  Signaling

   Signaling is used to convey various information to either intermedi-
   ate 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 potential augmentations to
   different types of signaling and state information to help support
   the distinction of 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] is a work in progress that defines a new header field for SIP
   known as the Resource Priority Header.  This new header field is
   meant to provide an additional measure of distinction that can influ-
   ence the behavior of gateways and SIP proxies.  The structure of the
   field is in the form of a NameSpace.Priority.  The "NameSpace" pro-
   vides a reference point by which the "Priority" values correspond to.
   In the example of the Defence Switched Network (DSN) namespace, six



Carlberg & Brown         Expires November 14, 2002             [Page 13]

Internet Draft               IEPS Framework                 May 14, 2002


   ordered priority values correlating to Multi-Level Priority & Prefer-
   ence (MLPP) [21] are defined.  Each of the defined values for the DSN
   NameSpace have a specific relation or priority to each other.  How-
   ever, the specific actions enacted on the value, and their relation-
   ship to other NameSpaces are subject to policies and SLAs.  We expand
   on the subject of policies below in section 4.2.

   Additional namespaces and value(s) would be registered with IANA. It
   would be our intention to follow the approach taken in [15] and
   register a new namespace attributed to IEPS.  Unlike [15], we would
   define a single value (e.g., "authorized-emergency") that would
   correspond to the NS/EP code point of SS7.  This will help facilitate
   a seamless interaction between the PSTN and the an IP network acting
   as either an internal backbone or as a peering ISP.

   Note #1: The work put forth by Polk in [34], which describes an
   architecture for MLPP, is similar to the subject of IEPS in the sense
   that both aim at distinguishing certain VoIP flows from others.  How-
   ever, MLPP and IEPS are not the same efforts.  One critical differ-
   ence is that MLPP involves the use of preemption, while the default
   model for IEPS is simply an increase in the probability of call com-
   pletion.

   Note #2: The term "Priority" has been a subject of strong debate.  In
   this document, we reference the term based on the terminology inher-
   ited from other drafts and documents, such as can be found in [15],
   and the Megaco RFC [23].  However, our focus is aimed at using the
   "priority" value as simply a label by which we distinguish one set of
   flows from another.


4.1.2.  Diff-Serv

   In accordance with [16], 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
   to best effort forwarding), Assured Forwarding, and Expedited For-
   warding.  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 in
   case the first set has been completely assigned.

   One candidate recomendation involves the specification of a new type
   of Per-Hop Behavior (PHB).  This would provide a specific means of
   distinguishing emergency related traffic (signaling and user data)
   from other traffic.  The existence of this PHB then provides a base-
   line by which specific code points may be defined related to various



Carlberg & Brown         Expires November 14, 2002             [Page 14]

Internet Draft               IEPS Framework                 May 14, 2002


   emergency related traffic: authorized emergency sessions (e.g.,
   IEPS), general public emergency calls (e.g., "911"), MLPP.  Aggre-
   gates would still exist with respect to the bundling of applications
   per code point.  Further, one would associate a forwarding paradigm
   aimed at a low loss rate reflective of the code point selected.  The
   new PHB could be in the form of a one or more code points that dupli-
   cate EF-type traffic characteristics.  Policies would determine IF a
   measure of importance exists per EF-type code-point.

   A potential issue that could be addressed by a 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 traffic engineering would be applied to avoid
   congestion of EF queues at internal/core merge points stemming from
   flows originating from different ingress nodes of the 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 PHB that has more than one code point to identify EF-
   type traffic may address congestion by associating a drop precedence
   for certain types 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.

   Another candidate recomendation would be to define a new or fifth
   class for the existing AF PHB.  Unlike the other currently defined
   classes, this new one would be based on five levels of drop pre-
   cedence.  This increase in the number of levels would conveniently
   correlate to the the levels of MLPP, which has five types of priori-
   ties.  The five levels would also correlate to a recent effort in the
   Study Group 11 of the ITU to define 5 levels for Emergency Telecom-
   munications Service (ETS).  Beyond these other standardization
   efforts, the 5 levels would provide a higher level of variance that
   could be used to supercede the existing 3 levels used in the other
   classes.  Hence, if other non-emergency aggregate traffic were
   assigned to the new class, the highest drop precedence they are
   assigned to is (3) -- corresponding to the other four currently
   defined classes.  Emergency traffic would be set to (4) or (5),
   depending on the SLA tht has been defined.

   It is important to note that as of the time that this document was
   written, the IETF is taking a conservative approach in specifying new
   PHBs.  This is because the number of code points that can be defined
   is relatively small, and thus 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 ini-
   tially recommend using the Assured Forwarding (AF) PHB [20] for dis-
   tinguishing emergency traffic from other types of flows.  At a



Carlberg & Brown         Expires November 14, 2002             [Page 15]

Internet Draft               IEPS Framework                 May 14, 2002


   minimum, AF would be used for the different SIP call signaling mes-
   sages.  If EF 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.

   It is critical to note that one cannot specify an exact code point
   used for emergency related data flows because the relevance of a code
   point is local to the given diff-serv domain (i.e., they are not glo-
   bally unique per micro-flow or aggregate of flows).  In addition, we
   can expect that the existence of a codepoint for emergency related
   flows is based on the service level agreements established with a
   given diff-serv domain.


4.1.3.  RTP

   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 are
   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 -- typically representing a specific form of application
   media.  The designers of RTP also assumed an underlying network pro-
   viding 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, presents new environments where RTP traffic may
   be forwarded over networks that support better than best effort ser-
   vice.  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 emer-
   gencies 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 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 have three choices in defining a persistent marking of data
   packets and thus avoid the transitory marking of diff-serv code
   points.  We can propose a new PHB dedicated for emergency type
   traffic as discussed in 4.1.2.  We can propose a specification of a
   new shim layer protocol at some location above IP.  Or, we 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



Carlberg & Brown         Expires November 14, 2002             [Page 16]

Internet Draft               IEPS Framework                 May 14, 2002


   amount 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) work-
   ing group of augmenting RTP so that it can carry a marking that dis-
   tinguishes emergency-related traffic from that which is not.  Specif-
   ically, one would define a new extention that contains a "classifier"
   field indicating the condition associated 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 payloads that it encapsulates.
   However, the AVT group has expressed a rough consensus that placing
   additional classifier state in the RTP header to denote the impor-
   tance of one flow over another is not an approach that wish to
   advance.  Objections ranging from relying on SIP to convey importance
   of a flow, as well as the possibility of adversely affecting header
   compression, were expressed.  There was also the general feeling that
   the extension header for RTP should not be used for RTP packet of a
   flow.

   Author's note: There was some debate as to whether to keep the above
   subsection concerning RTP in this document.  We have decided to
   retain it because it is felt that information concerning directions
   that should NOT be taken to support IEPS is important to the commun-
   ity at large.



4.1.4.  MEGACO/H.248

   The Media Gateway Control protocol (MEGACO) [23] defines the 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 changes of RFC 2886 (Megaco Errata) to the text of
   RFC 2885 (Megaco Protocol version 0.8).

   In [23], 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.

   The protocol does not specify individual values for priority.  We
   also do not recommend the definition of a well known value for the
   MEGAGO priority.  Any values set should be a function of any SLAs
   that have been established regarding the handling of emergency



Carlberg & Brown         Expires November 14, 2002             [Page 17]

Internet Draft               IEPS Framework                 May 14, 2002


   traffic.  In addition, given that priority values denote precedence
   (according to the Megaco protocol), then by default the IEPS data
   flows should probably receive the same priority as other non-
   emergency calls.  This approach follows the objective of not relying
   on preemption as the default treatment of emergency-related.


4.2.  Policy

   One of the objectives listed in section 3 above is to treat IEPS-
   signaling, and related data traffic, as non-preemptive in nature.
   Further, that 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 pro-
   ducing a baseline function to be supported; in our case, a default
   policy for non-preemptive call establishment of IEPS 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 [17].  There is no requirement as to how policy is
   accomplished.  Instead, if a domain follows actions outside of the
   default non-preemptive action of IEPS-related communication, then we
   stipulate a functional requirement that some type of policy mechanism
   is in place to satisfy the local policies of an SLA established for
   IEPS type traffic.


4.3.  Traffic Engineering

   In those cases where a network operates under the constraints of
   SLAs, one or more of which pertains to IEPS based traffic, it can be
   expected that some form of traffic engineering is applied to the
   operation of the network.  We make no requirements as to which type
   of traffic engineering mechanism is used, but that such a system
   exists and can distinguish and support IEPS signaling and data
   traffic.




Carlberg & Brown         Expires November 14, 2002             [Page 18]

Internet Draft               IEPS Framework                 May 14, 2002


   MPLS is generally the first protocol that comes to mind when the sub-
   ject of traffic engineering is brought up.  This notion is hightened
   concerning the subject of IP telephony because of MPLS's ability to
   to permit a quasi circuit switching capability to be superimposed on
   the current Internet routing model [33].

   However, having cited MPLS, we need to stress that it is an intra-
   domain 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.

   Note: As a point of reference, existing SLAs established by the NCS
   for GETS service tend to focus on a maximum allocation of (e.g., 1%)
   of calls allowed to be established through a given LEC using HPC.
   Once this limit is reached, all other GETS calls experience the same
   probably of call completion as the general public.  It is expected,
   and encouraged, that IEPS related SLAs will have a limit with respect
   to the amount of traffic distinguished as being emergency related,
   and initiated by an authorized user.


4.4.  Security

   As IEPS support moves from intra-domain PSTN and IP networks to dif-
   fuse inter-domain pure IP, authenticated service becomes more complex
   to provide.  Where an IEPS call is carried from PSTN to PSTN via one
   carrier's backbone IP network, very little IP-specific security sup-
   port is required.  The user authenticates herself as usual to the
   network using a PIN.  The gateway from her PSTN connection into the
   backbone IP network must be able to signal that the flow has IEPS
   priority.  Conversely, the gateway back into the PSTN must similarly
   signal the call's higher priority. A secure link between the gateways
   may be set up using IPSec or SIP security functionality. If the end-
   point is an IP device on the carrier's network, the link may be set
   up securely from the ingress gateway to the end device.

   As flows traverse more than one IP network, domains whose peering
   agreements include IEPS support must have means to securely signal a
   given flow's IEPS status. They may choose to use physical link secu-
   rity and/or IPSec authentication, combined with traffic conditioning
   measures to limit the amount of IEPS traffic that may pass between
   the two domains. The inter-domain agreement may require the originat-
   ing network to take responsibility for ensuring only authorized
   traffic is marked with IEPS priority; the downstream domain may still
   perform redundant conditioning to prevent the propagation of theft
   and denial of service attacks.  Security may be provided between
   ingress and egress gateways or IP endpoints using IPSec or SIP secu-
   rity functions.



Carlberg & Brown         Expires November 14, 2002             [Page 19]

Internet Draft               IEPS Framework                 May 14, 2002


   When a call originates from an IP device, the ingress network may
   authorize IEPS traffic over that link as part of its user authentica-
   tion procedures without necessarily communicating with a central IEPS
   authentication center as happens with POTS-originated calls. These
   authentication procedures may occur at the link or network layers,
   but are entirely at the discretion of the ingress network. That net-
   work must decide how often it should update its list of authorized
   IEPS users based on the bounds it is prepared to accept on traffic
   from recently-revoked users.


5.  Key Scenarios

   There are various scenarios in which IP telephony can be realized,
   each of which can infer 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.

   There are two scenarios that we use as a model for determining our
   objectives and subsequent functional requirements.  These are:



   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 carriers.  One is the legacy
   carrier, whose infrastructure retains the classic switching architec-
   ture attributed to the PSTN.  The other is the next generation car-
   rier, which uses a data network (e.g., IP) as its core infrastruc-
   ture, 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.




Carlberg & Brown         Expires November 14, 2002             [Page 20]

Internet Draft               IEPS Framework                 May 14, 2002


     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 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 sig-
   naling with other IP administrative domains via non-PSTN signaling
   protocols like SIP.



     Legacy           Next Generation            Next Generation



Carlberg & Brown         Expires November 14, 2002             [Page 21]

Internet Draft               IEPS Framework                 May 14, 2002


     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
   IEPS 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 IEPS-type traffic is indeed valid for
   the given source.



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)
      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  Gai, S., et. al., "RSVP Proxy", Internet Draft, Work in



Carlberg & Brown         Expires November 14, 2002             [Page 22]

Internet Draft               IEPS Framework                 May 14, 2002


      Progress, July 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  Ash, J., et. al., "Proposed MPLS/DiffServ TE Class Types", Inter-
   net
      Draft, Work In Progress, Nov 2001.

   10 Farrel, A., et. al., "Fault Tolerance for LDP and CR-LDP",
      Internet Draft, Work In Progress, October 2001.

   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) _ High Probability of
      Completion (HPC) Network Capability_, ANSI T1.631, 1993.

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

   15 Polk, J., Schulzrinne, H, "SIP Communications Resource Priority
      Header", Internet Draft, Work In Progress, December, 2001.

   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.

   18 ITU, "International Emergency Preparedness Scheme", ITU
      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.



Carlberg & Brown         Expires November 14, 2002             [Page 23]

Internet Draft               IEPS Framework                 May 14, 2002


   22 Rosenburg, J, et. al, "Telephony Routing over IP (TRIP)", Internet
      Draft, Work In Progress, April 2001.

   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 Folts, H., "Description of an International Emergency Preference
      Scheme (IEPS) ITU-T Recommendation  E.106 (Formerly CCITT
      Recomendation), Internet Draft, Work In Progress, February 2001

   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.

   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 Draft
      Recommendation H.GEF.4, September, 2001







Carlberg & Brown         Expires November 14, 2002             [Page 24]

Internet Draft               IEPS Framework                 May 14, 2002


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

   This framework document uses U.S. GETS as a target model for defining
   a framework for supporting authorized emergency related communication
   within the context of IP telephony.  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 (author-
   ized 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).
   This service was introduced in the 1950's at a time when loss of
   power to the PSTN due to war or natural disaster was of prime con-
   cern.  If a loss of power did occur, it was felt that the critical
   issue was to take action to limit phone usage by the general public
   so that power would be conserved for use by critical personnel
   involved in an emergency.

   The design and implementation of GTPS focused on the ability of the
   U.K.  PSTN to withdraw outgoing telephone service from the majority
   of the general public.  Inbound calls can still be received, but the
   net effect of the action is that power for the phone line service is
   conserved.  It can probably be argued that power loss is not as
   important an issue today as it was back in the 50's.  And in fact
   Oftel, the U.K. regulatory authority, is planning an evolutionary
   change to GTPS so that it reflects current needs and requirements for
   supporting emergency communications through the U.K. PSTN -- such as
   congestion, and the ability to provide roaming authorized access like
   that of GETS.

   At present, all local exchange access points (ie, phones) are divided
   into three categories:

     1: Time of War: people that are involved in operations and planning
          of a war or war conditions
     2: Natural Disaster: individuals that are involved in recovery and
          operations associated with natural disasters.
     3: General Public: people that are not associated with categories
          1 and 2, which is essentially over 99% of the population.


   Unlike the roaming ability of GETS users, GTPS associates preference
   with an originating phone.  This simplifies the process of determin-
   ing who is allowed outbound phone service, but it is also quite res-
   trictive in its usage.  Hence, individuals that want preferential
   service must use the phone that has been designated as Category 1 or
   2.  Note: for the general public, pay phones have been designated as
   Category 2 so that 999 (emergency calls to fire or police) can be



Carlberg & Brown         Expires November 14, 2002             [Page 25]

Internet Draft               IEPS Framework                 May 14, 2002


   made.

   In 1984, an updated version of GTPS was made available following the
   deregulation of the U.K. phone system.  In this new scheme, local
   exchanges retained the three category system while inter-exchange
   calls use call-gaping.  Priority marks, via C7/NUP, would bypass the
   call-gaping.  The authority to activate GTPS was also extended to the
   46 Constables (i.e., local police chiefs) of the U.K. -- each being
   responsible for their own jurisdiction.



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.  In the case of GTPS, one simply
   needs to define a new NameSpace that will define values for each of
   its three Categories of users.  These new labels will then allow a
   more transparant interoperation between IP telephony using SIP and
   the U.K. PSTN that supports GTPS.

   Restricting outbound call establishment within the context of IP
   telephony and SIP servers is a policy issue.  Service Level Agree-
   ments, presumably under the guidance or direction of local laws and
   regulations would determine the characteristics of the policy.



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 IEPS framework document
   because it simply generates a requirement to define and register with
   IANA a new NameSpace in the Resource-Priority header of SIP.




Carlberg & Brown         Expires November 14, 2002             [Page 26]

Internet Draft               IEPS Framework                 May 14, 2002


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 draft contribution [35] has been introduced into this group that
   would add a Priority Class parameter to the call establishment mes-
   sages of H.323.  This class is further divided into two parts; one
   for Priority Value and the other is a Priority Extension for indicat-
   ing subclasses.  It is this former part that roughly corresponds to
   the labels 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.

   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.




Carlberg & Brown         Expires November 14, 2002             [Page 27]

Internet Draft               IEPS Framework                 May 14, 2002


9.2.  Study Group 11 (ITU)

   To Be Done...




9.3.  T1S1 (ANSI)

   To Be Done...




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.



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


















Carlberg & Brown         Expires November 14, 2002             [Page 28]

Internet Draft               IEPS Framework                 May 14, 2002





                          Table of Contents



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


Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, 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



Carlberg & Brown         Expires November 14, 2002             [Page 29]

Internet Draft               IEPS Framework                 May 14, 2002


   the copyright notice or references to the Internet Society or other
   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 PRUPOSE.




































Carlberg & Brown         Expires November 14, 2002             [Page 30]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/