Network Working Group K. Carlberg
I. Brown
Internet Draft
<draft-carlberg-ieps-framework-00.txt> University
College
London
11/00
Framework for Supporting IEPS in IP Telephony
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 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
Carlberg & Brown Expires May,2001 1
Framework for Supporting IEPS in IP Telephony Nov,2000
document. These, models, coupled with an example of an existing
service in the PSTN, contribute to a constrained solution space.
1. Introduction
The Internet has become the primary target for worldwide
communications. This is 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, 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 measure
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, one was now able to achieve specific measures
of QoS for an end-to-end flow of traffic traversing an IP network.
In this case, our reference to a flow is one that is granular in
definition and applying to specific application sessions.
From a deployment perspective (as of the date of this document),
int-serv has been predominantly constrained to 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 ISPs and possibly some inter-domain paths, but it seems
unlikely that the original vision of end-to-end int-serv between
hosts in source and destination stub domains will become a reality
in the near future (the mid- to far-term is a subject for others to
contemplate).
In 1998, the IETF produced [8], which presented an architecture for
Differentiated Services (diff-serv). This effort focused on a more
aggregated perspective and classification of packets than that of
[2]. This is accomplished with the recent specification of the
diff-serv field in the IP header (in the case of IPv4, it replaced
Carlberg & Brown Expires May,2001 2
Framework for Supporting IEPS in IP Telephony Nov,2000
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 for 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
sensitive traffic like Voice over IP (VoIP). Specifically, we
refer to the discussion of a framework to support VoIP using MPLS
[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.2 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).
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 carriers backbone network, or into the Internet as
a whole, implies the 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
Carlberg & Brown Expires May,2001 3
Framework for Supporting IEPS in IP Telephony Nov,2000
which are attributed to national boundaries and accessible by the
general public. Outside of this exists emergency telephone
services that involved authorized usage, as described in the
following subsection.
1.2.1 Government Emergency Telecommunications Service (GETS)
GETS is an emergency telecommunications service available in the
U.S. and established by the National Communications System (NCS) --
an office established by the White House under an executive order.
Unlike "911", it is only accessible by authorized individuals. The
majority of these individuals are from various government agencies
like the Department of Transportation, NASA, the Department of
Defense, and the Federal Emergency Management Agency (to name but a
few). 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., congestion) on the U.S. Public Switched Telephone
Network by the general public.
The key aspect is that GETS only supports a probabilistic approach
to call completion, as opposed to call preemption. This
distinction is important because under U.S. law, emergency systems
like GETS are not allowed to terminate existing calls in order to
allow a GETS call to be established. Thus, the mechanisms and
specifications that comprise GETS only focus on increasing the
chances that a particular telephone call will be established.
The basis for GETS with respect to Signaling System 7 (SS7) support
is found in the T1.619 protocol on High Probability of Completion
(HPC) network capability [13]. This document describes the
specification of a National Security and Emergency Preparedness
(NS/EP) code point used for SS7 ISDN User Part (ISUP) Initial
Address Message (IAM). Together with this code point, Local
Exchange Carriers (LEC) increase the time out period for call
establishment in the hopes of increasing the chances that a circuit
will be freed and thus be made available for a GETS call. If
necessary (and if the ability is supported), the LEC will attempt
to forward the call through alternate inter-exchange carriers (IXC)
if it cannot complete the call through the default IXC.
The procedure for a user (i.e., a person) establishing a GETS call
is as follows:
Carlberg & Brown Expires May,2001 4
Framework for Supporting IEPS in IP Telephony Nov,2000
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
originated) attempts to establish the call through an IXC that it
has arbitrarily chosen. This is done 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
forward 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 and priority 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 established
between the U.S. Government and various telco carriers. Thus, the
default end-to-end service for establishing a GETS call can be
viewed as best effort and associated with the same priority as
calls from the general public. The exception to this rule is when
the call is forwarded through carriers that have been contracted to
support HPC, which results in a higher probability that the GETS
call will be established.
1.2.2 International Emergency Preparedness Scheme (IEPS)
[18] is a recent ITU standard that describes emergency related
communications over international telephone service. While systems
like GETS are national in scope, IEPS acts as an extension to local
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 to be accomplished are to be specified in future ITU
document(s).
Carlberg & Brown Expires May,2001 5
Framework for Supporting IEPS in IP Telephony Nov,2000
1.3 Scope of this Document
The scope of this document centers on the 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 we assume 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.
As an example of the distinction is when the Redundant Audio Tool
(RAT) [14] begins sending VoIP packets to a unicast (or multicast)
destination. RAT does not use an 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.
Beyond this, part of our motivation in writing this document is to
provide a reference point for ISPs and carriers so that they have
an understanding of objectives and accompanying function
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 capabilities of existing emergency voice
service currently available in the PSTN to that of IP and the
Internet. If nothing else, intrinsic differences between the two
communications architectures precludes this from happening. Note,
this does not prevent us from borrowing design concepts or
objectives from existing systems.
Section 2 presents several primary objectives that articulate what
is considered important in supporting 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 scenarios in IEPS can be deployed over IP
networks. These are not all-inclusive scenarios, nor are they the
only ones that can be articulated. However, they do show cases
Carlberg & Brown Expires May,2001 6
Framework for Supporting IEPS in IP Telephony Nov,2000
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 capability 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
existing 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 a proprietary IP network, or the
Internet, involves operational issues. Examples of this would be
the establishment of Service Level Agreements (SLA) with Internet
Service Providers (ISP), and/or the provisioning 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
communication system (as described in section 1.2.1) as well as the
existing restrictions and constraints placed by some countries. In
the former case, we do not attempt to mimic the system, but rather
extract information as a reference model. With respect to
constraints based 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 denominator in specifying technical functional requirements.
If such constraints 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 May,2001 7
Framework for Supporting IEPS in IP Telephony Nov,2000
The following list of objectives are termed primary because they
pertain to that which defines the underlying goals of IEPS in
relation to IP telephony. However, the primary objectives are not
meant to dictate major overhauls of existing IP protocols, nor do
they require 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 objective 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
3 through 5 below help us to qualify the term probability in the
context of other objectives.
The second objective involves the interaction of IP telephony
signaling with existing PSTN support for emergency related voice
communications. As mentioned above in Section 1.2, standard T1.613
specifies code points for SS7. Specifically, the National Security
and Emergency Preparedness (NS/EP) code point is defined for ISUP
IAM messages used by SS7. Hence, our objective in the interaction
between the PSTN and IP telephony with respect to IEPS is a direct
mapping between directly 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
agreements relating to IEPS are adhered. Note that we do not
assume that the actions taken to distinguish IEPS type packets is
Carlberg & Brown Expires May,2001 8
Framework for Supporting IEPS in IP Telephony Nov,2000
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.
At an abstract level, the forth 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
reasons: 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
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
description of two distinct scenarios of IP telephony and its
operation with IEPS and the PSTN.
It is important mention that this is a default objective influenced
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
advantageous 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 ubiquitous support, we feel the reliance of such
a requirement would doom even the contemplation of supporting IEPS
Carlberg & Brown Expires May,2001 9
Framework for Supporting IEPS in IP Telephony Nov,2000
by the IETF and the expected entities (e.g., ISPs) involved in its
deployment.
We use the existing GETS service in the U.S. as an existing example
in which emergency related communications does not need to be
ubiquitous. As mentioned previously, the measure and amount of
support provided by the U.S. PSTN for GETS is not ubiquitous across
all U.S. Inter-exchange Carriers (IXC) nor Local Exchange Carriers
(LEC). 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
services outlined in this framework. GETS users are authenticated
using a PIN provided to the telecommunications carrier, which
signals approval back to the user's local exchange over SS7. In an
IP network, the authentication center will need to securely signal
back to the IP ingress point that a given user is authorized for
the NS/EP diffserv codepoint. 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 consider the use of SIP's security functions to
aid this objective.
3. Value Added Objectives
These are objectives that are viewed as being helpful in achieving
a high probability of call completion. It is expected that their
realization within an IP network would be in the form of new
protocols or major 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.
The value added objectives are:
1) Alternate Path Routing
2) IEPS Domain Discovery
Carlberg & Brown Expires May,2001 10
Framework for Supporting IEPS in IP Telephony Nov,2000
The first 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 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 making use of noncongested alternate paths. We use the
term "minimal form" to concede the fact that care must be taken in
how the system provides an alternate paths so it does not
significantly contribute to the congestion that is to be avoided
(e.g., via excess control/discovery messages).
The second item above stems from one of the primary objectives that
precludes the need for ubiquitous support for IEPS. Thus, given
that we assume only a subset of transit ISPs will be contracted to
support IEPS, it stands to reason that it would be beneficial to
have networks/domains discover the nearest domain that supports
IEPS, and in turn forward IEPS telephony messages in that
direction.
4. Functional Requirements
In this section, we take the objectives presented above and specify
a 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 as separate
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
Carlberg & Brown Expires May,2001 11
Framework for Supporting IEPS in IP Telephony Nov,2000
4.1 Signaling
SIP
Signaling is further divided into two perspectives. The first is
application level signaling. We focus our attention on the Session
Initiation Protocol (SIP), since it is viewed as being used by
applications like IP telephony. Currently, SIP has an existing
"priority" field that distinguishes different types of sessions.
The five currently defined values are: "emergency", "urgent",
"normal", "non-urgent", "other-priority".
We propose the addition of a new value for this field titled
"authorized-emergency". This new value is used to denote an
emergency-related session that has been initiated by an authorized
user. In particular, we distinguish this value from the existing
"emergency" value, which could be attributed to emergency sessions
from the general public (e.g., a "911" call).
It is important to note that this is the one functional requirement
that is considered mandatory with respect to supporting IEPS within
IP telephony. We take this position because regardless of the
extent by which the underlying network supports IEPS-based traffic,
there is a need to distinguish IEPS sessions from others.
The existence of this new value in the SIP priority field allows an
IP telephony domain to map the NS/EP code point from an SS7
telephony domain. 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.
Author's Note: We do not make reference to the current Polk draft
[16] and its advocacy of expanding the SIP priority field to
include values attributed to Multi-Level Precedence and Preemption.
However, if that document were to be advanced, we could satisfy
our requirement of adding an "authorized-emergency" value with
minimal changes to the Polk draft. Specifically, by make
"preemption" a local and optional administrative issue, and adding
to the values specified in [16].
Diff-Serv
In accordance to [16] , the differentiated services code point
(DSCP) field is divided into 3 sets of values. The first set are
assigned by IANA. Within this set, there are currently, three
Carlberg & Brown Expires May,2001 12
Framework for Supporting IEPS in IP Telephony Nov,2000
types of Per Hop Behaviors have been specified: Default
(correlating 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 local or experimental use, but may later be reassigned to
IANNA in case the first set has been completely assigned.
We recommend the specification of a new type of PHB referred to as
Emergency Related Forwarding (ERF). This provides a means of
distinguishing emergency related traffic (signaling and user data)
from other traffic. The existence of this PHB then provides a
baseline by which specific code points may be defined related to
various emergency related traffic: authorized emergency sessions
(e.g., IEPS), general public emergency calls (e.g., "911"), etc.
Authors note: It is probable that this section may be contentious
given the advocacy of a new PHB group. Hence, this section may
require additional input and refinement.
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 producing 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
Carlberg & Brown Expires May,2001 13
Framework for Supporting IEPS in IP Telephony Nov,2000
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.
A potentially complimentary work in progress can be found in [9],
which articulates a framework for Voice over MPLS. We cite the
draft only as a point of reference, with the idea that it may be
augmented to reflect labeled path(s) dedicated to different values
in the SIP priority field -- such as those pertaining to
emergencies. But of more significance, [9] presents a specific
framework for traffic engineering support of toll quality (i.e., a
particular grade of service) IP telephony.
Note: As a point of reference, existing SLAs established by the NCS
for GETS service tend to focus on a maximum allocation of 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 cal 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
diffuse 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 support 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
Carlberg & Brown Expires May,2001 14
Framework for Supporting IEPS in IP Telephony Nov,2000
the flow has IEPS priority. The carrier's traffic engineering
measures than attempt to provide a higher probability of call
completion to that flow. 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 endpoint 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
security 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 originating 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 security functions.
When a call originates from an IP device, the ingress network may
authorize IEPS traffic over that link as part of its user
authentication 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 network 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
Carlberg & Brown Expires May,2001 15
Framework for Supporting IEPS in IP Telephony Nov,2000
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 dominate form of voice communication.
There are two scenarios that we use as a model for determining our
objectives and subsequent functional requirements. These being:
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
connected 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 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.
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 no problem of retaining toll quality Grade of
Carlberg & Brown Expires May,2001 16
Framework for Supporting IEPS in IP Telephony Nov,2000
Service as the voice traffic (data and signaling) exists 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, is the default scope of
security. We do not claim that the reliance of a PIN based
security system is highly reliable 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.
Multiple IP Administrative Domains
----------------------------------
We view the scenario of multiple IP administrative domains as a
superset of the previous scenario. Specifically, we retain the
notion that the IP telephony system peers with the existing PSTN.
In addition, segments (i.e., portions of the Internet) may exchange
signaling with other IP administrative domains via non-PSTN
signaling protocols like SIP.
Legacy Next Generation Next Generation
Carrier Carrier Carrier
******* *************** **************
* * * * * *
SW<--->SW <-----> SG <---IP---> SG <--IP--> SG <---IP---> SG
* * (SS7) * (SIP) * (SIP) * (SIP) *
******* *************** **************
SW - Telco Switch
SG - Signaling Gateway
Figure 2
Carlberg & Brown Expires May,2001 17
Framework for Supporting IEPS in IP Telephony Nov,2000
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
emergency related traffic from other types of traffic. In
addition, IP security becomes more important between domains in
order help ensure that the act of distinguishing IEPS-type traffic
is indeed valid for the given source.
8. Security Considerations
Information related to this area have been presented in sections 2
and 4.
9. 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
Progress, July 2000.
7 Wang, L, et. al., "RSVP Refresh Overhead Reduction by State
Compression", Internet Draft, Work In Progress, March 2000.
8 Blake, S., et. al., "An Architecture for Differentiated
Service", Proposed Standard, RFC 2475, Dec. 1998.
Carlberg & Brown Expires May,2001 18
Framework for Supporting IEPS in IP Telephony Nov,2000
9 Kankkunen, A., et. al., "VoIP over MPLS Framework_, Internet
Draft, Work In Progress, July 2000.
10 Sharma, V., et. al., "Framework for MPLS-based Recovery",
Internet Draft, Work In Progress, September 2000.
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., "SIP Precedence mapping to MLPP Interworking",
Internet Draft, Work In Progress, March, 2000.
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.
Carlberg & Brown Expires May,2001 19
10. Acknowledgments
To be done_
11. Author's Addresses
Ken Carlberg
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
Ian Brown
University College London
Department of Computer Science
Gower Street
London, WC1E 6BT
United Kingdom
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 the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing 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.
Carlberg & Brown Expires May,2001 20
Framework for Supporting IEPS in IP Telephony Nov,2000
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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PRUPOSE.
Carlberg & Brown Expires May,2001 21